Занималась тут оптимизацией чужого запроса. И вот вроде бы знаешь базу и хочешь её применить, но оптимизатор всегда оказывается хитрее 🙂

Среди прочего, пыталась применить одно из главных правил оптимизации — predicate pushdown. Это когда мы поднимаем условия фильтрации как можно выше, чтобы заранее уменьшить объем данных. Так вот, вынесла в cte фильтрацию одной таблички (~2GB), а в другом cte уже шла работа с отфильтрованными данными — джойны и тп. Смотрю в план запроса и вижу фигу, что снежок (snowflake) всё равно сначала сканирует таблицу целиком, затем джойнит, и только после этого фильтрует 😵 причём аналогичный сценарий на другой, но бОльшей таблице (~в 8GB) отрабатывает как надо 🥲 Видимо, размер данных или внутренняя статистика влияют на решения cost-based оптимизатора.

Никаких инсайтов в этой заметке вам не дам, но в очередной раз убеждаюсь: важно уметь читать (и понимать) планы запросов и анализировать query profile. Не всегда логичные на первый взгляд шаги оптимизации работают как ожидается. И не только от СУБД к СУБД поведение может разительно отличаться, но и даже в рамках таблиц в одном хранилище. Экспериментируйте и тестируйте на реальных данных 🤖

P.S. Тем, кто хочет использовать для анализа планов гпт, всё же советую сначала самостоятельно научиться их читать, т.к. LLM всё ещё склонны к галлюцинациям. Как говорится: "на ИИ надейся, да сам не плошай".

#sql #snowflake

Как-то в одной из моих команд появился коллега, который крайне негативно относился к GIT в DE-практиках, считая это никому не нужным усложнением 👀 и "вообще я привык один работать".

Git — это распределённая система контроля версий (VCS), которая позволяет отслеживать изменения в файлах и совместно работать над проектами.

Помню, тогда меня это сильно удивило, так как всегда считала использование гита стандартом де-факто в любой разработке. Да что уж там говорить – даже при написании документации он пригождается. Когда только начинала работать SA, я даже онлайн-митап проводила для наших аналитиков — объясняла, зачем им гит в контексте написания sql-скриптов и как им пользоваться.

С тех пор, конечно, много воды утекло. Но хочется напомнить и здесь, что владение гитом – это, действительно, важный навык, который вам пригодится в реальной работе, а не просто собесы проходить. Даже если вдруг вы работаете в одиночку, git всё равно будет вашим другом. Откатиться к рабочей версии после неудачного эксперимента? Легко. Посмотреть, что вы меняли в SQL-скрипте три месяца назад? (ну это на тот случай, если вы не любитель писать доки). Без проблем. А уж когда дело доходит до командной работы — тут вообще без вариантов. В общем, если вы ещё не пользовались гитом, пора восполнить пробелы в знаниях.

Пока я очень не спешно пишу заметки в блоге 🐈, более продуктивные ребята пилят полезный контент. Например, инженерообязанный Владимир записал отличное видео, где рассказывает про гит на пальцах. Для работы этой базы более чем достаточно, а чего будет не хватать — уж нагуглите спросите у гопоты в процессе.

Не реклама, рекомендация от души)

Меня дико бесят недокументированные данные! 🤬 А это, увы, встречается слишком часто. Злит, что пункт "документация" не входит в неотъемлемую часть разработки какого-либо продукта. И вот ты подцепляешься к базе какого-то нового используемого сервиса и видишь просто кучу табличек с 100+ столбцами без какого-либо намёка какие данные там лежат. Особенно "приятно", когда нет возможности пощупать сам сервис и поэкспериментировать с данными в UI. Садишься и пытаешься описать (читай — сделать чужую работу) всё это богатство, опираясь только на свою логику и здравый смысл.

Часто бывает, что задачи на интеграцию прилетают asap, и кажется, что тебе нужно просто загрузить данные, а там уж аналитики разберутся. Но терпеть не могу, когда в моём хранилище что-то лежит без описания 👿 поэтому в любом случае стараюсь заполнить метаданные по максимуму. Да, это занимает дополнительное время, но зато потом не приходится каждый раз заново разбираться в структуре и объяснять коллегам, что означает загадочное поле "fl_xyz_2".

Понимаю, что разработчики работают в условиях жёстких дедлайнов, но отсутствие доков — это техдолг, который рано или поздно аукнется. А сейчас, когда все активно используют ИИ, хорошие=правильные описания становятся ещё важнее, тем более когда мы говорим о сложных продуктах и запутанных взаимосвязях. Без доков даже самый умный ИИ будет строить уверенные предположения, которые чаще всего окажутся ошибочными. Опять же, разработчикам в эпоху ИИ накидать описания к полям и таблицам при наличии ТЗ к проекту и доступом к коду — вполне реально и быстро. Но пока это мне приходится использовать ИИ в паре с анализом, логикой и гаданием на кофейной гуще.

Когда-то я хотела стать техписом именно из-за того, что мне нравится всё описывать и структурировать, но решила, что совсем без технарской работы будет скучно 💻 а теперь совмещаю и то, и другое.

А вас какие боли при работе с данными? 🙃

Work-life balance или как проходит это лето

В последние пару недель встречаю очень много постов про то, как лето проходит мимо, и вспоминаю свои такие же периоды в жизни. Но в этом году моё лето настолько в стиле life, что balance совсем не соблюдается 🤫 Весна выдалась горячей и я решила выдохнуть и никуда не спешить, наслаждаясь моментами жизни (ведь мы за этим с вами растём и работаем, правда?).

Моё замедление пришло через совершенно неожиданные вещи. Зимой мы переехали в квартиру побольше и к лету я решила чуть оживить балкон зеленью, а в итоге всерьез увлеклась комнатными растениями. Теперь каждое утро начинается с чашечки кофе и обхода владений 🪴 поливы, пересадки, изучение грунтов и горшков – миллион информации из совершенно другого мира. Вместе с этим и вся жизнь как будто замедлилась. Бэклог личных дел растёт, но крокодил не ловится, не растёт кокос.

Много лет я жила в страхе "не успеть" и с желанием "бежать-развиваться", чтобы догнать ребят из инфо-поля. Казалось, что если остановишься хоть на день — и всё, отстанешь навсегда. Но чем больше ты развиваешься, тем больше растёт и развивается твоё инфо-поле, и этой гонке нет конца. Мне кажется, что это путь к выгоранию, насколько бы интересно тебе не было.

Хотя, конечно, и у замедлания есть обратная сторона. Во-первых, к размеренности слишком легко привыкнуть и вот уже мозг начинает лениться и тяжелее въезжает даже в обычные рутинные процессы. Появляются ошибки, сама грешна. А во-вторых, порой из замедления сложно выйти без встряски. Но лично у меня чаще всего бывает наоборот. Наступает момент, когда устаёшь от размеренности и с новыми силами "врываешься" в любимые активные дела. И, как будто бы, жизнь показывает: позволяя себе перерывы, в итоге мы становимся только продуктивнее. В конце концов, что такое пара месяцев в рамках множества рабочих лет?

А как проходит ваше лето? Боитесь отстать от IT-гонки или позволяете себе отдых?

#life