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

Привет, меня зовут Стас.
Последние 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, среди которых очень зашёл Макс Дорофеев. Раньше это слегка мучило, стоит и смотрит на меня - а теперь спрячу ее подальше :)