Куда идет StarRocks

На канале у CelerData вышло видео с подведением итогов квартала. Кому лень смотреть краткая выжимка: StarRocks позиционируется исключительно как shared-data движок либо со своим собственным быстрым форматом, либо как основной движок для datalake на основе почти всех свободных форматов.

Основные фичи квартала:
- интеграция с Unity Catalog. Тут все понятно без слов.
- реализация новой фичи Automatic Materialized View. Причина использования описана хорошо - покрутил в голове наш случай, этак можно детальный слой из дбт выкинуть. Но дальше в реализации начал скипать видео, подводных камней хватает и надо ждать переезда фичи из облачной версии в открытый StarRocks.

А заодно на днях вышла версия версия 3.3.6. И опять же, посмотрев фичи за последний квартал, можно увидеть, что развитие идет в shared-data движке. Уже даже начал задумывать о том, что надо тестировать и может быть мигрировать на него с shared-nothing - но остается вопрос таймингов. И самое интересное, что когда я делал PoC как раз сильно обломался, в то время невозможно было использовать HDFS как систему хранения. На данный момент все реализовано.

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

Apache Kafka и StarRocks

Выше писал про интеграцию с кафкой через механизм routine load.Механизм в продакшн режиме уже полтора месяца на количестве наполняемых таблиц до 10 единиц - и можно уже сделать немножко выводов.

Плюсы

Механика выглядит надежной и простой по подключениям ко всем видам кафок - у нас 3, включая managed aws кластер с разными видами аутентификаций: SASL_PLAINTEXT, SASL_SSL via SCRAM-SHA-512. И даже задаваемые креды в запросе маскируются при выводе show routine load:

{"security.protocol":"SASL_SSL","sasl.username":"username","sasl.mechanism":"SCRAM-SHA-512","kafka_default_offsets":"OFFSET_END","group.id":"dp_sr_1","sasl.password":"******"}

Минусы

Задания разделены по схемам нахождения таблиц, и это прям странно выглядит. То есть вы грузите таблицу в dds.table через задание и команда show routine load показывает только его, а то что в соседней схеме kafka есть еще 10 заданий никого не волнует. То есть в случае капитальных проблем нужно будет бегать и вспоминать (в нашем случае все записано в миграциях, но осадочек остается).

Особенности

В случае перегрузки кластера все задания ставятся на паузу, не мигрируя между живыми нодами. То есть пусть это будет обновление кластера на новую версию или добавление тега в k8s для добавления сетевых ACL - пауза везде. Тут важно мониторить метрику starrocks_fe_routine_load_jobs с значениями PAUSED (остановлено по какой-либо валидной причине - ручная операция или перегрузка кластера) и CANCELLED (сработал трешхолд по ошибкам в данных или нарушены значения ключей в таблице).

Epic fail

Середина рабочего дня, и вдруг вам в слак(ваш рабочий месенджер) приходит сообщение: "Я кластер XXX снес". Речь про k8s кластер, в котором у вас находится все - сервисы, базы данных, джобы эйрфлоу делают вжух. Эмоции были непередаваемые, голова сразу начинает работать сколько времени потребуется на восстановление данных - и эта основная часть как раз старрокс и данные из кассандры.

Кластер восстановили, старрокс за этом время не потерял ни одного сообщения из потока 👍 Вся эта хитрая модерновая история с тераформом может закончится вот так - команда на удаление одного узла развернулась в удаление всего кластера :) Люблю модерн оперейшенс стек ❤️

А что же цвет нашего modern data stack - cloud managed databases?

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

В компании есть небольшой проект, на котором мы решили потестировать работу только в облаке - BigQuery с месячным счетом в районе 500 баксов. Ничего не предвещало беды и все были очень довольны. Но бодрым октябрьским утром данные перестали поступать в бд - аккаунт был заморожен. Нет, РФ тут даже не при чем. Просто где-то там не понравились платежные документы аккаунта, и вместо уточнения по ним был приведен в действие рубильник. Отдел юристов бился как лев, но каждое наше письмо получало ответ в срок до 48 часов.

Итого 2 недели вся аналитика не функционировала - проект просто ехал в слепую. Ну да, ну да, уровень услуг чувствуется. Пожалуй, что спасибо, но нет.

Большая часть данных - не имеет цены

И это не намек на "данные - это новая нефть", а скорее на "сколько можно хранить мусор" :) Спасибо Никите, который принес статью и поделился своими историями в подтверждение ее тезисов. Каждый выносит из нее полезное на основании своего опыта, а основная часть в ней про моду последнего сезона в бигдатке - realtime analytics. Да, безусловно, король голый - большая часть заказчиков опять идет на поводу хайпа.

Но вот один из тезисов в статье редко озвучивается что в статьях, что на конференциях - как это "90% данных никому не нужная фигня, которая тратит ресурсы"? Да вы что, мы же тут каждую встречу на тусовках начинаем с мерялки сколько петабайт лежит в вашем хадупе и если меньше 10, то руку могут и не подать.

История из жизни

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

Поставьте себя на место лица, принимающего решение, в момент, когда приходит алерт о достижении 90-95-100-105% занятого места в хранилище (лицензия отрубает бд на 110 :). Ваш ход? Следуя логике бигдаты - стращаем СТО и покупаем на все выбитые бабки расширение и лицензии, да и о вычислительных ресурсах подумать можно. Вместе с ним можно и инженеров еще нанять - у нас же эльдорадо из новой нефти не за горами. И не отвертятся ведь от покупки - вот же графики роста, вот пользователи с горящими попамиглазами.

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

А вот какой результат варианта 2: 3+ года без расширения лицензий и железа, потребление места упало с 90% до 65%, падение обращений в команду по поводу нехватки ресурсов для выполнения запросов. Эти 3 года позволили спокойно подобрать и начать внедрение замены этой базы данных в оптимальном темпе.

О чем умолчал

Конечно умолчал :) Львиную долю разгрузки хранилища дало внедрение хадупа рядом. Вот только в чем фишка - пользователи туда стараются не ходить. Можно сказать, что это место подготовки и перевалки данных, и еще аргумент "мы здесь срезали срок хранения до 3 месяцев, но вся история есть в хадупе". И как вы думаете, сколько людей ходили смотреть эту всю историю за годы? :) Сейчас хадуп уже не нужен, s3 вокруг нас и решения стали еще проще.

PS есть еще интересный тезис в статье, но и так многа букф, оставлю на потом

Сделать правильно с первого раза

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

Мы потратили неделю+ на разработку нового процесса деплоя dbt для нового проекта под StarRocks. Потом еще тройка-пятерка сторипойнтов для удаления кусков конкретного проекта и создания удобного шаблона под остальные проекты.
После этого прошла миграция 2 проектов бигквери на новый шаблон - опять доработки.

И вот он - наш царь всех дбт - проект вертики. Легкая миграция на тщательно отлаженный шаблон превратился в головную боль на 3 дня. Оказалось, что неправильно было сделано больше 50% и как оно работало иначе как чудом не обозвать. И вроде как снаружи кажется, что ты знаешь как пользоваться этим вашим ArgoCD, gitlab-ci, helm, k8s, dockerfile, pytest и сам dbt. Но нет - недостаточно. Надо больше, выше, сильнее, пока мозги не треснут.

Люблю старые проекты, сразу показывают кто ты есть.

Опыт внедрения StarRocks нормальных людей

Мне очень нравится компания Agoda, но исключительно по одному человеку в сообществе из нее. Алекс очень классный, до сих пор помню как он мне помогал тайминги выжимать из HBase.
Вот тут и ниже он написал про боли, которые у них возникают в процессе внедрения: https://news.1rj.ru/str/hadoopusers/222943

Минусы
- это плюсы - а значит все может начать падать вместо красивых ошибок в логе у жабки
- порой код удивляет детскими болезнями и не очень зрелым подходом(где тестирование?)
- падение скорости разработки в репе на гитхабе начиная с лета - и сильный проигрыш в этом сейчас дорису: около 200 пул реквестов за прошлый месяц в СР против 1500 в дорис
- планировщик чудит
- медленно принимают пулреквесты

Плюсы
- быстрый
- пользователи довольны по сравнению с импалой (у них кейс как раз lakehouse - хранение данных в открытых форматах на hdfs)

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

Возврат наработок в upstream

Недавно писал про нашу миграцию дбт проектов. Хехе, нет, так просто оно не закончилось. На финишной прямой задача приведение stage кластера для вертики в production вид dbt run на всех 600 моделях начал падать в непредсказуемых местах - каждый раз новом. Еще денек на поиск: флажок --full-refresh. И да, это был баг в адаптере - вместо создания временной модели и потом замене существующей адаптер пытался создать еще раз существующую таблицу. Замена переменной в одной строчке и добавление строчки на дроп промежуточной таблицы, вот и весь фикс.

Свои форки

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

Промежуточный итог

Мы живем на своем форке и вот такие баги правим у себя (а встречали много). Но и в текущем апстриме этот баг поправлен. Сложно, короче, пушить свои правки в апстрим, как морально, так и физически. Вроде у себя ты уже поправил, а взаимодействие с ребятами с той стороны гитхаб репы бывает ух каким непростым. Так у меня висит пулреквест в фласк для работы с вложенными группами MS AD для airflow, кучка в вертику дбт, что-то в спарк дбт, что-то в цеппелин, и так с десяток реп. И иногда прямо стреляет :(

Где SR хранит офсеты кафки?

Если бы не мега редкий случай переезда с одного кластера на другой с сохранением consumer group правда бы и не раскрылась, вернее этот вопрос не заинтересовал. В документации есть абзац про использование по умолчанию автогенерации для названия группы, но можно задать его и руками.

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

ErrorReason{errCode = 104, msg='FE aborts the task with reason: failed to check task ready to execute, err: Consume offset: 7702455725 is greater than the latest offset: 100248496 in kafka partition: 1. You can modify 'kafka_offsets' property through ALTER ROUTINE LOAD and RESUME the job'}

Хм, то есть хранение офсетов происходит не в группе, а в самом старроксе, но при этом происходит эмуляция хранения и офсеты двигаются. Ок, проставляем офсеты с нового кластера - запускаем. Ошибка не меняется :)

Только создание новый группы и ручная подача стартовых офсетов для партиций срабатывают.

ALTER ROUTINE LOAD FOR dds.quotes
FROM KAFKA
(
"kafka_partitions" = "0, 1, 2",
"kafka_offsets" = "74280122, 99609165, 42423911",
"property.group.id"="dp_sr_quotes_1"
);

Дичь же? :)

Организация работы

На канале про лидов вышло очередное видео, долго откладывал, но посмотрел. Вроде и есть что пошеймить, с другой стороны, ну хочется людям ощущать себя кирпичиками, 1/10 000, которую менеджеры шпыняют туда-сюда со словами "тут не хватает ресурсов, сейчас с другой команды добавим" - это их дело. Очень понравилась история про то, что из плохих специалистов получаются хорошие лиды, а из топ перформеров - плохие. Ну да, ну да.

А вот теперь и правда минутка ненависти

В пятницу в районе 19-00 начинает кипеть чатик с алертами - сначала кучно пошли пул реквесты от автоматики, следом пошли аварийные сообщения. Что же тут у нас? А тут у нас молодцы, которые катят прод в пятницу вечером. Ненавижу скрам, ненавижу спринты, ненавижу спринты, которые заканчиваются в пятницы. Всю неделю команда ударно работала и значит в пятницу вечером наступает пора эту самую работу доставлять. Меняются колонки, добавляются и удаляются таблицы, вжух-вжух-пыщь-пыщь.

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

Как-как простите определить хорошего менеджера в команде? 1-1 говорите он должен регулярно проводить и календарь плотно забит?

Выводы

А вы знали, что в статистике канала в телеге можно посмотреть у скольки людей он стоит на мьюте? Для меня стало неожиданностью, что 70% не проставляют отключение оповещений сразу после подписки. Мне бы такую нервную систему, у меня даже телефон с часами после 23-00 гасят все входящее. И на попытку внедрить команду мониторинга к нам результат был бы таким же, как без нее - все равно трубку никто бы не снимал.

Так вот, убирайте оповещения в во время отдыха, ничего хорошего здесь не пишут :)

Гараж аналитических решений

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

История простая: у нас в компании есть DWH(да, вот так вот) на oracle или ms sql. Ситуация на рынке или выявленные ограничения диктуют замену текущему решению. И лицо, принимающее решение, начинает выбирать. Тут надо заметить, что выбор - это предпочтение одного варианта другому, а сколько вариантов есть?

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

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

Через какое-то время в стеке появляется hadoop, ну потому что GP перестал справляться, а в s3 или куда еще сыпят и сыпят эти ваши джосоны без схем. А hadoop у нас - это нормальный такой грузовик, ну давайте камаз самосвал. Можно в кабине попутчика подвести, а можно 10 тон песка на участок.

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

Цена ошибки (1): стоимость коробки

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

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

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

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

StarRocks/Apache Doris - при неудачном внедрении по этой категории рисков набирают 0 долларов затрат.

StarRocks 3.3.7 & 3.2.13

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

А вот что выглядит притихшим, так это дбт адаптер. Не смотря на то, что 1.7 выпустили в октябре, с тех пор репа стоит без обновлений. При этом уже почти все основные игроки готовятся к 1.9 - тут еще даже 1.8 ни в каком виде нет. Печалька :(

Линус, linux и opensource

Честно взял картинку у https://news.1rj.ru/str/it_gonzales. А вспомнил про нее благодаря посту на ЛОРе, в котором добрый человек прочитал годовой отчет Linux Foundations. Новости примерно такие:
- суммарный доход LF за прошедший год вырос до 292 миллионов долларов, расходы выросли до $299.7 миллионов;
- из них, доля расхода на собственно ядро Linux в процентном соотношении упала до 2%, что в два раза меньше расходов на Blockchain (4%) и почти в 6 раз меньше расходов на ИИ, машинное обучение и подобные штуки (11%).
- затраты на ядро Linux в LF в данный момент меньше, чем зарплата CEO Mozilla
- в этом году из отчёта напрочь исчезли такие термины как: diversity, inclusion, equity, climate change и другие интересные вещи
- 70% членов совета директоров работают на корпорации, регулярно нарушающие GPL, в том числе и в отношение этого самого Linux. И двое работают в Microsoft.

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

А что у нас?

А у нас до сих пор не доперли, что можно получать бесплатно то, что внутри компании надо делать за деньги. Да-да, до сих адаптер greenplum, да впрочем и сам greenplum не нашли себе дома в виде сообщества или фаундейшена. Продавать коробку или облако - пожалуйста, но сделать для него удобные инструменты - не то что денег нет, а мозгов нет. Вроде из требований просто создать репу и договориться, что теперь патчи присылать сюда. Поэтому каждый пользователь ГП допиливает гитхаб Марка как умеет.

Новые игрушки

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

Например рассказать о новом релизе dbt 1.9. Но на повороте меня обгоняет Паша из инженерки, что безусловно и неплохо. Когда сервис внедрен уже довольно давно - шаблон привычек работы с ним уже сформирован, подходы закреплены и заставить внутреннюю обезьянку изучать новые фичи довольно сложно. На каждое новое есть уже устоявшийся привычный подход. Да, он не идеален, но он есть и не требуется думать. Микробатчи - прикольно же. А вроде и так уже все работает :) Из года в год работает. Так что даже и рассказывать на митапах нечего. Завидую тем, кто внедряет новые для себя штуки - можно и так попробовать, и сяк, время на эксперименты заложено в решение бизнеса.

Нашел почему не дорис!

Потому что ситуация с адаптером dbt под него еще хуже, чем у старрокса :) На просторах гитхаба есть 2 адаптера - версии 1.3 и 1.5, обе давно EoL. Тут SR с его 1.7 хотя бы на поддерживаемой версии живет. Все не так плохо, можно жить дальше :)

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

Целевая аудитория

Прошлой зимой к нам для развития лидерских качеств пригласили достаточно известных Aletheia Digital, которые всю дорогу выступали и партнерились с highload conf, а затем и с teamlead conf. И среди дополнительной литературы они дали книгу "Искусство решения проблем" Акоффа. Прошел год и руки дошли дочитать.

Название классное, но при этом задает некие ожидания. А после прочтения первой главы ожидаешь как минимум откровения из ТРИЗ, не меньше. Вся эта история про творческий подход к решению проблем и угнетению воображения в школе. Но следом на нас обрушивается огромное число побасенок с небольшими выводами - прям как будто читаешь сборник сказок какого-то народа :) Так проходит первая половина книги - первая часть, а со второй все интересней. Там и про современные бирюзовые организации, и про информационные системы для помощи в принятии решений, и про моделирование. На минуточку - это книга 1978 года.
С одной стороны, эти 200 страниц читаются очень легко, и все достаточно увлекательно. С другой стороны я 2 дня ходил и думал - как оценить эту книгу, была она полезной или просто весело время провел.

Вот точно та же самая история была и с тренингом. Известные спикеры, которые имеют хорошие рекомендации. Но при этом структура курса из разряда объять необъятное, да еще на огромную группу самых разнородных лидеров - от С* до лидеров самых малых команд в 2 человека (это я, если что :). Широкая аудитория сильно размывает полезные мысли до уровня - делай хорошо, не делай плохо. А по другому 2/3 потребителей могут и не понять. Но это все равно понижает ценность, и так плохо, и по другому не лучше.

Хорошо выбирайте свою целевую аудиторию, это относится как к выступлениям на митапах, так и в подготовке презентаций/ретро/демо, да и выбору места работы.

А книжку прочитать стоит, просто для расширения кругозора :)

StarRocks 3.3.8

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

А вообще полезно читать release notes - узнал, что в SR есть динамическое партиционирование (оно же partition ttl). Где были мои глаза до этого... В итоге можно будет выкинуть очередную airflow таску на чистку партиций и заменить на внутренний механизм. Ура-ура.

А еще узнал, что можно задать лимиты на количество партиций во время чтения данных из hive или olap таблиц.

2025

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

А между тем CelerData выпустили видео с итогами 24 года и планами на 25. Основная информация на картинке - айсберг захватывает мир и трине придется потесниться. Еще в видео есть несколько кейсов от клиентов, но мне кажется что мы про них уже слышали. А так слайдов мало, но много китайского английского - не под каждое настроение зайдет.

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

Вообщем там или иначе, если кто будет в апреле на конфе, то можно поболтать.