Pythonic Cursor и литература

Когда-то в очень далекой галакти.. просто очень давно (лет 6-7 назад) я попал на собеседование на инженера данных в VK. Это было время, когда у них внутри никто и подумать не мог про яндекс балалайки, все мучали... рассказывали про свою самописную бд и свой PHP. И буквально за пару недель до собеса вышла статья про то, как они написали свой rate limiter для вставки данных в Clickhouse. И вот весь час собеседования мой интервьювер пытался выжать из меня идеальную реализацию лимитера на python (сразу скажу, что безуспешно :). И вот именно с тех пор я понял, что, во-первых, такие штуки не так просты, и ,во-вторых, не надо изобретать велосипеды и стоит брать уже готовые библиотеки для вашего языка.

Перемещаемся в наше время. Мне для какой-то очень простой апишки надо ограничить отправку данных в нее с нашей стороны - то есть добавить этот самый rate limiter. Скучная работа - добавить зависимостей, поменять 1 строчку в коде и накинуть тестов. А что у нас есть для скучной работы? Cursor! Хей, Cursor, добавь rate limiter вот тут для requests.post с ограничением в 100 запросов в секунду и сделай под этот функционал тестов. Было странно видеть, что в этом же файле появился новый класс с своей самописной реализацией лимитера (да еще и бажной). Если кто не знает, то есть обертка requests-ratelimiter, с которой вместо Session из requests просто используем LimiterSession. Поправили и забыли.

Но вот что кажется забавным - в python и правда очень любят писать свои велосипеды. Язык настолько простой, то прямо располагает к этому. Зачем читать чужую библиотеку, когда я и сам могу написать не хуже (вспоминая собес, ну, после 5 итерации наверное). Если llm натренирована на той куче кода в гитхабе, то и выдает она вполне Pythonic решение :)

А к чему это фото, подумаете вы? Просто для прочистки мозгов и улучшения вашего python кода очень советую почитать (а может даже и пописать) код на golang. Мне коллега как-то сказал, что мой код на python теперь напоминает гошку - и в принципе, я это считаю за комплимент :)

А у вас на прикроватной тумбочке что есть интересного? :)

DE больше не нужны

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

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

Начиная с какого-то уровня люди внутри компании (заказчики, бизнес) становятся более требовательными к качеству продуктов (визуал бордов, скорость и надежность поставки) - и вот появляется история с специализацией. На картинке не хватает еще BI инженера с BI аналитиком :)

Скорость доставки снижается, часть проблем утопает на стыках специалистов, но все становится красиво и качественно.

И вот тут каждая компания начинает ловить баланс - сколько кого им надо, в зависимости от потребностей, баланса, эго руководителей.

Дальше я вижу проблему в триаде аналитик данных - аналитик-инженер - инженер данных. Эти три роли примерно про одно и тоже, но стоят последовательно на спектре задач от технички до бизнеса. И при этом имеют два ограничения - домен данных и отсутствие масштабирования результатов труда. То есть в голову больше ограниченного объема бизнеса не получить, и витринки под каждого заказчика становятся все глубже и детальней. Техничка для инженеров не является никаким ограничением - ну камон, научиться использовать партиции в спарке, джойнить по ключам в постгрессе, использовать файнал в кликхаузе, ну не большая же наука?

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

Ну а если хочется остаться в техничке - это путь в платформенные команды или чистую разработку (как те же мл-ребята).

PS перечитал и увидел, что не раскрыл историю с бигтехами. Быть повелителями yml != инженером данных. Очень странно слышать про то, как угнетающе писать ямлы в Т, озоне и еще где-то, но при этом не мочь сказать ни слова про бизнес домен, в котором работаешь. В чем тогда состоит работа? Быть живым курсором?..

PPS никогда не работал в бигтехах :) и вообще сегодня пятница

Вот такой подарок привезли :)

Интересная штука. Я все гадал, что же может весить почти 2 килограмма :)

Любовь к переопределению стандартных настроек

Не знаю с чем связано непреодолимое желание определить свои настройки и забивать на стандартные практики в индустрии. Дам два примера:

* Apache Paimon и его ишью. Кратко: ваши желания в hdfs-site.xml - это ваши проблемы, а писать файлы мы всегда будем с фактором репликации 1. Доросли до версии 1.3, но исправление есть только в мастере.
* dbt-starrocks и его настройки адаптера по умолчанию. Что вы там на уровне кластера задали - ваши проблемы, все новые модели мы будем сохранять с фактором репликации 1.

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

ODBC и Qlik Sense

Почти во всех своих выступлениях я топил за то, что на StarRocks легко мигрировать за счет стандартных MySQL драйверов. Все системы подключили, формально все работало хорошо с хорошими размерами данных. Но мы начали массово переносить приложения в клике на данные из ср и получили непонятные проблемы :(

Загрузка данных возвращает пустой датасет - 0 строк. Запрос проходит успешно, на стороне клика ошибок нет. На стороне ср запрос завершился ошибкой, но ни текста, ни кода ошибки нет. При этом мы сейчас работаем с данными из хадупа, и ср тут служит лишь интерфейсом к нему - это породило определенные гипотезы на проверку.

* попали на обновление данные через спарк (нет, не попали)
* не обновилась мета файлов в StarRocks и запросы падают по причине несуществующих файлов (нет, обновилась. вплоть до того что пробовали втыкать перед загрузкой refresh external table и select limit 1 - данные есть и читаются)
* косяк с ODBC драйвером: начали с самого последнего 9+, потом нашел статью от CelerData по подключению PowerBI и там указана 8.0.23 (нет, не помогло)
* попытка перейти на Mysql Enterprise Edition драйвер, который предоставляет сам Qlik Sense (нет, StarRocks с ним не совместим)

Бродил по ишью в гитхабе и наткнулся на мнение интерна, что StarRocks вообще не очень хорошо поддерживает именно ODBC драйвер.

И самое интересное, что в нашем случае проблемы как таковой нет - у нас обновление приложений запускается через сторонний оркестратор (airflow) и ретрай всегда заканчивается успехом. И затронуты не все прилы.

Нипанятна :(

Сегодня день анонсов разных мероприятий по StarRocks, которые пройдут уже вот-вот.

Буквально вчера в канале спрашивали про работу iceberg через StarRocks на S3 от Selectel.

И вот тут есть что послушать (но не уверен про S3):

вебинар СР ТЕХ х Selectel 31 марта в 12:00.
Расскажем про результат прогона StarRocks на TPC-DS в облаке: от 3 узлов до 111, от 100 ГБ до 10 ТБ. Реальное поведение СУБД с графиками, цифрами и инженерными выводами.
Регистрация на вебинар: https://selectel.ru/blog/events/analytics-database/

А теперь мероприятие номер 2. Если кто хочет пообщаться с разработчиками StarRocks лично :) А таких я видел.

✨ 2 апреля в Москве на Data Summit от DIS Group выступят коллеги из StarRocks

💼 спикеры расскажут о следующих аспектах развития StarRocks:
🔹 применении ИИ‑агентов в StarRocks;
🔹 повышении скорости аналитики в реальном времени — том самом «молниеносном» быстродействии системы;
🔹 roadmap продукта, включая новости о материализованных представлениях и их субсекундных обновлениях;
🔹 улучшениях в механизмах кэширования и оптимизаторах;
🔹 работе с операциями UPSERT и MERGE;
🔹 поддержке рекурсивных CTE‑операций;
🔹 расширении возможностей UDF в SQL;
🔹 алгоритмах распределения данных в таблетах на основе интервалов значений.

📅 Ещё есть время зарегистрироваться на мероприятие: можно выбрать желаемый формат участия — онлайн или офлайн.

🚀 2 апреля — отличная возможность узнать о новинках и перспективах StarRocks из первых рук. Рекомендуем обратить внимание на это событие!

Ограничения архитектуры

Вчера абсолютно случайно набрел на выступление Виктора из Авито про стабильность платформы данных. Именно тот момент, когда получаешь интересный доклад на неожиданной площадке. И почему так важно выбирать площадку под доклад для получения нужной аудитории. Мне доклад понравился: решение проблем не заменой системы, а выстраиванием хорошего стека вокруг нее. Напоминаю, что тайминг этого доклада попадает с отказом от вертики и миграцией на трино, и тут причин еще больше набросали.

Так вот про архитектуру. Vertica при всех своих недостатках - шикарная база. Она очень удачно использует свою архитектуру и много где снимает головную боль с конечного пользователя. Например, та самая история про внутреннюю репликацию данных. Выставили вы степень репликации и знаете, что у вас отказоустойчивость -1 нода (или -2, если вы богатый буратино) - все как в ГП. StarRocks же предлагает на замену историю про таблеты (выше уже рассказывал про них).

И что в итоге? Мы словили проблему мелких файлов, столько известную в хадупе, на нашем кластере StarRocks. 180 тысяч таблетов на 6 нод. Вам может показаться, что это не так и много - но наш любимый стриминг впал в полный неадекват. Постоянные спайки на графиках отзывчивости, зависания потоков, 99 перцентиль ушел за пределы минуты. И это при свободном процессоре и свободной памяти. Все метрики на компакшне на графиках тоже особо не показательны - десятки и сотни мегабайт потребления.

Надо думать СВОЕЙ ГОЛОВОЙ при создании таблиц и всегда-всегда задавать количество бакетов. И не стоит мелочиться с партициями. Если нам прямо говорят, что таблет должен быть от 1 до 10 гигабайт, то так и надо делать.

Уменьшили количество таблетов в 6 раз, почти везде перешли на годовые партиции, количество бакетов чаще всего от 1 до 3. И только на больших таблицах оставили 6. Как итог - график выправился, работать стало стабильнее. Начал завидовать ребятам с дата лейками, насколько понимаю там эта ситуация обыграна лучше.

На всякий случай, картинка выше - про внутренние таблицы SR. У нас к этому еще около 10к таблиц из хадупа, ну и пара тысяч из mysql источников.

А чего так долго не был?

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

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

А дальше у нас будет пост про CI для StarRocks, к которому подключены десятки внешних каталогов. Хотел этот доклад на смартдату донести, но видимо придется где-то в сторонке сделать.

ИИшные будни и полный пятничный сумбур

Сегодня подводили итоги квартала и все команды дата офиса сейчас пишут контекст для своих помощников. И вот нонсенс - чем лучше ваша слоенная архитектура и чем больше у нее документации, тем сложнее ее запихать в RAG и тем хуже на ней работают модели. Спасибо умным людям (привет, Венера), которые начали подробно описывать метрики в компании в маркдауне в репке dbt еще в 22 году - это самый простой и потрясающий буст по контексту для простых потребителей. Но вернемся к тому, почему вроде работали,а получилась шляпа. Самый простой способ убедиться в этом без построениях всяких специальных рагов - поставить nao.

Кто не слышал про эту штуку (как я, например, и спасибо большое просвещающим коллегам) - это по сути самая простая обертка для агента, нацеленная на работу с dwh. С одной стороны вы подключаете любую модель (Claude, ChatGPT, локальные модели), с другой стороны у вас веб чат с аутентификацией и авторизацией, а посередине репа с текстовыми файлами контекста. На первом запуске, когда мы подключили локальную модельку я был в диком восторге - ответ получил за секунды и вроде похож на верный. Правда на следующий день мы выяснили, что он был полностью выдуманным и ни один запрос в бд не был сделан :) Но в общем и целом после тюнинга получается достаточно удобно.

Так вот, в эту репку можно прямо ссылкой отгрузить dbt проект. Плюс еще сам nao собирает мету со всех подключенных бд на этапе init. И потом с этой горой информационного мусоры мы пытаемся взлететь, а размер контекста у локальных моделей сильно отстает от лидеров рынка - будет сплошной мусор.

Решить этой штукой мне хотелось вечную боль команд данных - выгрузки. И все бы ничего, но в коробке такого функционала нет :) Отвечать на вопросы с цифрами может, графики рисовать умеет, но csv выплюнуть - не сделали. У нас в планах на следующий квартал реализовать и пушнуть в апстрим. Еще коллега впрягся и добавил туда поддержку StarRocks :)

А что по остальным командам? BI и их ужасные системы из большой тройки. Самая большая проблема там - найти интересующую тебя информацию. Даже если приложение имеет описание, надо его еще найти, посмотреть есть ли там нужные разрезы и метрики. Решение - RAG. Чуете чем пахнет? Дата говернансом, дада, тем самым. Когда-то внедряли каталоги данных за миллион денег, которые сами по себе не могут решить никаких проблем. Так вот описание нужно, а каталоги - нет. И сам по себе офис данных сейчас по сути становится держателем контекста информации всей компании, мне так кажется.

Обновки подъехали

Абсолютно случайно в ln увидел, что в SQLMesh завезли поддержку StarRocks. Здорово, что у кого-то это первый публичный pr и сразу такого размера :)

И вот сейчас вроде интересно попробовать - наконец-то у нас в обойме появилась хотя бы одна бд, которая поддерживается. Но с другой стороны - что SQLMesh, что DBT теперь принадлежат Fivetran с каким-то мрачным будущим. Да еще вот только что я делал CI в DBT для мультикаталогов в StarRocks и вот сильно не уверен, что это реально повторить в SQLMesh.

И есть подозрение, что ко всему этому мы начнем распиливать активно единый проект на много проектов.

Есть у кого опыт, стоит ли пробовать?

DBX

Так ли уж много надо для счастья на сегодняшний день? Полный бак бензина, хороший велик и... Чтобы хоть одна sql-ide показывала миллисекунды для datetime колонок в StarRocks!

Я очень люблю сообщества и неформальное общение. Там порой случайно можно узнать что-то интересное, способное поменять твои привычки в работе и сделать картинку вокруг чуточку лучше.

И вот недавно думали тряхнуть стариной и провести новый DBT митап с Алмазом, и он случайно обронил в разговоре dbx. Выглядит интересно, пошел смотреть что это такое.

Да, вся IDE поместилась в 15 мегабайт с поддержкой почти всех бд, которые сейчас есть на рынке. Но эти 15 мегабайт, конечно же, не включают в себя JDBC драйвера для вертики или хайва, например. А вот StarRocks включен в поставку по умолчанию. И то, с чем не справились ни JB с их убер зоопарком, ни DBeaver с аналогом - вот на скриншоте сверху.

А еще в DBX на маке работает cmd+enter для выполнения запросов, что благополучно сломали уже год как в DBeaver.

А еще там есть MCP для всех ваших коннектов и готовое how-to интеграция с курсором и клодом (и остальными). Который впрочем не работает на маках с арм :)

И еще рендеринг тупит и если быстро листать виртуальные столы - то видишь белый экран примерно пару секунд после перехода.

Но ладно, за миллисекунды и хоткеи все можно простить. Теперь это мой топчик. Спасибо, Алмаз :)