Data Mesh и Data Contracts

Введение

Централизованные команды данных не масштабируются. Когда одна data-команда из 7 человек обслуживает 500 сотрудников, каждый новый запрос встаёт в очередь. Data Mesh — архитектурный подход, который переносит ответственность за данные в доменные команды, превращая каждый домен в поставщика data products. Но децентрализация без контрактов — это хаос. Data Contracts обеспечивают согласованность в распределённой архитектуре.

Четыре принципа Data Mesh

Data Mesh, предложенный Zhamak Dehghani (2019), основан на четырёх принципах:

1. Domain Ownership

Каждый бизнес-домен (клиенты, заказы, финансы) владеет и данными, и пайплайнами, и качеством. Центральная data-команда не является бутылочным горлышком.

2. Data as a Product

Доменная команда не просто хранит данные — она поставляет data product: датасет с SLA, документацией, quality-метриками и контрактом. Потребители получают продукт, а не сырые таблицы.

3. Self-Serve Data Platform

Централизованная платформа предоставляет инфраструктуру (хранилище, вычисления, каталог) как сервис. Доменные команды используют платформу, но не зависят от центральной команды для создания пайплайнов.

4. Federated Governance (федеративное руководство)

Federated Governance (федеративное руководство) — модель, в которой центральный governance-орган определяет общие стандарты (naming, security, quality thresholds), а доменные команды реализуют их в своём контексте. Баланс между автономией и согласованностью.

Data Contracts

Data Contract — формальное соглашение между producer (поставщиком) и consumer (потребителем) данных. Контракт определяет: какие данные предоставляются, в каком формате, с каким SLA, и что происходит при нарушении.

Структура Data Contract

contract:
  name: customer_data_product
  version: "2.1.0"
  owner: CRM Domain Team

  schema:
    type: object
    properties:
      customer_id:
        type: integer
        description: Unique customer identifier
        pii: false
      email:
        type: string
        format: email
        description: Customer email address
        pii: true
        classification: confidential

  sla:
    freshness: "1 hour"
    availability: "99.5%"
    quality_score: "> 0.95"

  breaking_changes:
    policy: "30 days notice"
    notification: "[email protected]"

Версионирование контрактов

Data Contracts используют semver (Semantic Versioning):

• Major (2.x.x -> 3.0.0): breaking change — удаление колонки, изменение типа
• Minor (2.1.x -> 2.2.0): добавление колонки, новый consumer
• Patch (2.1.0 -> 2.1.1): fix описания, обновление SLA

Breaking changes требуют уведомления всех consumers за 30 дней (определяется в контракте).

Data Mesh vs Centralized: когда что применять

Выбор между Data Mesh и централизованной архитектурой — это архитектурное решение, зависящее от масштаба, зрелости и организационной структуры.

Когда Centralized подходит лучше

• Организация < 200 сотрудников (DataTech: 500, пограничный случай)
• Data-команда < 10 человек
• Governance maturity Level 1-2
• Немного доменов (< 5)

Когда Data Mesh оправдан

• Организация > 1000 сотрудников (FinSecure: 2000+)
• Выделенные data-инженеры в каждом домене
• Governance maturity Level 3+ с Federated Governance
• Централизованная команда стала бутылочным горлышком

Hybrid: практический компромисс

Большинство организаций используют гибридный подход: центральная платформа + domain ownership для крупных доменов. DataTech на текущем уровне зрелости (Level 1) должна начинать с централизованной архитектуры и переходить к mesh по мере роста.

Сценарий: DataTech оценивает Data Mesh

Сценарий: ДатаТех Солюшенз

CTO DataTech прочитал статью о Data Mesh и предложил внедрить его немедленно. VP Engineering сомневается.

За Data Mesh:

• Центральная data-команда (7 человек) не справляется с запросами от 500 сотрудников
• Каждый новый дашборд ждёт в очереди 2-3 недели
• Домены данных чётко определены: клиенты, заказы, продукты, финансы

Против Data Mesh:

• Governance maturity Level 1 — нет базовых стандартов и политик
• Ни один домен не имеет выделенного data-инженера
• Нет data platform (Self-Serve невозможен без инфраструктуры)
• 120 dbt-моделей без тестов и документации — ownership непонятен

Решение: DataTech не готова к Data Mesh. Первый шаг — centralized governance с чёткими naming conventions и data dictionary. Второй шаг (через 12-18 месяцев) — Domain Ownership для крупнейших доменов (клиенты, финансы). Третий шаг — Data Contracts между доменами.

Для сравнения: ФинСекьюр Банк

FinSecure (Level 3, 2000+ сотрудников) — более подходящий кандидат для Data Mesh. У них уже есть доменные Data Stewards, OpenMetadata (каталог), 12 data-инженеров. Проблема FinSecure — не масштаб, а legacy Oracle (800+ таблиц без документации). Data Mesh для FinSecure начнётся с микросервисных доменов (15 PostgreSQL баз), а не с Oracle.

Итоги

• Data Mesh — четыре принципа: Domain Ownership, Data as a Product, Self-Serve Platform, Federated Governance
• Data Contracts — формальные соглашения между producer и consumer: schema, SLA, breaking change policy
• Контракты версионируются по semver: major (breaking), minor (additive), patch (fix)
• Centralized подходит для < 200 сотрудников и Level 1-2 зрелости
• Data Mesh требует Level 3+ и доменные data-команды
• Hybrid — практический компромисс для большинства организаций
• DataTech: не готова к Mesh на Level 1, начать с centralized governance

В этом уроке мы рассмотрели Data Contracts как концепцию: структуру, SLA, semver-версионирование. В следующем уроке мы перейдём к Open Data Contract Standard (ODCS) — индустриальному стандарту, который формализует все эти концепции в единую machine-readable YAML спецификацию.