Data Mesh vs централизованная Data Platform¶

Сравнения · Data Mesh / Data Fabric

Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.

INFERENCE: сравнивается ownership data products. Централизованные инфраструктурные capabilities нужны и в Mesh. Centralized ownership не обязательно означает один технический монолит. Сценарии и схема — HYPOTHETICAL.

Матрица выбора¶

Критерий	Central product/pipeline ownership	Mesh domain ownership
Domain semantics	Центральная команда собирает знания	Domain teams отвечают за смысл
Delivery новых products	Общая очередь команды	Автономные lifecycles при общих правилах
People	Меньше platform/domain roles	Нужны engineering capabilities у доменов
Governance	Проще унифицировать в небольшой организации	Federated policies и enforcement
Platform	Общие tools плюс возможное ownership всех pipelines	Self-service как обязательная capability
Cross-domain metrics	Центральный owner обычно очевиднее	Нужно специально назначать consumer-product owner
Главный риск	Backlog и разрыв с domain knowledge	Несовместимые contracts и бесхозные общие задачи
Хороший fit	Небольшое число тесно связанных доменов	Много автономных зрелых teams и высокий change rate

Mesh оправдан не просто большим объёмом данных. Он отвечает на рост разнообразия и ответственности. Если домены не могут поддерживать pipelines, передача ownership без ресурсов ухудшит надёжность.

Конкретные сценарии¶

Небольшой FinTech: один payments core и несколько аналитиков. Central team с ясным owner, review и хорошим catalog может обеспечить меньше operational risk. Доменные эксперты участвуют в definitions.

Банк с автономными payments/risk/lending teams: Mesh может сократить semantic handoffs, если общая платформа делает ingestion/access/quality доступными self-service. Regulatory report при этом имеет одного ответственного за итоговый product и согласование cutoffs.

iGaming group с несколькими брендами: domain products по wallet/betting/player safety полезны при shared identity и договорённостях по corrections. Формальное разделение брендов без interoperability создаёт новые silos.

Hub-and-spoke позволяет централизовать infrastructure/security и постепенно передавать ownership конкретных data products. Это допустимая эволюция, а не обязательный «недо-Mesh».

Shared platform остаётся¶

flowchart TB
    P["Общая platform и enforcement"] --> C["Central team владеет products"]
    P --> D["Domain teams владеют products"]
    C --> U["Consumers"]
    D --> U
    G["Governance, identities и contracts"] -. "Общие требования" .-> C
    G -. "Общие требования" .-> D

Стрелки показывают две организационные модели поверх capabilities. Разделение ownership не задаёт Kafka, warehouse или lakehouse; разные технические варианты должны соблюдать общий contract.

Ограничения и evidence¶

FACT: Adyen прямо связывает Data Mesh adoption с ownership pipelines/tables у teams и общей Airflow-платформой. Adyen, 2021-05-19. Это конкретный organizational example, а не доказательство, что выбор Airflow автоматически создаёт Mesh.

FACT: Dehghani определяет domain ownership, data as product, self-serve platform и federated governance. Principles, 2020. INFERENCE: оценивать следует все эти capabilities, а не наличие catalog.

Ownership не гарантирует global consistency. Cross-domain joins должны фиксировать версии/время; policy metadata требует enforcement в настоящих access paths. Data Fabric products могут помогать обеим моделям и не определяют, кто отвечает за quality.

Типичные ошибки проектирования¶

Выдать каждой команде bucket без on-call; считать shared platform централизацией, запрещённой Mesh; потерять владельца итоговой метрики; внедрять federation там, где команда ещё не может обслужить базовый pipeline.

Вопросы на собеседовании¶

Что централизовать в Mesh? Повторяемые capabilities и machine-enforced interoperability/security controls; конкретные business products имеют domain owners.

Как понять, что пора decentralize? Когда bottleneck именно в semantic ownership и независимой эволюции, а домены способны взять ответственность. Один растущий Kafka cluster этого не доказывает.

Практические упражнения¶

Распределите RACI для source quality incident, catalog outage, policy violation и ошибочного cross-domain отчёта. Сравните central и Mesh варианты. Критерий: у каждого incident есть owner, budget и recovery responsibility.

Дополнительные источники¶

Mesh principles; Data Fabric terminology; общая карта уровней.