Архитектура и функционал команд в рамках Data Mesh
Data Mesh - это архитектурная и организационная структура, в рамках которой данные рассматриваются как продукт (в этой статье мы будем использовать термин "продукт данных"). Такая структура данных предполагает, что продукты данных разрабатываются командами, которые хорошо разбираются в этих данных и в процессе их обработки следуют определенным стандартам управления данными. После развертывания Data Mesh в рамках организации функциональные подразделения могут быстрее находить и получать доступ к интересующим их данным. Для создания по-настоящему функциональной Data в первую очередь необходимо разработать высокоуровневые архитектурные компоненты, а также правильно распределить роли и права доступа к данным.
В данной статье мы не рассматриваем возможность масштабирования Data Mesh с целью предоставления продуктов данных третьим лицам.
Архитектура
Для определения необходимых архитектурных компонентов, которые описываются в этой статье, используются следующие ключевые термины:
- Продукт данных – это логический контейнер или группа, состоящая из одного или нескольких связанных между собой ресурсов данных;
- Источник данных - это актив системы хранения данных, содержащий структурированные данные или хранящий запрос, который возвращает структурированные данные;
- Атрибут данных – это поле данных.
На следующей диаграмме представлены ключевые архитектурные компоненты Data Mesh, реализованные в Google Cloud.
Данная диаграмма отображает следующее:
- Центральные сервисы позволяют создавать и управлять продуктами данных, включая создание организационных политик, влияющих на контроль доступа к данным (через группы Identity and Access Management), а также на специфические для данной инфраструктуры артефакты. Примеры таких подобных инфраструктур Вы найдете в разделе Создание платформы компонентов данных.
- Центральные службы в первую очередь формируют каталог данных для всех продуктов данных в Data Mesh, а также определяют механизм идентификации потенциальных потребителей этих продуктов данных.
- Домены данных включают в себя подмножества данных в виде продуктов данных. Это могут быть таблицы, представления, структурированные файлы и т.д. В BigQuery это будет набор данных, а в облачном хранилище – папка данных. В качестве продукта данных могут выступать и различные типы интерфейсов. Наглядным примером интерфейса является представление BigQuery.
Эталонная реализация Data Mesh
Описание эталонной реализации архитектуры Data Mesh можно найти в репозитории data-mesh-demo . Скрипты Terraform, используемые в реализации архитектуры, отражают ключевые концепции Data Mesh. Используя эти скрипты, Вы сможете:
- Создавать шаблоны каталога данных для разработки интерфейсов продуктов;
- Помечать интерфейсы продуктов с помощью этих шаблонов;
- Предоставлять права доступа потребителям продуктов данных.
Эталонная реализация Data Mesh подразумевает использование следующих типов интерфейсов:
- Авторизованные представления над таблицами BigQuery.
- Потоки данных на основе Pub/Sub.
Более подробная информация содержится в файле README, сохраненном в репозитории.
Функции Data Mesh
Для эффективной работы Data Mesh необходимо распределить роли между людьми, выполняющими различные задачи в рамках сетки данных. Эти роли можно разделять и объединять между собой в зависимости от потребностей каждого предприятия.
Домен данных напрямую связан с бизнес-единицами (BU) или функциями в рамках предприятия. Примерами бизнес-доменов могут быть отдел ипотечного кредитования в банке или отдел HR предприятия. В рамках Data Mesh есть следующие команды: команды производителей данных и команды потребителей данных. Команда производителей данных производит продукты данных из данных, которыми она владеет. Команда потребителей данных использует продукты данных для выполнения тех или иных бизнес-задач.
Data Mesh также выполняет ряд функций, выполняемых централизованными командами специалистов по работе с данными. Эти команды следят за эффективной и бесперебойной работой Data Mesh. Они работают над тем, чтобы снизить операционную нагрузку на домены данных, а также обеспечивают построение крепких междоменных отношений.
В этой статье мы говорим только об основных функциях и ролях, необходимых для построения надежной Data Mesh. Существует еще несколько функций и ролей, которые необходимы каждому без исключения предприятию, в этой статье мы опустим их описание.
Четыре основные команды, работающие в рамках Data Mesh:
- Команды производителей данных, основанные на доменах данных, создают и курируют продукты данных на протяжении всего их жизненного цикла. Эти команды часто называют производителями данных;
- Команды потребителей данных, основанных на доменах данных, находят продуктов данных и используют их различных аналитических приложениях. Эти команды могут использовать продукты данных для создания новых продуктов данных. Такие команды часто называют потребителями данных.
- Главная команда по data governance разрабатывает и внедряет политику data governance в целях обеспечения высокого качества и достоверности данных, используемых потребителями данных. Эту команду часто называют командой data governance.
- Главная команда платформа данных предоставляет производителям данных сервис самообслуживания платформы данных. Эта команда специалистов также следит за возможностью обнаружения данных и обеспечивает наблюдаемость продуктов данных, которые используются как потребителями, так и производителями данных. Эту команду часто называют командой платформы данных.
В качестве дополнительной опции следует рассмотреть возможность создания центра передового опыта (CoE) для Data Mesh. Цель CoE заключается в управлении Data Mesh. CoE также является арбитражной группой, разрешающей любые конфликты, возникающие между различными командами Data Mesh.
Команда производителей данных
Как правило, продукты данных создаются на базе физического хранилища данных (одного или нескольких хранилищ). Для создания и поддержания бесперебойной работы физических хранилищ организации распределяют роли и права доступа, связанные с управлением платформой данных.
Для создания продуктов данных на основе физических хранилищ нужны специалисты-практики в области данных, такие как дата-инженеры и архитекторы данных. В таблице, приведенной ниже, перечислены все специфические для данной области роли пользователей, которые необходимы распределить в рамках команды производителей данных.
|
Роль |
Обязанности |
Необходимые навыки |
Желаемый результат |
|---|---|---|---|
|
Владелец продукта данных |
|
аналитика данных архитектура данных управление продуктом |
|
|
Главный технический специалист по продуктам данных |
|
инжиниринг данных архитектура данных инжиниринг ПО |
|
|
Специалист по поддержке продуктов данных |
|
инжиниринг ПО SRE (Site Reliability Engineering) |
|
|
Эксперт в предметной области (SME) в рамках домена данных |
|
аналитика данных архитектура данных |
|
|
Владелец данных |
|
|
|
Команда потребителей данных
В рамках Data Mesh люди, которые потребляют продукты данных, обычно являются пользователями данных. Они используют центральный каталог данных для поиска продуктов данных, соответствующих их потребностям. Поскольку существует вероятность того, что их ожиданиям могут соответствовать сразу несколько продуктов данных, они запросто могут воспользоваться всеми ими без необходимости использовать только один из них.
Если потребители данных не могут найти необходимый им продукт данных, они могут проконсультироваться с CоE Data Mesh. В ходе консультации потребители данных озвучивают свои потребности в области данных и получают совет по поводу того, как лучше удовлетворить их в рамках одного или нескольких доменов.
Потребители данных ищут данные, которые помогут им решить различные бизнес-задачи, такие как составление дашбордов и отчетов. Кроме того, потребители данных могут искать продукты данных, которые можно использовать в системах ИИ и ML. Для решения этих задач потребителям данных требуется помощь со стороны следующих специалистов:
|
Роль |
Обязанности |
Необходимые навыки |
Желаемый результат |
|---|---|---|---|
|
Аналитик данных |
Ищет, идентифицирует и оценивает продукты данных, относящиеся к одной или нескольким областям, с целью создания основы для проведения бизнес-анализа. |
аналитический инжиниринг бизнес-аналитика |
|
|
Разработчик приложений |
Разрабатывает структуру использования данных в одном или нескольких продуктах данных |
разработка приложений инжиниринг данных |
|
|
Специалист по визуализации данных |
|
анализ данных визуализация данных |
|
|
Data scientist |
|
инжиниринг ML аналитический инжиниринг |
|
Команда data governance
Команда data governance позволяет производителям и потребителям данных безопасно обмениваться данными, агрегировать и вычислять их в режиме самообслуживания, не подвергая организацию риску, связанному с несоблюдением нормативных требований.
Как правило, команда data-governance состоит из следующих специалистов по работе с данными:
|
Роль |
Обязанности |
Необходимые требования |
Желаемый результат |
|---|---|---|---|
|
Специалист по data governance |
|
знание правовых норм и требований знание правовых норм и требований в области безопасности данных знание правовых норм и требований в области конфиденциальности данных |
|
|
Data steward (в каждом домене данных есть свой специалист) |
|
Архитектура данных Data stewardship |
|
|
Инженер по data governance |
|
Инжиниринг ПО |
|
Команда платформы данных
Команда платформы данных отвечает за создание оптимального набора компонентов инфраструктуры данных. Распределенные команды доменов данных используют эти компоненты для создания и развертывания своих продуктов данных. Кроме того, команда платформы данных занимается продвижением лучших практик и внедрением инструментов и методологий эффективного внедрения новых технологий.
Инфраструктура платформы данных должна обеспечивать простую интеграцию с инструментами автоматизации соблюдения бизнес-требований. Кроме того, инфраструктура должна способствовать интеграции, позволяющей мотивировать распределенные команды на достижение успеха.
Команда платформы данных следует модели совместной ответственности, которую она использует для работы с командами доменов и командой базовой инфраструктуры данных. Модель отражает то, какие обязанности возложены на потребителей платформы, а какие - на команду платформы данных.
Платформа данных сама по себе является внутренним продуктом данных.
Команда платформы данных оперирует стандартным набором компонентов, которые пока еще находятся в разработке. Однако команды доменов данных могут решить использовать другой набор компонентов, если их потребности не совпадают с теми, что готова предоставить платформа данных. Если команды домена данных выберут другой подход, они должны убедиться в том, что любая инфраструктура платформы, которую они создают, полностью соответствует общеорганизационным политикам и принципам безопасности данных.
Возможно, Вам придется ограничить автономию команды платформы данных на ранних этапах создания Data Mesh, особенно если Ваша первоначальная цель заключается в получении одобрения заинтересованных сторон на масштабирование Data Mesh. Однако ограничение автономии чревато созданием узких мест платформе данных, которые в будущем могут помешать масштабированию сетки данных. Поэтому любые решения о централизации должны приниматься с осторожностью. Основная цель состоит в том, чтобы стимулировать соблюдение требований путем установления правильного баланса между свободой выбора и стандартизацией.
Наконец, правильно организованная команда платформы данных - это главный источник обучения и передачи ценного опыта остальным сотрудникам компании. Ниже перечислены некоторые из наиболее эффективных мероприятий, которые мы рекомендуем проводить на регулярной основе:
- Регулярный пересмотр проектов новых функциональных решений;
- Обмен знаниями и опытом, а также коллективное определение лучших практик и рекомендаций по разработке архитектур;
- Обеспечение инженеров необходимыми инструментами валидации данных на предмет содержания наиболее распространенных ошибок, таких как проблемы с кодом, баги и т.д.
- Организация внутренних хакатонов для того, чтобы команды разработчиков могли определиться со своими требованиями к внутренним продуктам данных.
Примерный перечень специалистов, входящий в состав команды платформы данных:
|
Роль |
Обязанности |
Необходимые навыки |
Желаемый результат |
|---|---|---|---|
|
Владелец продукта платформы данных |
|
стратегическое планирование в сфере данных Управление продуктом Взаимодействие с заинтересованными лицами |
Сокращение времени создания минимально жизнеспособного продукта и время выпуска продукта данных.
|
|
|
|
|
|
|
|
|
|
|
|
|
Дополнительные рекомендации, касающиеся Data Mesh
Существует несколько вариантов архитектуры платформы данных, каждая из которых имеет свои особенности. Чтобы реализовать ту или иную архитектуру Data Mesh, необходимо следовать лучшим практикам, перечисленным в этой статье.
Обеспечение финансирования платформы
Как сказано в статье под названием " Если Вы хотите преобразований, начните с финансов", платформа данных будет все время трансформироваться и развиваться в соответствии с меняющимися приоритетами компаний. Поэтому придется постоянно инвестировать в развитие платформы.
Основные расходы ложатся на того, кто является пионером в области внедрения Data Mesh в существующую корпоративную инфраструктуру данных. Обычно расходы делятся между командой, которая формирует первый домен данных, инициирующий внедрение Data Mesh, и основной технологической группой, в состав которой входит команда платформы данных.
Для того чтобы убедить руководство компании инвестировать в развитие платформы, рекомендуем Вам представить бизнес-обоснование данного решения, подтверждающее важность и ценность централизованной платформы данных.
Определение минимально жизнеспособной платформы данных для Data Mesh
Для того чтобы помочь Вам определиться с минимально жизнеспособной платформы для Data Mesh, рекомендуем реализовать пилотный проект и использовать его при решении различных бизнес-кейсов. Для пилотного проекта определите необходимые сценарии использования, в которых есть потребитель, готовый использовать полученный продукт данных.
Убедитесь в том, что команда, реализующая пилотный проект, понимает операционную модель Data Mesh:
- Команда производителей данных владеет бэклогом, а также имеет службу поддержки;
- Центральная команда определяет шаблоны самообслуживания и помогает бизнесу создавать продукт данных, а по завершении работы над созданием передает продукт данных бизнесу, чтобы тот им мог использовать его и управлять им;
- Главная цель заключается в том, чтобы доказать работоспособность и жизнеспособность бизнес-модели (домены производят данные, домены потребляют данные). Вторая по приоритетности цель состоит в том, чтобы доказать работоспособность технической операционной модели (паттерны самообслуживания, разработанные центральной командой);
- Поскольку ресурсы команд платформы сильно ограничены, используйте модель магистральных и отраслевых команд для накопления ценных знаний и опыта.
Кроме того, рекомендуем сделать следующее:
- Разрабатывайте дорожные карты, не позволяйте сервисам и функциям развиваться автономно;
- Определите минимальные жизнеспособные возможности платформы, охватывающие прием, хранение, обработку, анализ данных, а также ML.
- Внедряйте управление данными на каждом этапе внедрения Data Mesh
- Создайте возможности для управления платформой данных и управления ее изменениями. Минимально требуемые возможности - это те, которые удовлетворяют 80% бизнес-кейсов.
Синергия Data Mesh и существующей платформы данных
Многие организации, стремящиеся внедрить Data Mesh, скорее всего, уже имеют существующую платформу данных, например Data Lake, DWH или их комбинацию. Прежде чем приступить к непосредственному внедрению Data Mesh, эти организации должны разработать план того, как существующая платформа данных будет эволюционировать по мере внедрения Data Mesh.
Эти организации должны обратить свое внимание на следующие аспекты:
- Ресурсы данных, которые наиболее эффективны для Data Mesh
- Активы, которые должны остаться в рамках существующей платформы данных.
- Придется ли перетасовывать какие-либо активы данных или их можно сохранить в рамках существующей платформы и при этом продолжить внедрение Data Mesh.
