Про мощь тестов и кафку в старроксе.
Абсолютно случайно обнаружил интересную проблему в недавно заведенном потоке данных в starrocks - время в строчке отличалось от целевого на 1 секунду примерно в 50% случаев. Путем долгого копания и проверки исходных данных конечно я вышел на самого себя - картинка в заголовке ровно про это :)
А теперь откуда растут корни такого странного запроса.
В starrocks есть встроенный способ загрузки потоковых данных из kafka в таблички без всяких промежуточных таблиц и прочего непотребства - routine load. Работает быстро, стабильно, с небольшой нагрузкой, и даже умеет делать обновление по условию.
Но есть и ряд недостатков:
- нельзя фильтровать данные по полю, которого нет в итоговой табличке (на примере снизу event_name), но при этом можно отбрасывать использованные в других функциях колонки (payload)
- несмотря на большие количество функций по работе с временем нельзя получить datetime с миллисекундами из unixtime с миллисекундами
И про тесты: несмотря на двойной заслон тестов - мы поднимаем каждое новое задание через дев стенд и полные интеграционные тесты с прогоном fuzz данных, а далее потоковые данные по возможности сверяем с осевшими на проде - баг с картинки был пропущен :) Известная поговорка: тесты позволяют найти старые проблемы...
Абсолютно случайно обнаружил интересную проблему в недавно заведенном потоке данных в 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"
);
👍6❤1🔥1
Мелочи, о которых не задумываешься
Сравнений с кликхаузом и дальше будет много, но тут изображен тот редкий кейс его большей продуманности (либо следованию стандартным практикам в написании баз данных).
Угадаете? :) Предсозданная база данных по умолчанию, которая доступна для работы пользователям - default.
Только во время подготовки стендов разработки и стейджа я оценил насколько эта маленькая незаметная штука божественна.
Современный подход к разработке в бд
Каждый сервис, который работает с базой данных должен иметь свой дев стенд с последней версией мета информации продакшена, и далее после выкатки в UAT ситуация повторяется.
Этого достаточно легко реализовать при помощи сервисов миграции и dbt.
НО современный сервис миграции как правило хранит свое состояние в самой базе данных, к которой применяется. И в starrocks НЕТ схемы по-умолчанию, доступной для записи сервису.
В итоге пришлось делать форк helm chart кластера для реализации такой мелочи, а для all-in-1 образов городить помощников.
Культура разработки? Отрицание догм? Невнимательность? Широта китайской души? Наследие от Apache Doris :)
Сравнений с кликхаузом и дальше будет много, но тут изображен тот редкий кейс его большей продуманности (либо следованию стандартным практикам в написании баз данных).
Угадаете? :) Предсозданная база данных по умолчанию, которая доступна для работы пользователям - default.
Только во время подготовки стендов разработки и стейджа я оценил насколько эта маленькая незаметная штука божественна.
Современный подход к разработке в бд
Каждый сервис, который работает с базой данных должен иметь свой дев стенд с последней версией мета информации продакшена, и далее после выкатки в UAT ситуация повторяется.
Этого достаточно легко реализовать при помощи сервисов миграции и dbt.
НО современный сервис миграции как правило хранит свое состояние в самой базе данных, к которой применяется. И в starrocks НЕТ схемы по-умолчанию, доступной для записи сервису.
В итоге пришлось делать форк helm chart кластера для реализации такой мелочи, а для all-in-1 образов городить помощников.
Закрывая историю про сервисы миграций, у меня перед началом использования starrocks были большие надежды на обещанную совместимость с диалектом mysql и его драйверами.
Mysql диалект
Ожидания оправдались на 85%, на текущий момент существует такие отличия:
- ddl создания таблиц отличаются сильно
- prepared statement существую, но в очень специфичном виде
- в основных десктопных клиентах (dbeaver, datagrip) обрезаются миллисекунды для datetime. И это странно, потому что по стандарту для mysql они могут там быть
Cервисы миграций
В итоге пришлось дописывать поддержку диалекта в отличный гошный проект goose (и не смотря на небольшое сопротивление диалект был добавлен быстро под давлением сообщества - сюрприз, сюрприз). Картинка как раз из него.
Если вам не нужен монстр типа Liquibase, а надо просто чтобы работало всегда и везде - советую. Особенно совместно miga, в которой достаточно прописать в конфиге подключение к базе данных и указать путь к каталогу с миграциями.
Mysql диалект
Ожидания оправдались на 85%, на текущий момент существует такие отличия:
- ddl создания таблиц отличаются сильно
- prepared statement существую, но в очень специфичном виде
- в основных десктопных клиентах (dbeaver, datagrip) обрезаются миллисекунды для datetime. И это странно, потому что по стандарту для mysql они могут там быть
Cервисы миграций
В итоге пришлось дописывать поддержку диалекта в отличный гошный проект goose (и не смотря на небольшое сопротивление диалект был добавлен быстро под давлением сообщества - сюрприз, сюрприз). Картинка как раз из него.
Если вам не нужен монстр типа Liquibase, а надо просто чтобы работало всегда и везде - советую. Особенно совместно miga, в которой достаточно прописать в конфиге подключение к базе данных и указать путь к каталогу с миграциями.
👍3
#офтоп
Я знаком с питоном последние лет 10, а за код на нем получаю деньги уже лет 8. Но только примерно год или полтора назад ощутил, что его уровень сильно повысился до приемлемого уровня. Когда ты уже не скрипт программист, а нормальный писатель уровня мидл. И дело не в том, что мне стали сниться сны на asyncio или я стал рассказывать устройство GIL детям перед сном вместо сказки, а скорее вышел рывок в понимании как легче код будет прочтен, как идеоматично писать тот или иной кусок. Есть несколько причин, среди которых и работа на golang, и книга с фотографии выше. Ее чтение мне доставило большое удовольствие, несмотря на простоту или размеры, и даже приходилось себя останавливать в скорости чтения для лучшего усвоения.
А вот вторую книгу я прочитать не смог. Там котики, там лёгкая подача материала, там важные вещи. Сейчас активно выходят видео докладов с прошедшего codefest, среди которых очень зашёл Макс Дорофеев. Раньше это слегка мучило, стоит и смотрит на меня - а теперь спрячу ее подальше :)
Я знаком с питоном последние лет 10, а за код на нем получаю деньги уже лет 8. Но только примерно год или полтора назад ощутил, что его уровень сильно повысился до приемлемого уровня. Когда ты уже не скрипт программист, а нормальный писатель уровня мидл. И дело не в том, что мне стали сниться сны на asyncio или я стал рассказывать устройство GIL детям перед сном вместо сказки, а скорее вышел рывок в понимании как легче код будет прочтен, как идеоматично писать тот или иной кусок. Есть несколько причин, среди которых и работа на golang, и книга с фотографии выше. Ее чтение мне доставило большое удовольствие, несмотря на простоту или размеры, и даже приходилось себя останавливать в скорости чтения для лучшего усвоения.
А вот вторую книгу я прочитать не смог. Там котики, там лёгкая подача материала, там важные вещи. Сейчас активно выходят видео докладов с прошедшего codefest, среди которых очень зашёл Макс Дорофеев. Раньше это слегка мучило, стоит и смотрит на меня - а теперь спрячу ее подальше :)
❤1
Хорошо ходить в отпуск, пусть даже отпуск и в ноябре :)
Apache Doris vs Starrocks
Для человека со стороны различия между двумя этими базами данных совсем непонятны. И вот уже более 3 недель готовился написать статью о различиях: в каком случае выбирать одно, а в каком другое.
Но время решает за нас - развитие обеих баз летит вперед как starship Элона Маска, и 2 важных отличия между ними, которые привели к выбору starrocks для внедрения, обнулились :( То есть в марте-апреле даже вопроса для движка нового поколения lakehouse/dwh не стояло, то в ноябре надо тестировать и ванговать кто победит в гонке за общественное мнение в будущем.
Вот такой вот спойлер следующего цикла постов про причину выбора starrocks и краткого описания аналогичного функционала в doris.
Минутка истории
В комментариях к недавнему посту сбросили статью от одного из разработчиков дорис с немного обиженным отношением к starrocks - советую почитать, а вот цитата:
Кратко: 4 года назад часть разработчиков Apache Doris отделились и захотели развивать его по своему (и надо сказать, что сам дорис 4 года назад представлял не очень веселое зрелище по темпам развития). Так появилась сначала DorisDB, а из нее Starrocks. И если вы посмотрите в документацию, то много различий там не найдете. Особенно сейчас, когда в обе базы стали вливать много, очень много ресурсов и денег.
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 лет назад, а требования к железу и показываемая производительность не вдохновляли вовсе - особенно на фоне вертики. А дальше произошла череда покупок-продаж, в результате которых мы и вовсе остались ни с чем - на руках единицы реализаций локальных вендоров и очень туманные перспективы (можно было бы сказать их отсутствие).
- быстрые(дешевые) операции 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 лет назад, а требования к железу и показываемая производительность не вдохновляли вовсе - особенно на фоне вертики. А дальше произошла череда покупок-продаж, в результате которых мы и вовсе остались ни с чем - на руках единицы реализаций локальных вендоров и очень туманные перспективы (можно было бы сказать их отсутствие).
👍2❤1🔥1
Неделя просто выносит по уровню загрузки :(
Apple Silicon + современные аналитические базы данных
Из свежего: развернуть локальное окружения для разработки с участием StarRocks занимает копейки на любой известной платформе: в kind на новых маках без проблем поднимается all-in-1 образ самой базы данных, следом накатываются миграции, и следом дбт прокатывает свои сиды с моделями.
А вот vertica... Даже самая последняя 24.1 (или как там их новая система релизов выглядит) не имеет такой возможности. 2 дня прыжков вокруг нее. Причем эту особенность можно обойти через композ, так как он способен поднять образ с другой платформой, а вот в кубике никак нет :(
Кстати, а clickhouse поднимается на армах?
Apple Silicon + современные аналитические базы данных
Из свежего: развернуть локальное окружения для разработки с участием StarRocks занимает копейки на любой известной платформе: в kind на новых маках без проблем поднимается all-in-1 образ самой базы данных, следом накатываются миграции, и следом дбт прокатывает свои сиды с моделями.
А вот vertica... Даже самая последняя 24.1 (или как там их новая система релизов выглядит) не имеет такой возможности. 2 дня прыжков вокруг нее. Причем эту особенность можно обойти через композ, так как он способен поднять образ с другой платформой, а вот в кубике никак нет :(
Кстати, а clickhouse поднимается на армах?
🤯1
Современный 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 в питоне - две больших разницы.
Тренд последних лет у больших ребят - соединить объектное хранилище с основным аналитическим. Ибо ну сколько можно туда-сюда копировать, нет сил больше терпеть :) И именно тут врывается 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 в питоне - две больших разницы.
👍2👀1
Поддержал рублем Алексея, все-таки с его докладов пришло понимание о выжигающей роли современного скрама.
Практически каждый абзац в книге отдавался в ушах его голосом с очередного выступления на конференции. И если смотреть их большую часть года этак с 2018 - то бонусом в голове еще останутся разборы вопросов, которые возникают.
Так что по сути вся книга - опечатанные в буквы выступления с хорошей полиграфией. Очень много слышал и видел, и если не хочется тратить часов 10-15 на просмотр ютуба - то, что надо для понимания канбана.
Практически каждый абзац в книге отдавался в ушах его голосом с очередного выступления на конференции. И если смотреть их большую часть года этак с 2018 - то бонусом в голове еще останутся разборы вопросов, которые возникают.
Так что по сути вся книга - опечатанные в буквы выступления с хорошей полиграфией. Очень много слышал и видел, и если не хочется тратить часов 10-15 на просмотр ютуба - то, что надо для понимания канбана.
👍5
Порой подробности релизов пугают
2 недели назад вышел новый релиз StarRocks в ветке 3.3 - 3.3.5. Список изменений можно посмотреть по этой ссылке
Классно, подумал я, пора читать и обновляться и на первом же пункте я выпал в осадок:
Моя потоковая загрузка работает уже больше 2 месяцев, и в ней крайне важно наличие миллисекунд. И даже не так давно я делал пост, как ошибся с округлением. И миллисекунды в данных точно есть. Но добавили их только в 3.3.5. Что происходит то...
Еще слегка напрягает разбег фичей в ветках, для 3.2 тоже вышел новый релиз с фиксами ООМ. И вот непонятно - или этих ООМ уже нет в 3.3, или их еще нет, или про них забыли.
2 недели назад вышел новый релиз StarRocks в ветке 3.3 - 3.3.5. Список изменений можно посмотреть по этой ссылке
Классно, подумал я, пора читать и обновляться и на первом же пункте я выпал в осадок:
Supports millisecond and microsecond precision in the DATETIME type.
Моя потоковая загрузка работает уже больше 2 месяцев, и в ней крайне важно наличие миллисекунд. И даже не так давно я делал пост, как ошибся с округлением. И миллисекунды в данных точно есть. Но добавили их только в 3.3.5. Что происходит то...
Еще слегка напрягает разбег фичей в ветках, для 3.2 тоже вышел новый релиз с фиксами ООМ. И вот непонятно - или этих ООМ уже нет в 3.3, или их еще нет, или про них забыли.
❤1👍1🔥1
select distinct(id) from table
Одна из двух самых плохих вещей, на мой взгляд, что присутствуют сейчас в StarRocks - это проблема выполнения конкурентных запросов. Если 2 запроса пришли одновременно и оба требуют большую часть предоставляемой памяти, то упадут с сообщением о нехватке ресурсов они ОБА. Это просто ужас какой-то, почему не первый из них, почему не последний из них, почему не случайный? Столько вопросов, и ответ можно найти только в кодовой базе.
Поймал эту ситуацию на запуске тестов в dbt с threads = 5: unique на двух таблицах с единицами миллиардов значений на ограниченном по ресурсам пуле. Знаю, что плохо писать такие тесты, но в коробке dbt нет уника с ограничениями :)
Как оказалось вообще, такие запросы - самое слабое место для SR и в документации есть несколько разделов и способов для их оптимизации:
- битмапы для каунта дистинктов
- апроксимизация для каунта дистинктов
Так что если жить не можете без таких запросов на сотни миллионов, а еще лучше на миллиарды строк - то дважды подумайте стоит ли использовать StarRocks 😂
PS а по поводу падений одновременных запросов, мне кажется, волноваться не стоит. Так себя ведут все базы данных, у которых не хватает ресурсов - что ж с ними еще делать. Только перезапускать после освобождения. И стараться не писать такую дичь, благо для этого есть встроенный в StarRocks механизм blacklist избранных запросов.
Одна из двух самых плохих вещей, на мой взгляд, что присутствуют сейчас в StarRocks - это проблема выполнения конкурентных запросов. Если 2 запроса пришли одновременно и оба требуют большую часть предоставляемой памяти, то упадут с сообщением о нехватке ресурсов они ОБА. Это просто ужас какой-то, почему не первый из них, почему не последний из них, почему не случайный? Столько вопросов, и ответ можно найти только в кодовой базе.
Поймал эту ситуацию на запуске тестов в dbt с threads = 5: unique на двух таблицах с единицами миллиардов значений на ограниченном по ресурсам пуле. Знаю, что плохо писать такие тесты, но в коробке dbt нет уника с ограничениями :)
Как оказалось вообще, такие запросы - самое слабое место для SR и в документации есть несколько разделов и способов для их оптимизации:
- битмапы для каунта дистинктов
- апроксимизация для каунта дистинктов
Так что если жить не можете без таких запросов на сотни миллионов, а еще лучше на миллиарды строк - то дважды подумайте стоит ли использовать StarRocks 😂
PS а по поводу падений одновременных запросов, мне кажется, волноваться не стоит. Так себя ведут все базы данных, у которых не хватает ресурсов - что ж с ними еще делать. Только перезапускать после освобождения. И стараться не писать такую дичь, благо для этого есть встроенный в StarRocks механизм blacklist избранных запросов.
👍4
dbt docs
Мы достаточно давно живем на dbt docs в качестве единого места документации данных и метрик, и даже делали доклады на митапах. И всю дорогу ехали на предельно примитивном решении с поднятием эндпойнта `
Но у него есть 2 достаточных недостатка:
- скорость работы
- качество поиска
Проблему поиска без елки в составе решить сложно, но ее включение сразу ставит ресурсоемкость сервиса на один уровень с той же опенметадатой. А вот ускорить отдачу статики - это низко висящий фрукт. Я уже как-то делился в канале статьей ребят из дагстера, в которой они перепилили весь фронт и сократили время открытия страничек в доке до миллисекунд: https://dagster.io/blog/dbt-docs-on-react Но и проблем там хватает - чудовищный размер получаемого артифката (вместо мегабайт на выходе сотня мегабайт), отсутствие lineage на страничках, сложность сборки артефактов.
В итоге сделав все по заветам доки dbt - выставив перед 3 статичными файлами nginx с хорошей степенью сжатия удалось добиться вполне удовлетворительных результатов: размер манифеста на тестируемом проекте при передаче уменьшился с 2,5 мегабайт до 240 килобайт, время открытия странички сократилось с 10 секунд до меньше чем 1 секунды.
Стоило ли это сделать раньше? Пока на горизонте маячили крутые каталоги данных - оставалась надежда. Теперь ее больше нет - dbt наше всё :)
Мы достаточно давно живем на 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 наше всё :)
👍5
Вторая плохая вещь в StarRocks
Если почитать чатик https://news.1rj.ru/str/hadoopusers, то почти все при слове StarRocks начинают рассказывать про китайский язык, отсутствие сообщества и отсутствие успешных внедрений в компаниях 1 ранга в своих отраслях. И кажется, что это и есть та самая вторая плохая вещь.
Но нет.
Документация в проекте находится на достаточно зрелом уровне, в крайнем случае в вашем доступе есть гитхаб с примерами кода - например, транзакционная загрузку через API там есть в 3 или 4 вариантах. Или вот есть репа с demo.
Китайский язык вам понадобится только в случае жесткого дебага, скорее всего вы уйдете на китайские форумы где уже встречали такие баги. Но опять же, документация на английском + код покрывают этот кейс.
История про внедрения: ютуб завален видосами. Там и про сравнение с кликхаузом, и про будущее датабрикс + старрокс, и про опыт внедрения в компаниях разного масштаба. Не говоря о росте вакансий на hh.ru - там теперь целых 5 вакансий по сравнению с 1 в конце лета 😂
А теперь серьезно: я наткнулся на регресс в ветке 3.3 по отношению к 3.2 - констрейнты просто не работали :) 9 сентября создал ишью, через 15 минут баг подтвердили, на следующий рабочий день был готов код с фиксом, и итоговая версия с фиксом вышла через пару недель.
Ребят, да ладно, кто из вендоров сейчас вам настолько быстро поможет? :) Мертвый чат вертики? Разработка кликхауза, в которой транзакции не могут победить 5+ лет? :)
А что плохого то? А как раз пропуск вот таких глобальных багов в продакшн. Скорость разработки очень высокая, релизы идут раз-полтора в месяц и фичи поставлены в приоритет над стабильностью. Это требует со стороны внедрения затрат на предварительное тестирование перед обновлением.
Если почитать чатик https://news.1rj.ru/str/hadoopusers, то почти все при слове StarRocks начинают рассказывать про китайский язык, отсутствие сообщества и отсутствие успешных внедрений в компаниях 1 ранга в своих отраслях. И кажется, что это и есть та самая вторая плохая вещь.
Но нет.
Документация в проекте находится на достаточно зрелом уровне, в крайнем случае в вашем доступе есть гитхаб с примерами кода - например, транзакционная загрузку через API там есть в 3 или 4 вариантах. Или вот есть репа с demo.
Китайский язык вам понадобится только в случае жесткого дебага, скорее всего вы уйдете на китайские форумы где уже встречали такие баги. Но опять же, документация на английском + код покрывают этот кейс.
История про внедрения: ютуб завален видосами. Там и про сравнение с кликхаузом, и про будущее датабрикс + старрокс, и про опыт внедрения в компаниях разного масштаба. Не говоря о росте вакансий на hh.ru - там теперь целых 5 вакансий по сравнению с 1 в конце лета 😂
А теперь серьезно: я наткнулся на регресс в ветке 3.3 по отношению к 3.2 - констрейнты просто не работали :) 9 сентября создал ишью, через 15 минут баг подтвердили, на следующий рабочий день был готов код с фиксом, и итоговая версия с фиксом вышла через пару недель.
Ребят, да ладно, кто из вендоров сейчас вам настолько быстро поможет? :) Мертвый чат вертики? Разработка кликхауза, в которой транзакции не могут победить 5+ лет? :)
А что плохого то? А как раз пропуск вот таких глобальных багов в продакшн. Скорость разработки очень высокая, релизы идут раз-полтора в месяц и фичи поставлены в приоритет над стабильностью. Это требует со стороны внедрения затрат на предварительное тестирование перед обновлением.
👍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 Товарищи архитекторы, которые принимают от подрядчиков сервисы и которых в некоторых компаниях десятки и сотни - просьба не беспокоится, здесь я не про вас говорю :)
Два дня 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 Товарищи архитекторы, которые принимают от подрядчиков сервисы и которых в некоторых компаниях десятки и сотни - просьба не беспокоится, здесь я не про вас говорю :)
🔥3
Конференции
На почту упало письмо от ребят из Онтико о приеме докладов на DevOpsConf 2025. Немножко подумал для приличия день и отправил доклад по внедрению в платформу данных StarRocks. Вполне резонно возникает вопрос - почему эта конференция то? :)
Если судить по развитию аналитического окружения, и да и вообще появлению этих самых платформ данных - всё идет следом за основными трендами во взрослой разработке: сервисы миграций, появился dbt, который в версии 1.9 принесет нам еще и unit тесты, стенды разработки и приемочные стенды, построение зависимостей между сервисами поставки и потребления. Да и где еще обсуждать способы подключенния систем хранения в кубернетисе, не на смартдате же? :)
С другой стороны велик шанс не попасть в целевую аудиторию этой конфы, не собрать зал, не заработать свою стопку вопросов и минутку славы. И кажется, что попыток для выступлений на тему есть не так уж и много - окно будет быстро закрываться.
Посмотрим, что скажет программный комитет, в тренде оно все или нет...
На почту упало письмо от ребят из Онтико о приеме докладов на DevOpsConf 2025. Немножко подумал для приличия день и отправил доклад по внедрению в платформу данных StarRocks. Вполне резонно возникает вопрос - почему эта конференция то? :)
Если судить по развитию аналитического окружения, и да и вообще появлению этих самых платформ данных - всё идет следом за основными трендами во взрослой разработке: сервисы миграций, появился dbt, который в версии 1.9 принесет нам еще и unit тесты, стенды разработки и приемочные стенды, построение зависимостей между сервисами поставки и потребления. Да и где еще обсуждать способы подключенния систем хранения в кубернетисе, не на смартдате же? :)
С другой стороны велик шанс не попасть в целевую аудиторию этой конфы, не собрать зал, не заработать свою стопку вопросов и минутку славы. И кажется, что попыток для выступлений на тему есть не так уж и много - окно будет быстро закрываться.
Посмотрим, что скажет программный комитет, в тренде оно все или нет...
🔥5👍3❤1
А как выглядит ваша репа dbt?
В начале внедрения мы несколько раз меняли подходы к размещению и именованию объектов в dbt и в итоге со временем выработали свой подход и обоснование, почему всё так. А потом года через 2 к нам пришел очень классный человек Антон и вполне обосновано не согласился - у него был свой опыт и свое обоснование.
DBT - чистой воды конструктор под себя и сделать удобно можно по всякому. Варианты с размещением по слоям, по потребителям, по доменам - все идет в ход.
Но каждый раз когда аналитики открывают репу их встречает вот такая пугающая картина, и она мало связана с sql :)
Тащу все наши проекты dbt (сейчас их 6) в новый гитлаб с новым ci, с новыми окружениями и тестированием. Опять же переход с тестирования на баше в обвязку на питоне смотрится приятно.
В начале внедрения мы несколько раз меняли подходы к размещению и именованию объектов в dbt и в итоге со временем выработали свой подход и обоснование, почему всё так. А потом года через 2 к нам пришел очень классный человек Антон и вполне обосновано не согласился - у него был свой опыт и свое обоснование.
DBT - чистой воды конструктор под себя и сделать удобно можно по всякому. Варианты с размещением по слоям, по потребителям, по доменам - все идет в ход.
Но каждый раз когда аналитики открывают репу их встречает вот такая пугающая картина, и она мало связана с sql :)
Тащу все наши проекты dbt (сейчас их 6) в новый гитлаб с новым ci, с новыми окружениями и тестированием. Опять же переход с тестирования на баше в обвязку на питоне смотрится приятно.
👍2❤1🔥1
Куда идет StarRocks
На канале у CelerData вышло видео с подведением итогов квартала. Кому лень смотреть краткая выжимка: StarRocks позиционируется исключительно как shared-data движок либо со своим собственным быстрым форматом, либо как основной движок для datalake на основе почти всех свободных форматов.
Основные фичи квартала:
- интеграция с Unity Catalog. Тут все понятно без слов.
- реализация новой фичи Automatic Materialized View. Причина использования описана хорошо - покрутил в голове наш случай, этак можно детальный слой из дбт выкинуть. Но дальше в реализации начал скипать видео, подводных камней хватает и надо ждать переезда фичи из облачной версии в открытый StarRocks.
А заодно на днях вышла версия версия 3.3.6. И опять же, посмотрев фичи за последний квартал, можно увидеть, что развитие идет в shared-data движке. Уже даже начал задумывать о том, что надо тестировать и может быть мигрировать на него с shared-nothing - но остается вопрос таймингов. И самое интересное, что когда я делал PoC как раз сильно обломался, в то время невозможно было использовать HDFS как систему хранения. На данный момент все реализовано.
На канале у CelerData вышло видео с подведением итогов квартала. Кому лень смотреть краткая выжимка: StarRocks позиционируется исключительно как shared-data движок либо со своим собственным быстрым форматом, либо как основной движок для datalake на основе почти всех свободных форматов.
Основные фичи квартала:
- интеграция с Unity Catalog. Тут все понятно без слов.
- реализация новой фичи Automatic Materialized View. Причина использования описана хорошо - покрутил в голове наш случай, этак можно детальный слой из дбт выкинуть. Но дальше в реализации начал скипать видео, подводных камней хватает и надо ждать переезда фичи из облачной версии в открытый StarRocks.
А заодно на днях вышла версия версия 3.3.6. И опять же, посмотрев фичи за последний квартал, можно увидеть, что развитие идет в shared-data движке. Уже даже начал задумывать о том, что надо тестировать и может быть мигрировать на него с shared-nothing - но остается вопрос таймингов. И самое интересное, что когда я делал PoC как раз сильно обломался, в то время невозможно было использовать HDFS как систему хранения. На данный момент все реализовано.
YouTube
CelerData Quarterly Update: Automatic Materialized Views and More
Get ready to level up with CelerData Cloud’s latest features! In this quarterly update, we’re introducing exciting updates that help users reduce operational overhead, boost security, ensure availability, and enhance connectivity. Watch as CelerData Product…
🔥3❤1👍1
Apache Kafka и StarRocks
Выше писал про интеграцию с кафкой через механизм routine load.Механизм в продакшн режиме уже полтора месяца на количестве наполняемых таблиц до 10 единиц - и можно уже сделать немножко выводов.
Плюсы
Механика выглядит надежной и простой по подключениям ко всем видам кафок - у нас 3, включая managed aws кластер с разными видами аутентификаций: SASL_PLAINTEXT, SASL_SSL via
Минусы
Задания разделены по схемам нахождения таблиц, и это прям странно выглядит. То есть вы грузите таблицу в dds.table через задание и команда
Особенности
В случае перегрузки кластера все задания ставятся на паузу, не мигрируя между живыми нодами. То есть пусть это будет обновление кластера на новую версию или добавление тега в k8s для добавления сетевых ACL - пауза везде. Тут важно мониторить метрику starrocks_fe_routine_load_jobs с значениями PAUSED (остановлено по какой-либо валидной причине - ручная операция или перегрузка кластера) и CANCELLED (сработал трешхолд по ошибкам в данных или нарушены значения ключей в таблице).
Выше писал про интеграцию с кафкой через механизм routine load.Механизм в продакшн режиме уже полтора месяца на количестве наполняемых таблиц до 10 единиц - и можно уже сделать немножко выводов.
Плюсы
Механика выглядит надежной и простой по подключениям ко всем видам кафок - у нас 3, включая managed aws кластер с разными видами аутентификаций: SASL_PLAINTEXT, SASL_SSL via
SCRAM-SHA-512. И даже задаваемые креды в запросе маскируются при выводе show routine load:{"security.protocol":"SASL_SSL","sasl.username":"username","sasl.mechanism":"SCRAM-SHA-512","kafka_default_offsets":"OFFSET_END","group.id":"dp_sr_1","sasl.password":"******"}Минусы
Задания разделены по схемам нахождения таблиц, и это прям странно выглядит. То есть вы грузите таблицу в dds.table через задание и команда
show routine load показывает только его, а то что в соседней схеме kafka есть еще 10 заданий никого не волнует. То есть в случае капитальных проблем нужно будет бегать и вспоминать (в нашем случае все записано в миграциях, но осадочек остается).Особенности
В случае перегрузки кластера все задания ставятся на паузу, не мигрируя между живыми нодами. То есть пусть это будет обновление кластера на новую версию или добавление тега в k8s для добавления сетевых ACL - пауза везде. Тут важно мониторить метрику starrocks_fe_routine_load_jobs с значениями PAUSED (остановлено по какой-либо валидной причине - ручная операция или перегрузка кластера) и CANCELLED (сработал трешхолд по ошибкам в данных или нарушены значения ключей в таблице).
❤1