Телеграм канал «»

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