StarRocks and modern data stack

- Are not you afraid we're building Skynet? - I'm just afraid we are building Skynet on MariaDB. Поржал, но пг я не люблю больше :)

Конференции, хорошие и не очень Недели 3 уже пытаюсь сформулировать выводы про нескольким прошедшим осенним конференциям из мира данных. А сегодня в почту пришел опросник от Онтико по хотелкам для DevOpsConf 2027 и вроде созрело. Субъективная история - очень люблю ходить по митапам и слушать подкасты, и активно этим занимаюсь года с 2017 наверное - люблю уносить призы за вопросы, но не люблю стандартый конф мерч - начал устраивать свои митапы где-то с 2018-2019 гг, партнерился с Крок, Ростелеком, х5, Инженеркой и использовал ресурсы работодателя - и вроде получалось неплохо - в офлайне это были забитые залы, онлайн не отставал - для ходьбы по конференциям личных средств не хватало, поэтому в первый раз попал на питерский хайлоад аж в 24 году благодаря компании (и спасибо ей за это) - но показалось, что это слишком легкий (и одновременно сложный с точки зрения проблем обоснования) способ, поэтому решил заходить на них через доклады. В итоге за год успел выступить на трех конфах от трех разных компаний в разных городах и это был очень клевый опыт - не понимаю зачем конференции идут 2 дня - второй день всегда пропускал из-за перегруза головы от новой информации Что заставляет меня идти на конференцию - расширить кругозор и узнать про новые клевые штуки - зафиксировать насколько мое техническое виденье и реальность компании соответствуют общему состоянию (у нас все ок или мы отстаем даже от бигтехов) - поболтать, потому что моя сфера слишком узкая и как правило сильно не хватает окружения с твоими задачами и трейдофами А теперь простыня текста :) Если ты пришел на хайлоад и получил на нем 1 интересный тебе доклад - это хорошо, 2 - это вообще великолепно. Мы все понимаем, что угодить с темами для 1500-3000 человек невозможно. И пока работодатели платили и не спрашивали - было вполне норм, но в 26 году отдавать сотку за 1-2 доклада? А мне как человеку, который приносит заявку эйчару надо обосновать - как эти 2 доклада по полтинику сделают нашу компанию лучше... Не думаю, что хайлоад умрет, но ходить туда за деньги мне точно не светит. Единственный шанс пойти на такого рода общие конференции - подать свой доклад и выступить, и тут случается такое ограничение. Мне как спикеру нужна заточенная под мой доклад аудитория, а аудитории доклад под нее. Если люди не вдуплили в то, что ты вещаешь - проиграли все. Ты не собрал зал = для конфы это провал. Я потратил свой доклад (а стоит он для меня много - только подготовка к докладу занимает около месяца-двух, а ведь еще сам материал набираешь полгода) и не получил фидбека = для меня это провал. Аудитория потратила час хз на что = для аудитории тоже провал. Поэтому для себя я зарекся выступать на больших конференциях с узкими докладами (а почти весь мир инженерии данных - узкий). Итого остается тусовать на профильных конференциях - SmartData и всякие бигтеховские междусобойчики. Мы все понимаем, что список докладов обычно - это просто разношерстный набор, который смогли собрать за это время с сильным влиянием комитета и его окружения. Очень здорово, когда такой набор удовлетворяет трем критериям выше - например, прошлая SmartData 25 года. Я считаю ее очень интересной для себя и успешной (и нет, не потому что я там выступал :) - доклады были интересные, темы были интересные, подходы были интересные. Но так получается не всегда, и для меня в 26 году СД провалилась - я в расписании смог для себя смог отметить всего 1! интересную тему. И на этом фоне случился яндексовский Data Driven 26 - который я посмотрел с удовольствием в субботу. Почему? У них была единая тема всех докладов и они органично ее раскрывали. Как минимум 3 доклада зашли. Следом стоит пройтись по просачиванию ИИ - не знаю как вы, но я для себя вынес, что наша работа стала еще более важна после его прихода. Инженеры данных стали еще более ценны и загружены, ценность биая поднялась еще выше, и при этом требования и скорость работы сильно ускорились. Тот самый дата гавернанс не просто возник на горизонте, а оказалось что он уже должен быть внедрен вчера для успешной работы. И нет бле, не хочу я слушать про очередной RAG и страдания с векторами на дата конференции. И даже про агентов особо не хочу, толку то от них. Это совсем другие задачи. Да, это вызов для конференций - скорость внедрения и разработки выросли настолько, что мариновать какой-то доклад год выглядит провальной стратегией. Не иметь общей темы и вываливать кашу - ну такое. Посмотрим, чем порадуют нас в 27 году.

Линия не обрывается на витрине В dbt мы давно умеем хорошо рассказывать, как устроены модели: откуда таблица, какие колонки, кто на кого ссылается. Слабее всегда была обратная сторона — кто эти модели реально читает снаружи. Дашборды, отчёты, скрипты, аб-тесты. Заполнить зависимости один раз ещё можно, но постоянно обновлять - утопичненько. В итоге появляются экспожуры Шредингера - вроде есть, а актуальны ли... Сразу же на ум для решения приходит какая-нибудь openmetadata, но стоит ли она того?.. Ещё в 2023 году на одном из митапов Кирилл рассказывал о своем творении - сервисе парсинга экспожур, и мы задумывались выложить его в open source. И... лучше поздно, чем никогда. dbt-esync: консольная утилитка для регулярного запуска. За один запуск забирает несколько источников, сопоставляет таблицы с актуальным manifest.json и записывает в репозиторий dbt зависимости «внешних потребителей» (exposures) — одним коммитом, при желании с запросом на МР. Для запуска через Airflow хватает дефолтного конфига: всё нужное задаётся переменными окружения — так мы и крутим его в KubernetesOperator. Код · образ PS Наш оригинал был на python, эта версия на golang. PPS Поддержка git репок, mysql/hive, redash/superset/qlik sense enterprise, growthbook

Метрики заехали Вопрос как мерить эффективность разработки (айтишечки) волнует сейчас всех - нам подвезли свой сервис. Если бы не посмотрел, то никогда бы не поверил. На картинке мои результаты с 1 января. 2+ млн строк кода - это полная жесть. Я такого честно не ожидал. Но мне больше понравилась вторая картинка с падением 90 перцентиля времени решения задачи - вот там классно все видно.

Семантический слой без семантического слоя В 2023 году ребята из нашей BI команды придумали сохранять описание метрик прямо в репо dbt, про что и рассказали вот на этом митапе. Тогда казалось, что это простой другой способ хранения метрик относительно обычного в конфле. 3 года все старались и поддерживали эту историю (привет, Венера, Вова и Оля). И вот наступил 2026 год и внезапно оказалось, что без семантического слоя агенты не очень понимают запросы к ним от обычных людей. Со всех сторон нам стали говорить - семантический слой, семантический слой. Опять на поверхность стали всплывать такие штуки как cube.dev, dbt опять прикрутил yml к новой идее. Я не верю в возможность реализации отдавалища с таким интерфейсом, потому что слишком высок уровень абстракций. И в конце получается что-то типа движков Qlik Sense и иже с ними. А вот в хорошее актуальное описание метрик и разрезов я не то что верю, оно у нас есть. Теперь любой ответ агента на вопрос строится на базовом алгоритме: найди метрику (и разрез), найди ее реализацию в dbt, выполни запрос в StarRocks - дай ответ пользователю. А за счет хранения метрик рядом с изменяемой кодовой базой затраты на поддержку актуализации описаний ниже буквально за счет обновления метрики в том же мерж реквесте вместе с реализацией или изменением метрики. Да, я опять написал сервис на гошке, который делает мостик между агентами и метриками :) metrics-gate — read-only методология метрик для агентов. Он индексирует manifest.json после dbt docs generate и отдаёт четыре инструмента по HTTP и MCP: search, get_metric, get_dimension, list_metrics. Два способа завести методологию в dbt — macro-docs stubs (macros/metrics/) и semantic metrics (MetricFlow), плюс разрезы из markdown-таблицы в exposure. Поиск лексический, не векторный: для методологии важнее точные попадания по id/alias и предсказуемый «не найдено», без embedding-пайплайна и «почти той же» метрики. Пример SQL в доке помечен как executable=false и диалектом из конфига — агент не путает пример из Vertica/Spark с базой, куда считать. Один инстанс = один свежий индекс; агенты и люди ходят в API, а не в устаревший клон. Код · образ

AWS Glue + StarRocks = ❤️ Понадобилось вынести часть данных за периметр компании. Мне нравится StarRocks: 2 sql запроса на создание внешнего каталог и схемы данных поверх бакета и дело в шляпе.

CREATE EXTERNAL CATALOG glue_aws PROPERTIES ( "type" = "iceberg", "iceberg.catalog.type" = "glue", "aws.glue.use_instance_profile" = "false", "aws.glue.access_key" = "value", "aws.glue.secret_key" = "value", "aws.glue.region" = "eu-north-1", "aws.s3.use_instance_profile" = "false", "aws.s3.access_key" = "value", "aws.s3.secret_key" = "value", "aws.s3.region" = "eu-north-1" ); CREATE DATABASE IF NOT EXISTS glue_aws.marts PROPERTIES ( "location" = "s3://datasets-eu-north-1/marts" );

Копирование данных происходит через dbt (в котором стоит быть внимательнее с материализациями, при совпадении имени таблицы она имеет свойство дропать таблицу не в внешнем каталоге, а в дефолтном :). Порядка 80 таблиц уезжают в айсберг в aws минут за 5-6. Запросы по ним, кстати, из СР выполняются примерно секунды за 2, а нас разделяет под несколько тысяч километров.

Наблюдения со стороны 1. Некоторых детей в 10 лет приходится учить вешать полотенца на крючок. Буквально - учить. (Хаха, тупая иишка не смогла разобраться в моем проекте на 1 млн клок с первого захода, хаха). 2. Много лет архитекторов и разработчиков просят не брать пример с больших компаний при разработке своих решений - вы не фейсбук и даже не клаудфлейр для написания своего зоопарка микросервисов с сагами. Но до аналитики эта же история еще не дошла.

Итоги квартала и ИИ Самое время посчитать насколько выгодно мы обменяли подписки по 20 баксов в команде из 4 человек. На картинке ничего не понятно, но основных метрик по сути 3: время производства (отдельно по клиентским задачам и задачам команды), которое противопоставляется размеру и возрасту задач в беклоге. Напомню, что мы являемся платформенной командой и у нас много своих продуктовых задач. Мы получили сокращение производственного цикла клиентских задач примерно на 90% в 85 перцентиле, своих технических на 60%. Размер беклога упал незначительно, но при этом срезали 65% с его возраста. Выходит, что метрики не пытались взломать и эксперимент достаточно честный. Если уйти от объективных метрик к пользе: ее мы тоже получили с запасом - буст платформы за квартал получился очень приличным.

dbt-gate — read-only каталог dbt для IDE-агентов В dbt уже есть модели, колонки, lineage и скомпилированный SQL — но обычно это живёт в git или на docs-сайте, куда ходят далеко не все. Аналитикам и другим потребителям часто не нужен (и не дают) доступ к репозиторию, а сам проект постоянно меняется: локальный клон быстро устаревает. Не хватает простого актуального способа спросить каталог: «что это за таблица?», «откуда она течёт?», «покажи compiled SQL» — без выдачи репо и без «пересобери dbt у себя». Особенно это мешает агентам в IDE: им нужна стабильная API/MCP-точка, а не устаревший checkout. dbt-gate — маленький сервис: индексирует manifest.json после dbt compile / dbt docs generate (файл или HTTP URL) и отдаёт четыре инструмента по HTTP и MCP: search, get_model, lineage, get_exposure. Поиск лексический, не векторный: для каталога важнее точные попадания по FQN, alias и колонкам, плюс предсказуемый ranking — без отдельного embedding-пайплайна, модели и «почти тех же» таблиц. Один инстанс = один свежий индекс; агенты и люди ходят в API, а не в устаревший клон. Заточен под layout вроде dbt-StarRocks, но работает с любым dbt-адаптером — нужен только manifest.json.  Код образ Критика приветствуется, но у нас себя такой подход показал очень хорошо с различными llm - от claude и cursor до gemini.

За долгом всегда придут Где-то в прошлой до-ии жизни я написал негативную статью на хабре про Redpanda. Недавно на нее прилетел комментарий и я очень удивился, что статьи читают. И уже после нее на смартдате ребята из Авито рассказали как она классно работает (на выделенном железе и nvme ssd дисках, ну еще бы не работать...) К чему это? Причина, по которой у StarRocks нестабильная потоковая запись в таблицы найдена окончательно. И похоже я опять прошелся по тем же самым граблям :( Нас подвели 2 вещи: попытка завести основной marts слой на вьюхах и неверный выбор дисковой подсистемы для кластера. 1. Откуда view? Попытка склеить факты между собой либо склеить медленные факты с nrt фактами. В итоге StarRocks как попало делает pushdown в таблицы из вью, и достаточно часто на нагрузке не делает его вовсе. То есть запросто вместо чтения только последней партиции мы получаем фулскан чисто из-за ошибки оптимизатора. 2. Напомню, что в документации планирования кластера рекомендуются SSD диски ораниченного размера. Но мы исходили из того, что есть - пачка разделов с схд. Что получилось: у нас идет постоянный стриминг данных (от 1 до 10 тысяч событий в секунду). И тут прилетает фулскан гигиабайт на 600-700, а иногда они вовсе стоят в обновлении раз в 1-10 минут. IO на схд говорит - вы че там, двинулись? И в это время мы получаем еще удар на запись/чтение стриминга через механизм enable_persistent_index (это относительно свежая фича, при которой индексы вместо памяти хранятся на диске в RocksDB - что надежнее, но и затратнее). В итоге: кластер забил дисковую очередь чтениями, а запись в это время просто стоит. Никаким образом потоки или приоритеты разрулить нельзя. Память относительно свободна, процессор не утилизируется. Быстрая победа: этап безконтрольного выполнения запросов на кластере закончился - на все ресурсные группы былы выставлены ограничения как по размеру сканов, так и размеру самих запросов. Медленная победа: надо покупать ssd (впрочем, на дворе 26 год - давно пора). В чем плюсы то? На картинке поставил разницу в задержке воспроизведения CDC в Vertica и StarRocks - получается выигрыш x2.

DE, AI и та самая демократизация данных Мне кажется, что 80% успеха команд данных в современном AI мире строится на тех же самых скучных инструментах, которые используются более 5 последних лет. Не надо внедрять никаких супер-пупер RAG, автономных агентов, строить вики на векторных связях, городить единые хранилища контекста всея компания. Поворот в сознании случился в момент внедрения nao и попытках построить RAG поверх dbt и QlikSense - эти процессы просто встали из-за нехватки ресурсов. Ситуация представляется патовой - без предоставления прямого доступа команды инженеров умирают под текучкой, но и текучка не может выпустить инженеров предоставить нужные инструменты. Значит что? Значит надо строить обвязку ровно вокруг используемых инженерами инструментов :) С какими вопросами приходят в команды у нас? - Где лежит... Как считается... В каком борде можно посмотреть... Чтобы дать хорошее качество без догадок мы должны дать перевод бизнес языка на технический (название метрики в то, как она считается), показать где лежат нужные для расчета или селекта данные (описание таблиц и их связей), дать возможность выполнить запрос на корректном диалекте с нужными доступами. Отдельно идут BI системы, в которых традиционно хрен знает как искать нужную информацию, а значит мы должны подсказать где лежит любая метрика, разрез, борд с нужным описанием. Выходит стандартная архитектура - любой интерфейс доступа со стороны иишки (mcp, api+tool, skill), который умеет качественный поиск с бизнес ранжированием поверх рабочих интерфейсов - dbt (у нас в нем хранится не только мета таблиц, но и описание метрик - о чем мы рассказывали на митапе еще года 3 или 4 назад) и самого QlikSense. Любое изменение порождает перестройку индекса, работает в автоматическом режиме, никаких дополнительных затрат - сервисы кушают по 50-60 мегабайт памяти для хранения и поиска всей меты со скоростью в милисекунды. А дальше работа инженеров данных становится куда более критичной - описание нужно полное и актуальное, все должно работать как часы, безопасность должна быть безопасной (теперь если есть доступ человека к данным - значит данные уже утекли в claude, grok, ваш любимый роутер), скорость поставки должна сильно сократиться. То, чем мы занимались раньше столько лет становится еще более критичным - перед инженерами исчезает прослойка, которая могла сыграть амортизатором в каких то вещах. PS А nao теперь в итоге поднимается на связке этих mcp без всяких проблем - 0 затрат и внимания. PPS Опять выводы похожи с прошлым постом. Раньше сторонние коробки решали проблемы интерфейсом, который теперь стал не нужен. Какая разница как рисуется lineage в каталоге данных - нам нужна информация из него.

Выбор CDC сделан Нам очень хотелось сделать CDC из наших MySQL в Hadoop вместо StarRocks: это сильно уменьшает стоимость хранения, это убирает затраты ресурсов из дорогого места выполнения запросов в дешевое место технических джобов и больших серверов, это убирает лишние копии данных. Не вышло. Не вышло как хотели. Apache Paimon + Flink. Связка работает и вроде как работает неплохо. К сожалению доклад на смартдату сорвался :( Какие минусы: реализация в кубе - отстрел своих ног, снятие начального снепшота - проще застрелиться на бд большого размера, отсутствие вообще любого решения для non-pk таблиц. И самое главное - жаба жрет память ведрами, проигрыш современным нативным решениям такой, что даже нет смысла туда смотреть. Это гигабайты-десятки гигабайт против десятков и сотен мегабайт. Проблема сверок, проблема мониторинга. Проблема скорости внедрения (тут очень субьективная штука), но 8 месяцев заняло обстучать грабли у одного человека. Оставили работать на 2 достаточно больших базах данных, чтобы посмотреть стоимость поддержки. Итоговое решение (которое изначально не хотелось делать): допилили свой репликатор для Vertica, теперь он вставляет данные в StarRocks, и он же снимает дампы для флинка и восстанавливает их в Paimon 😂 Upsert здесь неплохо выручает, в итоге даже с реализацией транзакций в 3.5 ветке все работает достаточно стабильно. Потребление памяти в районе 40-50 мегабайт на сам сервис, ну и компакшн в ср выдает цифры в десятки/сотни мегабайт. Даже на дампе и импорте начального снепшота потребление не больше 100 мегабайт для любого размера таблиц и скорость на порядок выше флинка. Время реализации: около полутора недель активного написания кода + неделя отладки. Так как написано на golang, то в к8с встало как родное. PS можно много выводов сделать, но основной для меня - AI позволяет не бояться делать такие штуки и при наличии мозга получается очень адекватно реальности. Когда-нибудь мы донесем репликатор до опенсорса, но мне кажется что быстрее MySQL вымрет в округе :)

Какой-то микс нынче в дата мире происходит Сократят ли кожаных в пользу AI? Я тут погуглил. Мне кажется, что эти 2 компании умеют пользоваться иишкой как никто другой. Ну и чего, сократили там кого-нибудь? :) С другой стороны не пользоваться сейчас таким инструментом кажется довольно глупой идеей. Не знаю как у вас, у нас в командах данных текучки более 50 процентов. Я больше 10 лет пишу код, около 5 лет в текущей компании. Писать очередной оператор в эйрфлоу, объяснять зафиксированные метрики в дбт в очередной раз? Увольте пусть ии ответит за меня. И вот эта история с данными, мне кажется, подводит отделы данных к решению такой задачки, как создание "единого хранилища контекста", а моем понимании ai платформы в компании. Что все понимают под этими словами (и понимают ли) - большой вопрос. Есть ли какие-то устоявшиеся шаблоны или хотя бы примеры - нет. Можно ли угадать, куда пойдет развитие иишки - нет. Именно поэтому это довольно клевая задача :) Похоже, что StarRocks будет все меньше (хотя мы его и опробовали как хранилище векторов, и у меня для него лежит написание нативного CDC на гошке в беклоге), а больше будет всего подряд про современную техничку в офисе данных во всех ее ипостасях. Потому что никто не рассказаывает про графы для dbt, платформы агентов, тлен векторизации и как подсадить хотя бы 100 человек на свои скилы (оказалось, что писать mcp на гошке - кайф) :) PS кстати dbx - тормозная штука с глюками интерфейса. И да, это тот момент, когда даже гуй на жабе быстрее.

DBX Так ли уж много надо для счастья на сегодняшний день? Полный бак бензина, хороший велик и... Чтобы хоть одна sql-ide показывала миллисекунды для datetime колонок в StarRocks! Я очень люблю сообщества и неформальное общение. Там порой случайно можно узнать что-то интересное, способное поменять твои привычки в работе и сделать картинку вокруг чуточку лучше. И вот недавно думали тряхнуть стариной и провести новый DBT митап с Алмазом, и он случайно обронил в разговоре dbx. Выглядит интересно, пошел смотреть что это такое. Да, вся IDE поместилась в 15 мегабайт с поддержкой почти всех бд, которые сейчас есть на рынке. Но эти 15 мегабайт, конечно же, не включают в себя JDBC драйвера для вертики или хайва, например. А вот StarRocks включен в поставку по умолчанию. И то, с чем не справились ни JB с их убер зоопарком, ни DBeaver с аналогом - вот на скриншоте сверху. А еще в DBX на маке работает cmd+enter для выполнения запросов, что благополучно сломали уже год как в DBeaver. А еще там есть MCP для всех ваших коннектов и готовое how-to интеграция с курсором и клодом (и остальными). Который впрочем не работает на маках с арм :) И еще рендеринг тупит и если быстро листать виртуальные столы - то видишь белый экран примерно пару секунд после перехода. Но ладно, за миллисекунды и хоткеи все можно простить. Теперь это мой топчик. Спасибо, Алмаз :)

Обновки подъехали Абсолютно случайно в ln увидел, что в SQLMesh завезли поддержку StarRocks. Здорово, что у кого-то это первый публичный pr и сразу такого размера :) И вот сейчас вроде интересно попробовать - наконец-то у нас в обойме появилась хотя бы одна бд, которая поддерживается. Но с другой стороны - что SQLMesh, что DBT теперь принадлежат Fivetran с каким-то мрачным будущим. Да еще вот только что я делал CI в DBT для мультикаталогов в StarRocks и вот сильно не уверен, что это реально повторить в SQLMesh. И есть подозрение, что ко всему этому мы начнем распиливать активно единый проект на много проектов. Есть у кого опыт, стоит ли пробовать?

ИИшные будни и полный пятничный сумбур Сегодня подводили итоги квартала и все команды дата офиса сейчас пишут контекст для своих помощников. И вот нонсенс - чем лучше ваша слоенная архитектура и чем больше у нее документации, тем сложнее ее запихать в RAG и тем хуже на ней работают модели. Спасибо умным людям (привет, Венера), которые начали подробно описывать метрики в компании в маркдауне в репке dbt еще в 22 году - это самый простой и потрясающий буст по контексту для простых потребителей. Но вернемся к тому, почему вроде работали,а получилась шляпа. Самый простой способ убедиться в этом без построениях всяких специальных рагов - поставить nao. Кто не слышал про эту штуку (как я, например, и спасибо большое просвещающим коллегам) - это по сути самая простая обертка для агента, нацеленная на работу с dwh. С одной стороны вы подключаете любую модель (Claude, ChatGPT, локальные модели), с другой стороны у вас веб чат с аутентификацией и авторизацией, а посередине репа с текстовыми файлами контекста. На первом запуске, когда мы подключили локальную модельку я был в диком восторге - ответ получил за секунды и вроде похож на верный. Правда на следующий день мы выяснили, что он был полностью выдуманным и ни один запрос в бд не был сделан :) Но в общем и целом после тюнинга получается достаточно удобно. Так вот, в эту репку можно прямо ссылкой отгрузить dbt проект. Плюс еще сам nao собирает мету со всех подключенных бд на этапе init. И потом с этой горой информационного мусоры мы пытаемся взлететь, а размер контекста у локальных моделей сильно отстает от лидеров рынка - будет сплошной мусор. Решить этой штукой мне хотелось вечную боль команд данных - выгрузки. И все бы ничего, но в коробке такого функционала нет :) Отвечать на вопросы с цифрами может, графики рисовать умеет, но csv выплюнуть - не сделали. У нас в планах на следующий квартал реализовать и пушнуть в апстрим. Еще коллега впрягся и добавил туда поддержку StarRocks :) А что по остальным командам? BI и их ужасные системы из большой тройки. Самая большая проблема там - найти интересующую тебя информацию. Даже если приложение имеет описание, надо его еще найти, посмотреть есть ли там нужные разрезы и метрики. Решение - RAG. Чуете чем пахнет? Дата говернансом, дада, тем самым. Когда-то внедряли каталоги данных за миллион денег, которые сами по себе не могут решить никаких проблем. Так вот описание нужно, а каталоги - нет. И сам по себе офис данных сейчас по сути становится держателем контекста информации всей компании, мне так кажется.

Ограничения архитектуры Вчера абсолютно случайно набрел на выступление Виктора из Авито про стабильность платформы данных. Именно тот момент, когда получаешь интересный доклад на неожиданной площадке. И почему так важно выбирать площадку под доклад для получения нужной аудитории. Мне доклад понравился: решение проблем не заменой системы, а выстраиванием хорошего стека вокруг нее. Напоминаю, что тайминг этого доклада попадает с отказом от вертики и миграцией на трино, и тут причин еще больше набросали. Так вот про архитектуру. Vertica при всех своих недостатках - шикарная база. Она очень удачно использует свою архитектуру и много где снимает головную боль с конечного пользователя. Например, та самая история про внутреннюю репликацию данных. Выставили вы степень репликации и знаете, что у вас отказоустойчивость -1 нода (или -2, если вы богатый буратино) - все как в ГП. StarRocks же предлагает на замену историю про таблеты (выше уже рассказывал про них). И что в итоге? Мы словили проблему мелких файлов, столько известную в хадупе, на нашем кластере StarRocks. 180 тысяч таблетов на 6 нод. Вам может показаться, что это не так и много - но наш любимый стриминг впал в полный неадекват. Постоянные спайки на графиках отзывчивости, зависания потоков, 99 перцентиль ушел за пределы минуты. И это при свободном процессоре и свободной памяти. Все метрики на компакшне на графиках тоже особо не показательны - десятки и сотни мегабайт потребления. Надо думать СВОЕЙ ГОЛОВОЙ при создании таблиц и всегда-всегда задавать количество бакетов. И не стоит мелочиться с партициями. Если нам прямо говорят, что таблет должен быть от 1 до 10 гигабайт, то так и надо делать. Уменьшили количество таблетов в 6 раз, почти везде перешли на годовые партиции, количество бакетов чаще всего от 1 до 3. И только на больших таблицах оставили 6. Как итог - график выправился, работать стало стабильнее. Начал завидовать ребятам с дата лейками, насколько понимаю там эта ситуация обыграна лучше. На всякий случай, картинка выше - про внутренние таблицы SR. У нас к этому еще около 10к таблиц из хадупа, ну и пара тысяч из mysql источников. А чего так долго не был? Каждый раз, когда увеличивается зона ответственности, наступает период адаптации. Команд стало больше - справляться трудно. Интересно когда наступает предел, когда кукуха начинает уезжать. С другой стороны, буст от иишки очень сильно виден почти у всех. Не думаю, что команды и дальше будут расти по головам. Чото много мыслей на эту тему, но история все рассудит. А дальше у нас будет пост про CI для StarRocks, к которому подключены десятки внешних каталогов. Хотел этот доклад на смартдату донести, но видимо придется где-то в сторонке сделать.

✨ 2 апреля в Москве на Data Summit от DIS Group выступят коллеги из StarRocks 💼 спикеры расскажут о следующих аспектах развития StarRocks: 🔹 применении ИИ‑агентов в StarRocks; 🔹 повышении скорости аналитики в реальном времени — том самом «молниеносном» быстродействии системы; 🔹 roadmap продукта, включая новости о материализованных представлениях и их субсекундных обновлениях; 🔹 улучшениях в механизмах кэширования и оптимизаторах; 🔹 работе с операциями UPSERT и MERGE; 🔹 поддержке рекурсивных CTE‑операций; 🔹 расширении возможностей UDF в SQL; 🔹 алгоритмах распределения данных в таблетах на основе интервалов значений. 📅 Ещё есть время зарегистрироваться на мероприятие: можно выбрать желаемый формат участия — онлайн или офлайн. 🚀 2 апреля — отличная возможность узнать о новинках и перспективах StarRocks из первых рук. Рекомендуем обратить внимание на это событие!

А теперь мероприятие номер 2. Если кто хочет пообщаться с разработчиками StarRocks лично :) А таких я видел.

Сегодня день анонсов разных мероприятий по StarRocks, которые пройдут уже вот-вот. Буквально вчера в канале спрашивали про работу iceberg через StarRocks на S3 от Selectel. И вот тут есть что послушать (но не уверен про S3): вебинар СР ТЕХ х Selectel 31 марта в 12:00. Расскажем про результат прогона StarRocks на TPC-DS в облаке: от 3 узлов до 111, от 100 ГБ до 10 ТБ. Реальное поведение СУБД с графиками, цифрами и инженерными выводами. Регистрация на вебинар: https://selectel.ru/blog/events/analytics-database/