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

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

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

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

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

Понятие Data Mesh как архитектуры создания распределенных пайплайнов данных впервые ввела в обиход Жамак Дегани в статье How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh в 2019 году, и она основана на четырех основополагающих принципах, объединяющих известные концепции:

1. Принцип владения доменом обязывает команды домена нести ответственность за свои данные. Согласно этому принципу, аналитические данные должны быть составлены вокруг доменов, подобно границам команды, соответствующим ограниченному контексту системы. Следуя распределенной архитектуре, ориентированной на домен, владение аналитическими и операционными данными передается командам домена, а не центральной команде по данным. Это понятие пришло из парадигмы разработки ПО Domain Driven Design (DDD). Его используют для моделирования сложных программных решений. В Data Mesh домен данных – это способ определить, где начинаются и заканчиваются корпоративные данные. Границы зависят от компании и ее потребностей. Иногда разумно моделировать домены, учитывая бизнес-процессы или исходные системы.
2. Принцип «данные как продукт» проецирует философию мышления о продукте на аналитические данные. Этот принцип означает, что существуют потребители данных за пределами домена. Команда домена отвечает за удовлетворение потребностей других доменов, предоставляя высококачественные данные. По сути, данные домена следует рассматривать как любой другой публичный API. Data-продукты - важный компонент Data Mesh, связанный с применением к данным продуктового мышления. Чтобы Data-продукт работал, он должен приносить пользователям пользу в долгосрочной перспективе и быть пригодным к использованию, ценным и ощутимым. Он может быть реализован как API, отчет, таблица или датасет в озере данных.
3. Принцип платформы инфраструктуры данных с самообслуживанием заключается в адаптации платформенного мышления к инфраструктуре данных. Специальная команда платформы данных предоставляет функциональные возможности, инструменты и системы, не зависящие от домена, для создания, выполнения и поддержки совместимых продуктов данных для всех доменов. Благодаря своей платформе команда платформы данных позволяет группам доменов беспрепятственно потреблять и создавать продукты данных. Data Mesh строится экспертами широкого профиля, которые создают универсальные продукты и управляют ими. В рамках этого подхода вы будете опираться на децентрализацию и согласование с бизнес-пользователями, которые разбираются в предметной области, какое значение имеют те или иные данные. При этом у вас будут специализированные команды, которые разрабатывают автономные продукты, не зависящие от центральной платформы. Поэтому не получится использовать сложные и узкоспециализированные инструменты для эксплуатации фундамента платформы на основе Data Mesh.
4. Принцип федеративного управления обеспечивает совместимость всех продуктов данных посредством стандартизации, которая продвигается через всю сетку данных группой управления. Основная цель федеративного управления – создание экосистемы данных с соблюдением организационных правил и отраслевых норм. Когда вы переходите на распределенную Data-платформу самообслуживания, нужно сосредоточиться на Governance. Если не уделять ему внимание, вы скоро окажетесь в ситуации, когда во всех доменах применяются разрозненные технологии, а данные дублируются. Поэтому и на уровне платформы, и на уровне данных нужно внедрить автоматизированные политики.

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

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

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

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

Но что связывает домены и соответствующие активы данных? Это уровень универсальной взаимной совместимости, на котором применяется одинаковая инфраструктура, синтаксис и стандарты данных.

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

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

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

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

Заключение

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

Термин «озеро данных» подразумевает монолитность, но на практике оно реализуется вместе с высокораспределенной технологией, такой как объектное хранилище. Потому команды по развитию платформы могут создавать Data Mesh, образуя изолированные Data-среды для Data-продуктов. Монолит можно разбить на маленькие озера – по одному на каждый продукт.

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