StarRocks and modern data stack

Кому бы дать деньги

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

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

И да, это пост - не реклама (не видать мне мерседеса еще долго видимо) :)

Трино против (или вместе)

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

А между тем поток видео на канале cleverdata стал каким-то безумным - видимо финансовый год подходит к концу и настала пора пиарить успехи. Вот Grab отчитался, как starrocks ускорил построение отчетов в superset по сравнению с trino. И смешно видеть опять историю про написание своего гейтвея к трино - все говорят про это узкое место (и авито говорило при внедрении, и тинек), и вместо стандарта каждый пилит свое. Вообщем примерно в 10 раз быстрее стало - можете сами посмотреть

Для тех, кто не любит видео есть слайды

Из своего опыта тоже набрали кое-что, попозже напишу.

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

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

2025

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

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

StarRocks 3.3.8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Линус, linux и opensource

Честно взял картинку у https://t.me/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 не нашли себе дома в виде сообщества или фаундейшена. Продавать коробку или облако - пожалуйста, но сделать для него удобные инструменты - не то что денег нет, а мозгов нет. Вроде из требований просто создать репу и договориться, что теперь патчи присылать сюда. Поэтому каждый пользователь ГП допиливает гитхаб Марка как умеет.

StarRocks 3.3.7 & 3.2.13

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

Где 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"
);

Дичь же? :)

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

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

Свои форки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О чем умолчал

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

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

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

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

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

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

Epic fail

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

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