YDB

Так получилось, что на конференции раньше моего доклада выступал Олег Бондарь с рассказом, как они сделали аналитический движок в свою ydb. Я не пошёл на доклад, а видео его мы сможем увидеть только через полгода. Но в итоге этот доклад спровоцировал вопрос уже на моем докладе - зачем старрокс, если есть ydb? :) Вспоминаю историю про ytsaurus - меня метнуло в сторону масштабов, но Олег в докладе прямо сказал что из бд готова для работы даже в 3 нодовом виде :)

Так почему нет? А потому: https://ydb.tech/docs/ru/concepts/datamodel/table#column-oriented-tables
Ограничений - великое множество, чём-то напоминает кликхауз 5 летней давности. И да, инсертов и делитов нет, впрочем даже переименований таблиц нет. Так что нет, сейчас совсем не конкурент.
Может вырастет, а может нет, время покажет.

Вопрос про интерактив для грядущего митапа :)

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

А при чем тут Grok? :)

Так как городить vpn очень лень, то доступный платным клиентам телеги @GrokAI является вроде неплохим решением попробовать AI в своей жизни. И для слака у него получается очень неплохо - апи очень стабилен и прост, примеров море. Но стоит шагнуть немножко в сторону, например попросить код для создания скриншота борда из Qlik Sense - становится все плохо вплоть до галюцинаций методов в селениуме. Напоследок решил использовать его для создания документации кода - шляпа, вместо описания фунций получил разбросанные по коды однострочные комментарии.

И захотелось сделать выводы

Чем более закрытый у софта код с дурацкой документацией, тем больше шансов, что вас как программиста с ним работающего не заменят никакие AI :) У Qlik Sense он именно такой, а селениум просто слишком велик и сложен. Уж не говоря о сборке всех кусочков в работающее приложение - создание pdf отчета по дашбордам из клика и отправки его в слак. А вот пользователи популярных открытых|старых|хорошо представленных в интернете вещей пойдут под замену. Помню был когда-то бизнес на создании слак ботов, интересно что там сейчас.

Lakehouse meetup #3

А вы заметили как ловко Trino meetup (вот тут последний лежит с номером 2) превратился в Lakehouse meetup с номером 3? Какая интересная манипуляция, после которой взгляд на рынок аналитических движков уменьшается до одного :)

А я вот поделюсь опять видео с канала celerdata - одно из самых просматриваемых (и которое я пропустил :) Ага, оно называется Trino Vs StarRocks - How to Get Data Warehouse Performance on the Lakehouse. Неплохой технический уровень и очень неплохие столкновения лоб в лоб во время конкуренции на продажу платформы в компании с большоооой датой. Основными техническими преимуществами названы SIMD и крутой кеш. И кстати этот самый кеш является закрытой частью в starrocks, его нет в гитхибе.

Но вообще я далек от этой истории и до сих пор не понимаю, зачем компаниям уровня Азбука вкуса или Лемана про влезать в трино, айсберг и компанию. Гибридные движки, как это умеет starrocks или greenplum с pxf гораздо выгоднее. А уж на том количестве данных...

Apache Hadoop. Рассвет или закат opensource. Как живет онпрем в 24 году

Воспользуюсь еще раз второй частью названия канала про modern data stack и скину доклад про hadoop :) Год назад в первый раз выступил на сцене вместо привычного ютубчика, и это было прикольно (спасибо, Лестат). Решил вспомнить корни при подготовке митапа по SR, так сказать. И на самом деле часто внедрения - это веселые походы под пиратским флагом, потому что так больше жить нельзя.

Серьезные люди тут же придут и начнут бухтеть про кто будет поддерживать, когда ты уволишься и т.д. Лет 10 назад было как - ты приходишь на работу админом, а там хадуп. Ну ладно, хадуп так хадуп, поехали. И сейчас без черного пояса по кунг...керберосу и знания ATSv2 (и его проблем) никуда тебя не возьмут.

PS забавно, что даже на канале Лестата видно, насколько кликхауз популярнее всего остального. А уж по отношению к хадупу ровно на порядок.

Deepseek v3

Стоит ли менять trino на starrocks?

Решение о замене Trino (ранее PrestoSQL) на StarRocks зависит от конкретных требований вашей аналитической нагрузки. Оба инструмента имеют свои сильные и слабые стороны.

### 1. Когда StarRocks лучше Trino?
StarRocks (ранее Doris) — это высокопроизводительная MPP-СУДБ, оптимизированная для аналитических запросов с низкой задержкой.

✅ Выберите StarRocks, если вам нужно:
- Высокая производительность на сложных агрегациях (OLAP-запросы с JOIN, GROUP BY, Window Functions).
- Поддержка реального времени (вставки данных с низкой задержкой, near real-time аналитика).
- Горизонтальная масштабируемость (автоматическое шардирование и репликация).
- Совместимость с MySQL-протоколом (удобно для BI-инструментов, таких как Tableau, Superset).
- Встроенные оптимизации под колоночные форматы (Apache Parquet, ORC, Iceberg).
- Поддержка материализованных представлений (ускорение запросов без переписывания кода).

### 2. Когда Trino (Presto) лучше StarRocks?
Trino — это распределенный SQL-движок для выполнения запросов к различным источникам данных.

✅ Оставьте Trino, если вам важно:
- Федеративные запросы (объединение данных из разных источников: Hive, Kafka, PostgreSQL, MongoDB и др.).
- Гибкость и поддержка множества коннекторов.
- Запросы к данным в S3 / HDFS без ETL (Trino отлично работает с Iceberg, Delta Lake, Hudi).
- Ad-hoc аналитика (быстрые exploratory запросы без предварительной загрузки данных в СУБД).

### 3. Производительность
- StarRocks обычно быстрее на сложных аналитических запросах (особенно с JOIN и агрегациями) благодаря своей MPP-архитектуре и векторному исполнению.
- Trino может проигрывать в скорости на больших JOIN, но выигрывает в гибкости.

### 4. Экосистема и интеграции
- StarRocks лучше интегрирован с Kafka, Flink, Spark (поддержка stream-загрузки).
- Trino имеет более богатую экосистему коннекторов (подходит для data lake и data mesh).

### Вывод: стоит ли переходить?
- Да, если у вас OLAP-нагрузка (аналитика, дашборды, агрегации) и нужна максимальная скорость.
- Нет, если важна федерация данных или работа с разнородными источниками.

Можно рассмотреть гибридный подход:
- StarRocks — для горячих данных и быстрых запросов.
- Trino — для федеративных запросов и работы с data lake.

Если у вас есть конкретные требования (объем данных, типы запросов, SLA), можно дать более точную рекомендацию.

Аналитика уровня AI. Как они это делают...

Рейтинги подъехали

Есть такой сайт - https://db-engines.com, который на основе трендов в поиске, количестве вакансий и вопросам на СО выстраивает рейтинги для большого количества баз данных. Конечно, сперва интересна методология ранжирования - она здесь, а потом соответствие бд группам, в которые они размещены. Clickhouse в ряду реляционок, вместе с trino и остальными. Ну что ж...

Расшифровка сверху вниз:
* apache hive
* apache spark
* clickhouse (красная ракета)
* trino
* starrocks
* apache doris

Есть подозрение, что фиговый STS вместо kyuubi сильно подрывает позиции для спарка в рейтинге. А так бы давно хайв отправился на замену. Трино давно вышли на плато и не смотря на раскрутку хайпа стоят. СР и дорис - вообще незаметны на фоне грандов.

Кстати, этот график прямо противоречит, например, с просмотрами видео на канале Лестата, который скидывал выше.

Сообщество StarRocks/Doris

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

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

У меня через личку стало проходить много интересного по СР, которые было бы лучше выносить на публику, да и на какие то вещи нет ответа с моей стороны из-за узости профиля.

Да, это такая длинная подводка к новой группе: https://news.1rj.ru/str/starrocks_users. И именно для развития этой новой группы и будет проведен митап по StarRocks 19 июня. Кому интересно - присоединяйтесь :)

dbt starrocks

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

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

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

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

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

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

async quieries

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

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

upsert & new version

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

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

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

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

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

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

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, то дальше можно встретить везде :)

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

StarRocks meetup

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

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

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

Последние 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.
Статус: кроилово привело к попадалову.

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

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

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

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

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