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

Существует два основных типа данных: операционные — поддерживают транзакции, обеспечивают работу продукта или системы; аналитические — предназначены для хранения детализированных и агрегированных исторических данных, обработки, прогнозирования и моделирования. Первые передаются между продуктами: например, кинотеатр KION отправляет информацию в книжную библиотеку «Строки». Для операционных данных есть интеграционные платформы с манифестами подписки и публикации, которые по сути являются дата-контрактами. Однако возникает вопрос работы с аналитическими данными: как быть с интеграциями (загрузками данных) для построения, например, витрин в хранилище?

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

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

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

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

Дата-контракты заключаются только для тех данных, которые являются дата-сервисами с определенными свойствами. Данные должны быть видимыми и доступными, а для них настроены DQ-контроли [1].

Для достижения перечисленных целей требовалось автоматизировать дата-контракты, связать их с Каталогом данных и с инструментом по мониторингу качества данных. За основу был выбран стандарт Data Contract — спецификация контракта данных, определяющая формат YAML (YAML Ain't Markup Language, удобный для чтения человеком механизм обмена данными) для описания атрибутов наборов данных. Стандарт не зависит от платформы данных и может использоваться, например, с AWS S3, Google BigQuery, Azure, Databricks и Snowflake. Спецификация контракта — это открытая инициатива по определению общего формата контракта данных, соответствующая соглашениям OpenAPI и AsyncAPI. Этот стандарт был дополнен необходимыми нам специфичными полями.

В структуре дата-контракта мы выделяем семь блоков.

Описание данных. Блок включает в себя метаданные, описание объектов данных, тип обновления (инкрементальная загрузка или полная), время готовности и глубину хранения. Это позволяет потребителям понимать, что они могут получить и как долго данные будут доступны.

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

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

Информация о доступе к источнику. Описание порядка получения потребителем доступа к данным, включая возможные технические требования и параметры подключения.

Ограничения использования. Блок включает допустимое количество запросов за интервал времени, максимальное число открытых сессий и другие параметры, например, время регламентного окна.

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

Срок уведомления о планируемых изменениях. Это важный аспект долгосрочных отношений между источником и потребителями. Уведомления могут быть критичные: изменения в структуре источника, требующие времени на адаптацию потребителей, например переезд на новый адрес или смена технологии — срок уведомления в этом случае обычно 10–14 рабочих дней. О некритичных изменениях формата, ограничений или названий обычно сообщают за пять рабочих дней (смена технологии требует более длительной проработки на стороне потребителя).

Дата-контракт может включать один или несколько объектов данных. Его состав определяется первым потребителем — следующие соглашаются либо предлагают добавления.

По списку объектов из Каталога данных в дата-контракте фиксируются метаданные, их описание и тип обновления: инкрементальная или полная загрузка, глубина хранения, время готовности (потребители понимают, когда забирать и получать данные). Контракт фиксируется с обеих сторон.

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

Дата-контракты имеют ряд преимуществ. Их удобно заполнять при настройке интеграции — файл в YAML/UI позволяет поддерживать актуальность контракта в релизном цикле. Согласование дата-контракта происходит непосредственно в месте его составления — в UI-форме с вовлечением ответственных, указанных в карточке схемы метаданных в Каталоге данных. Имеется связь с DQ-контролями и со схемой метаданных, которую можно отслеживать с помощью Каталога данных, а у объектов в нем тоже появляется отметка наличия по ним дата-контракта. Наконец, имеется возможность отслеживать изменения по схеме метаданных.

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

Сервис данных должен удовлетворять трем базовым требованиям.

  • Актуальность данных в соответствии с установленными правилами обновления. Если в объекте нет календарной бизнес-даты, например, это справочник регионов, то допускается проверка актуальности по технической дате создания или обновления данных. Эту проверку можно пропустить, если бизнес- или техническую дату невозможно добавить.
  • Отсутствие дублей. В объект нужно прописать бизнес-ключ — одно или несколько полей, позволяющих однозначно определить запись. Каждому бизнес-ключу должна соответствовать лишь одна запись в объекте. Например, если говорить про курсы валют, то бизнес-ключом будет связка полей «Код валюты» и «Дата». Не рекомендуется в бизнес-ключ добавлять технические идентификаторы, которые формируются автоматически и не могут быть задублированы. Было бы ошибочно добавить в бизнес-ключ технический идентификатор записи курса, который система генерирует автоматически.
  • Полнота. Данные должны быть без лишних пропусков в полях — требуется заполнять все атрибуты, которые несут ценность по бизнес-логике. Как минимум, необходимо проверять на актуальность атрибуты бизнес-ключа и календарной даты.

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

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

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

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

***

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

Литература

1. Что такое Data Service и почему он может быть вам полезен. URL: Экосистема дата-контракта

Дата-контракты заключаются только для тех данных, которые являются дата-сервисами с определенными свойствами. Данные должны быть видимыми и доступными, а для них настроены DQ-контроли [1].

Для достижения перечисленных целей требовалось автоматизировать дата-контракты, связать их с Каталогом данных и с инструментом по мониторингу качества данных. За основу был выбран стандарт Data Contracthttps://datacontract.com — спецификация контракта данных, определяющая формат YAML (YAML Ain't Markup Language, удобный для чтения человеком механизм обмена данными) для описания атрибутов наборов данных. Стандарт не зависит от платформы данных и может использоваться, например, с AWS S3, Google BigQuery, Azure, Databricks и Snowflake. Спецификация контракта — это открытая инициатива по определению общего формата контракта данных, соответствующая соглашениям OpenAPI и AsyncAPI. Этот стандарт был дополнен необходимыми нам специфичными полями.

В структуре дата-контракта мы выделяем семь блоков.

Описание данных. Блок включает в себя метаданные, описание объектов данных, тип обновления (инкрементальная загрузка или полная), время готовности и глубину хранения. Это позволяет потребителям понимать, что они могут получить и как долго данные будут доступны.

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

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

Информация о доступе к источнику. Описание порядка получения потребителем доступа к данным, включая возможные технические требования и параметры подключения.

Ограничения использования. Блок включает допустимое количество запросов за интервал времени, максимальное число открытых сессий и другие параметры, например, время регламентного окна.

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

Срок уведомления о планируемых изменениях. Это важный аспект долгосрочных отношений между источником и потребителями. Уведомления могут быть критичные: изменения в структуре источника, требующие времени на адаптацию потребителей, например переезд на новый адрес или смена технологии — срок уведомления в этом случае обычно 10–14 рабочих дней. О некритичных изменениях формата, ограничений или названий обычно сообщают за пять рабочих дней (смена технологии требует более длительной проработки на стороне потребителя).

Дата-контракт может включать один или несколько объектов данных.datacontract.com/examples/covid-cases/datacontract.html%3F Его состав определяется первым потребителем — следующие соглашаются либо предлагают добавления.

По списку объектов из Каталога данных в дата-контракте фиксируются метаданные, их описание и тип обновления: инкрементальная или полная загрузка, глубина хранения, время готовности (потребители понимают, когда забирать и получать данные). Контракт фиксируется с обеих сторон.

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

Дата-контракты имеют ряд преимуществ. Их удобно заполнять при настройке интеграции — файл в YAML/UI позволяет поддерживать актуальность контракта в релизном цикле. Согласование дата-контракта происходит непосредственно в месте его составления — в UI-форме с вовлечением ответственных, указанных в карточке схемы метаданных в Каталоге данных. Имеется связь с DQ-контролями и со схемой метаданных, которую можно отслеживать с помощью Каталога данных, а у объектов в нем тоже появляется отметка наличия по ним дата-контракта. Наконец, имеется возможность отслеживать изменения по схеме метаданных.

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

Сервис данных должен удовлетворять трем базовым требованиям.https://habr.com/ru/companies/ru_mts/articles/806967

Актуальность данных в соответствии с установленными правилами обновления. Если в объекте нет календарной бизнес-даты, например, это справочник регионов, то допускается проверка актуальности по технической дате создания или обновления данных. Эту проверку можно пропустить, если бизнес- или техническую дату невозможно добавить.

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

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

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

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

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

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

***

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

Литература

1. Что такое Data Service и почему он может быть вам полезен. URL: https://habr.com/ru/companies/ru_mts/articles/806967 (дата обращения 31.12.2024).

Патрисия Кошман (pnkoshman@mts.ru) — руководитель группы по управлению данными и эксперт по управлению метаданными, Аксинья Ласкова (aslaskova@mts.ru) — эксперт по практикам качества данных, МТС (Москва). Статья подготовлена на основе материалов выступления на форуме «Управление данными 2024».">https://habr.com/ru/companies/ru_mts/articles/806967 (дата обращения 31.12.2024).

Патрисия Кошман (pnkoshman@mts.ru) — руководитель группы по управлению данными и эксперт по управлению метаданными, Аксинья Ласкова (aslaskova@mts.ru) — эксперт по практикам качества данных, МТС (Москва). Статья подготовлена на основе материалов выступления на форуме «Управление данными 2024».