Если вы работаете с данными, то за последние пару лет точно слышали эти слова: 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 – это про масштабирование организации данных, а не про замену технологий, это ответ на вопрос как нам выжить, когда нас станет слишком много.
Сводная таблица со сравнением
Как не запутаться и выбрать свое
Исходите из своих проблем и болей:
- Данные дублируются, дорого хранить, тяжело считать -> cмотрите в сторону Lakehouse.
- Данные размазаны по 100500 системам, и вы не можете сделать сводный отчет -> мотрите в сторону Data Fabric.
- Центральная команда данных задыхается от запросов, бизнес недоволен скоростью -> Смотрите в сторону Data Mesh.Поймите, что они не исключают друг друга. Можно построить Lakehouse как базовое хранилище, сверху накинуть Data Fabric, чтобы отдавать данные из этого Lakehouse и других систем, а по мере роста внедрять Data Mesh-принципы, где домены сами становятся поставщиками данных через ту самую Fabric-платформу .
Резюме для тех, кто дочитал
Мир данных окончательно усложнился и в 2026 году уже недостаточно знать только SQL и уметь собирать дашборды, уже нужно понимать архитектурные парадигмы. Запомните главное:
Lakehouse – это про то, где и как хранить.
Fabric – про то, как связать то, что уже есть.
Mesh – про то, кто за что отвечает.
Ни одна из этих концепций не является серебряной пулей, они лишь инструменты в арсенале архитектора данных, и уже ваша задача здесь не гнаться за хайпом и модными концепциями, а выбрать тот набор инструментов, который подходит в вашей ситуации и лечит боль именно вашей компании.
💚Больше про полезные навыки и задачи аналитика данных в моем тг канале 🌸Таня и Данные📊
