Распределённые архитектуры данных
~ 30 минут
Фраза «распределённые архитектуры данных» часто вызывает ассоциации с десятком микросервисов, которые живут на месте древнего DWH или «болота с данными». Но по факту распределённая архитектура данных — о владении, а не о техническом решении.
Распределённая архитектура данных вполне может содержать в себе DWH или Data Lake или и то и другое.
При росте компании генерируется огромное количество данных, которые по мере погружения компании в подход Data Driven хочется уметь готовить и понимать. Это полезно во многих сферах.
DWH и Data LakeHouse никак не противоречат этому: в зависимости от решения лишь получается разная степень полезности данных. От DWH можно получить операционные данные, а от Data Lake и Data LakeHouse — узнать чуть больше из полуструктурированной и неструктурированной информации и сделать умнее наши рекомендательные системы, чат-боты и так далее.
Проблема может возникнуть, когда данных и команд становится слишком много и компании упираются в «бутылочное горлышко» в виде команды хранилища и аналитиков. Все, кому нужна информация, приходят именно к ним. Аналитик при этом обращается к другому аналитику, который может знать, где находятся нужные данные, или сам ищет в Wiki, в чатах и каталогах.
А ещё по мере разрастания хранилища его команде, которая по факту владеет данными всех сервисов и схемой, приходится следить за ними, менять код интеграций, отчётов и так далее. Как следствие, растёт time to market, а команда хранилища перегружена. Из-за большого количества разнородные данные могут противоречить друг другу, быть неполными, нарушать комплаенс. При этом нанимать большую команду и заставлять их изучить все бизнесы компании — не вариант.
Чтобы подобное не случалось, возникла более глубокая специализация и разделение ответственности. В архитектуре данных произошёл сдвиг “left and shift” — от монолитного владения данными к владению данными продуктовыми командами.
Подход Data Mesh
В 2019 году Джамак Дегхани представила подход Data Mesh. Вместо того чтобы рассматривать данные как побочный продукт или централизованный актив, Data Mesh рассматривает данные как продукт, которым должны владеть и управлять эксперты в предметной области.
Этот подход основан на предположении, что те, кто ближе всего к бизнес-контексту, лучше всего подходят для управления данными и извлечения из них пользы. Команды хранилищ вздохнули с облегчением, а владельцы данных обрадовались, что у них появляется автономность и возможности быстрых экспериментов.
Data Mesh состоит из четырёх основных компонентов для создания масштабируемой и эффективной архитектуры данных.
Предполагается, что есть глобальные стандарты качества, но команды сами создают, поставляют и описывают данные. Именно они настраивают правила использования, делают проверку качества — всё для того, чтобы данные стали продуктом и их смогли потреблять другие домены или внешние приложения.
При переходе к Data Mesh бизнес получит гибкость, улучшит качество и скорость работы с данными, улучшит комплаенс. Но всё же есть сложности, с которыми он может потенциально столкнуться.
Ограничения Data Mesh
- Повышение сложности инфраструктуры и, как следствие, повышение стоимости и требований к навыкам сотрудников.
- Организационные сложности. Для реализации Data Mesh должно поменяться мышление: надо быть готовым к постепенному процессу и к тому, что выгода будет не сразу.
- Необходимость построения платформы данных в парадигме единой инфраструктуры для команд.
Принципы Data Mesh
Принцип 1. Разделение контекстов бизнеса. В курсе вы рассматривали DDD-подход, и он очень помогает в реализации Data Mesh.
Принцип 2. Выстраивание единой инфраструктурной платформы. Она, c одной стороны, обеспечит потребности команд в части интеграций данных и, с другой стороны, должна удовлетворять потребностям пользователей в части обнаружения данных, облегчения поиска и так далее.
Принцип 3. Продуктовое мышление. Этот принцип означает работу с данными как с продуктом.
Например, обычно для покупателя любого товара важны:
- Опыт покупки: доступен ли товар, легко ли дойти до кнопки «купить» или найти отзывы, насколько хорошо описан товар, есть ли фото.
- Скорость доставки: как быстро можно получить покупку.
- Качество товара: насколько качественным окажется товар.
Для потенциального «покупателя» данных важны очень похожие моменты:
- Доступность для поиска: насколько легко новому сотруднику пройти онбординг.
- Доступность по адресу: сколько тысяч лет сотруднику нужно ждать, чтобы получить права на данные, и у кого их вообще получать.
- Достоверность и правдивость: можно ли верить этим данным.
- Документирование: можно ли не изучать всю структуру данных и их происхождение, а увидеть это в «карточке товара».
- Взаимодействие друг с другом и соответствие глобальным стандартам: насколько данные соответствуют правилам комплаенса компании и не дублируются ли они другими данными.
- Безопасность и управление глобальным доступом: есть ли возможность безопасного доступа к данным (например, с помощью определения политики RBAC).
В целом принцип сводится к тому, что данные должны быть привлекательными для «покупки» другими доменами компании.
Принцип 4. Обеспечение управления данными через единые политики. В архитектуре такого подхода существует независимая группа экспертов, которая вырабатывает стандарты и политики для продуктов, в идеале эти политики автоматизируются на уровне платформы данных. То есть в команде продукта вручную не отсматривают данные, чтобы решить, загружать их или нет.
Концептуальная архитектура такого подхода выглядит так:
- Каждый продукт данных (data product, DP) имеет границы по DDD, собирает операционные данные, использует аналитические данные и публикует контракт, который может использовать другой продукт.
- Продукт данных использует платформу самообслуживания — единую инфраструктуру для данных. Так же, как отдельные квартиры в доме используют общую систему водоснабжения.
Теперь, когда с принципами подхода разобрались, стоит ответить на вопросы, как внедрить и технически реализовать Data Mesh.
Реализация подхода Data Mesh
Так как к внедрению Data Mesh чаще всего подходят с багажом в виде существующего хранилища, нет смысла делать всё сразу красиво и дорого. Это постепенный процесс.
Этапы внедрения Data Mesh
- Разделение бизнеса на домены
На первом этапе нужно организовать данные по этим доменам в текущих хранилищах. Например, разделить существующий Data Lake на области-домены по данным (в DWH это обычно сделать проще в силу структурированности информации). Разделение на домены подразумевает назначение владельцев доменов, которые будут отвечать за данные в своих областях.
- Организационные изменения — деление на команды
Важно сформировать команды доменов, где каждая будет отвечать за свою систему в домене или домен целиком и состоять из людей, обладающих необходимыми знаниями и умениями. «Аренда» таких сотрудников у других команд, тем более вне домена, — плохая практика, которая приводит к нарушению границ домена и к ущербу одному из доменов.
- Разработка стандартов и политик
Продукты данных должны разрабатываться со стандартными API, схемами и интерфейсами — необходимо разработать стандарты и политики и по возможности их автоматизировать (например, проверка JSON-схем на уровне CI/CD).
- Внедрение инструментов управления данными
На этом этапе создаются каталоги или своеобразные витрины — «маркетплейсы» данных. В них удобно ориентироваться, находить «карточки товаров». Аналитики и разработчики могут быстрее найти данные благодаря поиску по ключевым словам и категоризации по доменам.
- Внедрение платформы или преобразование текущего IT-ландшафта с доработками.
Техническая реализация Data Mesh
Единого подхода или единого решения, как сделать платформу данных, чтобы реализовать принципы архитектуры Data Mesh, не существует. Всё зависит от стека, возможностей компании, объёма данных и других факторов. Но концептуально можно выделить такие компоненты:
Существуют, например, варианты реализации на AWS-стеке.
Источник: Data Mesh Learning, July 2021. Data Lake Strategy via Data Mesh Architecture at JPMorgan Chase; Data Mesh Learning Meetup #005
Вам знакомы почти все составляющие этой архитектуры, осталось понять, что за место, которое выступает тем самым «маркетплейсом» данных и обеспечивает полный цикл управления.
Управление метаданными
Реализация управления метаданными (data governance) отвечает за политики автоматизаций на уровне CI/CD, организационных мероприятий, а также включает:
- Поиск и обнаружение данных (search and discovery): схемы данных, поля, теги, информацию об использовании, описание данных, дополнительную документацию.
- Контроль доступа (access control): группы контроля доступа, пользователи, политики.
- Происхождение данных (data lineage): выполнение конвейера данных, запросы, журналы API, схемы API — то есть то, как данные путешествуют по системам, откуда они пришли и кто их загрузил.
- Соответствие требованиям безопасности (compliance): таксономию типов аннотаций конфиденциальности / соответствия данных.
- Управление данными (data management): конфигурацию источника данных, конфигурацию приёма, конфигурацию хранения, политики очистки данных и экспорта данных.
- Объяснимость ИИ, воспроизводимость (AI explainability, reproducibility): определение функции, определение модели, выполнение тренировочного прогона, постановку проблемы.
- Data Ops: выполнение конвейера, обработанные разделы данных, статистику данных.
- Определения правил качества данных, результаты выполнения правил, статистику данных.
За все эти функции в той или иной мере (зависит от технического решения) отвечает каталог данных — Data Catalog.
Data Catalog
Каталоги данных как техническое решение пережили уже несколько этапов эволюции.
Есть первое поколения каталогов, которые строились на простейшей реализации: источники данных, ETL/ELT и полнотекстовый поиск (ElasticSearch, например). В них метаданные нужно было индексировать и искать в едином интерфейсе. Такие каталоги были обычно самописными.
Второе и третье поколения каталогов уже умеют больше:
- Расширенный поиск и обнаружение: эти каталоги позволяют бизнес-аналитикам и специалистам по анализу данных эффективно находить и понимать соответствующие ресурсы с данными. Они предоставляют контекстную информацию и позволяют пользователям создавать подробные страницы, похожие на Wiki, для каждого ресурса с данными.
- Управление метаданными: расширенные возможности для ведения документации по данным, обработкам, происхождению и информации о владельцах.
- Поддержка управления данными: инструменты для внедрения и обеспечения соблюдения методов управления данными, включая управление качеством данных и контроль доступа.
- Бизнес-глоссарий: функции для определения бизнес-терминов и управления ими, устраняющие разрыв между техническими и нетехническими пользователями.
- Управление правами: расширенные функции для ограничения доступа к данным на основе ролей и разрешений пользователей.
- Расширенные функции работы с данными: добавление более продвинутых возможностей, таких как визуализация цепочки передачи данных, показатели качества данных и интегрированные редакторы SQL.
- Загрузка данных и в pull-, и в push-вариантах: push-модель предполагает, что данные отправляются от источника к получателю автоматически по мере их появления. А в pull-модель сервер сбора данных регулярно опрашивает источники для получения актуальной информации.
Вариантов технической реализации каталога данных по лицензии достаточно много от разных вендоров.
Пример реализации такого каталога — банк, где много доменов, в каждом из которых свой глоссарий и свои интеграции. Без единой точки знаний всё будет лежать в Wiki с непонятным статусом и чаще всего неактуальное. С каталогом и сторонние решения, которые хотят интегрироваться, и аналитики, и новые сотрудники могут быстро погрузиться в контекст и начать приносить пользу.
Хорошим решением является DataHub в силу своей распределённой архитектуры (у OpenMetadata она всё-таки модульная). Посмотрим на него чуть подробнее.
DataHub
Это комбайн, который решает все задачи каталога данных, умеет получать потоковые данные и интегрируется с большим количеством решений.
Pull-интеграция осуществляется с помощью расширяемой библиотеки Python, которая извлекает метаданные из внешних систем, таких как Postgres, Snowflake, MySQL и других.
Push-интеграция позволяет обновлять метаданные в реальном времени при их изменении. Примерами таких инструментов являются AirFlow и Great Expectations. Изменения могут быть переданы через Kafka, REST или с помощью Python-эмиттера.
Полученные метаданные направляются на уровень обслуживания, центральным компонентом которого является сервис метаданных.
Сервис метаданных предоставляет REST API и GraphQL API для работы с метаданными.
Запросы на полнотекстовый и расширенный поиск направляются в поисковый индекс (ElasticSearch), а сложные графовые запросы, такие как lineage, — в индекс графа (Neo4J ― графовая база данных).
Все изменения метаданных фиксируются в постоянном хранилище. События об этих изменениях поступают в журнал Metadata Change Log (Kafka), который создаётся сервисом метаданных. Поток этих событий представляет собой общедоступный API, на который могут подписываться внешние системы, что позволяет им реагировать на изменения метаданных (например, посредством уведомлений в Slack).
Журнал Metadata Change Log используется для внесения соответствующих изменений в графовый и поисковой индексы.
Итак, с теоретическими аспектами вы разобрались. Осталось собрать пайплайн с Data Mesh на практике. Этим и займёмся в следующем уроке.
Использование push- и pull-моделей обеспечивает своевременное обновление информации о данных, делая её актуальной для пользователей.
Итоги
- Data Mesh — это подход к работе с данными, который делает их доступными и удобными для использования, акцентируя внимание на простоте поиска, быстром получении доступа, достоверности информации, прозрачной документации и соответствии корпоративным стандартам. Основная идея — продуктовый подход к данным. Продуктовое мышление предполагает работу с данными как с продуктом, делая их доступными, достоверными, безопасными и легко документируемыми, чтобы другие домены могли их приобрести.
- Принципы Data Mesh основывается на DDD-подходе, где данные структурируются по бизнес-доменам, это улучшает понимание, где данные находятся и кому принадлежат. Но единые политики управления данными создаются независимой экспертной группой, автоматизируются и внедряются через платформу самообслуживания, чтобы стандарты соблюдались без ручного вмешательства отдельных команд.
- Для внедрения подхода Data Mesh бизнес делится на домены, а данные организуются по этим областям в существующих хранилищах (например, путём разделения Data Lake или DWH). Каждому домену назначаются владельцы, отвечающие за управление данными, а также формируются команды, которые полностью отвечают за свои домены и обладают всеми необходимыми навыками. Далее разрабатываются стандарты API, схемы и интерфейсы, чтобы продукты данных соответствовали единой политике, с возможной автоматизацией этих процессов.
- Для упрощения работы создаются каталоги данных — своего рода витрины, где аналитики и разработчики могут быстро находить нужную информацию. Каталоги упрощают поиск, документирование и доступ к данным. DataHub является примером такого каталога, который структурирует поток данных, связывает их с метаданными и помогает обеспечивать их качество, безопасность и соответствие требованиям пользователей.