Data Mesh

Data Mesh (дословно «сетка данных») это архитектурный и организационный подход к управлению корпоративными данными. Ответственность за аналитические данные здесь распределяется между бизнес-доменами, а не концентрируется в одной центральной команде. Термин ввела Zhamak Dehghani в 2019 году. С тех пор Data Mesh остаётся одним из самых обсуждаемых и одновременно самых неверно понятых понятий в мире данных. Главная путаница в том, что его регулярно принимают за технологию, хотя это в первую очередь способ распределить владение.

Что такое Data Mesh и какую проблему он решает

Классическая схема выглядит так. Одна платформенная команда данных обслуживает всю компанию: забирает данные из систем-источников, чистит их, складывает в хранилище и отдаёт аналитикам. Пока доменов пять, схема работает. Когда их становится пятьдесят, центральная команда превращается в узкое горлышко. Она не разбирается в бизнес-логике каждого источника, но обязана поддерживать пайплайны по всем.

Data Mesh переворачивает эту конструкцию. Домен, который порождает данные (платежи, маркетинг, риски, логистика), сам отвечает за их качество, документацию и доступность. Наружу домен выставляет не сырую таблицу и не выгрузку по заявке, а Data Product. Это оформленный набор данных с владельцем, описанной схемой, гарантиями по свежести и понятным способом подключиться. Центральная команда при этом не исчезает, а меняет роль. Вместо того чтобы делать пайплайны за всех, она строит платформу, на которой домены делают пайплайны сами.

Формально Data Mesh относят к классу децентрализованных архитектур аналитических данных. Но правильнее считать его социотехническим подходом: изменения в оргструктуре здесь весят не меньше, чем изменения в стеке.

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

Zhamak Dehghani  сформулировала четыре принципа, и они с 2019 года не поменялись. Убери любой из них, и конструкция рассыпается. Три принципа из четырёх дают либо хаос, либо тот же централизованный монолит под новой вывеской.

Domain-driven ownership

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

Data as a Product

Домен смотрит на свои данные как на продукт, а на соседние команды как на клиентов. У продукта есть владелец (data product owner), метрики использования и обратная связь. Ключевой критерий здесь придумала сама Dehghani: данные должны быть discoverable, addressable, trustworthy, self-describing, interoperable и secure. Проще говоря, потребитель должен найти набор данных, обратиться к нему по стабильному адресу, понять его без разговора с автором и доверять содержимому.

Self-serve data platform

Если каждый домен будет с нуля собирать себе инфраструктуру, компания получит двадцать несовместимых зоопарков. Поэтому платформенная команда даёт общий фундамент: хранилище, оркестрацию, каталог, мониторинг качества, шаблоны CI/CD. Задача платформы в том, чтобы выпуск нового data product занимал дни, а не кварталы, и не требовал от доменной команды глубокой инфраструктурной экспертизы.

Federated computational governance Data Mesh

Самый недооценённый принцип. Домены автономны, но не суверенны: есть общие правила по безопасности, приватности, форматам, именованию и версионированию схем. Слово computational здесь принципиально. Правила должны быть исполняемым кодом в пайплайне, а не PDF-регламентом на портале. Если проверка политики не падает автоматически в CI, политики фактически нет. Как устроен сам свод правил и роли вокруг него, подробно разбирает статья Data Governance.

Как устроен Data Product внутри

Data Product это не таблица. Это самостоятельная единица развёртывания. Внутрь упакованы сразу три вещи: сами данные, код их трансформации и метаданные с политиками. Такая упаковка и делает продукт переносимым и проверяемым.

Порт вывода (output port) это контракт доступа. Один и тот же продукт может отдаваться и таблицей в хранилище, и топиком Kafka, и REST-эндпоинтом, но схема и гарантии при этом одни. Именно порт делает возможным то, ради чего всё затевалось: соседний домен подключается к данным сам, не открывая тикет.

Роли и переход к доменному владению

Принципы описывают целевое состояние, но не говорят, кто конкретно делает работу. Ролей появляется три, и все три новые для компании.

• Data product owner. Отвечает за набор данных как за продукт: собирает требования потребителей, ведёт роадмап схемы, договаривается о гарантиях свежести. Это роль внутри домена, а не в центральной команде.
• Инженер данных в домене. Пишет трансформации и тесты качества рядом с бизнес-логикой. Обычно приходит переводом из центральной команды, реже нанимается заново.
• Платформенная команда. Бывшая центральная команда данных. Строит инструменты самообслуживания и перестаёт делать пайплайны руками за чужие домены.

Отдельно собирается governance-группа из представителей доменов. Она договаривается об общих определениях и превращает их в проверки. Переход при этом идёт не разом. Разумный порядок такой: взять два-три зрелых домена, довести их до полноценных data product, отладить на них платформу и правила, и только потом расширять периметр. Типичная ошибка выглядит иначе. Существующие команды просто переименовывают в домены, ответственность за качество и документацию остаётся у центра, и всё сводится к новой строке в презентации.

Чем Data Mesh отличается от Data Fabric и Lakehouse

Эти три термина постоянно ставят в один ряд, хотя они отвечают на разные вопросы. Data Mesh отвечает на вопрос «кто отвечает за данные». Data Fabric на вопрос «как автоматически связать разрозненные источники». Lakehouse на вопрос «где физически лежат данные». Подробный разбор первой пары есть в статье блога Data Fabric и Data Mesh: versus или вместе?, а устройство третьего разобрано в отдельной статье LakeHouse. Здесь ограничимся сводной таблицей.

Противопоставление здесь искусственное. На практике зрелые компании берут Lakehouse как физический фундамент, Data Mesh как модель владения поверх него, а инструменты Data Fabric подключают для каталогизации и федеративного доступа.

Где Data Mesh не взлетает

Раздел, которого обычно нет в маркетинговых материалах. Между тем большинство неудачных внедрений спотыкаются об одни и те же вещи.

• Дефицит инженеров в доменах. Принцип «домен владеет данными» подразумевает, что в домене есть кому этим заниматься. Если в команде маркетинга нет ни одного дата-инженера, владение существует только на бумаге, а работу по-прежнему делает центр.
• Дублирование логики. Автономные домены независимо считают одни и те же метрики и получают разные цифры. Без общих определений в governance компания приходит к трём версиям выручки вместо одной.
• Governance по остаточному принципу. Первые три принципа внедряют охотно, четвёртый откладывают на потом. Через год получается не сетка, а набор изолированных силосов с разными схемами именования.
• Ожидания по срокам. Полная перестройка занимает от полутора до трёх лет: это переучивание людей и смена оргструктуры, а не установка продукта. Компании, рассчитывавшие на квартал, обычно бросают на середине.
• Периметр безопасности. Децентрализация размывает контроль доступа: точек, где данные покидают домен, становится в разы больше. Тема отдельно разобрана в материале Безопасность архитектуры данных: проблемы Data Mesh и их решения.

Общий вывод простой. Сложность никуда не девается, она переезжает из центральной команды в координацию между доменами. Data Mesh выигрывает тогда, когда стоимость этой координации ниже стоимости прежнего узкого горлышка.

Когда применять, а когда не стоит

Data Mesh имеет смысл в крупной организации с несколькими зрелыми независимыми доменами. Условий два: центральная команда объективно перегружена, а бизнес готов выделить людей на владение данными внутри доменов. Хороший сигнал готовности виден по бэклогу. Задачи платформенной команды ждут месяцами, и половина из них требует знания предметной области.

Не стоит браться, если компания небольшая и доменов по сути два, если нет платформы самообслуживания и её не планируют строить, или если руководство воспринимает затею как чисто техническую миграцию. В этих случаях централизованный Lakehouse с нормальным каталогом даст больше пользы за меньшие деньги. Продуманно спроектировать такой фундамент помогает курс по архитектуре данных и проектированию DWH.

Контракт данных как код

Federated computational governance держится на data contract. Это машиночитаемое описание продукта, которое лежит рядом с кодом и проверяется в CI. Ниже пример по спецификации Open Data Contract Standard, показывающий структуру такого файла.

# синтаксис по спецификации Open Data Contract Standard v3.0.0
apiVersion: v3.0.0
kind: DataContract
id: payments-transactions-v1
name: Транзакции платежей
# домен-владелец и ответственная команда
domain: payments
status: active
# описание схемы: потребитель читает её без разговора с автором
schema:
  - name: transactions
    physicalType: table
    properties:
      - name: transaction_id
        logicalType: string
        required: true
        primaryKey: true
      - name: amount
        logicalType: number
        required: true
      - name: created_at
        logicalType: date
        required: true
# гарантии по свежести и качеству, проверяются автоматически
slaProperties:
  - property: frequency
    value: 1
    unit: h
  - property: retention
    value: 24
    unit: m
# владелец продукта и канал поддержки
support:
  - channel: payments-data
    tool: slack

Ценность здесь не в конкретном YAML, а в том, что описание живёт в репозитории вместе с трансформациями. Попытка выкатить изменение схемы, ломающее контракт, падает на пайплайне до того, как о ней узнают потребители.

Заключение

Data Mesh это не продукт, который можно купить, и не слой в схеме архитектуры. Это решение о том, кто отвечает за данные, подкреплённое платформой и исполняемыми правилами. Работает он там, где организационное узкое горлышко реально болит и где домены готовы взять данные под свою ответственность. Там, где такой готовности нет, четыре принципа превращаются в четыре красивых слайда, а данные остаются ровно там же, где были.

Референсные ссылки

• Zhamak Dehghani. Data Mesh Principles and Logical Architecture
• Data Mesh Architecture. Практическое руководство по принципам и стеку
• Open Data Contract Standard. Спецификация контрактов данных
• Thoughtworks. Материалы по стратегии данных и Data Mesh
• IBM. What Is a Data Mesh