StarRocks and modern data stack

dbt & hive catalog: эпилог 1

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

{{
config(
alias='hp_appsflyer_blocked_installs_test',
schema='dapadoop.sandbox',
materialized='hive_table',
file_type='parquet',
tags=['hp_appsflyer_blocked_installs_test', ]
)
}}

В таком виде таблица создается и отлично читается и из starrocks, и из spark. Но при повторном запуске для проверки удаления все сломалось и тут я как понял...

Проблема в хранении меты внутри старрокса, таблицы из внешних каталогов не доступны во внутренних таблицах в схеме information_schema. Это порождает боль - дбт не может определить, есть ли такая таблица. Да, можно патчить адаптер и выгребать список таблиц через show catalogs..show databases in catalog..show tables from catalog.schema (я такое уже когда-то делал для спарк адаптера не помню почему). Вот только тип мы все равно не узнаем - вью или таблица :( И кстати адаптер поддерживает определение catalog в профиле, но при указании недефолтного значения ломается вообще все - дбт ищет эту самую information_schema в этом внешнем каталоге и естественно не находит.

dbt & hive catalog

Текущий адаптер dbt нормально работает на чтение и запись с форматами старрокс и только на чтение из внешних каталогов, не смотря умение создавать таблицы и писать в них со стороны SR. Дел то на 5 минут, подумал я, допишу за полчаса поддержку и можно перевозить нашу репу дбт спарка. Написал для пробы пера table материализацию. А вот и нифига, сказал мне dbt, выдав ошибку: 1064 (HY000): This connector doesn't support alter table type: RENAME.

Вы поняли, да? :) StarRocks не умеет переименовывать таблицы во внешних каталогах, а даже если бы умел - то создание tmp_relation в стандартных table/incremental материализациях напрочь ломают логику сохранения таблиц в заданный location. В итоге надо писать свои материализации по количеству каталог*2 (таблица, инкремент, вьюха по идее должна и так создавать, если она нужна конечно.) Ну ладно, чуть посложнее и чуть больше времени, но вполне типовая история при работе с dbt.

Но как это все будет происходить в новом dbt fusion с растом решительно не понятно.

Scale BE out

Масштабирование shared nothing кластера на картинке. Даже рассказать нечего, никаких повестей от бывалых кликхаузеров про решардинг с слезами на глазах :( Просто replica в crd поправил и меньше чем через час наступила новая реальность. Сама.

Решение кроилова

За всей движухой постоянно коплю долги на канале в виде постов, попробую нагонять.

Решение поста с отключением 50% дисков от кластера в к8с.

Как и писалось, в кубике через оператор нельзя менять для существующих statefulset ничего кроме количества реплик, энв переменных, лейблов и всяких других описательных куб штук. Удалить, изменить или добавить volume нельзя. Поэтому планируйте заранее свой кластер с умом, а не как я :) Так вот, если нельзя, но очень хочется - просто при живом операторе удаляем statefulset для be нод. Поды будут удалены один за другим, и после исчезновения сущности SF оператор заново её создаст и подключит старые диски с данными. Ни один байт не пострадал, хотя я уже стал мастером бекапов.

Но на самом деле это самая простая часть этой операции, и самая надёжная. А вот изменение конфига старрокс с удалением из него директорий хранения на живом кластере убивает все данные вне зависимости от количества реплик. И делает это весьма некрасиво. Данные между всеми директориями и на бе ноде нарезаются очень ровно, а значит скорее всего и между нодами кластера одинаковые данные будут лежать в одном и том же разделе (напоминаю, что в доке ср рекомендуют использовать несколько разделов на одном сервере - это сильное удешевление требований к железу и повышение скорости). В итоге реплик потерянных данных в случае кластеров с малым количеством нод не будет :(
При этом кластер будет добро рапортовать в метриках, что диски заняты, количество таблетов старое, количество строк не изменилось, но на запросе реплик или попытке сделалать селект из любой табличке кроме меты падать с пустой ошибкой.

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

По итогам - я думал, что будет хуже. А все решилось тех окном на 3 часа.

StarRocks and modern data stack pinned a photo

StarRocks meetup 19.06: итоги

Запишу сюда, чтобы висело в закрепе: youtube, rutube, vk.

И немного статистики по мероприятию, которую обычно никто не пишет :)
Число регистраций: 282.
Число уникальных зрителей: 220.
Средний онлайн на протяжении всех докладов: 90-130.
Хороший такой зал собрали, спасибо всем.

Saint highload'25 немного выводов

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

Вот такие выводы высосал из пальца и общения :) И да, питерский летний хайлоад - это +15 и проливной дождь.

Saint highload'25

Забавно как иногда все поворачивается. Сижу на докладе от яндекса как хорош ydb по сравнению с спарк и трино, и в конце докладчик получает вопрос: а чем ydb лучше starrocks? :)
Хах, я на докладе про старрокс получил ровно обратный - чем старрокс лучше ydb.
А ответ - они не знают про него и не смотрят, сейчас основной конкурент трино и гринплам.

привет
ссылка на трансляцию митапа по StarRocks: https://kinescope.io/0cphQxWPC9cVwaRJDuXej5

Кроилово и попадалово

Задача: изменить количество подключенных дисков в кластер StarRocks.
Статус: кроилово привело к попадалову.

Kubernetes очень классная штука: делает вжух-вжух, имеет встроенный балансировщик и больше никаких шеллов и ансиблов. Но вот там ишью в текущем операторе starrocks - Can't change storage for existing cluster. То есть в созданном кластере нельзя изменить все, связанное с дисками никак через оператор и это ограничение самого k8s (а я то надеялся, что форкну оператор, подмахну пару строчек и поеду дальше). Удалить и создать кластер по новой - в случае использования shared data это задачка на 30 секунд, в случае shared nothing и бекапов - задачка пропорциональная размеру базы данных (вчера на такое потратил около 2 часов). Но есть загвоздка, про которую писал чуть выше - мы не стали использовать LDAP аутентификацию и храним пароли пользователей внутри бд. Бекапить эту информацию СР не умеет (да и не должен), и пересоздание кластера приведет к сбросу паролей - чего хотелось бы избежать.

В ишью выше пишут про удаление хельма, после чего оператор заново его накатит и разделы даже подключатся обратно. Вот только ArgoCD накатывает не helm, а манифесты от него.

У вас есть решение? :)

Да, этой проблемы вообще бы не случилось при установке на железо. И второй истории про то, как старрокс переживает удаление части дисков на всех нодах кластера (очень интересно, вплоть до полной неработоспособности с зелеными индикаторами). Напишу попозже.

П - прокрастинация и б - бекапы

Последние 2 недели почти целиком ушли на срочное переписывание сервиса последней мили до пользователей нашей платформы, который уже даже после биай системы. Было весело, и за это даже получил сердечко от ceo утречком в субботу. Приятно - значит сервис нужен.

И вот настало время вернуться к СР и наша сегодняшняя тема - бекапы. Актуально для ребят с shared nothing.

Что же там хорошего:
- очень прозрачный механизм создания бекапа и восстановления
- интеграция с объектными файловыми системами (от hdfs до s3)
- работает быстро (снять снепшот со схемы целиком и записать в локальных хадуп заняло около 2 минут, 112 гигабайт в СР превратились в 77 в хадупе)*
- бекапить можно таблицы, схемы как и когда угодно

* в версии 3.4 обещали значительное ускорение, но перейти ради этого на ветку 3.4 не решился :)

Что плохого:
- If the RESTORE job overwrites an existing database, table, or partition, the overwritten data cannot be restored after the job enters the COMMIT phase. If the RESTORE job fails or is canceled at this point, the data may be corrupted and inaccessible. Восстанавливаться надо осторожно, как и всегда.
- нет бекапа меты самой бд - аккаунтов (это спорная история и можно поспорить: в моем кейсе он бы помог, а абстрактно это дыра)

А при чем тут прокрастинация? Завтра надо иметь на руках черновик презентации на митап, а его еще нет :)

StarRocks and modern data stack pinned a photo

StarRocks meetup

Всем привет.
Рады пригласить вас на первый онлайн митап по восходящей звезде аналитических баз данных StarRocks 19 июня в 19:00МСК. Митап состоится онлайн, регистрация по ссылке.

Сообщество пользователей подготовило 2 доклада, охватывающие весь спектр задач - от типичного dwh небольшой компании до использования lakehouse движка поверх S3 и открытых форматов. От часовых витрин до bi безумия из сотен тысяч запросов. Мы постараемся ответить - жив ли еще опенсорс, есть ли альтернатива кликхаузу, гринпламу или трино. А если вдруг что-то забудем, то после докладов приглашаем вас на сессию вопросов и ответов в zoom к докладчикам 👍

StarRocks 3.4

Была у меня привычка писать про каждый релиз версий 3.3, а тут релизнулась и следующая ветка 3.4, а теперь и вовсе уже озвучена 3.5. Больше хотелось написать про 3.5, потому что там для меня прям классные фичи озвучены, но как же пропускать большой релиз :) Тем более ожидать 3.5 можно не раньше нового года с учетом доведения той версии до стабильной работы.

Вот видео, как всегда все классно нарисовано: https://youtu.be/NHi-0QpMXBA?si=lprLlghiH0JkZok1
И вот почему 3.4 для меня не очень интересна - она идет ровно в том векторе, что озвучивали на новый год: очень сильный упор на SR как lakehouse движок. Повышение скорости работы - тут завезли и асинхронный листинг каталогов, и оптимизации кешей, примочки для iceberg с цифрами в 20% прироста скорости в стандартных бенчмарках.

Для себя увидел прикольное:
* прокачали бекапы - они стали быстрым (утилизация всей пропускной способности сети), они выкидывают в бекап все сущности, которыми может оперировать SR
* протокол arrow flight допонительно к mysql - выгружать в модельки данные станет очень быстро
* python udf - ну куда же без них

Еще прикольно видел, что на FE ноды пришли снепшоты состояния при синке фоловеров с мастера. Архитектура почти везде одинаковая - что знали в hadoop, то дальше можно встретить везде :)

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

День, когда мой мир рухнул

Этот пост снова не про SR :)

Так вот, с школьной скамьи (ну почти, практически с первого собеседования в дату или бек) спрашивают про ACID в базах, и везде крутится речь про транзакции. И вроде бы из общения со всеми базами данных мы знаем, что если у нас появилась ошибка, то значит что транзакция не была закомичена. Как всегда, например, в mysql надо читать мелкий шрифт в договор..документации: транзакция будет закомичена, но клиент не обязательно об этом узнает. 😱

В бд отправляется запрос на запись, он не укладывается в таймаут на клиенте и клиент отпадает. БД при этом завершает запрос и успешно завершает транзакцию. В клиенте у нас фейл, по факту успех.

А при чем тут аналитика? Та самая realtime аналитика на событийке, в которой события отправляются после успешной транзакции в бд. А у нас не отправляются, потому что запись в бд прошла не успешно. Но данные там появились и вовремя. И тут иногда думаешь, что CDC не так уж и плоха. Какой-то замкнутый круг это все: от батчей уходишь на cdc, от cdc на событийку, от событийки на батчи - и все это сверками, сверками поверху.

CDO и его проблемы

Забавная игрушка - https://www.whoisthebestcdo.com. В первый раз прошел без напряга, а вот последующие разы были уже интересней. Все это выглядит достаточно жизненно, и знаете что самое прикольное? Вот эти циферки в каждом письме, которые +5 авторитета, -100 000$ бюджета, +50 000$ прибыли компании - это ведь ровно то, что жаждет получить бизнес для каждого своего решения от этого самого CDO :) А там каждый раз мрак.

Внедрение СР тоже происходит без циферок, их даже не угадать. ROI в дате? Мне кажется, что для малых/средних компаний, кто не торгует этими самыми данными оно выглядит очень нереально.

upsert & new version

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

А потом бах - мы везде используем primary key таблицы, у которых в случае совпадения ключа происходит операция upsert без этих всех ваших дополнительных условий. Рука-лицо, дубли невозможны в принципе. Но как обычно, это порождает и обратную ситуацию - крайне легко затереть то, что не надо. У нас шардированные продакшн базы имеют сквозные идентификаторы как раз за счет проверки на уникальность в едином месте - платформе аналитики... Вот тебе и два стула.

А тем временем для версии 3.5 уже выпустили RC1. Темпы просто поражают.

async quieries

Вчера развлекался с частичной чисткой и заменой данных - примерно 700 млн строчек из хадупных цсвшек в табличку СР. И обнаружил для себя, что кроме асинхронных операций insert бд еще умеет асинхронные CTAS. С одной стороны это плохо, что тебе выкручивают руки - вот тебе 300 секунд, а все что больше делай через таски. С другой сразу прививается хороший тон. Зачем делать такие длительные и тяжелые операции, успешность которых зависит от стабильности твоего канала связи до бд или каких-то совсем неопределенных вещей. В чем вообще смысл наблюдать, как крутится тяжелый запрос? А с тасками глянул статус и занимаешься дальше своей работой.

И подумал вечером, что это ведь подход для работы с dbt, но вот как там реализовать эту асинхронность. Оказалось, что надо просто в профиль написать is_async и поехали. Просто пришествие 21 века.

Delete всему голова

Немножко посравниваю с вертикой, потому что сталкиваемся с ее ограничениями. Где-то выше я рассказывал, что у нас достаточно много CDC, которые проигрывает 1 в 1 из мусклей самописный сервис. И самые тяжелые времена настают, когда на проде надо обновить много строчек. Понятно, что для мусклей это тоже не очень веселая операция, но не идет ни в какое сравнение с вертикой. Обновление 30-40 млн строк занимает столько времени, что проще переналить с чистого листа все данные с 10 шардированных бд.

Старрокс на 8 млрд таблице это делает со скоростью вставки новых строчек. И это не говоря про то, что в нем есть апсерт вместо реализованного алгоритма delete+insert в вертике (то есть мы делаем там х2 операций).

И вот такая штука сильно поможет нашему продакшену, потому что ребята из бека уже привыкли, что им дышать на свои таблички надо с осторожностью. А ведь можно и нормально жить :)

dbt starrocks

2 недели назад на конфе я показывал вот такой слайд, учитывая заброшенность репы адаптера на гитхабе. Но оказалось, что надо постоянно проверять новости от кипящих проектов - 20 марта выпустили сразу релиз 1.9.0. Для новой ветки старрокса 3.4 включили поддержку микробатчей всех видов и вообще почти всего, до чего смогли дотянуться. Единственное, что осталось - кафку затянуть в дбт (правда у меня вопрос, зачем она там нужна...).

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