Enterprise Data Mesh

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

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

Что касается технологий, то в представлении Oracle о концепции сетки данных фигурируют три новых важных области для архитектуры, ориентированной на обработку данных:

1. Инструменты, которые предоставляют продукты данных, такие как наборы данных, события данных и аналитика данных.
2. Распределенные, децентрализованные архитектуры данных, которые помогают организациям, решившим перейти от монолитных архитектур к мультиоблачным или гибридным облачным решениям, либо компаниям, реализующим концепцию глобальной децентрализации.
3. Данные в движении для организаций, которые не могут полагаться только на централизованные, статические, пакетные данные, а переходят к использованию управляемых событиями реестров данных и потоковых конвейеров для событий данных реального времени, которые предоставляют более своевременную аналитику.

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

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

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

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

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

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

Вот несколько технологических тенденций, которые привели к появлению сетки данных:

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

К числу таких освоенных методов относятся:

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

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

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

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

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

• Аналитика — отчеты и панели мониторинга, составленные по историческим данным или данным, поступающим в режиме реального времени.
• Наборы данных — коллекции данных разных форм и форматов.
• Модели — объекты доменов, модели данных, функции машинного обучения.
• Алгоритмы — модели машинного обучения, оценки, бизнес-правила.
• Сервисы данных и API — документы, полезная нагрузка, API REST и др.

Продукт данных создается для потребления, обычно находится за пределами ИТ-отдела и требует отслеживания дополнительных атрибутов, в том числе следующих:

• Карта заинтересованных сторон. Кто владеет, создает и потребляет этот продукт?
• Упаковка и документирование. Как он потребляется? Как он маркируется?
• Назначение и ценность. Какова подразумеваемая/явная ценность продукта? Теряет ли он свою ценность со временем?
• Качество и согласованность. Каковы показатели KPI и SLA использования? Можно ли проверить?
• Происхождение, жизненный цикл и управление. Данные являются доверенными и объяснимыми?

Децентрализованные ИТ-системы являются современной реальностью, а с учетом развития приложений SaaS и инфраструктуры публичного облака (IaaS) можно уверенно говорить, что децентрализация приложений ― это всерьез и надолго. Архитектуры прикладных приложений уходят от централизованного монолита прошлого и смещаются в сторону распределенных микросервисов (сетка сервисов). Архитектура данных последует в том же направлении к децентрализации, при этом данные будут становиться все более распределенными по различным физическим объектам и многим сетям. Это мы и называем Data Mesh.

Сетка ― это сетевая технология, позволяющая большой группе неиерархических узлов плодотворно работать друг с другом.

Вот несколько распространенных примеров:

• WiFiMesh — множество узлов, работающих совместно для обеспечения более качественного покрытия.
• ZWave/Zigbee — сеть устройств умного дома с низким потреблением энергии.
• Сетка 5G — более надежные и устойчивые сотовые подключения.
• Starlink— сетка спутниковой широкополосной связи в глобальном масштабе.
• Сетка сервисов — способ предоставления унифицированных элементов управления децентрализованными микросервисами (прикладным программным обеспечением).

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

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

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

Вот лишь некоторые соображения на этот счет.

• Шифрование в состоянии покоя — данные и события, которые записываются в хранилище.
• Распределенная аутентификация — для сервисов и хранилищ данных, таких как mTLS, сертификатов, SSO, хранилищ секретов и хранилищ данных.
• Шифрование в движении — данные и события, которые записываются в хранилище.
• Управление идентификацией — сервисы типа LDAP или IAM (Oracle Identity and Access Management), кроссплатформенные.
• Распределенная авторизация — для конечных точек сервисов, чтобы редактировать данные.
  Например, расширение Open Policy Agent (OPA) для размещения точки принятия решения по политике (PDP) в контейнер или кластер K8S, где обрабатывается конечная точка микросервиса. В качестве LDAP/IAM может использоваться любой сервис, поддерживающий JWT.
• Детерминированное маскирование — чтобы надежно и согласованно скрывать данные PII.

Добиться безопасной работы любой ИТ-системы бывает затруднительно, когда же требуется обеспечить высокую безопасность в распределенной системе, сложность только возрастает. Однако все это решаемые проблемы.

Основным компонентом Data Mesh является понятие распределения владения и ответственности. Рекомендуется отдавать владение продуктами данных и доменами данных людям, которые в организации находятся ближе всего к данным. На практике это может соответствовать исходным данным (например, источникам двоичных данных, таким как операционные системы записи или приложения) или аналитическим данным (например, обычно составным или агрегированным данным, отформатированным для простоты использования потребителями данных). В обоих случаях источники и потребители данных часто соответствуют коммерческим подразделениям компании, а не ИТ-организациям.

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

В Data Mesh функциональное разделение доменов данных имеет повышенный приоритет. Различные методологии разделения данных для моделирования доменов можно адаптировать под архитектуру Data Mesh, включая моделирование классического хранилища данных (такого как Kimball и Inmon) или моделирование хранилища данных типа Data Vault, однако в настоящее время в архитектуре сетки данных чаще всего используют метод предметно-ориентированного проектирования (domain-driven design, DDD). Метод DDD возник в сфере функционального разделения микросервисов, а теперь его также применяют в контексте Data Mesh.

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

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

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

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

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

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

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

• Книга событий общего назначения, такая как Kafka или Pulsar
• Книга событий данных — распределенные CDC/инструменты репликации.
• Промежуточное ПО для обмена сообщениями, в том числе ESB, MQ, JMS и AQ.
• Книга для блокчейна — для безопасных, неизменяемых, многосторонних транзакций.

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

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

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

Некоторые другие важные атрибуты Data Mesh:

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

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

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

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

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

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

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

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

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

• Логические транзакции с очень низкой задержкой (кроссплатформенные)
• Поддержка ACID гарантирует получение правильных данных
• Широкий спектр активности, двунаравленность и разрешение конфликтов

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

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

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

• Между микросервисами в контексте
• Между микросервисами и между контекстами
• Из монолита в микросервис и наоборот

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

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

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

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

• Связывание событий устройств в реальном мире с ИТ-системами
• Интеграция бизнес-процессов в ERP-системах
• Соотнесение операционных баз данных с хранилищами данных для аналитики

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

В хранилищах данных для аналитики могут быть киоски данных, другие хранилища данных, кубы OLAP, озера данных и озерные хранилища данных.

Вообще, существует только два способа внесения данных в эти хранилища данных для аналитики:

• Загрузка пакетов/микропакетов — планировщик по времени.
• Получение потоков — непрерывная загрузка событий данных.

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

• События данных из баз данных или хранилищ данных
• События устройств от телеметрии физических устройств
• Ведение журналов событий приложений или бизнес-транзакции

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

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

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

• Обнаружение и подготовка данных с самоуправлением
• Управление ресурсами данных в разных доменах
• Подготовка и преобразование данных в требуемые форматы продуктов данных
• Проверка данных по политике, которая гарантирует их согласованность

Эти конвейеры данных должны иметь возможность работать с разными физическими хранилищами данных (такими как киоски, хранилища или озера) или как «магазинный поток данных» в платформах аналитических данных, поддерживающих потоковые данные, таких как Apache Spark и другие технологии озерных хранилищ.

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

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

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

• Анализ простого потока событий (веб-событий)
• Мониторинг бизнес-действий (события SOAP/REST)
• Обработка сложных событий (многопотоковая корреляция)
• Анализ событий данных (по транзакциям БД/ACID)

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

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