Data mesh: что это значит для руководителей, не для инженеров
Концепция data mesh набирает популярность. Разбираю, что за ней стоит и когда она имеет смысл для реального бизнеса.
В последний год в разговорах об архитектуре данных всё чаще звучит термин "data mesh". Консультанты рекомендуют его как следующий шаг после data lake. Конференции по данным посвящают ему отдельные треки. Компании начинают писать в вакансиях "опыт с data mesh приветствуется".
Мне важно разобраться, что за этим стоит на практике - не для того, чтобы следовать моде, а чтобы понять, когда это решает реальную проблему, а когда это просто переименование.
Какую проблему решает data mesh
Классическая схема устроена так: есть центральная команда данных, которая собирает данные из всех источников, обрабатывает их и предоставляет бизнес-подразделениям. Это работает при небольшом масштабе. При росте компании центральная команда становится узким местом: очередь запросов растёт, задачи от разных подразделений конкурируют за одних инженеров, понимание бизнес-контекста в центральной команде неизбежно хуже, чем у тех, кто работает с данными каждый день.
Data mesh предлагает другой принцип: данные принадлежат доменам. Команда продаж отвечает за данные о продажах. Команда логистики отвечает за данные о перемещениях. Каждая команда - не просто источник данных, а владелец продукта данных, который она предоставляет другим.
В чём суть на практике
Четыре принципа, которые составляют концепцию:
Доменное владение. Данные принадлежат той команде, которая лучше всего понимает их природу и значение. Не центральной команде данных.
Данные как продукт. Каждый домен предоставляет данные другим с явными стандартами качества, документацией и обязательствами по доступности - как внутренний продукт.
Самообслуживание инфраструктуры. Платформенная команда создаёт инструменты, которые позволяют доменным командам работать с данными без специализированной экспертизы каждый раз.
Федеративное управление. Общие стандарты - форматы, политики доступа, требования к качеству - формируются совместно, а не диктуются сверху.
Когда это имеет смысл
Ключевое слово - масштаб. Data mesh решает проблему узкого горлышка центральной команды. Если у вас нет центральной команды данных и нет очереди к ней - концепция решает несуществующую проблему.
Признаки, что data mesh может быть актуален:
- компания достаточно большая, чтобы данные из разных подразделений жили отдельно и требовали разной экспертизы;
- центральная команда данных перегружена и не успевает обслуживать все запросы;
- бизнес-подразделения жалуются, что данные, которые им нужны, недоступны или устарели;
- существующий data lake превратился в болото - данные есть, но никто не знает, каким доверять.
Для компании с одной командой аналитиков и парой источников данных это избыточное решение.
Что это значит для собственника
Внедрение data mesh - это не технический проект. Это организационное изменение. Оно требует, чтобы бизнес-подразделения взяли на себя ответственность за качество своих данных. Это конкретная работа конкретных людей - не разовая настройка.
Вопросы, которые стоит задать до того, как запускать такой проект:
- Готовы ли руководители бизнес-подразделений отвечать за качество данных своего домена?
- Есть ли у этих подразделений достаточно технической компетентности или её нужно строить?
- Кто будет поддерживать общую платформу и стандарты?
- Как мы будем измерять, что изменилось к лучшему?
Если ответов нет - сначала нужно ответить, потом решать, подходит ли концепция.
Data mesh - это хорошая идея для правильного контекста. Как и большинство хороших идей в архитектуре, она не универсальна.