Кто объяснит сведения о доставках и кто отвечает за их качество? На условном примере разбираем домены, продукты данных, общую платформу и совместные правила.
Одна очередь на все вопросы
Представим условную торговую компанию. Продажи, склад и доставка отправляют запросы одной небольшой команде аналитической платформы. Специалистам нужно не только подготовить данные, но и выяснить, что означает каждый статус. Почему заказ считается завершённым до вручения? Какая дата относится к возврату? Техническая очередь превращается ещё и в очередь за объяснениями.
Data Mesh — подход к организации работы с аналитическими данными, в котором ответственность распределяют по направлениям бизнеса. Вопрос здесь шире выбора базы: кто выпускает полезные другим сведения, кто объясняет их смысл и как разные части компании договариваются между собой. Это организационная и техническая задача одновременно.
Домен знает свою предметную область
Домен — область деятельности со своими понятиями и ответственностью, например доставка. В исходном изложении Жамак Дехгани доменное владение — один из четырёх принципов Data Mesh. За аналитические данные отвечает команда, близкая к соответствующей работе, а не только удалённый технический посредник.
В нашем примере команда доставки может объяснить, чем попытка вручения отличается от успешного получения. Но знать процесс недостаточно: нужно ещё выпускать сведения так, чтобы ими могли пользоваться другие. Поэтому назначение владельца не сводится к фамилии в справочнике. Важны реальные возможности поддерживать обещанный результат и отвечать на изменения.
Продукт данных нужен конкретному потребителю
Продуктом данных можно назвать подготовленный набор сведений вместе с условиями использования и сопровождением. Open Data Mesh описывает его через понятного владельца, границы, жизненный цикл и интерфейсы доступа. Пользователю требуется не просто файл: он должен понимать, что получает и чего ожидать.
Предложим учебный продукт «Завершённые доставки за день». Финансовому отделу нужны дата вручения, связь с заказом и понятное правило исправлений. Команда доставки договаривается, когда сведения готовы и куда сообщать о расхождении. Обещание «здесь все наши таблицы» слишком расплывчато: оно не отвечает на конкретную задачу потребителя.
Автономия опирается на общую платформу
Другие принципы Data Mesh в исходной статье — данные как продукт, инфраструктура самостоятельного использования и совместное управление общими правилами. Платформа должна убирать повторяющуюся техническую работу. Это не требование каждому отделу заново создавать собственное хранилище, обслуживание и способы безопасного доступа.
Для условной компании можно представить общие средства публикации и наблюдения за качеством. Доставка выпускает свой продукт, склад — свой, а техническая основа помогает им использовать единый путь. При таком обсуждении полезно различать ответственность за смысл сведений и ответственность за работу общей инфраструктуры. Перенос первой не отменяет вторую.
Что остаётся общим между направлениями
Если доставка и продажи по-разному понимают номер заказа, их продукты не получится надёжно сопоставить. Поэтому самостоятельность требует договорённостей на границах: как связывать записи, обозначать время, описывать изменения и предоставлять доступ. Общие правила нужны там, где сведения пересекают границы команд.
В учебном разборе предложим начать с одного обмена. Склад сообщает о передаче отправления, доставка — о вручении, аналитик сопоставляет события. Если значения не сходятся, стороны проверяют описание и конкретные записи. Потребителю не должно требоваться угадывать смысл по названию папки. Тип хранения при этом остаётся отдельным решением: озеро и хранилище описывают другой уровень системы.
Когда стоит обсуждать такой подход
Data Mesh не обещает автоматически ускорить каждую компанию. Если у направления нет людей и времени на сопровождение, смена названий не создаст ответственность. Предлагаемый первый вопрос: какие потребители уже зависят от наших сведений и какие затруднения повторяются? Затем можно проверить одну понятную границу вместо объявления масштабной реорганизации.
Об устройстве всей системы и согласовании технических решений рассказываем в материале о роли архитектора данных. Освоить основы проектирования помогает программа «Архитектор данных». Полезная учебная задача — описать один продукт: его потребителя, владельца, содержание, способ получения и порядок разбора ошибки. Так обсуждение получает конкретный предмет.
