Data mesh - это организационный паттерн, а не технологический выбор
Data mesh обсуждают, как будто это инструмент для покупки или платформа для развёртывания. Это не так. Понимание того, чем он является на самом деле, меняет оценку того, подходит ли он вашей ситуации.
Data mesh уже несколько лет остаётся устойчивой темой в разговорах об инжиниринге данных. Обсуждение часто заходит в тупик, потому что люди подходят к нему как к технологическому решению - какого вендора выбрать, какую платформу развернуть. Этот фрейм почти полностью упускает суть.
Data mesh - это в первую очередь ответ на конкретный организационный сбой. Если этот сбой в вашей компании отсутствует, data mesh не является ответом на вашу проблему - независимо от того, насколько убедительно выглядят схемы.
Сбой, который решает data mesh
Классический паттерн, для ответа на который был создан data mesh, выглядит так: центральная команда данных владеет всеми пайплайнами, всеми моделями данных, всем контролем качества. Бизнес-команды зависят от центральной команды для любой новой возможности с данными. Центральная команда становится узким местом. Бэклоги растут. Доверие падает. Бизнес-команды начинают строить теневые пайплайны в Excel и BI-инструментах. Центральная команда тратит большую часть времени на поддержку, а не на новую ценность.
Если вы узнаёте это описание, вы сталкиваетесь с проблемой узкого места. Data mesh - один из архитектурных ответов на неё.
Что data mesh предлагает на самом деле
Основная идея - владение доменом: команды, которые производят данные, несут ответственность и за то, чтобы предоставлять их другим командам как продукт. Команда управления заказами владеет данными домена заказов, поддерживает их качество и публикует в форме, которую другие команды могут надёжно потреблять.
Это основывается на четырёх принципах Жамак Дехгани: доменное владение данными, данные как продукт, инфраструктура самообслуживания и федеративное вычислительное управление. Первые два - о том, кто чем владеет. Третий - о том, как сделать владение устойчивым без превращения каждой доменной команды в команду инженеров данных. Четвёртый - о том, как поддерживать согласованность при децентрализованном владении.
Где организации попадают в ловушку
Самый частый сбой, который я вижу, - переход к вопросу инфраструктуры до решения вопроса владения. Компании тратят месяцы на оценку вендоров платформ, которые пишут «готово к data mesh» в маркетинговых материалах. Но ни одна платформа не делает компанию способной к распределённому владению данными. Эта способность - организационный и культурный сдвиг. Технология вторична.
Второй частый сбой - применение логики data mesh к организации, у которой нет того сбоя, который он решает. Если у вас один продукт, небольшая команда данных и никакой серьёзной проблемы с узким местом, введение распределённого владения добавляет координационные издержки без соответствующей выгоды.
Полезный тест
Прежде чем формулировать любую дискуссию о данных как «стоит ли нам делать data mesh?», я нахожу более полезным спросить: кто сейчас владеет каждым доменом данных, и несёт ли он ответственность за качество? Если ответ «командой данных владеет всем, и больше никто не чувствует себя ответственным» - это и есть реальная проблема. Назовёте ли вы решение «data mesh» или как-то иначе - вторично.
Практическая работа - это определение границ владения, установление контрактов на продукты данных и построение инфраструктуры, которая позволяет доменным командам выполнять эти контракты. Эта работа тяжёлая и долгая. Ни один вендорский ярлык не обходит её.