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