Data mesh или центральное хранилище: как выбирать без идеологических споров

За последние два года data mesh прошёл обычный путь: сначала евангелизм, потом маятниковый откат, потом попытки найти, где это реально работает. В разговорах с руководителями я вижу одну и ту же картину - команда прочитала про data mesh, загорелась, и теперь хочет убедить бизнес в переходе. Или наоборот - команда слышала про data mesh, но не разобралась, и предлагает по умолчанию строить "ещё одно хранилище".

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

Что на самом деле решает каждый подход

Централизованное хранилище данных решает одну проблему очень хорошо: у организации есть единое место, где данные из разных источников собраны, приведены к общему виду и доступны для аналитики. Это работает хорошо, когда команда данных небольшая, источников не слишком много, и ответственность за данные можно сосредоточить в одном месте.

Data mesh решает другую проблему: что делать, когда данных много, источников много, команд много - и центральная команда стала узким местом, которое не успевает обрабатывать все запросы, а качество данных страдает потому, что никто рядом с источником не несёт за него ответственности.

Это не конкурирующие технологии. Это разные организационные паттерны, которые решают разные проблемы.

Признаки, что централизованное хранилище подходит

Несколько характеристик, которые говорят в пользу централизованного подхода:

• У компании одна или две ключевых аналитических задачи, а не десятки.
• Данных несколько десятков таблиц из трёх-пяти систем-источников.
• Нет выделенных команд с данными внутри бизнес-единиц - есть одна общая команда аналитики.
• Скорость ответа на аналитический запрос важнее, чем гибкость.
• Размер компании: до 500-1000 человек.

В этом случае data mesh - это архитектурная сложность без архитектурной выгоды.

Признаки, что пора думать о децентрализации

Ситуации, где централизованная модель начинает трещать:

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

Это признаки, что организационная структура переросла централизованную модель. Data mesh здесь - это не техническое решение, а организационное.

Что часто путают

Самая распространённая ошибка - воспринимать data mesh как набор инструментов. Никакой инструмент не делает данные децентрализованными. Data mesh - это про то, кто владеет данными и кто несёт ответственность за их качество. Это решение про людей и процессы, а не про платформу.

Второй частый источник путаницы: "мы хотим data mesh, потому что это современно". Если реальной проблемы узкого места нет - переход создаст сложность без пользы.

Вопросы для принятия решения

Прежде чем выбирать архитектуру, стоит честно ответить на несколько вопросов:

1. В чём конкретно сейчас болит работа с данными - это медленность, неточность, недоступность, или что-то ещё?
2. Сколько команд работает с данными независимо и насколько их задачи пересекаются?
3. Есть ли внутри бизнес-единиц люди, которые могут и хотят владеть данными своей области?
4. Что будет сложнее - организовать централизованную команду или договориться о стандартах между децентрализованными командами?
5. Если через два года число источников данных удвоится - какая модель справится лучше?

Ответы на эти вопросы обычно указывают в конкретном направлении - без необходимости читать ещё одну статью про data mesh.