🤩 Data Warehouse, Lake, Lakehouse, Fabric, Mesh — в чём разница? Если вы работаете с данными, эти слова наверняка уже мелькали в вакансиях, презентациях и созвонах А если копнуть глубже, начинается путаница: где что лежит, чем одно отличается от другого и нужно ли это вообще внедрять...

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

— первые три — про то, где и как хранить данные — последние две — про то, как их связывать и кто за них отвечает

Data Warehouse — классика

Сюда попадают уже очищенные и структурированные данные. Таблицы, схемы, порядок. Всё заточено под отчёты и BI Нужен понятный дашборд по продажам — DWH обычно отлично справляется. А вот сырые логи, тексты и видео «на всякий случай» — уже дорого и неудобно

Data Lake — другой подход

Сюда данные кладут почти как есть: логи, аудио, выгрузки, всё подряд. Хранение дешёвое, гибкость большая. Для DS и ML — удобная площадка Но без правил и владельцев озеро быстро превращается в болото: всё лежит, а можно ли этому доверять — уже отдельный разговор

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

Data Lakehouse как раз про попытку это починить: взять гибкое хранение озера и добавить сверху то, за что любят DWH — транзакции, схемы, SQL, отчёты. Часто через Delta Lake или Iceberg

На одних данных можно и BI крутить, и модели обучать. Но Lakehouse отвечает только на вопрос «где и как хранить». Он не решает, как подружить кучу систем и кто за какие данные отвечает

Data Fabric — это уже не хранилище, а слой поверх существующих систем

В реальной жизни данные почти никогда не живут в одном месте. Они в CRM, ERP, облаках, SaaS и иногда в Excel у человека, которого все боятся потревожить

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

Data Mesh — совсем другая история

Это уже не столько про технологию, сколько про устройство работы с данными Классика: одна центральная data-команда обслуживает весь бизнес. Пока компания небольшая — работает. Потом запросов становится слишком много, бизнес встаёт в очередь, инженеры не вывозят

Data Mesh предлагает другой взгляд: пусть каждый домен сам владеет своими данными и отвечает за них как за продукт — с документацией, качеством и понятными потребителями

Центральная команда никуда не исчезает — она становится платформой и задаёт стандарты. Но больше не тащит всё на себе

Звучит красиво. На практике сложно: нужна зрелая культура, сильные доменные команды и готовность менять процессы

Как не потеряться?

Проще смотреть не на модные названия, а на то, где болит:

— данные дублируются, цифры расходятся → Lakehouse — данные размазаны по куче систем → Data Fabric

И да, они не мешают друг другу. Можно держать Lakehouse как основу, сверху — Fabric, а по мере роста отдавать доменам владение данными

В итоге: DWH — чистые данные для отчётов Lake — сырые данные для экспериментов и ML Lakehouse — попытка совместить плюсы обоих Fabric — как связать то, что размазано по системам Mesh — кто за какие данные отвечает

🎵 Ни одна из этих концепций сама по себе всё не решит. Это просто разные ответы на разные вопросы Поддержи пост сердечком 🥺