Data Mesh и Data Fabric: где проходит граница между владением данными и доступом к ним

9 сентября 2026 г.

Евгений Левашов

Автор статьи

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

Data Mesh и Data Fabric часто упоминают вместе, но это разные подходы. Data Mesh распределяет владение данными и ответственность за их качество между доменами. Data Fabric объединяет разрозненные источники в единый слой доступа. Федеративный SQL-движок позволяет работать с несколькими системами одним запросом, не собирая данные в отдельном хранилище.

Разберём различия между Data Mesh и Data Fabric, устройство федеративных запросов и задачи, для которых всё ещё нужны ETL и витрины.

Статья подготовлена совместно с экспертом

Павел Савченко, архитектор предпродажных решений

Проблема централизованных данных

В централизованной модели все источники сводят в одно хранилище, а за качество данных отвечает дата-офис. Пока источников немного, эта схема работает стабильно и не требует больших затрат.

Проблемы начинаются вместе с ростом числа источников и запросов. Например, в S7 Airlines до перехода на self-service отчёты готовились долго: данные приходилось переносить между системами, а разбор ошибок в ETL занимал больше времени, чем разработка.

Каждый новый вопрос бизнеса превращается в отдельный отчёт и новую заявку в очередь.

У такого подхода три последствия.

Копии начинают расходиться. Данные попадают из источника в хранилище, затем в витрину и BI. У каждой копии свой график обновления, поэтому через несколько месяцев два отчёта об одном показателе могут показывать разные значения.
Найм не сокращает очередь. Команда растёт, но вместе с ней увеличиваются количество источников, наборы данных и число вопросов от бизнеса.
Падает доверие к цифрам. Пользователи не доверяют данным, к которым у них нет доступа. В S7 Airlines доверие выросло после того, как команды получили возможность самостоятельно загружать и анализировать данные.

Отсюда два подхода. Первый меняет распределение ответственности между доменами — это Data Mesh. Второй строит слой, который даёт единый доступ к разрозненным источникам, — это Data Fabric. Оба направления лучше закладывать в общий план.

Что такое Data Mesh

Data Mesh — это социотехнический подход к работе с данными. Он сочетает децентрализованное владение по доменам и техническую архитектуру.

Концепцию предложила Zhamak Dehghani из Thoughtworks. Первые материалы о Data Mesh появились в 2019 году, а набор принципов был сформулирован в документе «Data Mesh Principles and Logical Architecture» в 2020 году.

Data Mesh нельзя купить и включить настройкой в платформе — он требует изменить процессы внутри команды.

Доменное владение и данные как продукт

В основе Data Mesh четыре принципа:

Domain-oriented decentralized data ownership and architecture — доменное децентрализованное владение данными. За датасет отвечает команда, которая ближе всего к источнику и предметной области.
Data as a product — данные рассматриваются как продукт. У датасета есть владелец, SLA, документация, версии и понятные потребители.
Self-serve data infrastructure as a platform — доменные команды получают инструменты и платформу, а не отправляют каждую задачу в дата-офис.
Federated computational governance — правила вырабатываются совместно, а платформа проверяет их автоматически.

Последний принцип часто сокращают до «федеративного governance», хотя важна именно вычислительная часть. Если правило существует только в регламенте, его можно не соблюдать. В Data Mesh требования к схемам, качеству, доступам и контрактам должны проверяться системами.

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

Что такое Data Fabric

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

В основе Data Fabric лежат активные метаданные. Пассивные метаданные организация собирает и хранит в каталоге. Активные метаданные читаются и обновляются постоянно, помогая автоматизировать управление данными.

Платформа сопоставляет описание данных с тем, как они используются на практике. На этой основе формируется knowledge graph: какие наборы данных существуют, кто ими пользуется, как часто они запрашиваются, для каких задач и в каких системах находятся.

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

Без покрытия метаданными Data Fabric не работает. Если каталог неполный, источники не описаны, а зависимости не собираются, единый слой доступа быстро превращается в ещё один набор ручных процессов.

Чем отличаются Data Mesh и Data Fabric

Ось сравнения	Data Mesh	Data Fabric
Природа	Социотехнический подход: организационная модель и архитектура	Технологический слой интеграции и метаданных
Кто ввёл	Zhamak Dehghani, Thoughtworks	Forrester, Noel Yuhanna
Единица работы	Data product, принадлежащий домену	Активные метаданные и автоматизированная интеграция
Governance	Федеративное: правила исполняет платформа	Централизованное и автоматизированное поверх источников
Что меняется	Ответственность людей и команд	Путь данных к потребителю
Основной риск	Организационная незрелость и отсутствие операционного процесса	Неполные или некачественные метаданные
Как внедряют	Постепенно, через изменение процессов	Через инструменты, каталог и интеграционный слой

Архитектурную схему Data Mesh можно продумать, но без регулярной работы с каталогом она быстро перестаёт быть полезной. Data products устаревают, владельцы меняются, описания не обновляются, и нужный набор данных снова приходится искать через личные сообщения.

Типовые проблемы выглядят так:

Домены публикуют data products, но потребители не могут их найти.
Правила governance существуют в документах, но не проверяются в системах.
Команды расходятся в соглашениях об именовании, схемах и требованиях к качеству.
Документация устаревает, а пороги качества постепенно снижаются под давлением сроков.
Нет операционного слоя метаданных, который связывает владельцев, правила, каталоги и потребителей.

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

Противопоставлять эти подходы не нужно. Домены могут отвечать за свои data products, а платформа — помогать находить их, проверять качество и управлять доступом.

Что не относится к этому сравнению

Data Mesh и Data Fabric иногда ставят в один ряд с Lambda architecture и Kappa architecture, хотя они описывают другой уровень архитектуры.

Lambda architecture строит две ветки обработки: батчевую и потоковую. Kappa architecture оставляет одну потоковую ветку и пересчитывает историю тем же кодом.

Lambda и Kappa отвечают на вопрос, как обрабатывать данные. Data Mesh и Data Fabric отвечают на вопросы, кто ими владеет и как получить к ним доступ. В современной архитектуре данных эти подходы комбинируются.

Роль федеративного движка

Data Mesh и Data Fabric упираются в один технический вопрос: как дать пользователю доступ к данным из десяти систем, не копируя их в одиннадцатую.

Для этого используют федеративный SQL-движок.

Trino как точка федеративного доступа

Trino, ранее известный как PrestoSQL, — открытый распределённый SQL-движок с MPP-архитектурой. Он подключается к источникам через коннекторы: объектным хранилищам с Iceberg, PostgreSQL, MySQL, Cassandra, Kafka, MongoDB и Elasticsearch.

Данные остаются в исходных системах. Compute отделён от storage, а сам движок не хранит данные.

Запрос проходит так:

Основной механизм оптимизации — pushdown. Движок передаёт часть работы источнику, чтобы не забирать лишние данные по сети.

Trino поддерживает:

projection pushdown — чтение только нужных колонок;
dereference pushdown — чтение отдельных полей внутри ROW;
aggregation pushdown — выполнение части агрегаций в источнике, если это поддерживает коннектор и структура запроса это позволяет.

Где заканчивается федерация

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

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

Если каталог поддерживает запись только в режиме autocommit, появится ошибка AUTOCOMMIT_WRITE_CONFLICT.

У федерации есть и другие ограничения:

Скорость определяется самым медленным источником. Быстрый движок не компенсирует медленное чтение из нижележащей системы.
Pushdown зависит от коннектора. Два подключённых источника могут вести себя по-разному: один выполнит агрегацию сам, а другой отправит весь объём в движок.
Статистика может быть неполной. Удалённые системы не всегда отдают точные статистики, поэтому оптимизатору сложнее выбрать хороший план для сложных join.
Cross-catalog join платит за сеть. Данные перемещаются между узлами, и топология сети начинает сильно влиять на время выполнения.
Координатор один. Отказ координатора останавливает приём запросов. Fault-tolerant execution помогает пережить сбой воркера, но не решает проблему координатора.
Fault-tolerant execution добавляет задержку. Промежуточные данные уходят через exchange manager в объектное хранилище, поэтому короткие запросы под нагрузкой могут работать медленнее.

Кажется, что проще собрать всё в одно хранилище, ведь централизованное хранилище даёт предсказуемые планы выполнения, полную статистику и транзакции. Но запросы бизнеса проходят через дата-офис, ETL и витрины. По пути появляются новые копии данных, которые со временем начинают расходиться.

Федеративный доступ сокращает этот путь. Аналитик может обратиться к данным из своего домена без отдельной заявки и получить ответ в тот же день.

Федерация не заменяет моделирование данных, ETL и витрины. Она подходит для ad-hoc-запросов, self-service-аналитики и исследования данных. Тяжёлые регулярные отчёты, фиксированные модели и расчёты по расписанию лучше оставлять витринам.

Data Mesh и Data Fabric с CedrusData

CedrusData Engine — коммерческий форк Trino. С 26 марта 2026 года CedrusData входит в группу VK Tech. Продукт сохраняет собственную документацию и релизный цикл.

Его задача совпадает с задачей федеративного слоя: дать единый SQL-доступ к разнородным источникам без копирования данных для каждого нового отчёта.

Подключение источников и Greenplum-коннектор

CedrusData Engine подключается к нескольким классам источников:

аналитическим СУБД: Greenplum, Vertica, Teradata, ClickHouse и Apache Druid;
реляционным СУБД: PostgreSQL, MySQL, Oracle, SQL Server и MariaDB;
NoSQL-системам и потоковым платформам: Cassandra, MongoDB, Redis и Kafka;
S3-совместимым объектным хранилищам, включая Iceberg и открытые форматы ORC, Parquet и Avro.

Для Greenplum доступен собственный коннектор, который читает сегменты кластера параллельно. В обычном Trino такого режима нет.

Greenplum популярен в России и часто выступает корпоративным хранилищем, но на деле это устаревшая и неэффективная технология. Разница между подключённым и параллельно читаемым источником влияет на работу real-time-запросов. Выполнение распределяется по воркерам, а данные не нужно предварительно загружать в движок.

CedrusData Catalog реализует протокол Iceberg REST Catalog, управляет Iceberg-таблицами и materialized views, включает Web UI, RBAC и управление группами доступа.

Catalog распространяется бесплатно по открытой лицензии. Для CedrusData Catalog доступны коммерческие варианты с технической поддержкой. В Data Fabric CedrusData Catalog Catalog может выступать операционным слоем метаданных, который помогает поддерживать каталог, доступы и правила работы с данными.

Российский контур поставки

Продукт включён в единый реестр российских программ, запись № 15789 от 5 декабря 2022 года.

CedrusData Engine можно протестировать бесплатно в течение 30 дней. Лицензия рассчитывается по ядрам compute-слоя, минимальная конфигурация — 32 физических ядра. CedrusData Catalog распространяется бесплатно.

Для установки Engine из архива на Linux нужны x64, JVM 21 или новее и около 8 ГБ RAM. Установка занимает примерно 10 минут. Docker-образ и Helm-чарт позволяют развернуть движок быстрее.

С лета 2025 года часть ядра перенесена на Rust поверх Apache DataFusion. В проекте Oxide внутренние операторы переводятся с Java на нативное исполнение.

В Engine уже есть cost-based оптимизатор на базе Cascades. Поддержка Cascades для части правил, включая планирование порядка join, заявлена в следующих версиях. При проектировании архитектуры стоит опираться на возможности текущей версии, а не на роадмап.

Пример S7 Airlines. После перехода на виртуализацию данных сотрудники S7 Airlines стали сами собирать отчёты и простые ETL-процессы через dbt. На анализ стало уходить меньше времени, а доступность данных повысила доверие к результатам. Этот пример говорит о виртуализации данных и self-service, а не о полноценном Data Mesh. Движок упрощает доступ к источникам, но не распределяет ответственность за данные между командами.

Подключите источники к единому SQL-доступу

CedrusData Engine — федеративные запросы к Greenplum, PostgreSQL, Kafka и объектным хранилищам без копирования данных.

Готова ли организация к Data Mesh

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

Есть слой обнаружения. Потребитель может найти чужой data product в каталоге, а не искать владельца в мессенджере.
Governance исполняется системами. Схемы, качество и доступы проверяются автоматически, а не только описаны в регламентах.
Доменные команды используют CI/CD. Команда может самостоятельно выпускать изменения в production.
Дата-инженерная экспертиза распределена. Она есть в доменах, а не сосредоточена в одной небольшой команде.
Есть поддержка руководства. Такая трансформация занимает годы и не помещается в квартальный проект.

Что отдавать федерации, а что оставлять витринам

Задача	Федеративный доступ	ETL и витрины
Ad-hoc-вопрос бизнеса и разведка данных	Да	Избыточно
Self-service-аналитика внутри домена	Да	Нет
Прототип витрины перед разработкой	Да	Нет
Регулярный тяжёлый отчёт по расписанию	Нет	Да
Сложные join больших таблиц из разных систем	Рискованно: влияют статистика и сеть	Да
Атомарная запись в две системы	Невозможно	Да, через оркестрацию
Историческая витрина с фиксированной логикой	Нет	Да

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

Частые вопросы про Data Mesh и Data Fabric

Чем Data Mesh отличается от Data Fabric?

Data Mesh описывает распределение ответственности: кто владеет данными и отвечает за их качество. Data Fabric — это технический слой с метаданными, интеграцией источников и автоматизацией доступа.

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

Нужен ли мне Data Mesh?

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

Перед реорганизацией проверьте, есть ли каталог data products, автоматические проверки качества и доступов, а также CI/CD у доменных команд. Обычно сложности возникают не на проектировании схемы, а в её ежедневной поддержке.

Что такое доменное владение данными?

Доменное владение — первый принцип Data Mesh. За датасет отвечает команда, которая ближе всего к его источнику, а не центральный дата-офис. Команда публикует датасет как продукт: с документацией, SLA, версиями и понятными потребителями.

Какова роль федеративного движка?

Федеративный SQL-движок даёт единый SQL-доступ к разнородным источникам без предварительного копирования данных. Домен может опубликовать data product там, где данные уже находятся, а потребитель — прочитать его одним запросом. Федерация хорошо подходит для чтения. Скорость запроса зависит от самого медленного источника, а распределённых транзакций между каталогами нет.

С чего начать?

Начните с инвентаризации источников и метаданных, а не с реорганизации. Подключите к федеративному движку три-пять ключевых источников, соберите каталог и проверьте, какие запросы бизнеса можно закрыть без новых ETL-процессов. Открытые табличные форматы, Iceberg и REST-каталог дают основу для lakehouse, на которой можно развивать и Fabric-слой, и доменные data products.

Заключение

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

Федеративный SQL-движок связывает эти подходы на практике. Он даёт аналитикам и доменным командам единый доступ к данным из разных систем без обязательного копирования в центральное хранилище. Это сокращает путь от вопроса к ответу и снимает с дата-офиса часть однотипных запросов.

Но федерация не заменяет хранилище, ETL и витрины. Она удобна для исследования данных, self-service-аналитики, прототипов и нерегулярных запросов. Для отчётов по расписанию, тяжёлых расчётов, исторических срезов и операций, где нужна согласованная запись в несколько систем, остаются ETL-процессы и витрины.

Начинать стоит не с объявления Data Mesh, а с инвентаризации источников, данных и владельцев. Затем можно подключить к федеративному движку несколько ключевых систем, собрать каталог и проверить, какие задачи уже решаются без новых копий и очереди в дата-офис. Если домены готовы поддерживать свои data products, а правила качества и доступов исполняются автоматически, технический слой постепенно станет основой для Data Fabric и Data Mesh.