Давайте рассмотрим, как шаблон «Неизменяемый журнал изменений/аудита» используется корпоративной сеткой данных.
Неизменяемый журнал изменений/аудита: базовый шаблон сетки данных
В этой статье обсуждается неизменяемый журнал изменений/аудита, и она является третьей в серии статей о фундаментальных шаблонах сетки данных. Я подытожу назначение шаблона, область его проблем и бизнес-контекст, принципы работы шаблона и поставщиков-кандидатов, поддерживающих этот шаблон.
В этой статье предполагается, что вы хорошо разбираетесь в 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 являются как данные, блок и событие, которое на него воздействовало.
Как это работает
- Change Data Capture (CDC) фиксирует изменения данных из журнала транзакций базы данных из операционной, вовлеченной или аналитической базы данных, форматирует их как события и публикует события (используя Event Streaming Backbone) для использования нижестоящими системами.
- Одной из нижестоящих служб является «Микрослужба агрегации», которая получает событие изменения данных CDC и создает запись о происхождении данных, которая сопоставляет «до» (до изменения данных) и «после» (изменение данных). конечное состояние данных) изображения данных и событие, вызвавшее изменение данных.
- Запись о происхождении данных хранится в неизменном журнале изменений/аудита; Обратите внимание, что «неизменная» характеристика важна — обычно она реализуется как журнал «только для добавления» и, следовательно, обеспечивает постоянную и неизменяемую историческую запись жизненного цикла единицы данных.
- Записи о происхождении данных направляются в Каталог продуктов корпоративных данных; Каталог позволяет осуществлять поиск и визуализацию записей о происхождении данных (а также многих других атрибутов) по требованию.
- Реестр схем предоставляет определения для всех событий, а также записи о происхождении данных (и содержащуюся в них информацию о событиях), предоставляя необходимую структуру для проведения сложного анализа происхождения данных.
- Пользователи по всему предприятию — специалисты по обработке и анализу данных, члены группы управления и разработчики — могут использовать записи о происхождении данных по мере необходимости.
Сценарии использования
Специалисты по данным используют этот шаблон, чтобы понять происхождение обучающих данных, чтобы обеспечить воспроизводимость, отслеживаемость и проверяемость своих моделей, что требуется, поскольку ИИ / машинное обучение поддерживает принятие все более важных решений.
Команды по управлению данными также используют этот шаблон для понимания происхождения данных и связанных с ними моделей потребления в масштабах предприятия.
Ландшафт торговца
Существует несколько компонентов, которые взаимодействуют для захвата, каталогизации и визуализации записей о происхождении данных, хранящихся в шаблоне журнала неизменяемых изменений/аудита:
- Реестр схем: поскольку этот компонент предоставляет определение (обычно схема JSON или AVRO) событий, он тесно связан с магистралью потоковой передачи событий. У меня был хороший опыт работы с Confluent версией реестра Kafka Schema Registry.
- Каталог продуктов корпоративных данных. Пока что я не нашел конкретного поставщика, который занимался бы этим, и мне пришлось создавать собственные системы, связывающие реестр схем, микросервисы агрегации, визуализацию событий и каталог с возможностью поиска. Имея это в виду, я обычно начинаю с гибкого статического сервиса управления контентом с открытым исходным кодом, такого как Docusaurus или Hugo, который поставляется с надежными функциями поиска и хранения контента, а затем добавляет возможности агрегации и визуализации. Я понимаю, что, вероятно, есть более сложные решения, но это работает хорошо и может быть быстро реализовано.
- Неизменяемый журнал: здесь подойдет любая надежная база данных, которая может хранить неструктурированные данные; Кроме того, хотя эта возможность отличается от источника событий, постоянный журнал, который ведет Kafka, может быть основой для неизменного журнала изменений/аудита, хотя, вероятно, потребуется реализовать дополнительные возможности и конфигурацию.
Полное раскрытие информации: у меня нет финансовой заинтересованности в том, чтобы рекомендовать какой-либо из вышеперечисленных продуктов — я выделяю эти продукты, потому что у меня есть некоторый опыт работы с ними, и они хорошо себя зарекомендовали.
Другие статьи из этой серии
Полный цикл статей из этой серии об основных шаблонах Data Mesh приведен ниже.
- Шаблон сбора данных об изменениях (CDC), который отслеживает изменения в базе данных и фиксирует их как события (доступно здесь).
- Шаблон Event Streaming Backbone, используемый CDC и другими приложениями для публикации и подписки/получения событий в Enterprise Data Mesh (доступно здесь).
- Шаблон неизменяемого журнала изменений/аудита, который сохраняет журналы и отслеживает происхождение данных в корпоративной сетке данных для будущего аудита и управления (эта статья).
- Шаблон корпоративного каталога продуктов данных, представляющий собой каталог/репозиторий, содержащий метаданные о продуктах данных в корпоративной сетке данных (скоро).
Заключительные мысли
Неизменяемый журнал изменений/аудита — это базовый шаблон сетки данных. В сочетании с реестром схем и каталогом корпоративных данных он обеспечивает базовую возможность для реализации линии передачи данных, требуемой регулирующими органами, аудиторами и специалистами по управлению данными, при реализации основного принципа Data Mesh «федеративного управления вычислениями»).
***
Все изображения в этом документе, если не указано иное, были созданы Эриком Брода (автором этой статьи). Все значки, используемые в изображениях, являются стандартными значками PowerPoint и не защищены авторскими правами.