Красивые картинки

Сразу скажу, что рекламу не даю - просто картинка понравилась :)
Так вот, пришла на почту реклама от VK - прям одно загляденье. Ребята каждым пунктом бьют по живому - тут тебе и уменьшение затрат, и повышение скорости, и линейный рост вместо экспоненциального.

А потом ради интереса я в эту картинку то всмотрелся, и получилось что у нас раза в 2 дешевле самого дешевого варианта. Кто-то вспомнит про то, что управляемые сервисы обслуживать не надо и здесь будет экономия, но до 300 тб и так на это нужно примерно 0.2-0.3 ставки (а то и ноль, потому что дата инженерам придется понимать как все нормально раскладывать в любых вариантах).

Вот так и сорвался наш переезд в светлое будущее 😂

Airflow 3

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

Совместимость с 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 драйверу - пока все классно. Как же это здорово, когда не приходится вкорячивать эти кривые старые (или новые как у кликхауза - которые кстати у нас сломали в очередной раз) драйвера и все сразу работает.

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 ветке :)

Воу, воу, воу
И самое забавное, что два доклада по ср будут проходить в одно и тоже время. Что происходит то :)
А про дорис пока ничего...

StarRocks summit 2025

#starrocks

https://summit.starrocks.io/2025

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

Куда же без AI

Пропал на 2 недели, потому что занимался очень инженерными задачами - писал очередной стриминг, потом бота для соединения гитлаба со слаком и опять веселился с апишкой qlik sense. Задачи по миграции висят мертвым грузом, каждую неделю говорю себе "ну еще недельку и точно получится добраться".. и нет.

Последнюю неделю достаточно злостно подсел на курсор и не могу понять есть ли толк :) Точно можно сказать, что его нельзя и не получится применять без знаний ни контекста бизнеса, ни знаний языка. Что в sql, что в python, что в golang - везде в итоге приходится достаточно активно думать. Единственное что, курсор закрывает (или пытается закрыть) какие-то неочевидные корнер кейсы в коде и очень хорошо пишет документацию. Это прям его конек. А уж документацию к моделям в дбт генерировать просто сказка.

В итоге выиграл ли я по перфу - нет, ни сколько. Но приложение может быть будет меньше падать и потомкам описание кода читать понравится :) Двадцать баксов того стоят, тем более можно общаться с ним на русском, не теряя точность при переводе.

 PS Самое злое было, кстати, написать взаимодействие с апи клика. модели генерировали кучу галюцинаций, каждая что-то свое. Поэтому закрытые сервисы и проиграют, с ними не будет опыта и будут дорогие специалисты :) Которые могут открыть веб клика, нажать ф12 и вытянуть необходимые параметры из нетворк консоли 😂

5 минут работы, вошли и вышли

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

Логично предположить, что таблицы с технической метой (схема information_schema) точно так же хранятся на основных разделах данных и скорее всего-то же будут испорчены. Тогда я не проверил конкретно эту таблицу, но по остальным решил об успешности проведения работ.

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

SELECT state, PROGRESS, ERROR_MESSAGE FROM information_schema.task_runs where task_name = 'insert-3bf372bf-7a09-11f0-9446-1223cff75f84';

на самом деле идет обращение в совсем другую таблицу (на что я не обратил сначала внимания). И все попытки удалить существующие записи или выполнить транкейт этой таблицы task_runs утыкался в то, что такая операция невозможна.

Посидев, подумав, еще раз прочитав ошибку увидел, что запрос выше внутри превращается на самом деле в запрос

SELECT history_content_json FROM _statistics_.task_run_history

Не сообразив, что это обычная таблица я подумал, что придется чистить таблеты прямо руками с диска и выполнил запрос на получение этих самых таблетов для таблички (и кстати говоря на этом пункте дипсик врёт безбожно, но спасает дока)

SHOW TABLETS FROM _statistics_.task_run_history;

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

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

Раз, и delete по таблице сработал. Раз, и транкейт по таблице сработал. И сразу после этого все и заработало. Более того, каким-то образом там появилась задача от позавчера (после транкейта то...).

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

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

А я так и сижу со своей расшифровкой доклада с митапа. Оказалалось, перевести доклад в статью не так просто. А нейронка отлично умеет делать выдержку, но что-то не очень переписать доклад в статью. Да еще местами включения информации из интернета вместо самого доклада. Но когда-нибудь я завершу работу! :)

Регресс непонятно почему

Стримы не стоят на месте и вот мы перешагнули размер потока в 10 000 eps. Часто на собесах дата инженеров начинают мучить кафкой, всякими флинками или кафкой стримс - гошка на таком потоке кушает 130 мегабайт памяти и 0.1 процессора надо сказать.

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

И теперь даже не понять, это регрессы обновлений кластера с версии на версию, старые проблемы миграции дисков, или просто общий регресс кластера (под нагрузкой). Видимо надо поднять новый кластер и потестировать с нуля.

Change data capture

Потратил субботу на разбирательство с текущими сервисами для репликации из наших mysql в starrocks. Что видеть отрадно - появилась целая куча инструментов, которым больше не нужна кафка посередине (ну просто зачем иметь еще один лог когда ты уже читаешь из лога, а уж передавать инитиал снепшоты через кафку - отдельный вид мазохизма). Что плохо, они все сделаны на базе debezium, а значит если по каким-то причинам не подошел один, то и все остальные не смогут помочь.

Что может из коробки синкать с настройкой одного конфига и без плясок вокруг: apache seatunnel, apaсhe inlong. Что не умеет в cdc, но может вам помочь например при transaction outbox - sling. Что имеет ограничения на ровном месте и "интересные" настройки - risingwave (внутри дебезиум, но фишки из остальных сервисов в нем будут за деньги).

Итогом дня стало то, что нам не подошел ни один из них :( В принципе даже если форкать, то возврат кода в апстрим потом не примут никогда. С учетом отсутствия джавистов в компании выходит, что нам проще дописывать наш внутренний репликатор на golang, который уже 5+ лет перекладывает данные в vertica. Печалька, хотелось другого окончания. Причны подробно уже затащу в доклад на смартдате, а то надо же что-то там интересное рассказать :)

ps на картинке конфиг для seatunnel со всякими ухищрениями, которыми пытался обойти компанейские особенности

4 релиз не за горами

https://github.com/StarRocks/starrocks/releases/tag/4.0.0-rc01
Много айсберга, джойны ещё класснее, оптимизация спилов неожиданно (но очень желанна)

Прикольно было, весёлые уточки :)

4.0rc2

Supports Multi-Table Write-Write Transactions, allowing users to atomically commit INSERT, UPDATE, and DELETE operations. These transactions are compatible with both Stream Load and INSERT INTO interfaces, ensuring cross-table consistency in ETL and real-time ingestion scenarios.

Жду, ой как жду

Доклад в 10 утра в воскресенье, но циферки того стоили :)

SmartData 2025

Мне очень понравилось. Вот онлайн мне смотреть было не очень, а в офлайне на отлично. Атмосфера, люди, место, общение - классно. Послушал как надо делать, как не надо делать, увидел как люди начинают убегать от меня с криками "опять про старрокс" :)

Мой доклад мне не понравился, и наверное стоит на этом завершить карьеру спикера. Гештальт закрыт, не стоит делать то что не выходит. И поэтому даже как-то неудобно ни презент для спикеров принимать, и время людей жалко :(

А вот что понравилось, так это офигенный доклад от Артёма Маркина "DWH на StarRocks: год в продакшен". В нем все здорово - подача, материал, и вообще итоговое решение проблемы. Был оракл со своими проблемами, стал старрокс с дбт - заложили огромный запас под рост, ускороили работу на порядок, дёшево. Жаль, что видео в открытом доступе долго ждать.

Было и много другого интересного, просто тематика канала чуть в стороне. И sale, и ozon, и много чего.

Всем спасибо большое за общение, очень был рад пообщаться вживую после чатов, вы классные. Увидимся :)

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

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

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. Утечки памяти, множество багов везде, поломанные рабочие решения, неудачный гуй. Не верится, что компания, которая зарабатывает на этом продукте деньги могла допустить вот такой релиз, как будто первый год этим занимаются.

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

DevOpsConf 2026

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

Так вот, открыт набор докладов на следующий 2026 год: https://cfp.devopsconf.io/
Если вам есть, что рассказать - то очень советую. У Онтико очень классная подготовка к докладам - вас научат выступать, готовить хорошие презы, прогонят через обучение и всячески будут помогать. Ну и остальные пре-вовремя и афтер пати звездного состава тоже включены.

ps да, знаю, что не совсем в тематику, но мало ли :) я то начал с этого