В тему "отсутствия энергии". На днях пожаловалась тренеру, что "твой спорт лишает меня последних сил" 😈 (у меня с детства тяжелые отношения со спортом, но здоровья для теперь стараюсь заниматься регулярно).

А потом пошла и сдала анализы, по которым у меня оказался латентный дефицит железа (в числе прочего). Перед тренером пришлось извиниться 😬 а самой пойти в аптеку, да записаться к врачу.

К чему это всё. Когда вам кажется, что у вас нет сил — причина может быть физической.

Не забывайте делать регулярные чекапы и берегите себя.

#life

🎄🎄🎄 не забудьте начать новый год с качественного отдыха 😇

Всем весёлых праздников и хорошего настроения ✨👍✨

Эти праздники слишком длинные и, если вы не знаете чем заняться и что посмотреть, рекомендую не бежать к успешному-успеху, а отдохнуть и залипнуть в новый сериал от создателя «Во все тяжкие» — Pluribus (на ру «Одна из многих»). Мы посмотрели ещё до праздников на одном дыхании. Это микс научной фантастики, хоррора, роуд-муви и драмы с элементами черного юмора. А для тех, кто работает с данными, есть отдельный бонус — сериал буквально для нас. Ну, в каком-то смысле 😅

Итак, почему да. Когда то Винс Гиллиган заставил меня переживать за учителя химии, варящего мет ☠️ поэтому вопрос смотреть или нет не стоял)

Завязка звучит как типичный зомби-апокалипсис: странный космический сигнал и выведенный на его основе вирус, молниеносно поразивший человечество. А вот дальше начинается странное, заражённые не торопятся превращаться в монстров. Они становятся.. счастливыми. Прямо невыносимо, до приторности счастливыми. И добрыми. А ещё ужасно эффективными. Все они объединяются в коллективный разум, тут же прекращают войны и попутно пытаются решить экологические проблемы.

Но, естественно, заразились все, да не все. Главная героиня — ворчливая писательница с иммунитетом к вирусу. Единственный хмурый человек в море улыбающихся лиц. И вот тут начинается самое вкусное: смотришь и не понимаешь, а кто здесь злодей. Всеобщее счастье, которое отнимает твоё «я» или упрямая тётка, которая портит всем кайф? Играет её Рэа Сихорн — Ким из «Лучше звоните Солу». Гиллиган писал эту роль специально для неё, и она здесь просто огонь 🔥

Ещё меня зацепил темп. Здесь нет экшена, это медленное и вдумчивое кино. В нём много тишины, деталей и долгих сцен. На мой взгляд для праздничного залипания на диване как раз то, что нужно.

При этом я люблю, когда сериал не даёт готовых ответов. А поразмышлять здесь есть о чём.

Например, я вижу в этом сериале аллегорию на полномасштабное и стремительное внедрение ИИ в нашу жизнь. Заражённые реагируют на просьбы как будто гпт отвечает на наши с вами промты. Они вежливые, услужливые, знают о тебе всё (так как память-то общая) и искренне хотят «решить твой запрос» на счастье. Спойлер: даже если для этого придётся стереть твою личность.

А ещё было особенно забавно ловить параллели. Коллективный разум собирает в себя воспоминания всех поглощённых людей — это же настоящее хранилище данных с единым источником правды, на основе которой он генерит «правильные» ответы и даже идеальных собеседников под предпочтения конкретного человека. Мир в сериале — это человечество после нормализации: эффективное, оптимизированное, усреднённое, не содержащее никаких выбросов и аномалий. Только вот аномалии — это и есть живые люди со своей индивидуальностью.

В общем, рекомендую 🚀

#life

Первый рабочий день: вспоминаем Git за 2 минуты

Пишешь в терминале git stahs... и понимаешь, что руки что-то помнят, а вот голова пока не очень? 😅

Знакомо? Тогда вот быстрая разминка для тех, кто работает с dbt, airflow или просто хранит SQL-скрипты в репозитории (а если не держите, то это знак начать).

6 полезных git-команд на каждый день:
🔵 git stash / git stash pop
Позволяет временно «отложить» незакоммиченные изменения, переключиться на другую ветку (например, если нужен срочный хотфикс, а коммитить незаконченный код не хочется), а потом вернуть всё обратно через pop. Главное потом не забыть, что и зачем спрятал (тут поможет `git stash list`).

🔵 git commit --amend
Позволяет изменить последний коммит, например, исправить сообщение или добавить забытые файлы. При этом старый коммит заменяется новым — в истории ветки останется один коммит вместо двух. Важно: если коммит уже запушен, после amend понадобится git push --force

🔵 git log --oneline --graph
Выводит историю коммитов в компактном виде с визуализацией веток. Помогает быстро понять, что вообще происходит в репо, когда возвращаешься после перерыва.

🔵 git reflog
История всех действий, даже после reset. Если случилась ситуация "я что-то нажал и оно исчезло" — вам сюда.

🔵 git switch / git restore
Современная замена старому доброму checkout. switch используется для веток, а restore для файлов, так у нас меньше путаницы.

🔵 git diff --staged
Показывает, что именно уйдёт в коммит. Полезно проверить перед тем, как нажимать enter 🤝

Типичный сценарий с stash:

# пилишь фичу, вдруг в чате: "прод лежит, нужны срочные правки!"
git stash -u -m "new feature" # прячем незаконченное
git switch -c hotfix-branch # переключаемся на хотфикс
# ..фиксим баг, коммитим, пушим...
git switch feature-branch # возвращаемся к фиче
git stash pop # достаём отложенные изменения
# продолжаем как ни в чём не бывало

А что вы забыли после длинных выходных?

#git

Ну что, ребят, как работается после праздников? 😵

Раньше SQL-разработчики жили без оконных функций. Как они выживали 👀? Натолкнулась тут на задачку и хочу с вами её разобрать.

Условие простое: есть таблица с одним столбцом Element (значения A, B, C, D, E, F), нужно добавить колонку ID с числами от 1 до 6. Выглядит просто - пишем ROW_NUMBER() OVER (ORDER BY element) или RANK() .. и идём пить кофе. Но есть нюанс, использование окошек запрещено, у нас на руках только базовый SQL.

Такие задачки любят давать на собеседованиях, потому что они проверяют не знание синтаксиса, а понимание того, как вообще работает SQL под капотом.

А решение на самом деле простое: идея в том, чтобы соединить таблицу саму с собой и для каждого элемента посчитать, сколько элементов идут до него (включая его самого):

SELECT 
    t1.element,
    COUNT(t2.element) AS id
FROM elements t1
JOIN elements t2 
  ON t1.element >= t2.element
GROUP BY t1.element
ORDER BY id;

Логика такая: для A условию >= A удовлетворяет только сам A, поэтому COUNT = 1. Для B подходят A и B, поэтому COUNT = 2. И так далее.

Ещё один вариант оформления через коррелированный подзапрос (не надо так делать в проде!):

SELECT 
    element,
    (SELECT COUNT(*) FROM elements t2 WHERE t2.element <= t1.element) AS id
FROM elements t1
ORDER BY element;

Подводные камни о которых часто забывают:
Во-первых, без ORDER BY результат недетерминирован — в SQL нет «естественного порядка» строк, это фундамент реляционной теории.
Во-вторых, если в реальных данных будут дубликаты, вы получите одинаковые номера, причем это будет похоже не на чистый RANK, а со сдвигом. А чтобы получить логику DENSE_RANK, придётся использовать COUNT(DISTINCT t2.element).
В-третьих, производительность O(n²) — на больших таблицах это будет очень больно 👾.

Проверьте, self-join работает в 10–25 раз медленнее, чем ROW_NUMBER(). Поэтому в проде для таких задач используем оконные функции. А вот для понимания механики и для собеседований такое решение самое то (но не забываем упомянуть о моментах выше).

А вы встречали подобные задачи на интервью? Какое решение предложили бы?

#sql

Заканчивается вторая рабочая неделя, а я всё ещё ощущаю себя примерно так 🫠 Вот так разгрузила голову в праздники 😬

Работаю сейчас над исправлением большой чужой мешанины из кода витрины (в перерывах между asap-задачами), которую не успела доделать в декабре. Вам знакомо это чувство, когда открываешь скрипт и первые минут пятнадцать просто пытаешься понять, что тут происходит и почему оно вообще работает? А потом ещё минут двадцать, почему оно НЕ работает.
Спасает только одно: в декабре, разбирая этот код, я всё документировала, каждую правку и всякие "а, вот почему тут так" или "а это тут зачем?". Сейчас читаю эти записи и благодарю себя 🙏

Так что вот вам пятничный совет: если сегодня бросаете задачу на полпути, потратьте пять минут и запишите, где остановились и что думали. В понедельник скажете себе спасибо 😉

Хороших выходных! Как вы — уже 🚀 или пока 🐢?

#life

0.012% викинга

Давно увлекаюсь генеалогией, и как-то решила сдать ДНК-тест. Захотелось понять, откуда у меня способности кайфовать как от идеально поднявшегося бисквита, так и от часов ковыряния в legacy без потери веры в человечество. Когда открыла результат, почувствовала себя как тот мужик из моей любимой рекламы. Он тоже сдал ДНК-тест и узнал, что на 0.012% викинг. От счастья он хватает меч, вздымает его к небу и рычит так, что сам Один его услышал. И да, спойлер: где-то в глубине веков мои предки по прадеду тоже скандинавы.

Так вот. Ноль целых ноль-ноль-двенадцать процента — ведь это даже не погрешность, по сути это пыль на весах. Но мужик теперь точно ВИКИНГ и попробуй ему это оспорь 😈

И тут ловлю себя на мысли: так мы же с данными часто делаем ровно то же самое. Конверсия выросла на 0.3%? Круто, A/B-тест успешен, катим фичу в прод, пока никто не спросил про статистическую значимость. Метрика чуть дрогнула после релиза? О, корреляция есть, значит точно наша заслуга, презентуем руководству. Выборка из тридцати человек? Да ладно, тренд же виден невооружённым глазом. А то, что через неделю всё вернётся к прежним значениям... ну, это уже будет другой спринт и другие графики. DQ проверка упала? Ну, наверное, порог был слишком строгий для этого источника, ослабим немного и всё позеленеет 👻

Данные-то не врут. А вот мы иногда приходим к ним с готовым ответом и сами ищем, за что зацепиться 😏

Признавайтесь, у кого тоже просыпался внутренний викинг при виде нужной цифры в отчёте? 😉

#life

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

Потому что между "у нас есть данные" и "у нас есть полезный график" лежит бездна, в которой живут не только падающая Kafka и коллега, который решил "чуть поэкспериментиовать" в юпитере. Там ещё обитает легаси-код без документации, написанный людьми, которые давно ушли из компании, и теперь никто не знает, почему в запросе WHERE status != 3. Там API-источник, у которого нет нормальных ключей для отслеживания изменений, зато есть лимиты на запросы и любовь к внезапной смене формата ответа. Там "временный костыль" 2016 года, который теперь стал почему-то критическим компонентом системы 👍 И там же рядом источник, который молча поменял схему данных, потому что "а мы не знали, что вы это используете".

Самое смешное, что к этому хаосу даже привыкаешь. И когда всё вдруг работает без инцидентов, начинаешь нервничать, что может что-то сломалось и просто алерты не дошли? У нас, к слову, на этот случай приходит утренняя отбивка: All done! все процессы отработали, данные обновлены, за ночь ничего не упало. Без неё я бы, наверное, не могла спокойно пить утренний кофе 😅

А у вас какая любимая "мозоль" в мире данных?

Дисциплина, конечно, прошла мимо меня 😄 в черновиках 1000 и 1 пост, но ни один из них не дописан на уверенные 100% и, соответственно, не запощен.

С развитием ИИ и обилием информации всё чаще ловлю экзистенциальный кризис... и всё никак не могу перестать спорить с собой. Ведь вся инфа и инструменты максимально доступны, гпт тебе расскажет и подскажет. Ну кому нужен ещё один пост про мой любимый NULL? Но если подумать с другой стороны, информации стало так много, что найти среди неё живой голос, а не очередную выжимку из документации, уже отдельная задача. И если мой иногда оказывается таким — значит всё не зря. Здорово, если какой-то из постов окажется для кого-то той самой точкой, от которой захочется двигаться дальше.

Убедила ли я себя? Честно? Не особо 😀 Но пишу, да и долги по книжным конспектам пора отдавать. Так что.. поехали 🚀

P.S. в тему дисциплины вспомнилось, как много лет играла за дисциплин-приста в WoW, хилила в рейдах как боженька и не знала печали 😅

Знаете, какая фраза чаще всего дорого обходится компании? "Работает — и ладно" 🥂

Результат есть, да и дашборд вроде выводит корректные данные, какие-то dq проверки отбегали — ну красота же. Но где-то в это время система сканирует 300+ столбцов вместо трёх, разворачивает пятнадцать условий LIKE там, где справилось бы одно регулярное выражение, и три раза читает одну и ту же таблицу, потому что так написалось и на маленьком семпле данных работало шустро. В облаке всё это превращается в чёрную дыру, куда буквально улетают деньги — каждое лишнее сканирование, каждое вычисление прямо в условии JOIN, каждый ненужный DISTINCT тихо утекают кредитами. С on-premise примерно та же история, только счёт приходит очередями, перегруженным сервером и дашбордами, которые "ну грузятся долго, но это норм, мы привыкли".

Спойлер: это не норм 🙂

Сейчас ещё популярна идея, что можно особо не заморачиваться — оптимизатор же умный, а уж ИИ и подавно напишет нормальный производительный код, только вопрос правильно сформулируй. Отчасти это правда (пока у вас запросы на 25 строк). Но понимать, что происходит внутри системы в момент выполнения запроса, всё равно нужно — хотя бы для того, чтобы оценить, что тебе написали, и не тащить в прод красиво выглядящий, но дорогой запрос.

Поэтому оптимизация, за которую я регулярно топлю — это не занудство и не перфекционизм, а базовое понимание механики. Именно оно позволяет не просто писать SQL, а понимать, чего это стоит системе.

А вы доверяете ИИ писать запросы в прод — или всё-таки смотрите, что там внутри? 👀

#sql #dwh

Этот мем — точная копия одного рабочего дня, который я, кажется, прожила уже раз двести 😄

Прилетает задача от аналитика: перевести в прод витрину из песочницы. Звучит невинно, ровно до тех пор пока не откроешь sql-файл и не увидишь там две тысячи строк кода без единого комментария, документации и даже намёка на то, зачем здесь этот хитрый self-join и почему применён именно этот фильтр.

Начинаешь погружаться в чужую логику, разбираться, строить гипотезы, проверять, вносить правки (потому что не учли особенности некоторых данных), документировать 👀 но тут прилетает правка поверх старого кода: "Юль, я тут кое-что поправил, берём в работу этот вариант". Потом вторая... потом кто-то выше вообще меняет концепцию, и оказывается, что половину сделанного надо откатить (Галя, у нас отмена!). А ты к этому моменту уже не очень помнишь, с чего вообще начинала, потому что в процессе три раза переписала логику агрегации (спасибо git, который помнит за тебя, конечно).

Самое смешное, что это не история про плохих людей или злой умысел. Аналитики у нас классные, просто бизнес слишком активно меняется и задач много)

Поэтому в таких задачках половина работы это не SQL, а детективное расследование чужих намерений (иногда своих собственных, что ещё веселее 🙃).

А сколько строк было в вашей самой страшной витрине из песочницы?

#work

Борьба с ветряными мельницами
Думаю, многим из вас уже набили оскомину разговоры об ИИ. Мне бы тоже хотелось написать про что угодно другое, но сложно не поныть 🥲

Нанотехнологии не могли не доехать до рабочих процессов. "А зачем нам вобще (подставь любую должность), если любой может сделать его работу с ИИ?". В итоге мы получаем нейродашборды (к чёрту BI), которые тянут нейроданные из не нейроисточников (да, порой вот так напрямую, ибо зачем тратить время на это ваше dwh), отражающие действительность под тем углом, который нужен тому, кто писал промт. Самое главное не забывать о приставке "нейро", тогда результату 100% можно доверять 🤡 Главное, что компания на острие технологий! Доказать (не)уместность не представляется возможным.

При этом логика в такой картине мира живёт не в архитектурных процессах, а в чьём-то промте, который через полгода никто не найдёт и не вспомнит, почему он вообще так написан. Этому явлению уже даже название придумали - rule debt. По сути техдолг решений за которые потом некому отвечать.

Отдельный кайф (нет), когда от далеких от кода людей прилетает навайбкоженный sql-скрипт на 1200 строк, который просят по-быстрому оптимизировать 😝🤪

Как мне кажется, дальше будет хуже, ведь новые специалисты растут уже без понимания зачем нужны знания, если можно всё в ииху закинуть. Если что, я не адепт "раньше не гуглили", но проверяя домашки своих студентов магистратуры я ожидаемо встречаю на 100% ИИ ответы с вставками "Хотите, я объясню этот шаг подробнее или приведу дополнительные примеры?" без попыток думать. Сначала даже пыталась с этим бороться, но битву я ожидаемо проиграла (понять и простить, это мой первый наивный опыт большого преподавания). Несмотря на то, что мои студенты взрослые люди, часто сами оплачивающие своё дорогое обучение, они как будто из мира, где кажется, что главное - это "бумажка" (спойлер, всем пофигу), а не навыки. И верят, что в остальном зарешает ИИ. Печально, что без базовых знаний они даже не смогут понять, где ИИ им наврал 😑 А может, я как бабка уже ворчу, и студенты испокон веков списывали, тем не менее мы все живы?)

Содной стороны хочется посмотреть, когда всё таки упадёт этот колосс на глиняных ногах. А с другой стороны - бросить всё и "уехать на ферму" 🙄

Всё ещё считаю llm и агентов на их основе классными инструментами. Но только в руках тех, кто понимает что делает, зачем это делает, задаёт правильные вопросы и представляет как это всё будет жить, масштабироваться и поддерживаться дальше.

А пока улыбаемся и машем 🐈

#work

Продолжая тему тех самых SQL-скриптов на 1200 строк, хочу напомнить одну важную вещь, которая касается вообще любого кода.

Когда пишешь код, всегда помни, что потом его ещё кому-то читать, менять и поддерживать.

Иногда открываешь чужой запрос и первая мысль: "лучше бы он вообще не работал". Потому что разобраться в нём сложнее, чем написать заново 🤪

Понятные названия CTE и алиасов, разбиение сложной логики на логичные этапы, единый стиль оформления, комментарии там, где действительно есть неочевидная бизнес-логика - всё это не делает код быстрее! Зато делает его гораздо проще для чтения и поддержки 😉

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

Хороший пример таких соглашений давно существует. Например, SQL Style Guide от Simon Holywell. Да, можно бесконечно спорить, писать ключевые слова в UPPERCASE или lowercase, ставить запятые в начале или в конце строки, выравнивать ли JOIN и ON. Но гораздо важнее, чтобы внутри команды был единый и удобный для всех стиль оформления кода.

То же самое касается комментариев. Не стоит комментировать очевидное. Если код ищет максимум, комментарий "получаем максимум" никому не поможет. А вот объяснить, почему здесь именно такой фильтр или откуда взялось это бизнес-правило нужно.

Код пишется один раз, а читается десятки. Поэтому хороший код - это тот, который понимаешь не только ты 👽

#sql