Всем привет! На связи Патрисия Кошман, руководитель группы по управлению данными и эксперт по управлению метаданными, и Аксинья Ласкова, эксперт по практикам качества данных из МТС.

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

Проблема взаимодействия источника и потребителя данных

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

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

Существует два основных типа данных:

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

• Аналитические: предназначены для хранения детализированных и агрегированных исторических данных, обработки, прогнозирования и моделирования.

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

История создания дата-контрактов

Проблема такого взаимодействия не нова. Несколько лет назад мы в МТС работали в два шага. Сначала делали страницу в Confluence с подробным описанием передаваемых данных. Затем запускали на согласование соглашение в текстовом формате, которое проходило через систему электронного документооборота (СЭД).

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

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

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

Новый подход

Мы поставили перед собой несколько целей при внедрении дата-контрактов:

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

• объекты, указанные в них, мониторятся на актуальность структуры и качество данных.

• есть четкая связь с реальными процессами интеграции и метаданными.

Мы заключаем дата-контракты только для тех данных, которые являются дата-сервисами с определенными свойствами. Данные должны быть видимыми и доступными, на них настроены DQ-контроли. Подробности есть в нашем посте «Что такое Data Service и почему он может быть вам полезен», где мы детально рассматриваем требования к источникам данных и механизмы обеспечения их качества.

Наше видение дата-контрактов

Вместе с коллегами из DataOps Platform мы стали думать, как автоматизировать дата-контракты и связать их с Каталогом данных и инструментом по мониторингу качества данных.

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

Мы выделяем семь блоков:

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

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

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

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

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

6. Срок уведомления о планируемых изменениях
   Это важный аспект долгосрочных отношений между источником и потребителями. Мы делим уведомления на два типа:
   - Критичные: к ним относятся изменения в структуре источника, которые требуют времени на адаптацию потребителей. Например, это переезд на новый адрес или смена технологии. Срок уведомления в этом случае обычно 10–14 рабочих дней.
   - Некритичные: изменение формата, ограничений или названия полей. О них обычно сообщают за 5 рабочих дней.

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

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

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

Преимущества дата-контрактов

• Их удобно заполнять при настройке интеграции: дата-контракт представляет собой Yaml-файл/UI-форму, что позволяет поддерживать его актуальность в релизном цикле.

• Согласование идет прямо в месте составления: в UI-форме с вовлечением ответственных, указанных в карточке схемы метаданных в Каталоге данных.

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

• И конечно же, возможность следить по схеме метаданных, были изменения или нет.

Права и обязанности источника и потребителей

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

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

Мы сформулировали три базовых требования для сервиса данных:

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

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

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

Подробно об этих требованиях мы говорили в статье о data-service.

Что мы получили от внедрения дата-контрактов

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

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

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

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

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

На этом у нас все, мы готовы ответить на ваши вопросы по дата-контрактам.