Starrocks and modern data stack

У нас в компании любят стриминг и любят CDC. Какие требования к функционалу влечет этот подход? - быстрые(дешевые) операции delete и update - невозможность использования движков над объектными хранилищами - транзакции для операций вставки хотя бы на уровне таблиц - возможность выполнять джойны, которые не вмещаются в память Казалось бы, vertica закрывает все эти вопросы (с достаточно сильными ограничениями в пункте 1), но непонятные перспективы развития, плата за потребляемое место и отдельный весомый счет за техническую поддержку заставляли искать замену. И если 3-4 года назад на рынке кроме greenplum альтернатив не было, то все изменилось после появления StarRocks. Тут стоит раскрыть, почему не слива и почему не дорис, ведь оба существуют на рынке достаточно давно. Почему не Apache Doris В дорис существует 3 основных и несколько дополнительных(типа работы с внешними каталогами) движков для работы с данными. До 2022 года основной движок Unique Key мог похвастаться только MoR (merge-on-read) механизмом для мутаций, все как в кликхаузе с его загонами. И только в 1.2 был реализован MoW (merge-on-write), который на порядки увеличил скорость таких операций. И тут минутка про StarRocks: форк произошел задолго до добавления этого функционала, и они не стали переделывать текущую реализацию написав новую - Primary Key. Именно поэтому сейчас функционал Unique Key таблиц в обеих базах сильно отличается, хотя носит одинаковое название. Не знаю кто у кого подсмотрел реализацию, но сейчас по функционалу Unique Key в Doris и Primary Key в StarRocks - близнецы. Быстрый upsert по умолчанию с возможностью partial update во время вставки. Больше прочитать про реализацию можно здесь. Но такое эволюционное развитие играет злую шутку - помня все старые ограничения движков и не учитывая бешенное развитие проекта, для меня он ушел в тень StarRocks. А еще мне понравились цифры с доклада авито с смартдаты за 2023 год - если честно я так и не понял причины выбора ими trino. Почему не Greenplum Идея с постгресами была классная, но жизнь показала, что все не так просто. Мой опыт ограничивается установкой ванильной версии в 20 году, и постоянной нестабильностью того кластера. При этом архитектура самой базы данных устарела еще 5 лет назад, а требования к железу и показываемая производительность не вдохновляли вовсе - особенно на фоне вертики. А дальше произошла череда покупок-продаж, в результате которых мы и вовсе остались ни с чем - на руках единицы реализаций локальных вендоров и очень туманные перспективы (можно было бы сказать их отсутствие).

Хорошо ходить в отпуск, пусть даже отпуск и в ноябре :) Apache Doris vs Starrocks Для человека со стороны различия между двумя этими базами данных совсем непонятны. И вот уже более 3 недель готовился написать статью о различиях: в каком случае выбирать одно, а в каком другое. Но время решает за нас - развитие обеих баз летит вперед как starship Элона Маска, и 2 важных отличия между ними, которые привели к выбору starrocks для внедрения, обнулились :( То есть в марте-апреле даже вопроса для движка нового поколения lakehouse/dwh не стояло, то в ноябре надо тестировать и ванговать кто победит в гонке за общественное мнение в будущем. Вот такой вот спойлер следующего цикла постов про причину выбора starrocks и краткого описания аналогичного функционала в doris. Минутка истории В комментариях к недавнему посту сбросили статью от одного из разработчиков дорис с немного обиженным отношением к starrocks - советую почитать, а вот цитата:

Да, прошло четыре года с момента первого форка. И Apache Doris, и StarRocks выросли и развились по-своему. Хотя у них много общих функций, они достигли разных уровней зрелости, что мы признаем.

Кратко: 4 года назад часть разработчиков Apache Doris отделились и захотели развивать его по своему (и надо сказать, что сам дорис 4 года назад представлял не очень веселое зрелище по темпам развития). Так появилась сначала DorisDB, а из нее Starrocks. И если вы посмотрите в документацию, то много различий там не найдете. Особенно сейчас, когда в обе базы стали вливать много, очень много ресурсов и денег.

#офтоп Я знаком с питоном последние лет 10, а за код на нем получаю деньги уже лет 8. Но только примерно год или полтора назад ощутил, что его уровень сильно повысился до приемлемого уровня. Когда ты уже не скрипт программист, а нормальный писатель уровня мидл. И дело не в том, что мне стали сниться сны на asyncio или я стал рассказывать устройство GIL детям перед сном вместо сказки, а скорее вышел рывок в понимании как легче код будет прочтен, как идеоматично писать тот или иной кусок. Есть несколько причин, среди которых и работа на golang, и книга с фотографии выше. Ее чтение мне доставило большое удовольствие, несмотря на простоту или размеры, и даже приходилось себя останавливать в скорости чтения для лучшего усвоения. А вот вторую книгу я прочитать не смог. Там котики, там лёгкая подача материала, там важные вещи. Сейчас активно выходят видео докладов с прошедшего codefest, среди которых очень зашёл Макс Дорофеев. Раньше это слегка мучило, стоит и смотрит на меня - а теперь спрячу ее подальше :)

Закрывая историю про сервисы миграций, у меня перед началом использования starrocks были большие надежды на обещанную совместимость с диалектом mysql и его драйверами.  Mysql диалект Ожидания оправдались на 85%, на текущий момент существует такие отличия: - ddl создания таблиц отличаются сильно - prepared statement существую, но в очень специфичном виде - в основных десктопных клиентах (dbeaver, datagrip) обрезаются миллисекунды для datetime. И это странно, потому что по стандарту для mysql они могут там быть Cервисы миграций В итоге пришлось дописывать поддержку диалекта в отличный гошный проект goose (и не смотря на небольшое сопротивление диалект был добавлен быстро под давлением сообщества - сюрприз, сюрприз). Картинка как раз из него. Если вам не нужен монстр типа Liquibase, а надо просто чтобы работало всегда и везде - советую. Особенно совместно miga, в которой достаточно прописать в конфиге подключение к базе данных и указать путь к каталогу с миграциями.

Мелочи, о которых не задумываешься Сравнений с кликхаузом и дальше будет много, но тут изображен тот редкий кейс его большей продуманности (либо следованию стандартным практикам в написании баз данных). Угадаете? :) Предсозданная база данных по умолчанию, которая доступна для работы пользователям - default. Только во время подготовки стендов разработки и стейджа я оценил насколько эта маленькая незаметная штука божественна. Современный подход к разработке в бд Каждый сервис, который работает с базой данных должен иметь свой дев стенд с последней версией мета информации продакшена, и далее после выкатки в UAT ситуация повторяется. Этого достаточно легко реализовать при помощи сервисов миграции и dbt. НО современный сервис миграции как правило хранит свое состояние в самой базе данных, к которой применяется. И в starrocks НЕТ схемы по-умолчанию, доступной для записи сервису. В итоге пришлось делать форк helm chart кластера для реализации такой мелочи, а для all-in-1 образов городить помощников. Культура разработки? Отрицание догм? Невнимательность? Широта китайской души? Наследие от Apache Doris :)

Про мощь тестов и кафку в старроксе. Абсолютно случайно обнаружил интересную проблему в недавно заведенном потоке данных в starrocks - время в строчке отличалось от целевого на 1 секунду примерно в 50% случаев. Путем долгого копания и проверки исходных данных конечно я вышел на самого себя - картинка в заголовке ровно про это :) А теперь откуда растут корни такого странного запроса. В starrocks есть встроенный способ загрузки потоковых данных из kafka в таблички без всяких промежуточных таблиц и прочего непотребства - routine load. Работает быстро, стабильно, с небольшой нагрузкой, и даже умеет делать обновление по условию. Но есть и ряд недостатков: - нельзя фильтровать данные по полю, которого нет в итоговой табличке (на примере снизу event_name), но при этом можно отбрасывать использованные в других функциях колонки (payload) - несмотря на большие количество функций по работе с временем нельзя получить datetime с миллисекундами из unixtime с миллисекундами И про тесты: несмотря на двойной заслон тестов - мы поднимаем каждое новое задание через дев стенд и полные интеграционные тесты с прогоном fuzz данных, а далее потоковые данные по возможности сверяем с осевшими на проде - баг с картинки был пропущен :) Известная поговорка: тесты позволяют найти старые проблемы...

CREATE ROUTINE LOAD dds.quotes ON quotes
COLUMNS(
    event_name
    , payload
    , project=JSON_QUERY(payload, '$.project')
    , pair=JSON_QUERY(payload, '$.code')
    , ts=TIMESTAMPADD(MILLISECOND, cast(substring(cast(JSON_QUERY(payload, '$.timestamp_ms') as varchar(13)), -3) as int), FROM_UNIXTIME(CAST(JSON_QUERY(payload, '$.timestamp_ms') AS BIGINT) / 1000))
    , ask=JSON_QUERY(payload, '$.ask')
    , bid=JSON_QUERY(payload, '$.bid')
    , mid=JSON_QUERY(payload, '$.mid')
),
WHERE event_name = 'ticks.platform'
PROPERTIES (
    "max_batch_interval"="30",
    "format"="json",
    "jsonpaths"="[\"$.event_name\",\"$.payload\"]",
    "timezone"="Europe/Moscow"
)
FROM KAFKA (
    "kafka_broker_list"="kafka-main:9092",
    "kafka_topic"="ticks.platform",
    "property.kafka_default_offsets"="OFFSET_BEGINNING",
    "property.group.id"="dp_sr_quotes"
);

Пост-знакомство Привет, меня зовут Стас. Последние 7 лет я занимаюсь платформами данных - от хадупов в телекоме и проме до гибких платформ в среднем бизнесе. 3 года развиваю канал про dbt & modern data stack, люблю устраивать, проводить и участвовать в митапах: dbt meetups, x5 openmetadata meetup, rostelecom nifi meetup, croc bigdata meetup... Канал про DBT сильно вырос и стало не всегда удобно делиться мыслями, достижениями и интересностями в нем - поэтому появился этот канал. А еще наша команда сейчас занимается одним из первых внедрений интересной аналитической базы данных starrocks в русскоязычной сфере технологий - так что про это будет много :) Всем спасибо за участие.