Data mesh на отечественном стеке: domain ownership, ClickHouse и где федерация данных ломается

Data mesh - это когда команда, ответственная за домен, сама владеет своими данными: их качеством, схемой, доступностью и SLA. Центральная BI-команда перестаёт быть единственным горлышком, через которое протаскиваются все пайплайны. Звучит как здравая идея, особенно когда у заказчика восемь продуктовых доменов и один измотанный дата-инженер на всех.

На практике мы сейчас ведём именно такой проект - крупный промышленный холдинг, несколько бизнес-единиц, исторически разрозненные данные. Задача: выстроить data mesh поверх отечественного стека без иностранных SaaS-каталогов и без единого централизованного хранилища, которое всех и замедляло.

Как устроена архитектура

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

Поверх этого - единый каталог данных. Мы взяли OpenMetadata (self-hosted, лицензия Apache 2.0), интегрировали с каждым ClickHouse-кластером через коннекторы и сделали из него точку входа: где что лежит, кто владелец, какие данные готовы к межменному потреблению.

Data contract - ключевое понятие в этой схеме. Каждый домен публикует не просто таблицы, а явные контракты: какие поля, какие типы, какой SLA обновления, какая гарантия качества. Контракт описывается в YAML, версионируется в git, регистрируется в каталоге. Потребитель подписывается на конкретную версию контракта и получает уведомление при breaking change.

Domain A (CRM)         Domain B (Production)      Domain C (Logistics)
  ClickHouse-A           ClickHouse-B               ClickHouse-C
  + data contracts       + data contracts            + data contracts
        |                       |                          |
        +-------------- OpenMetadata Catalog -------------+
                                |
                      Cross-domain consumers
                      (BI, ML, reporting)

Где ломается федерация

Вот где начинается настоящий разговор.

Первое - cross-domain запросы. ClickHouse умеет делать распределённые запросы через движок Distributed и remote-функции. Но это работает нормально, когда кластеры находятся в одной сети с предсказуемой задержкой. У нашего заказчика домены физически в разных ЦОД-ах (историческое наследие). Remote-запрос из кластера логистики в кластер CRM для join-а даёт latency, с которой BI-инструменты просто не справляются интерактивно. Решение, к которому мы пришли: для межденного потребления домен публикует не живую таблицу, а реплицированный «data product» - периодически обновляемую агрегированную копию для внешних потребителей. Живой федерации нет, зато есть предсказуемость.

Второе - governance без диктатора. В классическом монолитном DWH есть центральная команда, которая говорит «эта колонка называется так, этот тип вот такой, дедупликация по этому ключу». В data mesh этого человека нет по дизайну. У нас довольно быстро выяснилось, что два домена независимо завели сущность «клиент» с несовместимыми идентификаторами. Домен CRM использует внутренний UUID, домен биллинга - ИНН. Джойнить их сложно, и это не проблема инструментов - это организационная проблема, которую инструменты не решают.

Мы ввели уровень «federated governance»: небольшой совет из владельцев доменов, который собирается раз в две недели и согласует общие справочники и master-сущности. Без принуждения, но с явным реестром «что должно быть одинаковым». Работает с переменным успехом - зависит от того, насколько заняты участники.

Третье - observability данных. Когда у тебя один DWH, ты видишь всё в одном месте. Когда восемь кластеров - мониторинг качества данных надо строить отдельно. OpenMetadata умеет запускать data quality checks через своё UI, но интеграция с ClickHouse по части column-level lineage работает не идеально: lineage строится по SQL-запросам, которые OpenMetadata перехватывает через query log, и на сложных CTE иногда теряет часть рёбер графа. Мы дополнили это ручной разметкой критичных пайплайнов.

Четвёртое - версионирование контрактов на практике. В теории: вышла новая версия контракта, потребители получили уведомление, мигрировали. На практике: потребитель - это тоже команда со своим спринтом и бэклогом. Breaking change в контракте домена производства завис на две недели, потому что команда BI-отчётности была занята другим. Контракт v2 вышел, но отчёты работали на v1-таблицах, пока кто-то не заметил расхождение. Помогло бы автоматическое тестирование на стороне потребителя - сейчас это добавляем.

Что работает без оговорок

ClickHouse как база для domain-owned хранилища - хорошее решение. Команды разворачивают кластер через Helm-чарты, управляют самостоятельно, релизный цикл у каждого домена свой. После того как мы написали базовые runbook-и и настроили мониторинг через VictoriaMetrics, нагрузка на центральную инфра-команду по этим кластерам невысокая.

OpenMetadata как каталог - функционально достаточен, хотя UX в некоторых местах требует привыкания. Главное, что он self-hosted, поддерживает LDAP-аутентификацию и не тянет данные наружу - для заказчиков с требованиями по суверенитету данных это не опция, а требование.

Где мы сейчас

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

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

Если работаете с похожей задачей - распределёнными данными по нескольким доменам и нужен порядок без монолитного DWH - в рамках DWH/BI-проектов мы помогаем выстроить как архитектуру, так и governance-процессы вокруг неё.