Пост-знакомство

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

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

Всем спасибо за участие.

Про мощь тестов и кафку в старроксе.

Абсолютно случайно обнаружил интересную проблему в недавно заведенном потоке данных в 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"
);

Мелочи, о которых не задумываешься

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

Угадаете? :) Предсозданная база данных по умолчанию, которая доступна для работы пользователям - default.

Только во время подготовки стендов разработки и стейджа я оценил насколько эта маленькая незаметная штука божественна.

Современный подход к разработке в бд

Каждый сервис, который работает с базой данных должен иметь свой дев стенд с последней версией мета информации продакшена, и далее после выкатки в UAT ситуация повторяется.
Этого достаточно легко реализовать при помощи сервисов миграции и dbt.
НО современный сервис миграции как правило хранит свое состояние в самой базе данных, к которой применяется. И в starrocks НЕТ схемы по-умолчанию, доступной для записи сервису.

В итоге пришлось делать форк helm chart кластера для реализации такой мелочи, а для all-in-1 образов городить помощников.

Культура разработки? Отрицание догм? Невнимательность? Широта китайской души? Наследие от Apache Doris :)

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

 Mysql диалект

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

Cервисы миграций

В итоге пришлось дописывать поддержку диалекта в отличный гошный проект goose (и не смотря на небольшое сопротивление диалект был добавлен быстро под давлением сообщества - сюрприз, сюрприз). Картинка как раз из него.
Если вам не нужен монстр типа Liquibase, а надо просто чтобы работало всегда и везде - советую. Особенно совместно miga, в которой достаточно прописать в конфиге подключение к базе данных и указать путь к каталогу с миграциями.

#офтоп

Я знаком с питоном последние лет 10, а за код на нем получаю деньги уже лет 8. Но только примерно год или полтора назад ощутил, что его уровень сильно повысился до приемлемого уровня. Когда ты уже не скрипт программист, а нормальный писатель уровня мидл. И дело не в том, что мне стали сниться сны на asyncio или я стал рассказывать устройство GIL детям перед сном вместо сказки, а скорее вышел рывок в понимании как легче код будет прочтен, как идеоматично писать тот или иной кусок. Есть несколько причин, среди которых и работа на golang, и книга с фотографии выше. Ее чтение мне доставило большое удовольствие, несмотря на простоту или размеры, и даже приходилось себя останавливать в скорости чтения для лучшего усвоения.

А вот вторую книгу я прочитать не смог. Там котики, там лёгкая подача материала, там важные вещи. Сейчас активно выходят видео докладов с прошедшего codefest, среди которых очень зашёл Макс Дорофеев. Раньше это слегка мучило, стоит и смотрит на меня - а теперь спрячу ее подальше :)

Хорошо ходить в отпуск, пусть даже отпуск и в ноябре :)

Apache Doris vs Starrocks

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

Минутка истории

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

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

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

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

Неделя просто выносит по уровню загрузки :(

Apple Silicon + современные аналитические базы данных

Из свежего: развернуть локальное окружения для разработки с участием StarRocks занимает копейки на любой известной платформе: в kind на новых маках без проблем поднимается all-in-1 образ самой базы данных, следом накатываются миграции, и следом дбт прокатывает свои сиды с моделями.

А вот vertica... Даже самая последняя 24.1 (или как там их новая система релизов выглядит) не имеет такой возможности. 2 дня прыжков вокруг нее. Причем эту особенность можно обойти через композ, так как он способен поднять образ с другой платформой, а вот в кубике никак нет :(

Кстати, а clickhouse поднимается на армах?

Современный 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 в питоне - две больших разницы.

Поддержал рублем Алексея, все-таки с его докладов пришло понимание о выжигающей роли современного скрама.

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

Так что по сути вся книга - опечатанные в буквы выступления с хорошей полиграфией. Очень много слышал и видел, и если не хочется тратить часов 10-15 на просмотр ютуба - то, что надо для понимания канбана.

Порой подробности релизов пугают

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

Supports millisecond and microsecond precision in the DATETIME type.

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

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

select distinct(id) from table

Одна из двух самых плохих вещей, на мой взгляд, что присутствуют сейчас в StarRocks - это проблема выполнения конкурентных запросов. Если 2 запроса пришли одновременно и оба требуют большую часть предоставляемой памяти, то упадут с сообщением о нехватке ресурсов они ОБА. Это просто ужас какой-то, почему не первый из них, почему не последний из них, почему не случайный? Столько вопросов, и ответ можно найти только в кодовой базе.

Поймал эту ситуацию на запуске тестов в dbt с threads = 5: unique на двух таблицах с единицами миллиардов значений на ограниченном по ресурсам пуле. Знаю, что плохо писать такие тесты, но в коробке dbt нет уника с ограничениями :)

Как оказалось вообще, такие запросы - самое слабое место для SR и в документации есть несколько разделов и способов для их оптимизации:
- битмапы для каунта дистинктов
- апроксимизация для каунта дистинктов
Так что если жить не можете без таких запросов на сотни миллионов, а еще лучше на миллиарды строк - то дважды подумайте стоит ли использовать StarRocks 😂

PS а по поводу падений одновременных запросов, мне кажется, волноваться не стоит. Так себя ведут все базы данных, у которых не хватает ресурсов - что ж с ними еще делать. Только перезапускать после освобождения. И стараться не писать такую дичь, благо для этого есть встроенный в StarRocks механизм blacklist избранных запросов.

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 наше всё :)

Вторая плохая вещь в StarRocks

Если почитать чатик https://news.1rj.ru/str/hadoopusers, то почти все при слове StarRocks начинают рассказывать про китайский язык, отсутствие сообщества и отсутствие успешных внедрений в компаниях 1 ранга в своих отраслях. И кажется, что это и есть та самая вторая плохая вещь.

Но нет.

Документация в проекте находится на достаточно зрелом уровне, в крайнем случае в вашем доступе есть гитхаб с примерами кода - например, транзакционная загрузку через API там есть в 3 или 4 вариантах. Или вот есть репа с demo.
Китайский язык вам понадобится только в случае жесткого дебага, скорее всего вы уйдете на китайские форумы где уже встречали такие баги. Но опять же, документация на английском + код покрывают этот кейс.
История про внедрения: ютуб завален видосами. Там и про сравнение с кликхаузом, и про будущее датабрикс + старрокс, и про опыт внедрения в компаниях разного масштаба. Не говоря о росте вакансий на hh.ru - там теперь целых 5 вакансий по сравнению с 1 в конце лета 😂

А теперь серьезно: я наткнулся на регресс в ветке 3.3 по отношению к 3.2 - констрейнты просто не работали :) 9 сентября создал ишью, через 15 минут баг подтвердили, на следующий рабочий день был готов код с фиксом, и итоговая версия с фиксом вышла через пару недель.

Ребят, да ладно, кто из вендоров сейчас вам настолько быстро поможет? :) Мертвый чат вертики? Разработка кликхауза, в которой транзакции не могут победить 5+ лет? :)

А что плохого то? А как раз пропуск вот таких глобальных багов в продакшн. Скорость разработки очень высокая, релизы идут раз-полтора в месяц и фичи поставлены в приоритет над стабильностью. Это требует со стороны внедрения затрат на предварительное тестирование перед обновлением.

staff engineer и его путь

Два дня argo+helm программирования изнасиловали мой мозг и теперь остается только текстики писать для расслабухи.

Посмотрел видео от ребят из Т Code of Leadership #6 - Staff+ инженеры, как мы их растим внутри и нанимаем с рынка: разговор о той самой мифической ветки развития в техничку после синьора помидора и какие занимательные конкурсы придумали в самом "техничном" банке на просторах всея РФ. Минут на 30 завис в мыслях, что же так не понравилось в нем и почему традиционно получилось казаться, а не быть.
Самое ценное во всем видео - иллюстрация из книги Staff engineer от Will Larson. Да, вот с этим я абсолютно согласен.

И даже натяну свою реальность на картинку с маленькими дополнениями:
- Solver - решатель проблем и человек уникального знания куда надо ударить. Ценный staff engineer, который при этом вообще не ходит на собеседования на рынке. Это к нему приходят люди с чемоданом денег и просьбой помочь. Ау, где вы админы хадупа в 24 году с умением настроить ATSv2 и kerberos за 2 недели.
- Right hand - правая рука. Все мы знаем, что путь в архитекторы лежит через постель с CTO. Чаще всего он приглядывает за командами за заслуги, или его нанимают чтобы приглядел. На собеседования тоже не ходит, он довесок к руководителю.

А теперь спорные ребята, на мой взгляд про одно и тоже, но в разных масштабах:
- Techlead - на мой взгляд, построение новой команды начинается как раз с техлида в основе, компетенции от которого дальше распространяются по самой команде. И даже если первым внедряющим кликхауз оказался случайно Вася-пхпист, то скорее всего знаний у него будет больше окружающих. Тянет ли техлид на стафа - вроде нет. Стоит ли эту роль гонять по придуманным собесам - тоже вроде нет.
- Architect - мечта всех 20 летних юношей. Есть ли польза брать архитекторов со стороны для компании - нет. Человек высоких материй просто не сможет со стороны зайти и получить нужную глубину знаний. Мы все видели ребят из выскоких замков, которые рисуют красивые презы или умеют писать тайные письмена архитекторов, но где та польза? Полезный архитектор вырос в компании, за время работы поработал со многими людьми (что обеспечивает необходимый для изменений социальный вес), поработал со многими системами (что обеспечивает нужный уровень знаний что надо менять, что не надо менять, где есть проблемы на миллион, а где мы строим космолет из прихоти). Поэтому может собесить его и надо, но не стоит.
Плюс к этому любой найм с рынка на такие роли сильно бьет по внутренним компетенциям и амбициям молодежи, а ведь именно для удержания людей и придумали эти громкие титулы.

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

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

Конференции

На почту упало письмо от ребят из Онтико о приеме докладов на DevOpsConf 2025. Немножко подумал для приличия день и отправил доклад по внедрению в платформу данных StarRocks. Вполне резонно возникает вопрос - почему эта конференция то? :)

Если судить по развитию аналитического окружения, и да и вообще появлению этих самых платформ данных - всё идет следом за основными трендами во взрослой разработке: сервисы миграций, появился dbt, который в версии 1.9 принесет нам еще и unit тесты, стенды разработки и приемочные стенды, построение зависимостей между сервисами поставки и потребления. Да и где еще обсуждать способы подключенния систем хранения в кубернетисе, не на смартдате же? :)

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

Посмотрим, что скажет программный комитет, в тренде оно все или нет...

А как выглядит ваша репа dbt?

В начале внедрения мы несколько раз меняли подходы к размещению и именованию объектов в dbt и в итоге со временем выработали свой подход и обоснование, почему всё так. А потом года через 2 к нам пришел очень классный человек Антон и вполне обосновано не согласился - у него был свой опыт и свое обоснование.

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

Но каждый раз когда аналитики открывают репу их встречает вот такая пугающая картина, и она мало связана с sql :)

Тащу все наши проекты dbt (сейчас их 6) в новый гитлаб с новым ci, с новыми окружениями и тестированием. Опять же переход с тестирования на баше в обвязку на питоне смотрится приятно.