Если вы работаете с данными, то за последние пару лет точно слышали эти слова: Data Mesh, Data Fabric, Data Lakehouse. Их можно увидеть в заголовках конференций, вендорскиех презентациях и вакансиях для дата-архитекторов, но если копнуть глубже, начинается путаница.

Почему вообще возникает путаница?
Еще лет 10 назад все было просто, был Data Warehouse (хранилище данных) как единый источник правды для отчетов и BI, был Data Lake (озеро данных) – место хранения для любых данных в сыром виде, чтобы была возможность экспериментировать с данными.

Но потом случилось три вещи:

• Данных стало слишком много и они стали слишком разными (теперь не только таблички, но и логи, картинки, сенсорные потоки).

• Бизнес перестал ждать, сейчас отчеты за прошлый месяц уже никому не нужны, все данные нужно смотреть здесь и сейчас, процессы стали гораздо быстрее меняться, за всем нужно следить.

• Облака породили зоопарк инструментов, теперь данные живут в AWS, Azure, on-premise, в SaaS-сервисах – и все это надо как-то соединять.

Data Lakehouse

Долгое время у компаний была «двухголовая» архитектура: данные копировались в Data Lake для гибкости и отдельно в Data Warehouse для производительности, но это приводило к дублированию данных, рассогласованности и лишним расходам на ETL-процессы - то есть при росте количества данных возникали проблемы.

Что предлагает Lakehouse?

Lakehouse – это попытка объединить лучшее из двух миров: хранилище как в Data Lake и возможности как в Data Warehouse.
Берем хранилище как в Data Lake: дешевое объектное хранилище (S3, ADLS), открытые форматы (Parquet, ORC).
Берем возможности как в Data Warehouse: ACID-транзакции, управление схемой, оптимизация запросов.

Технически это реализуется через специальные слои поверх озер – транзакционные форматывроде Delta Lake, Apache Iceberg или Apache Hudi.

Кому это нужно?

Компаниям, которые устали таскать данные туда-сюда, тех, кому нужно на одних и тех же данных крутить и BI-отчеты и ML-модели, а также проектам, где важна единая версия правды и без дублирования.

В чем проблема?

• Lakehouse не решает проблемы интеграции данных из разных источников и не меняет организационную структуру.

• Инструменты вокруг Iceberg/Delta зреют, но местами «сыроваты».

• Ваши инженеры не обязаны уметь делать что-то в Spark и открытые форматы.

Так, Lakehouse – это про технологическую конвергенцию, это все же эволюция, а не революция.

Data Fabric

Ваши данные живут везде: в облаках, в старых on-premise системах, в CRM, в ERP, в Excel-файлах у кладовщика и чтобы получить целостную картину, приходится строить сложные пайплайны, копировать данные туда-сюда и только после этого мучительно сводить метрики.

Что предлагает Data Fabric?

Data Fabric – это интеллектуальный интеграционный слой поверх всех ваших источников:

• Ему не нужно двигать данные, fabric работает через виртуализацию, запрос идет к данным там, где они лежат.

• Он управляется метаданными, система сама знает, где какая таблица лежит, кто к чему имеет доступ, как связаны сущности внутри нее.

• Он использует AI, активные метаданные помогают автоматически находить связи и оптимизировать запросы внутри системы.

Кому это нужно?

Крупным компаниям с гибридной или multi-cloud инфраструктурой, тем, кто не может перенести все данные в одно место (регуляторика, legacy). Также полезно будет тем сценариям, где нужны реалтайм-данные из разных источников сводить без копирования и дубликации.

В чем проблема?

• если есть бардак с каталогом и качеством данных, Fabric этот бардак только усугубит.

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

• построить по-настоящему умный Fabric не просто, не быстро и не дешево.

Так, Data Fabric – это про интеграцию и унификацию доступа, когда нельзя (или слишком дорого) все свозить в одну кучу.

Data Mesh: когда централизация ломается об организацию

Классическая архитектура подразумевает центральную команду данных, которая обслуживает весь бизнес, но пока ваша компания маленькая – это работает, а когда бизнес-юнитов становится уже очень много, центральная команда становится бутылочным горлышком:
- Чтобы получить новую витрину, нужно вставать в очередь к дата-инженерам;
- Команда данных не знает и не может знать бизнес-контекст так же хорошо, как сами участники этого процесса.

Что предлагает Data Mesh?

Data Mesh – это в первую очередь организационная, а не техническая парадигма и она включает в себя:

• Владение данными по доменам, чтобы каждый бизнес-домен (маркетинг, продажи, производство) сам отвечал за свои данные.

• У каждого датасета есть владелец, документация, SLA, к ним относятся как к продукту для внутренних потребителей.

• Центральная платформенная команда дает доменам инструкции и поддержку чтобы они могли сами готовить свои данные.

• Единые стандарты (безопасность, метаданные) согласуются централизованно, но применяются гибко юнитами внутри.

Кому это нужно?

Это нужно крупным корпорациям (1000+ сотрудников) с автономными бизнес-юнитами или компаниям поменьше, но, где центральная команда данных уже не справляется с потоком запросов.

В чем проблема?

• Это ОЧЕНЬ сложно, Data Mesh требует зрелой культуры данных и сильных доменных команд.

• Перестройка на такой формат может занять 6–18 месяцев и более, это очень долгий и трудоемкий процесс.

• Есть риск хаоса при переходе, так как изменения глобальные.

• Не продается "из коробки", нет возможности просто взять и купить Data Mesh, это подход, а не технология и для него нужна сильная команда специалистов внутри компании.

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

Сводная таблица со сравнением

Как не запутаться и выбрать свое

1. Исходите из своих проблем и болей:
   - Данные дублируются, дорого хранить, тяжело считать -> cмотрите в сторону Lakehouse.
   - Данные размазаны по 100500 системам, и вы не можете сделать сводный отчет -> мотрите в сторону Data Fabric.
   - Центральная команда данных задыхается от запросов, бизнес недоволен скоростью -> Смотрите в сторону Data Mesh.

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

Резюме для тех, кто дочитал

Мир данных окончательно усложнился и в 2026 году уже недостаточно знать только SQL и уметь собирать дашборды, уже нужно понимать архитектурные парадигмы. Запомните главное:
Lakehouse – это про то, где и как хранить.
Fabric – про то, как связать то, что уже есть.
Mesh – про то, кто за что отвечает.

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

?Больше про полезные навыки и задачи аналитика данных в моем тг канале ?Таня и Данные?