Давайте рассмотрим, как шаблон «Неизменяемый журнал изменений/аудита» используется корпоративной сеткой данных.

Неизменяемый журнал изменений/аудита: базовый шаблон сетки данных

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

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

  • Принципы Data Mesh (более подробная информация доступна здесь)
  • Архитектура Data Mesh (более подробная информация доступна здесь)
  • Паттерны Data Mesh (более подробная информация доступна здесь)

Полный список статей по базовым шаблонам Data Mesh приведен в конце этой статьи.

Резюме шаблона

Шаблон Immutable Change/Audit Log отслеживает происхождение данных в Enterprise Data Mesh. Это достигается за счет создания журнала изменений данных, который обычно подается из системы Change Data Capture (CDC) Enterprise Data Mesh, который можно агрегировать, анализировать и нарезать для поддержки потребностей аудита и федеративного управления.

Контекст и бизнес-проблема

Большинство крупных предприятий сбиты с толку, казалось бы, простыми проблемами. Откуда берутся мои данные? Что с ним произошло, когда он переместился из одного приложения и базы данных в другое? И кто внес изменения в данные?

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

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

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

Решение

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

Журнал неизменяемых изменений/аудита прослушивает (в магистрали потоковой передачи событий) события изменения данных. Он уведомляется о событиях изменения данных и автоматически фиксирует изменения в блоке данных (используя шаблон Change Data Capture), отображает изменение блока данных (и метаданные) как событие происхождения данных, сохраняет событие в постоянный журнал только для добавления и публикует событие происхождения данных (используя шаблон Event Streaming Backbone), чтобы другие заинтересованные нижестоящие стороны могли использовать события происхождения данных.

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

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

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

И если первичным объектом в источнике событий является событие, а не блок данных, на который оно воздействовало, основным объектом в шаблоне Immutable Change/Log являются как данные, блок и событие, которое на него воздействовало.

Как это работает

  1. Change Data Capture (CDC) фиксирует изменения данных из журнала транзакций базы данных из операционной, вовлеченной или аналитической базы данных, форматирует их как события и публикует события (используя Event Streaming Backbone) для использования нижестоящими системами.
  2. Одной из нижестоящих служб является «Микрослужба агрегации», которая получает событие изменения данных CDC и создает запись о происхождении данных, которая сопоставляет «до» (до изменения данных) и «после» (изменение данных). конечное состояние данных) изображения данных и событие, вызвавшее изменение данных.
  3. Запись о происхождении данных хранится в неизменном журнале изменений/аудита; Обратите внимание, что «неизменная» характеристика важна — обычно она реализуется как журнал «только для добавления» и, следовательно, обеспечивает постоянную и неизменяемую историческую запись жизненного цикла единицы данных.
  4. Записи о происхождении данных направляются в Каталог продуктов корпоративных данных; Каталог позволяет осуществлять поиск и визуализацию записей о происхождении данных (а также многих других атрибутов) по требованию.
  5. Реестр схем предоставляет определения для всех событий, а также записи о происхождении данных (и содержащуюся в них информацию о событиях), предоставляя необходимую структуру для проведения сложного анализа происхождения данных.
  6. Пользователи по всему предприятию — специалисты по обработке и анализу данных, члены группы управления и разработчики — могут использовать записи о происхождении данных по мере необходимости.

Сценарии использования

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

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

Ландшафт торговца

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

  • Реестр схем: поскольку этот компонент предоставляет определение (обычно схема JSON или AVRO) событий, он тесно связан с магистралью потоковой передачи событий. У меня был хороший опыт работы с Confluent версией реестра Kafka Schema Registry.
  • Каталог продуктов корпоративных данных. Пока что я не нашел конкретного поставщика, который занимался бы этим, и мне пришлось создавать собственные системы, связывающие реестр схем, микросервисы агрегации, визуализацию событий и каталог с возможностью поиска. Имея это в виду, я обычно начинаю с гибкого статического сервиса управления контентом с открытым исходным кодом, такого как Docusaurus или Hugo, который поставляется с надежными функциями поиска и хранения контента, а затем добавляет возможности агрегации и визуализации. Я понимаю, что, вероятно, есть более сложные решения, но это работает хорошо и может быть быстро реализовано.
  • Неизменяемый журнал: здесь подойдет любая надежная база данных, которая может хранить неструктурированные данные; Кроме того, хотя эта возможность отличается от источника событий, постоянный журнал, который ведет Kafka, может быть основой для неизменного журнала изменений/аудита, хотя, вероятно, потребуется реализовать дополнительные возможности и конфигурацию.

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

Другие статьи из этой серии

Полный цикл статей из этой серии об основных шаблонах Data Mesh приведен ниже.

  • Шаблон сбора данных об изменениях (CDC), который отслеживает изменения в базе данных и фиксирует их как события (доступно здесь).
  • Шаблон Event Streaming Backbone, используемый CDC и другими приложениями для публикации и подписки/получения событий в Enterprise Data Mesh (доступно здесь).
  • Шаблон неизменяемого журнала изменений/аудита, который сохраняет журналы и отслеживает происхождение данных в корпоративной сетке данных для будущего аудита и управления (эта статья).
  • Шаблон корпоративного каталога продуктов данных, представляющий собой каталог/репозиторий, содержащий метаданные о продуктах данных в корпоративной сетке данных (скоро).

Заключительные мысли

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

***

Все изображения в этом документе, если не указано иное, были созданы Эриком Брода (автором этой статьи). Все значки, используемые в изображениях, являются стандартными значками PowerPoint и не защищены авторскими правами.