StarRocks and modern data stack

Рынок труда и всякое К концу года совсем иссякли силы на всякую активность :( Очень хотелось провести закрывающий митап с историями неуспеха и коммерческого успеха, но прям совсем сил не осталось, к сожалению. Ну ничего, в новый год с новыми радужными ожиданиями. А пока хотелось немножко поговорить про текущий рынок труда на просторах РФ, а он поменялся. Делаю выводы из наблюдения за ХХ и по результатам трехмесячного висения нашей вакансии там же. Про StarRocks: вакансии есть, примерно десяток набирается. Часть из них по итогам коммерческого внедрения в ближнем зарубежье, часть по внедрениям опенсурса (привет оцрв, Артем, мы). Часть вакансий достаточно интересная для опытных ребят типа продакт менеджера дата платформы МТС или деврела для DIS. Джуны, мидлы и сеньоры тоже востребованы как исполнители на уже внедренные системы, или эксперты для выбора (тот же Х5 поменял требования в своих вакансиях и там снова появился может быть временно SR). Конкуренция с Apache Doris - по нему нет ни одной вакансии, нет такой системы :) А если говорить вообще про рынок дата инженеров в РФ, то вот такое: наша очень простая вакансия набрала уже больше 150 откликов на ХХ, и такого не бывало никогда. Отклики из больших компаний идут прям массово, маленькие не отстают. Из 150 человек только 2 человека не имели работу, все остальные ищут не отходя от станка. Джуны с резюме мидлов, мидлы с резюме сеньоров, чаще всего смена работы раз в год и менее. Мне тут кажется, что рынок поменялся очень сильно и вот эта старая парадигма умерла. И бюджетов на такие подвиги не осталось, и данные не стали новой нефтью. А может это просто брюзжание старпера - мне на пенсию пора по меркам айтишечки :)

Apache Livy & Spark 3.5.7 Вокруг все так любят постгрес, так любят, что в итоге фикс корректной работы с timestamp через JDBC есть только в спарке 3.5.0. Все в костылях, но любовь до гроба :) А чтобы обновиться до этой ветки на нашем ванильном хадупе надо обновить Livy с версии 0.7 до... Надо сказать, что мы пересобирали старую версию для поддержки нашего 3 спарка. Но очередной обновление скалы все сломало, не считая заодно проблем с поддержкой python >3.8. Поэтому воодушевившись вот этим ишью я пошел искать свежий релиз, а его нет :) Два топа, 3 прихлопа, сборка 0.9 бранча на маке м3 (надо апнуть версию maven-jar-plugin и maven-assembly-plugin >3.0.0) - и вот желаемый архив на руках. Не забыв поправить забытую кавычку в башнике для запуска в bin/, все завелось с полпинка. В качестве награды в новой версии добавили LIVY_CLASSPATH, куда наконец-то можно пробросить класпас хадупа вместо копирования жарок внутрь. В целом приключение на пару дней. Надо подметить, что вот эти старые сервисы из наследия HDP сейчас выживают в основном за счет ребят из Китая - посмотрите контрибьюторов ливи, цеппелина. Нормальные стабильные сервисы, в которых нет и не будет уже суперфич, но пользоваться удобно. Ну и глядя на такого рода баги в спарке для самой популярной бд - не так все плохо в СР, примерно как у всех :)

Работа мечты Вот ссылка: https://spb.hh.ru/vacancy/124275143 Классно же - болтаешь, статьи пишешь, ковыряешься в том что интересно. Тем более что внутренний уровень развития продукта в селене достаточно высок. А не вот эти ваши жсоны по кругу гонять :)

DevOpsConf 2026 Примерно год назад ко мне в почтовый ящик пришло письмо с приглашением выступить на конференции DevOpsConf 2025, ну знаете такая общая болванка на всех. А я подумал - почему бы и нет, и откликнулся. С этого начался мой год конференций и комфортной жизни спикера :) В этом году я познакомился с очень интересными людьми, посетил Екат (мне очень понравился), и дошел до смартдаты. Но самое забавное, что так и не выступил на этой самой первой конфе, так как резерв не случился 😂 Так вот, открыт набор докладов на следующий 2026 год: https://cfp.devopsconf.io/ Если вам есть, что рассказать - то очень советую. У Онтико очень классная подготовка к докладам - вас научат выступать, готовить хорошие презы, прогонят через обучение и всячески будут помогать. Ну и остальные пре-вовремя и афтер пати звездного состава тоже включены. ps да, знаю, что не совсем в тематику, но мало ли :) я то начал с этого

Airflow 3 и StarRocks 4 А вот подоспела и статья в блоге про выход 4 версии для тех, кто как и я не любит смотреть видосы: https://www.starrocks.io/blog/starrocks-4.0-now-available Написано красиво. Единственное, что мне пока не понятно - это политика релизов. В статье на сайте пишут про поддержку 3 последних минорных версий, но ветка 3.3 все еще является stable (и мы на ней сидим :). В связи с выходом новой мажорной версии по идее стейбл должен уйти на 3.4. Видимо не все сразу и надо подождать еще недельку или две до объявления и окончания поддержки 3.3. А вот кто совсем не умеет в новые мажорные версии, так это Airflow. Кто помнит релиз второй ветки - так вот с третьей дела на старте (полгода прошло уж) обстоят еще хуже, намного хуже. Появилось множество новых сущностей, которые вроде как должны были повысить отказоустойчивоть и масштабируемость сервиса, но получилось как обычно. Даже в 3.1 - чрезвычайно нестабильная система, особенно новые api-server. Утечки памяти, множество багов везде, поломанные рабочие решения, неудачный гуй. Не верится, что компания, которая зарабатывает на этом продукте деньги могла допустить вот такой релиз, как будто первый год этим занимаются. В итоге вместо улучшения хоть какого-то: надежности, простоты для стендов разработки - мы получили ведро недостатков, но со змейкой и думом в плагинах. Вангую, что дальше можно идти только по накатанной, и мы ждем новое поколение оркестраторов без этих проблем (не кестра, не дагстер, не перфект - у этих ребят вся архитектура похожа на аф и проблемы где-то рядом). Часто думаю про оркестратор своей мечты, но похоже что в рамках питона он будет не отличаться от аф в силу ограничений экосистемы, а вот на других языках можно придумать интересно...

Большой релиз с красивой цифрой. Подробности можно посмотреть здесь. К сожалению, в блоге более подробной информации нет (например почему 4, а не 3.6), но есть видео от Челси с саммита на ютубе. Приятно видеть прогресс, но обновляться мы сейчас конечно не будем :) А кто не читал, вот тут от Владимира Озерова статья-бенч трино/импала/дорис/старрокс. Очень нравится такая подача материала, когда не только цифры показывают, но и объясняют почему они такие в том или ином движке. Как обычно высший класс.

StarRocks summit 2025 #starrocks https://summit.starrocks.io/2025 А вот внезапно (для меня конечно) скоро пройдет вот такое событие, и оно даже будет онлайн. Докладчиков много, людей из компании много - так что если хочется задать каверзные вопросы или послушать про 4 версию - наверное стоит идти.

Воу, воу, воу А про дорис пока ничего.

Qlik Sense и 3.5 #qliksense #starrocks #3.5 Сперва про картинку. Данные лежат в hdfs в parquet. Слева доступ через kyuubi+spark+hive driver, справа через starrocks + mysql odbc driver. Кажется, что это бенчмарк драйверов, а совсем не систем. 5 дней назад на канале celerdata вышло видео про релиз 3.5. Мне было смотреть интересно, хотя обычно я пролистываю. Что показалось интересным и крутым: - разница в перформансе на стандартных тестах между shared data и shared nothing на прогретых кешах составляет всего 4%. Результат космический. - создание снепшотов кластеров (это как раз та заявочка на создание тестовых окружений, ради чего часто выбирают айсберг) - time-to-live для партиций и создание мат вью поверх айсберг таблиц (или любых других таблиц из внешних каталогов). То есть вместо надежды на механизм кеширования мы делаем надежный sla по скорости запросов, создавая мат вью надо горячими частями таблиц фактов во внешних каталогах. Идея очень хороша и мне крайне зашло: я выше писал, что работа с внешними каталогами требует нетривиальных стендов разработки. А подход с заносом таблиц внутрь позволяет всё значительно упростить - слой мат вью создает источники, а дальше внутри старрокса уже дбт как обычно работает с моделями. Остается дождаться стабильности, потому что пока мы все еще на 3.3 ветке :)

Совместимость с mysql #mysql #qliksense #starrocks Очередной вечер прохладных историй про mysql :) Я вот когда увидел то, что на картинке, был весьма озадачен. Округление datetime, все можно встретить в этой жизни. Но нет, оказывается, что это не баг, а фича. Более того, для 5 версии изменить поведение сервера нелья, а в 8 появилась настройка TIME_TRUNCATE_FRACTIONAL, которая меняет поведение. Дополнительно написано вот такое:

No warning or error is given when such rounding occurs. This behavior follows the SQL standard.

Ради интереса проверил vitess (который построен на mysql) - поведение такое же. А вот StarRocks уже показывает ожидаемо - обрезая часть с миллисекундами. И вот когда кто-то хочет соответствовать под чужой стандарт (драйвер, диалект) должен ли он соблюдать и такое вот поведение? :) Подключили ср к qliksense через odbc mysql драйвер как замену spark драйверу - пока все классно. Как же это здорово, когда не приходится вкорячивать эти кривые старые (или новые как у кликхауза - которые кстати у нас сломали в очередной раз) драйвера и все сразу работает.

Airflow 3 Очень странные ощущения от него. Как будто попал в версию 1, только изувеченную начинающим дизайнером от бога. Из плюсов разве что гуй очень отзывчивый.

Красивые картинки Сразу скажу, что рекламу не даю - просто картинка понравилась :) Так вот, пришла на почту реклама от VK - прям одно загляденье. Ребята каждым пунктом бьют по живому - тут тебе и уменьшение затрат, и повышение скорости, и линейный рост вместо экспоненциального. А потом ради интереса я в эту картинку то всмотрелся, и получилось что у нас раза в 2 дешевле самого дешевого варианта. Кто-то вспомнит про то, что управляемые сервисы обслуживать не надо и здесь будет экономия, но до 300 тб и так на это нужно примерно 0.2-0.3 ставки (а то и ноль, потому что дата инженерам придется понимать как все нормально раскладывать в любых вариантах). Вот так и сорвался наш переезд в светлое будущее 😂

Четверг это почти пятница Последнее время писал про dbt не совсем зря, хотел кроме совмещения полезного сделать подводку к выложенным выступлениям на прошедшем Dump'25. У нас он очень активно используется, в том числе для получения стендов разработки. И весь доклад про то, как вписывать новые базы данных в текущую инфраструктуру и как это делать, чтобы максимально увеличивать шансы на успешность миграции на них в компаниях малых и средних. Особенно тех, где вам этот приказ не спускает сверху ЛПР, и вам еще надо продать эту идею всем своим клиентам :) Видео на ютубе

dbt & hive catalog: эпилог 2 Закрываю для себя идею реализации записи в паркеты через dbt через starrocks, и причиной тому 3 вещи. Причина 1: можно увидеть на картинке. Время приведено в секундах расчета без поднятий сессий, взято для спарка из dbt spark. Один и тот же код прогоняется через датасеты разных размеров (у нам они приходят именно так, это разные дневыне отчеты от одного провайдера). И чтобы считать на спарке 10 мегабайт в течение 80 секунд - надо написать выдающийся код витрины. Уже на сотне мегабайт старрокс ушел за пределы лимитов и стал проигрывать спарку, что я попробовал победить перегонкой данных в родной формат вместо паркета (хотя казалось бы - какая разница, проблема таких долгих вычисления явно не чтение). И даже получилось отыграть скорость, но на гигабайтах и это не помогло. Запросы были переведны с диалекта спарка на диалект старрокс без оптимизаций как есть, по пути заменив только функции работы с временем и хешами. Овчинка выделки не стоит, тем более мы все равно не собираемся отказываться от спарка. Причина 2: названная в прошлом посте - отсутствие метаданных по внешним каталогам в дбт/dbeaver/datagrip (клиентах). Тут кажется начинает стрелять в ногу как раз совместимость с mysql (но это не точно). И пока эта фича не будет реализована - со стороны людей будет много недопонимания, а со стороны сервисов много грязного кода. Причем все каталоги отлично показываются в вебке старрокса по порту 8030 :( Причина 3: высокая сложность реализации дев и стейдж стендов. Для тестирования такого совмещенного проекта дбт надо поднимать не только старрокс, но старрокс в связке с хадупом и хмс. Не очень просто, но так или иначе нам придется это делать. Взяли себе в беклог устранение причины 3 и пристально наблюдаем за развитием старрокс для устранения причины 2. А 1 кажется будет решена так или иначе, просто по причине текущего вектора развития старрокса как lakehouse движка. Вот такие пироги.

dbt & hive catalog: эпилог 1 Как оказалось на самом деле - добавлять свои материализации еще проще, чем патчить адаптер. Материализации можно размещать в своих локальных проектах в директории макросов и они легко подтягиваются в проект. Поэтому написание hive_table заняло времени еще меньше, нежели патч в адаптер.

{{ config( alias='hp_appsflyer_blocked_installs_test', schema='dapadoop.sandbox', materialized='hive_table', file_type='parquet', tags=['hp_appsflyer_blocked_installs_test', ] ) }}

В таком виде таблица создается и отлично читается и из starrocks, и из spark. Но при повторном запуске для проверки удаления все сломалось и тут я как понял... Проблема в хранении меты внутри старрокса, таблицы из внешних каталогов не доступны во внутренних таблицах в схеме information_schema. Это порождает боль - дбт не может определить, есть ли такая таблица. Да, можно патчить адаптер и выгребать список таблиц через show catalogs..show databases in catalog..show tables from catalog.schema (я такое уже когда-то делал для спарк адаптера не помню почему). Вот только тип мы все равно не узнаем - вью или таблица :( И кстати адаптер поддерживает определение catalog в профиле, но при указании недефолтного значения ломается вообще все - дбт ищет эту самую information_schema в этом внешнем каталоге и естественно не находит.

dbt & hive catalog Текущий адаптер dbt нормально работает на чтение и запись с форматами старрокс и только на чтение из внешних каталогов, не смотря умение создавать таблицы и писать в них со стороны SR. Дел то на 5 минут, подумал я, допишу за полчаса поддержку и можно перевозить нашу репу дбт спарка. Написал для пробы пера table материализацию. А вот и нифига, сказал мне dbt, выдав ошибку: 1064 (HY000): This connector doesn't support alter table type: RENAME. Вы поняли, да? :) StarRocks не умеет переименовывать таблицы во внешних каталогах, а даже если бы умел - то создание tmp_relation в стандартных table/incremental материализациях напрочь ломают логику сохранения таблиц в заданный location. В итоге надо писать свои материализации по количеству каталог*2 (таблица, инкремент, вьюха по идее должна и так создавать, если она нужна конечно.) Ну ладно, чуть посложнее и чуть больше времени, но вполне типовая история при работе с dbt. Но как это все будет происходить в новом dbt fusion с растом решительно не понятно.

Scale BE out Масштабирование shared nothing кластера на картинке. Даже рассказать нечего, никаких повестей от бывалых кликхаузеров про решардинг с слезами на глазах :( Просто replica в crd поправил и меньше чем через час наступила новая реальность. Сама.

Решение кроилова За всей движухой постоянно коплю долги на канале в виде постов, попробую нагонять. Решение поста с отключением 50% дисков от кластера в к8с. Как и писалось, в кубике через оператор нельзя менять для существующих statefulset ничего кроме количества реплик, энв переменных, лейблов и всяких других описательных куб штук. Удалить, изменить или добавить volume нельзя. Поэтому планируйте заранее свой кластер с умом, а не как я :) Так вот, если нельзя, но очень хочется - просто при живом операторе удаляем statefulset для be нод. Поды будут удалены один за другим, и после исчезновения сущности SF оператор заново её создаст и подключит старые диски с данными. Ни один байт не пострадал, хотя я уже стал мастером бекапов. Но на самом деле это самая простая часть этой операции, и самая надёжная. А вот изменение конфига старрокс с удалением из него директорий хранения на живом кластере убивает все данные вне зависимости от количества реплик. И делает это весьма некрасиво. Данные между всеми директориями и на бе ноде нарезаются очень ровно, а значит скорее всего и между нодами кластера одинаковые данные будут лежать в одном и том же разделе (напоминаю, что в доке ср рекомендуют использовать несколько разделов на одном сервере - это сильное удешевление требований к железу и повышение скорости). В итоге реплик потерянных данных в случае кластеров с малым количеством нод не будет :( При этом кластер будет добро рапортовать в метриках, что диски заняты, количество таблетов старое, количество строк не изменилось, но на запросе реплик или попытке сделалать селект из любой табличке кроме меты падать с пустой ошибкой. Вариарт решения - восстановление из бекапов, что и сделал. Операцию можно запускать синхронно, то есть сразу кормить пачки схем на восстановление. По итогам - я думал, что будет хуже. А все решилось тех окном на 3 часа.

StarRocks meetup 19.06: итоги Запишу сюда, чтобы висело в закрепе: youtube, rutube, vk. И немного статистики по мероприятию, которую обычно никто не пишет :) Число регистраций: 282. Число уникальных зрителей: 220. Средний онлайн на протяжении всех докладов: 90-130. Хороший такой зал собрали, спасибо всем.

Saint highload'25 немного выводов Сравниваю исключительно с моим прошлым посещением году в 23 или 22. По самой конфе - доклады стали лучше, даже не 1 и не 2 достаточно интересные. И даже сбер-вк-яндекса стало меньше, а там где есть они стали более техничными. И эта техничность видна по аудитории, общий уровень в айтишечке прыгнул достаточно сильно и высоко. Теперь от мала до велика все умеют патчить опенсорс и не боятся писать сервисы под свои потребности, включая выкладывание в апстрим крупных и больших проектов. И кажется, что на это не только повлиял уход западных вендоров, но и наше импортозамещение с сумасшедшими ценниками за перекомпиляцию и пару фич сверху. И конечно смена технических лидеров в компаниях или смена ветров - все эти разговоры про надежность поставщиков и 2-3 линию поддержку остались в прошлом. Рынок меняется. Вот такие выводы высосал из пальца и общения :) И да, питерский летний хайлоад - это +15 и проливной дождь.