Data mesh на отечественном стеке: что закрыли, что не закрыли совсем

Data mesh как идея живёт в конференционных докладах уже несколько лет. Но в этом году мы впервые увидели, как крупный российский клиент реально пытается сдвинуться в эту сторону - не ради концепции, а потому что монолитный DWH перестал справляться с темпом изменений. Разные бизнес-домены хотят управлять своими данными сами, а центральная аналитическая команда физически не успевает делать это за всех.

Нас попросили помочь с архитектурой перехода. И сразу встал вопрос, который оказался интереснее, чем мы ожидали: на каком инструментарии строить? С зарубежными решениями всё привычнее - Collibra, DataHub, OpenMetadata плюс Atlan. С отечественным стеком поле пустое, и туда смотреть приходится, потому что клиент работает в регулируемом секторе.

Что нужно для data mesh по минимуму

Три вещи, без которых всё рассыпается в теорию:

• Data catalog - единый реестр датасетов, владельцев, метаданных. Без него domain-команды не находят данные друг друга, и идея децентрализации превращается в хаос.
• Data contracts - формальное описание того, что один домен обязуется поставлять другому: схема, качество, SLA. Без этого зависимости между доменами держатся на устных договорённостях и падают в пятницу вечером.
• Lineage - граф того, откуда пришли данные в конкретном датасете. Нужен для отладки, для регуляторных требований и для понимания последствий изменений.

Data catalog: есть, но с оговорками

Единственный отечественный инструмент, который мы нашли с реальной поддержкой data catalog - это несколько продуктов от вендоров, работающих на рынке управления данными: DataLine Catalog (продукт от «ДатаЛайн»), решения в составе платформы «Сберданных» для внутреннего использования, и ряд самодельных реализаций на базе OpenMetadata, которые интеграторы разворачивают как проект под заказчика.

Мы остановились на OpenMetadata как основе - он open-source, разворачивается в Kubernetes, и несколько российских команд уже имеют с ним опыт. Интерфейс нормальный, REST API есть, коннекторы к ClickHouse, PostgreSQL, Kafka - работают из коробки.

Минус, который сразу проявился: OpenMetadata создавался под английскую операционную среду. Поля описаний, теги, UI - всё работает с кириллицей без проблем, но поиск по метаданным с русскими терминами ведёт себя не всегда предсказуемо. Это не блокер, но команде клиента пришлось потратить время на настройку индексации в Elasticsearch-бэкенде.

Data contracts: сложнее

С data contracts на отечественном стеке почти ничего нет. Это не продуктовый пробел одного вендора - это отсутствие сложившейся практики в целом. В зарубежной экосистеме data contracts начали формализовываться как паттерн пару лет назад, и инструменты вроде Soda, Great Expectations, DQOps появились достаточно быстро. У нас аналогов в виде коробочного продукта нет.

Что мы сделали: взяли Great Expectations, развернули локально, написали базовый шаблон контракта в YAML - схема, критерии качества, SLA на latency обновления. Это работает, но это ручная работа, а не экосистема. Версионирование контрактов через Git, оркестрация проверок через Airflow - всё собирается из кубиков, а не берётся готовым.

Проблема не техническая: Great Expectations хорошо работает на Python-стеке. Проблема организационная - domain-команды клиента не готовы сами писать и поддерживать контракты. Им нужен UI, нотификации, история нарушений. В российских коробочных продуктах этого нет ни у кого.

Lineage: частично закрыто, но с потерями

OpenMetadata умеет строить lineage, если данные поступают от поддерживаемых источников через коннекторы. ClickHouse-коннектор парсит DDL и понимает CREATE VIEW AS SELECT - для этих случаев граф строится автоматически.

Проблема возникает с ETL-процессами, написанными не на Airflow и не в dbt. У клиента часть пайплайнов - кастомные Python-скрипты, которые запускаются через собственный оркестратор. Lineage по ним не строится автоматически: нужно либо инструментировать код вручную через OpenLineage API, либо смириться с пробелами в графе.

Мы выбрали инструментирование, потому что регулятор требует прослеживаемость. Но это добавило несколько недель к проекту - OpenLineage API надо встраивать в каждый скрипт, это не «поставил коннектор и готово».

Что не закрыли совсем

Data quality monitoring в реальном времени. Есть проверки на момент загрузки, есть батчевые проверки по расписанию. Но нет отечественного аналога, который бы мониторил качество потоковых данных непрерывно с алертингом в Telegram/почту на понятном языке.

Governance UI для бизнес-пользователей. Каталог настроен, lineage работает, но показывать это domain-владельцу данных, у которого нет технического бэкграунда, - боль. OpenMetadata требует понимания концепций, которые аналитику надо объяснять. Нормального «бизнесового» интерфейса поверх каталога нет ни в одном отечественном продукте.

Автоматическое обнаружение PD. У клиента в данных есть персональные данные, и их нужно маркировать в каталоге. Сделали через теги вручную. Автоматической классификации с обнаружением PD по содержимому - нет.

Где мы сейчас

Через несколько месяцев работы у клиента есть работающий MVP: каталог на OpenMetadata, lineage для 70-80% пайплайнов, базовые data contracts для критических доменов. Это реально функционирующая data mesh - не идеальная, но рабочая.

Чего не хватает - готовой российской экосистемы вокруг концепции. Отдельные кирпичи есть: базы данных, оркестраторы, хранилища. Но склеивающий слой - catalog, contracts, governance - приходится собирать из open-source компонентов своими руками. Это не трагедия, но это честный ответ на вопрос «насколько данная архитектура доступна в текущем отечественном стеке».

Подробнее про подходы к DWH и аналитической платформе можем обсудить отдельно - особенно если задача про регулируемый сектор и ограничения на зарубежный инструментарий.