Средний

12 мин

2

Объем и разнообразие корпоративных данных значительно возрастает с каждым годом. Вместе с этим появляются новые требования к их хранению, обработке и использованию.

Развиваются различные подходы к архитектуре и управлению данными:

• Data Warehouse (DWH) для централизованной аналитики 

• Data Lake для хранения больших объемов разнородной информации 

• Data Lakehouse как объединение преимущества обоих подходов 

• Data Fabric для интеграции распределенных источников данных  

• Data Mesh — концепция, предлагающая передать ответственность за данные непосредственно бизнес-доменам 

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

Но действительно ли Data Mesh подходит большинству компаний?

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

Что такое Data Mesh и почему о нем так много говорят

Data Mesh — это подход к управлению данными, при котором ответственность за сбор, хранение, качество и предоставление данных переходит от централизованной data-команды разным бизнес-подразделениям (доменам) компании.

В классической централизованной модели управления данными все запросы на данные проходят через единую data-команду или ИТ-подразделение. В результате возникают типичные ограничения:

• очереди на разработку

• перегруженные ETL-процессы

• медленное внедрение новых инструментов и методологий

• отсутствие ответственности бизнеса за качество данных

• зависимость аналитики от узкого круга специалистов

Data Mesh предлагает изменить организационную модель работы с данными.

В основе Data Mesh лежат следующие сущности:

• Дата-домен — бизнес-область или подразделение (маркетинг, продажи, производство, логистика, финансы), которое не просто генерирует данные, а полноценно владеет ими как продуктом: отвечает за их смысл, структуру, качество, SLA и развитие. Дата-домен несет ответственность перед другими подразделениями как перед потребителями данных.

• Дата-продукт — это оформленный, готовый к использованию набор данных (или поток данных), имеющий назначение, владельца, описание, контракт потребления, метрики качества и гарантии доступности. Дата-продукт - данные, представленные как сервис для других команд.

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

История концепции и ее автор

Концепцию Data Mesh предложила технический директор компании ThoughtWorks Жамак Дегани (Zhamak Dehghani) в 2019 году. На тот момент многие компании уже активно использовали Data Lake и корпоративные хранилища данных DWH, однако даже крупные data и ИТ-команды не всегда успевали обеспечивать потребности бизнеса в новых данных и аналитических сервисах.

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

Почему концепция стала популярной

• Рост data-driven компаний и объемов данных

За последние годы данные стали одним из ключевых активов бизнеса. Одновременно выросло количество источников данных: ERP, CRM, мобильные приложения, маркетплейсы, IoT-устройства, веб-сервисы и внешние системы. В результате объемы данных растут значительно быстрее, чем возможности традиционных архитектур и команд по их обработке.

• Bottleneck централизованных data-команд

Во многих компаниях все запросы на новые интеграции, витрины данных и отчеты проходили через единую data-команду. По мере роста бизнеса такой подход превращался в «бутылочное горлышко»: данных требовалось все больше, а скорость их подготовки оставалась ограниченной ресурсами одного подразделения. Бизнес-подразделения были вынуждены ждать реализации своих задач неделями.

• Масштабирование аналитики в Big Tech

Одними из первых с проблемой централизованного управления данными столкнулись крупные технологические компании. В организациях, где одновременно работают десятки продуктовых команд, каждая команда генерирует собственные данные и нуждается в своих аналитических сервисах. Именно опыт Big Tech во многом стал основой для появления и популяризации концепции Data Mesh.

• Тренд на распределенные архитектуры (Distributed Architecture)

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

Четыре принципа Data Mesh

В основе концепции Data Mesh лежат четыре ключевых принципа:

1. Domain-Oriented Ownership - децентрализованное владение данными

Данные принадлежат бизнес-доменам, а не централизованной ИТ или data-команде. Каждый домен становится владельцем своих данных и отвечает за их качество, актуальность, доступность и развитие.

Например, за данные о продажах отвечает команда продаж, за данные о логистике — подразделение логистики, а за финансовые показатели — финансовый блок.

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

2. Data as a Product – данные как продукт

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

Это означает, что у набора данных должны быть:

• владелец

• SLA

• документация

• контроль и гарантированный уровень качества

• понятные интерфейсы доступа

• поддержка пользователей

Реализация принципа Data as a Product требует зрелой продуктовой культуры, понятных ролей и ответственности в команде.

3. Self-Service Data Platform — инфраструктура самообслуживания

Центральная data-команда перестает быть единственной точкой входа для всех задач, связанных с данными. Вместо этого она создает и поддерживает единую платформу самообслуживания (Self-Service Data Platform), которой могут пользоваться все домены компании.

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

• подключения источников

• загрузки и трансформации данных

• управления доступами

• мониторинга

• контроля качества

• публикации дата-продуктов

Для реализации принципа требуется высокий уровень автоматизации, зрелая платформенная инженерия (Platform Engineering), развитая DevOps-культура и единые стандарты работы с данными.

4. Federated Computational Governance — федеративное управление данными

Четвертый принцип Data Mesh предполагает, что при распределенном владении данными компания сохраняет единые правила и стандарты работы с ними, разработанные центральной data-командой.

Домены действуют в рамках общих требований, которые включают:

• единые стандарты именования и описания данных

• общие требования к качеству данных

• централизованные политики информационной безопасности

• единые правила предоставления доступов

• контроль происхождения данных (data lineage)

• использование общего каталога данных (data catalog)

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

Почему Data Mesh сложно внедрить на практике

1. Низкий уровень зрелости управления данными

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

Оценить готовность к изменениям в работе с данными можно с помощью модели зрелости управления данными DMMA (Data Management Maturity Assessment):

2. Высокоцентрализованная культура принятия решений

Во многих российских компаниях управление строится по централизованной модели:

• жесткая вертикальная иерархия

• централизованный контроль бюджета и стандартов

• ограниченная автономия бизнес-команд

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

В такой ситуации попытки внедрения Data Mesh часто приводят к двум сценариям:

• Псевдодецентрализация — домены формально считаются владельцами данных, но все ключевые решения по-прежнему принимает центральный IT-отдел

• Управленческий хаос — подразделения начинают конкурировать за влияние, по-разному трактуют стандарты и требуют адаптировать дата-продукты под собственные потребности

3. Низкий уровень доверия между подразделениями

Data Mesh предполагает активное взаимодействие между доменами и свободный обмен данными внутри компании. Часто этому мешают особенности корпоративной культуры:

• конкуренция подразделений за бюджеты и влияние

• восприятие данных как политического актива

• нежелание терять контроль над информацией

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

4. Слабая продуктовая культура вне IT

Один из ключевых принципов Data Mesh — Data as a Product, то есть отношение к данным как к полноценному продукту. Однако во многих российских компаниях продуктовый подход хорошо развит в ИТ, но значительно реже встречается в бизнес-подразделениях.

Для многих команд характерны:

• ориентация на выполнение процессов, а не развитие продукта

• размытая ответственность за данные

• отсутствие KPI, связанных с качеством данных

• недостаточное внимание к потребностям пользователей

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

5. Отсутствие поддержки доменов

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

• IT-бюджет централизован

• data-инженеры работают в едином подразделении

• найм специалистов контролируется центральным ИТ-отделом

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

6. Смещение в сторону контроля, комплаенса и безопасности

Многие российские компании, особенно из финансового сектора, промышленности и госсектора, уделяют повышенное внимание вопросам безопасности и контроля данных.

При этом Data Mesh предполагает:

• распределенные пайплайны данных

• множественных владельцев

• доменное хранение и публикацию дата-продуктов

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

7. Проблема распределения компетенций

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

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

8. Страх персональной ответственности домена

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

Во многих компаниях по-прежнему распространены:

• коллективная ответственность

• размытые зоны владения

• стремление минимизировать персональные риски

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

9. Мышление в формате крупного разового проекта

Компании привыкли реализовывать изменения через масштабные трансформационные процессы с фиксированным планом и заранее определенной целевой архитектурой.

Data Mesh предполагает:

• постепенное внедрение

• непрерывное развитие дата-продуктов

• эволюцию процессов и культуры управления

• длительную организационную трансформацию

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

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

Однако, исходя из проектного опыта Qlever Solutions, большинство компаний, реализующих проекты развития аналитики, сегодня по-прежнему сосредоточены на решении более базовых задач: консолидации данных, построении DWH, повышении качества данных и внедрении процессов Data Governance.

Только после формирования такой основы и достижения высокого уровня зрелости управления данными появляется практический смысл рассматривать внедрение отдельных принципов или полноценной модели Data Mesh.

Почему большинству компаний в России сейчас нужен DWH

Централизация данных все еще решает основные задачи бизнеса

На минимальном или установленном уровне зрелости управления данными бизнесу важно выстроить единое пространство данных для аналитики.

Централизованное DWH позволяет решить ключевые проблемы автоматизации аналитики:

• создать единую версию данных (Single Source of Truth)

• обеспечить прозрачность показателей

• повысить управляемость процессов

• улучшить качество аналитики и отчетности

• сократить количество противоречивых метрик и расчетов

DWH проще внедрять и поддерживать

По сравнению с Data Mesh корпоративное хранилище данных предъявляет значительно меньше требований к организационной структуре компании.

Преимущества DWH:

• ниже организационная сложность

• меньше требований к инженерным компетенциям в бизнес-подразделениях

• проще обеспечить единые стандарты данных

• можно получить быстрые бизнес-результаты (time-to-value)

Именно поэтому большинство успешных проектов по развитию аналитики начинается с построения DWH как основы для развития аналитической системы и масштабирования практик управления данными.

От простого к сложному: естественная эволюция архитектуры данных

Развитие технологий для работы с данными обычно происходит поэтапно:

DWH → Data Lake / Lakehouse → Data Mesh

• Компания создает единый источник достоверных данных DWH и выстраивает процессы управления данными

• По мере роста объемов и разнообразия источников данных появляются Data Lake или Lakehouse

• После достижения высокой зрелости управления данными можно рассматривать распределенный подход Data Mesh

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

• хранение структурированных и неструктурированных данных

• более гибкую работу с дата-продуктами

• поддержку различных сценариев использования данных

• развитые механизмы Data Governance

• масштабируемость и независимость доменов

Когда Data Mesh действительно оправдан

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

Data Mesh оправдан, если компания:

• имеет несколько независимых продуктовых команд

• работает в нескольких странах или регионах

• обладает зрелой DevOps- и DataOps-культурой

• уже столкнулась с bottleneck централизованного DWH и готова масштабироваться

• имеет развитую data-platform engineering команду

• готова инвестировать в Data Governance

Чаще всего такие условия характерны для Big Tech, международных digital-компаний и крупных платформенных экосистем.

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

• сильные data-инженеры внутри доменов

• развитая платформенная инфраструктура

• единые инструменты управления и мониторинга

• зрелые процессы управления данными

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

Что стоит делать российским компаниям прямо сейчас

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

• Построить единое DWH

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

• Внедрить Data Governance и Data Quality

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

• определить владельцев данных

• внедрить правила и стандарты

• организовать контроль качества

• создать единый подход к работе со справочниками и метриками

Без этого дальнейшее масштабирование аналитики становится затруднительным независимо от выбранной архитектуры.

• Развивать Data Literacy

Технологии сами по себе не делают компанию data-driven. Необходимо повышать уровень работы с данными среди сотрудников и руководителей, развивать культуру принятия решений на основе данных и формировать понимание ответственности за качество информации на всех уровнях организации.

• Перейти от DWH к более гибким архитектурам

По мере роста объемов данных и появления новых сценариев использования — AI, ML, потоковой обработки и анализа неструктурированных данных — классического DWH может стать недостаточно. На этом этапе стоит рассматривать развитие платформы в сторону Data Lakehouse, сохраняя при этом единые процессы управления данными.

• Только потом рассматривать Data Mesh

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

Путь к Data Mesh начинается не с распределения ответственности между доменами, а с построения качественного DWH, зрелых процессов управления данными и сильной data-культуры внутри компании.