Ограничения архитектуры

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

Так вот про архитектуру. Vertica при всех своих недостатках - шикарная база. Она очень удачно использует свою архитектуру и много где снимает головную боль с конечного пользователя. Например, та самая история про внутреннюю репликацию данных. Выставили вы степень репликации и знаете, что у вас отказоустойчивость -1 нода (или -2, если вы богатый буратино) - все как в ГП. StarRocks же предлагает на замену историю про таблеты (выше уже рассказывал про них).

И что в итоге? Мы словили проблему мелких файлов, столько известную в хадупе, на нашем кластере StarRocks. 180 тысяч таблетов на 6 нод. Вам может показаться, что это не так и много - но наш любимый стриминг впал в полный неадекват. Постоянные спайки на графиках отзывчивости, зависания потоков, 99 перцентиль ушел за пределы минуты. И это при свободном процессоре и свободной памяти. Все метрики на компакшне на графиках тоже особо не показательны - десятки и сотни мегабайт потребления.

Надо думать СВОЕЙ ГОЛОВОЙ при создании таблиц и всегда-всегда задавать количество бакетов. И не стоит мелочиться с партициями. Если нам прямо говорят, что таблет должен быть от 1 до 10 гигабайт, то так и надо делать.

Уменьшили количество таблетов в 6 раз, почти везде перешли на годовые партиции, количество бакетов чаще всего от 1 до 3. И только на больших таблицах оставили 6. Как итог - график выправился, работать стало стабильнее. Начал завидовать ребятам с дата лейками, насколько понимаю там эта ситуация обыграна лучше.

На всякий случай, картинка выше - про внутренние таблицы SR. У нас к этому еще около 10к таблиц из хадупа, ну и пара тысяч из mysql источников.

А чего так долго не был?

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

С другой стороны, буст от иишки очень сильно виден почти у всех. Не думаю, что команды и дальше будут расти по головам. Чото много мыслей на эту тему, но история все рассудит.

А дальше у нас будет пост про CI для StarRocks, к которому подключены десятки внешних каталогов. Хотел этот доклад на смартдату донести, но видимо придется где-то в сторонке сделать.

ИИшные будни и полный пятничный сумбур

Сегодня подводили итоги квартала и все команды дата офиса сейчас пишут контекст для своих помощников. И вот нонсенс - чем лучше ваша слоенная архитектура и чем больше у нее документации, тем сложнее ее запихать в RAG и тем хуже на ней работают модели. Спасибо умным людям (привет, Венера), которые начали подробно описывать метрики в компании в маркдауне в репке dbt еще в 22 году - это самый простой и потрясающий буст по контексту для простых потребителей. Но вернемся к тому, почему вроде работали,а получилась шляпа. Самый простой способ убедиться в этом без построениях всяких специальных рагов - поставить nao.

Кто не слышал про эту штуку (как я, например, и спасибо большое просвещающим коллегам) - это по сути самая простая обертка для агента, нацеленная на работу с dwh. С одной стороны вы подключаете любую модель (Claude, ChatGPT, локальные модели), с другой стороны у вас веб чат с аутентификацией и авторизацией, а посередине репа с текстовыми файлами контекста. На первом запуске, когда мы подключили локальную модельку я был в диком восторге - ответ получил за секунды и вроде похож на верный. Правда на следующий день мы выяснили, что он был полностью выдуманным и ни один запрос в бд не был сделан :) Но в общем и целом после тюнинга получается достаточно удобно.

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

Решить этой штукой мне хотелось вечную боль команд данных - выгрузки. И все бы ничего, но в коробке такого функционала нет :) Отвечать на вопросы с цифрами может, графики рисовать умеет, но csv выплюнуть - не сделали. У нас в планах на следующий квартал реализовать и пушнуть в апстрим. Еще коллега впрягся и добавил туда поддержку StarRocks :)

А что по остальным командам? BI и их ужасные системы из большой тройки. Самая большая проблема там - найти интересующую тебя информацию. Даже если приложение имеет описание, надо его еще найти, посмотреть есть ли там нужные разрезы и метрики. Решение - RAG. Чуете чем пахнет? Дата говернансом, дада, тем самым. Когда-то внедряли каталоги данных за миллион денег, которые сами по себе не могут решить никаких проблем. Так вот описание нужно, а каталоги - нет. И сам по себе офис данных сейчас по сути становится держателем контекста информации всей компании, мне так кажется.

Обновки подъехали

Абсолютно случайно в ln увидел, что в SQLMesh завезли поддержку StarRocks. Здорово, что у кого-то это первый публичный pr и сразу такого размера :)

И вот сейчас вроде интересно попробовать - наконец-то у нас в обойме появилась хотя бы одна бд, которая поддерживается. Но с другой стороны - что SQLMesh, что DBT теперь принадлежат Fivetran с каким-то мрачным будущим. Да еще вот только что я делал CI в DBT для мультикаталогов в StarRocks и вот сильно не уверен, что это реально повторить в SQLMesh.

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

Есть у кого опыт, стоит ли пробовать?

DBX

Так ли уж много надо для счастья на сегодняшний день? Полный бак бензина, хороший велик и... Чтобы хоть одна sql-ide показывала миллисекунды для datetime колонок в StarRocks!

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

И вот недавно думали тряхнуть стариной и провести новый DBT митап с Алмазом, и он случайно обронил в разговоре dbx. Выглядит интересно, пошел смотреть что это такое.

Да, вся IDE поместилась в 15 мегабайт с поддержкой почти всех бд, которые сейчас есть на рынке. Но эти 15 мегабайт, конечно же, не включают в себя JDBC драйвера для вертики или хайва, например. А вот StarRocks включен в поставку по умолчанию. И то, с чем не справились ни JB с их убер зоопарком, ни DBeaver с аналогом - вот на скриншоте сверху.

А еще в DBX на маке работает cmd+enter для выполнения запросов, что благополучно сломали уже год как в DBeaver.

А еще там есть MCP для всех ваших коннектов и готовое how-to интеграция с курсором и клодом (и остальными). Который впрочем не работает на маках с арм :)

И еще рендеринг тупит и если быстро листать виртуальные столы - то видишь белый экран примерно пару секунд после перехода.

Но ладно, за миллисекунды и хоткеи все можно простить. Теперь это мой топчик. Спасибо, Алмаз :)

Какой-то микс нынче в дата мире происходит

Сократят ли кожаных в пользу AI? Я тут погуглил. Мне кажется, что эти 2 компании умеют пользоваться иишкой как никто другой. Ну и чего, сократили там кого-нибудь? :)

С другой стороны не пользоваться сейчас таким инструментом кажется довольно глупой идеей. Не знаю как у вас, у нас в командах данных текучки более 50 процентов. Я больше 10 лет пишу код, около 5 лет в текущей компании. Писать очередной оператор в эйрфлоу, объяснять зафиксированные метрики в дбт в очередной раз? Увольте пусть ии ответит за меня.

И вот эта история с данными, мне кажется, подводит отделы данных к решению такой задачки, как создание "единого хранилища контекста", а моем понимании ai платформы в компании. Что все понимают под этими словами (и понимают ли) - большой вопрос. Есть ли какие-то устоявшиеся шаблоны или хотя бы примеры - нет. Можно ли угадать, куда пойдет развитие иишки - нет.

Именно поэтому это довольно клевая задача :)

Похоже, что StarRocks будет все меньше (хотя мы его и опробовали как хранилище векторов, и у меня для него лежит написание нативного CDC на гошке в беклоге), а больше будет всего подряд про современную техничку в офисе данных во всех ее ипостасях. Потому что никто не рассказаывает про графы для dbt, платформы агентов, тлен векторизации и как подсадить хотя бы 100 человек на свои скилы (оказалось, что писать mcp на гошке - кайф) :)

PS кстати dbx - тормозная штука с глюками интерфейса. И да, это тот момент, когда даже гуй на жабе быстрее.

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 в каталоге данных - нам нужна информация из него.

За долгом всегда придут

Где-то в прошлой до-ии жизни я написал негативную статью на хабре про 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.

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.

Итоги квартала и ИИ

Самое время посчитать насколько выгодно мы обменяли подписки по 20 баксов в команде из 4 человек.

На картинке ничего не понятно, но основных метрик по сути 3: время производства (отдельно по клиентским задачам и задачам команды), которое противопоставляется размеру и возрасту задач в беклоге.

Напомню, что мы являемся платформенной командой и у нас много своих продуктовых задач.

Мы получили сокращение производственного цикла клиентских задач примерно на 90% в 85 перцентиле, своих технических на 60%. Размер беклога упал незначительно, но при этом срезали 65% с его возраста.

Выходит, что метрики не пытались взломать и эксперимент достаточно честный.

Если уйти от объективных метрик к пользе: ее мы тоже получили с запасом - буст платформы за квартал получился очень приличным.

Наблюдения со стороны

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

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

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, а нас разделяет под несколько тысяч километров.

Семантический слой без семантического слоя

В 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, а не в устаревший клон.

Код · образ