StarRocks and modern data stack

dbt docs Мы достаточно давно живем на dbt docs в качестве единого места документации данных и метрик, и даже делали доклады на митапах. И всю дорогу ехали на предельно примитивном решении с поднятием эндпойнта `dbt docs serve`. Поборовшись в openmetadata в последний раз пару дней и оценив рынок каталогов данных, приняли решение и дальше использовать dbt в качестве единого сервиса документации. Но у него есть 2 достаточных недостатка: - скорость работы - качество поиска Проблему поиска без елки в составе решить сложно, но ее включение сразу ставит ресурсоемкость сервиса на один уровень с той же опенметадатой. А вот ускорить отдачу статики - это низко висящий фрукт. Я уже как-то делился в канале статьей ребят из дагстера, в которой они перепилили весь фронт и сократили время открытия страничек в доке до миллисекунд: https://dagster.io/blog/dbt-docs-on-react Но и проблем там хватает - чудовищный размер получаемого артифката (вместо мегабайт на выходе сотня мегабайт), отсутствие lineage на страничках, сложность сборки артефактов. В итоге сделав все по заветам доки dbt - выставив перед 3 статичными файлами nginx с хорошей степенью сжатия удалось добиться вполне удовлетворительных результатов: размер манифеста на тестируемом проекте при передаче уменьшился с 2,5 мегабайт до 240 килобайт, время открытия странички сократилось с 10 секунд до меньше чем 1 секунды. Стоило ли это сделать раньше? Пока на горизонте маячили крутые каталоги данных - оставалась надежда. Теперь ее больше нет - dbt наше всё :)

select distinct(id) from table Одна из двух самых плохих вещей, на мой взгляд, что присутствуют сейчас в StarRocks - это проблема выполнения конкурентных запросов. Если 2 запроса пришли одновременно и оба требуют большую часть предоставляемой памяти, то упадут с сообщением о нехватке ресурсов они ОБА. Это просто ужас какой-то, почему не первый из них, почему не последний из них, почему не случайный? Столько вопросов, и ответ можно найти только в кодовой базе. Поймал эту ситуацию на запуске тестов в dbt с threads = 5: unique на двух таблицах с единицами миллиардов значений на ограниченном по ресурсам пуле. Знаю, что плохо писать такие тесты, но в коробке dbt нет уника с ограничениями :) Как оказалось вообще, такие запросы - самое слабое место для SR и в документации есть несколько разделов и способов для их оптимизации: - битмапы для каунта дистинктов - апроксимизация для каунта дистинктов Так что если жить не можете без таких запросов на сотни миллионов, а еще лучше на миллиарды строк - то дважды подумайте стоит ли использовать StarRocks 😂 PS а по поводу падений одновременных запросов, мне кажется, волноваться не стоит. Так себя ведут все базы данных, у которых не хватает ресурсов - что ж с ними еще делать. Только перезапускать после освобождения. И стараться не писать такую дичь, благо для этого есть встроенный в StarRocks механизм blacklist избранных запросов.

Порой подробности релизов пугают 2 недели назад вышел новый релиз StarRocks в ветке 3.3 - 3.3.5. Список изменений можно посмотреть по этой ссылке Классно, подумал я, пора читать и обновляться и на первом же пункте я выпал в осадок:

Supports millisecond and microsecond precision in the DATETIME type.

Моя потоковая загрузка работает уже больше 2 месяцев, и в ней крайне важно наличие миллисекунд. И даже не так давно я делал пост, как ошибся с округлением. И миллисекунды в данных точно есть. Но добавили их только в 3.3.5. Что происходит то... Еще слегка напрягает разбег фичей в ветках, для 3.2 тоже вышел новый релиз с фиксами ООМ. И вот непонятно - или этих ООМ уже нет в 3.3, или их еще нет, или про них забыли.

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

Современный LakeHouse Тренд последних лет у больших ребят - соединить объектное хранилище с основным аналитическим. Ибо ну сколько можно туда-сюда копировать, нет сил больше терпеть :) И именно тут врывается presto, trino, а теперь и doris с starrocks. И не будем здесь вспоминать про готовые движки в clickhouse и greenplum, которые вполне себе быстро читают, но не могут записать. За что же выбрать StarRocks Он предлагает на выбор 2 варианта: 1. Работа с внешними каталогами и открытыми форматами хранения. То есть просто подключаешь HMS своего любимого хадупчика (или другую дичь всяких айсбергов) и можешь читать, считать и записывать данные обратно. Причем доступ к данным настраивается дополнительно на уровне самой базы данных с гранулярностью в таблицу. Почитать больше можно здесь. И вокруг будет еще огромная куча внешних каталогов вплоть до JDBC. 2. Работа внутреннего формата данных поверх объектного хранилища. Как раз для ребят с большим количеством данных или перекосом горячих/холодных - когда количество вычислительных ресурсов разбалансированно относительно ресурсов хранения данных. Для хранения можно использовать только S3-like с версии 3.1 S3 как вендоров, так и открытые реализации типа minio, либо HDFS. Тут все должны понимать, что скорость будет равна количеству хаков в обработке и размеру горячего хранилища для кешей. Почитать больше можно здесь. При всем этом в кластере StarRocks используется 2 типа инстансов для хранения и вычислений над данными: backend nodes and compute nodes. Отличаются они тем, что BE хранят данные локально на себе, а CN используются только для расчетов. В варианте один можно использовать оба типа нод, в варианте 2 так как локального хранения нет используются только CN. Минутка практики Для себя мы выбрали вариант 1. Скорость работы с хадупом через HMS позволяет отказаться от использования spark в ad-hoc запросах и сильно упрощает требования на клиентской стороне: mysql драйвер или собрать какой-нибудь pyhive в питоне - две больших разницы.

Неделя просто выносит по уровню загрузки :( Apple Silicon + современные аналитические базы данных Из свежего: развернуть локальное окружения для разработки с участием StarRocks занимает копейки на любой известной платформе: в kind на новых маках без проблем поднимается all-in-1 образ самой базы данных, следом накатываются миграции, и следом дбт прокатывает свои сиды с моделями. А вот vertica... Даже самая последняя 24.1 (или как там их новая система релизов выглядит) не имеет такой возможности. 2 дня прыжков вокруг нее. Причем эту особенность можно обойти через композ, так как он способен поднять образ с другой платформой, а вот в кубике никак нет :( Кстати, а clickhouse поднимается на армах?

У нас в компании любят стриминг и любят 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 в русскоязычной сфере технологий - так что про это будет много :) Всем спасибо за участие.