Data Mesh

Зачем

К 2018-му в больших организациях (Netflix, JPMorgan, Zalando) централизованная data-команда стала бутылочным горлышком. Сотни data-engineers, очередь работы — месяцы. Marketing хочет KPI? Открывает тикет в data team. Payments хочет dashboard? Тикет. Команда из 50 человек физически не успевает писать ETL для 100 доменов, разбираться в их бизнес-логике и поддерживать качество.

Zhamak Dehghani (ThoughtWorks 2019) формализовала Data Mesh — децентрализованную парадигму. Идея: data ownership разделяется по доменам, как microservices разделили ownership сервисов. Команда orders владеет orders DB и аналитическими data products про orders. Central data team превращается в platform team — даёт инфраструктуру, не пишет pipelines.

Это не «новый Snowflake», а organizational + technical сдвиг. Без mature engineering culture, без 100+ data engineers — Mesh принесёт больше боли, чем пользы.

Mental model

«Data Mesh = microservices для данных: каждый бизнес-домен владеет своими data products end-to-end. Platform team даёт self-serve инфраструктуру. Federated governance задаёт стандарты, enforce через CI, а не через митинги.»

Четыре принципа Dehghani:

1. Domain-oriented decentralized ownership — кто владеет operational data (orders microservice), тот владеет и analytical data про этот домен.
2. Data as a product — discoverable, addressable, trustworthy (с SLO), self-describing, interoperable, secure. У продукта есть owner.
3. Self-serve data platform — domain team создаёт новый data product за день без тикетов.
4. Federated computational governance — committee задаёт глобальные стандарты, политики кодифицируются (OPA, schema validators), enforce в CI.

Что на диаграмме

Шесть групп на канвасе:

• Federated Governance Council — opa (OPA policies для PII, GDPR, schema), contracts (Data Contracts schema + SLO).
• Self-Serve Data Platform — s3 (S3 + Iceberg storage), catalog (DataHub discovery + lineage), compute (Spark/Trino/Flink), observ (Monte Carlo quality SLOs).
• Orders Domain Team — ord-db (orders DB) + ord-prod (data product orders_summary).
• Payments Domain Team — pay-db + pay-prod (payments_daily).
• Marketing Domain Team — mkt-prod (campaign_attribution) + mkt-bi (dashboards).
• Legacy DWH (Gen 1-2) — central-team с очередью ETL-тикетов и dwh-bottleneck для сравнения с Mesh.

Edges: domain DB → product (CDC + dbt), product → s3 (publish) и → catalog (register), governance ноды → catalog/storage (policy enforce, SLO alerts), legacy: domain DBs → central-team → dwh.

Сценарии

Generation 1-2: монолитный central DWH. Orders и payments шлют тикеты в central team. Очередь — 47 тикетов, ожидание 3 месяца. Sequential pipelines, один баг ломает всё. DWH превращается в data swamp с 10K таблиц без ownership. Central team — single point of contention для бизнеса.

Domain team публикует data product сам. Orders team строит orders_summary через dbt + Iceberg. Кладёт в s3://lake/domains/orders/orders_summary/v1. Регистрирует в DataHub: schema, owner, SLO 1h freshness. Публикует data contract v1 с 30-day breaking change notice. Monte Carlo автоматом трекает freshness и quality. Platform team в процессе не участвовала.

Marketing discovers + consumes через catalog. Marketing ищет в DataHub «orders by country last 30 days», находит orders.orders_summary с owner и SLO. OPA auto-approves access (federated policy). Через Trino делает join orders_summary + payments_daily, билдит campaign_attribution как новый data product. Lineage auto-detected. BI dashboards consumes — быстрая итерация без тикетов в central team.

Computational governance блокирует breaking change. Orders team хочет переименовать колонку country → country_code. Data contract v1 нарушен — 30-day notice не дан. CI пайплайн читает OPA policies, блокирует merge в репозиторий (не на митинге). Downstream mkt-prod был бы сломан, но enforcement не дал. Catalog нотифицирует orders-team: нужен migration plan и notice.

Freshness SLO violation triggers alert. orders_summary не обновлён 6 часов (SLO 1h). Monte Carlo fires anomaly detection. PagerDuty шлёт owner data product, не central team. Marketing dashboard переходит на cached fallback, помечен как stale. Accountability у Data Product Owner — это и есть «data as a product».

Trade-offs (ADR)

ADR-001: когда выбирать Data Mesh, а когда — нет.

• Context. К 2018 централизованные data teams в больших компаниях стали bottleneck — очередь работы месяцами при сотнях engineers. Dehghani формализовала Mesh как децентрализованную парадигму. Но это organizational изменение в первую очередь, и многие реализации провалились из-за неподходящего масштаба.
• Подходит если: >100 data engineers / 20+ domain teams; centralized team действительно bottleneck; domains имеют свою expertise (medical, financial, compliance); engineering culture mature (microservices, CI/CD, observability); готовы инвестировать в platform 1-2 года setup.
• НЕ подходит: <50 data people; все данные в одном домене; нет mature data platform; domain teams без data engineering capabilities; модель «data team в углу» работает.
• Roadmap. 2-3 года incremental migration. Не «all-or-nothing за спринт». Начни с 2-3 pilot domains.

ADR-002: catalog — DataHub vs Atlan vs OpenMetadata. DataHub (open source, self-hosted) выбран в типовом enterprise: нет vendor lock-in, сильнейшая column-level lineage через dbt/Spark integrations, GraphQL API легко интегрируется в CI. Trade-off: UX слабее коммерческого Atlan ($100-180K/year), нужны 2 FTE для operate, setup 6 недель.

ADR-003: federated computational governance vs human review. Старая модель — committee утверждает каждую schema change через тикет; превращается в очередь хуже централизованной. Mesh-модель: committee пишет политики (OPA Rego, Avro compat, dbt tests), CI блокирует нарушения. Human review только для исключений: новый PII data class, cross-region data movement, breaking change без notice. Метрика успеха — <5% решений требуют human review через год.

Реальные системы

• Zalando — один из первых внедренцев (2019-2020), 1000+ engineers, сотни data products.
• JPMorgan Chase — large-scale Mesh для cross-line-of-business data sharing.
• HelloFresh — 50+ domain teams (recipes, ingredients, logistics, marketing).
• Adevinta (eBay classifieds spin-off) — Mesh на Iceberg + dbt.
• Saxo Bank — Mesh + data contracts.
• Netflix — не Mesh формально, но decentralized: domain teams владеют данными, central platform team.
• PayPal — open-sourced data contracts template, стал de-facto спекой.

Инструментальная экосистема: DataHub / OpenMetadata / Atlan (catalogs), Monte Carlo / Bigeye / Soda (quality observability), OPA / Apache Ranger / Unity Catalog (governance), Iceberg / Delta Lake / Hudi (storage), dbt contracts (schema enforcement), Snowflake Data Sharing (cross-domain exchange).

Anti-patterns

• «Mesh-washing» — переименовали centralized team в «platform», но они продолжают писать pipelines. Структурно ничего не поменялось.
• «Mesh без platform» — каждый domain строит свой mini-stack. Дубли, нельзя cross-query, total cost растёт линейно по командам.
• «Domain ownership без accountability» — нет роли Data Product Owner. Никто не отвечает за quality, всё ломается, никто не виноват.
• «Federated governance = no governance» — без enforcement политик. PII утекает, schema breaks ломают downstream, compliance fail.
• «Скопировали Zalando» — Mesh успешен у них потому что 1000+ engineers. Стартапу с 5 data engineers это убьёт продуктивность.
• «All-or-nothing migration за спринт» — реальный roadmap 2-3 года incremental. Иначе — failed программа.
• «Platform team как ticket queue» — domains просят platform добавить feature, обратно к centralized модели. Лечение: self-serve UI/CLI/API, platform owns только roadmap.
• «Cost explosion без centralized billing» — domains не видят, что их queries в Snowflake стоят $50K/month. Нужен cost attribution per domain.

Когда НЕ использовать

• <50 data people, <10 доменов. Overhead Mesh (platform team, governance council, catalog, contracts) сожрёт весь benefit. Используй central data team + dbt — этого хватит на годы.
• Все данные живут в одном bounded context. Если это в реальности один большой домен — нет смысла дробить искусственно.
• Нет mature data platform. Mesh поверх Hadoop+cron — кошмар. Сначала построй self-serve платформу (S3+Iceberg+Spark+catalog+CI/CD), потом разделяй ownership.
• Domain teams без data engineering capabilities. Если бизнес-команды не могут хотя бы базово писать SQL/dbt — ты просто переложил работу на тех, кто не умеет.
• Регуляторно требуется централизованный data steward (некоторые финансовые/медицинские области). Federated computational governance не везде принимается аудиторами.

Дальше читать

• [CONCEPT]etl-vs-elt — Mesh опирается на ELT-парадигму (трансформации в data product, не в pipeline).
• [CONCEPT]iceberg-deltalake-hudi — Iceberg как де-факто storage format для Mesh data products.
• [CONCEPT]change-data-capture — CDC из operational DB как самый частый source для data products.
• [CONCEPT]stream-processing — Kafka топики как альтернатива Iceberg таблицам для streaming data products.

Канонические источники:

• Zhamak Dehghani, «How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh» (Martin Fowler blog, 2019) — оригинал.
• Zhamak Dehghani, Data Mesh: Delivering Data-Driven Value at Scale (O'Reilly 2022) — главная книга.
• Mundkur, Hagedorn et al., Data Mesh in Action (Manning 2023) — практика.
• Open Data Contract Standard (bitol.io) — спека для contracts.
• PayPal data-contract-template на GitHub.