Дата-контракты: как мы научили жить дружно источники и потребителей данных
Всем привет! На связи Патрисия Кошман, руководитель группы по управлению данными и эксперт по управлению метаданными, и Аксинья Ласкова, эксперт по практикам качества данных из МТС.
В нашей компании порядка 400 разных продуктов, и мы часто сталкиваемся с проблемой синхронизации данных между ними. Легкое изменение в структуре источника может привести к тому, что сломается сразу несколько систем. Один из вариантов их синхронизации — дата-контракты. Они позволяют достичь взаимопонимания между участниками обмена данных, обеспечить их правильную передачу и интерпретацию. В этом посте мы расскажем, как мы пришли к идее внедрения дата-контрактов, что нам это дало и как их можно автоматизировать.
Проблема взаимодействия источника и потребителя данных
Представьте себе ситуацию: тимлид обращается к разработчику с просьбой изменить типы колонок в таблице из-за новых бизнес-требований. И получает замечательный ответ: «Отлично! Как раз проверим, кто с ней работает». В этот момент пользователи выглядят так:
В мире больших данных один и тот же продукт используется разными командами, и любое изменение может быть для них крайне неприятно. Например, удаление в источнике колонки с полом повлияет на работу рекомендательных систем, которые используют конечную витрину или отчет с этими данными.
Существует два основных типа данных:
Операционные: поддерживают транзакции, обеспечивают работу продукта или системы.
Аналитические: предназначены для хранения детализированных и агрегированных исторических данных, обработки, прогнозирования и моделирования.
Первые передаются между продуктами: например, кинотеатр KION отправляет информацию в книжную библиотеку «Строки». Для них есть интеграционные платформы с манифестами подписки и публикации, которые по сути являются дата-контрактами. Однако встает вопрос работы с аналитическими данными: как быть с интеграциями для построения, например, витрин в хранилище?
История создания дата-контрактов
Проблема такого взаимодействия не нова. Несколько лет назад мы в МТС работали в два шага. Сначала делали страницу в Confluence с подробным описанием передаваемых данных. Затем запускали на согласование соглашение в текстовом формате, которое проходило через систему электронного документооборота (СЭД).
Однако такой подход имел свои недостатки. Когда соглашение подписывалось, уведомления о внесенных правках получала вся IT-команда и нельзя было точно определить, касается это письмо тебя или кого-то еще. И само согласование затягивалось из-за большого числа участников, многие из которых не понимали цель соглашения, так как оно было оторвано от реальных процессов интеграции и метаданных.
При больших объемах данных любое обновление условий и семантики обмена должно отслеживаться. Однако на практике это не работало. Отсутствие верификации изменений метаданных и информации об отправке уведомлений приводило к непредсказуемым последствиям. Например, могли сломаться витрины, а расследование таких инцидентов занимает много времени.
С ростом числа производителей и пользователей данных появляется необходимость новых правил работы. Мы решили применить дата-контракты: изучили существующие решения и адаптировали их под наши задачи.
Новый подход
Мы поставили перед собой несколько целей при внедрении дата-контрактов:
их формирование занимает минимум времени и должно быть доступным разработчику в момент интеграции.
объекты, указанные в них, мониторятся на актуальность структуры и качество данных.
есть четкая связь с реальными процессами интеграции и метаданными.
Мы заключаем дата-контракты только для тех данных, которые являются дата-сервисами с определенными свойствами. Данные должны быть видимыми и доступными, на них настроены DQ-контроли. Подробности есть в нашем посте «Что такое Data Service и почему он может быть вам полезен», где мы детально рассматриваем требования к источникам данных и механизмы обеспечения их качества.
Наше видение дата-контрактов
Вместе с коллегами из DataOps Platform мы стали думать, как автоматизировать дата-контракты и связать их с Каталогом данных и инструментом по мониторингу качества данных.
За основу разработки нашего сервиса взяли стандарт Data Contract и дополнили его необходимыми нам специфичными полями. Сразу отмечу, что эту схему мы сделали под свои задачи и возможности — у вас может быть другой состав и количество атрибутов.
Мы выделяем семь блоков:
Описание данных
Этот блок включает в себя метаданные, описание объектов данных, тип обновления (инкрементальная загрузка или полная), время готовности и глубину хранения. Это позволяет потребителям понимать, что они могут получить и как долго данные будут доступны.Контакты с обеих сторон
Включает сведения о контактных лицах и группах обслуживания/эксплуатации, отвечающих за данные с обеих сторон. Это позволяет эффективно наладить коммуникацию и поддержку.Зафиксированные требования и проверки качества данных
Этот блок охватывает требования к актуальности, отсутствию дублей, полноте и другим аспектам качества. Мы предлагаем использовать шаблоны для их автоматизации.Информация о доступе к источнику
Описывает, как потребители могут получить доступ к данным, включая возможные технические требования и параметры подключения.Информация о доступе к источнику
Описывает, как потребители могут получить доступ к данным, включая возможные технические требования и параметры подключения.Категория информационной безопасности
Уровень безопасности данных определяется по требованиям к защите информации, что позволяет управлять рисками и соответствовать нормативным актам.Срок уведомления о планируемых изменениях
Это важный аспект долгосрочных отношений между источником и потребителями. Мы делим уведомления на два типа:
— Критичные: к ним относятся изменения в структуре источника, которые требуют времени на адаптацию потребителей. Например, это переезд на новый адрес или смена технологии. Срок уведомления в этом случае обычно 10–14 рабочих дней.
Некритичные: изменение формата, ограничений или названия полей. О них обычно сообщают за 5 рабочих дней.
Дата-контракт может включать один или несколько объектов данных. Его состав определяется первым потребителем. Следующие или соглашаются, или предлагают что-нибудь добавить.
По списку объектов из Каталога данных в дата-контракте фиксируются сами метаданные, их описание и тип обновления: инкрементальная загрузка или полная, глубина хранения, время готовности (так потребители понимают, когда забирать и получать данные). Затем контракт фиксируется с обеих сторон.
Контакты источника автоматически берутся из Каталога, а у потребителей заполняются вручную. По умолчанию также мы указываем продукт, контактное лицо и группу, ответственную за поддержку.
Преимущества дата-контрактов
Их удобно заполнять при настройке интеграции: дата-контракт представляет собой Yaml-файл/UI-форму, что позволяет поддерживать его актуальность в релизном цикле.
Согласование идет прямо в месте составления: в UI-форме с вовлечением ответственных, указанных в карточке схемы метаданных в Каталоге данных.
Связь с DQ-контролями и со схемой метаданных, которую мы отслеживаем с помощью Каталога данных. У объектов в нем тоже появляется отметка наличия по ним дата-контракта.
И конечно же, возможность следить по схеме метаданных, были изменения или нет.
Права и обязанности источника и потребителей
Мы живем во время agile, поэтому, скорее всего, источник будет периодически менять структуру данных. Он имеет на это полное право, но должен в рамках дата-контракта уведомлять потребителей о планируемых изменениях в объектах и, конечно же, следить за качеством данных.
Потребители могут подписаться на существующий дата-контракт, тем самым заявив, что на них изменения тоже повлияют и необходимо уведомлять и их. Если у потребителя есть дополнительные требования к качеству данных, он также может заявить о них — источник рассмотрит их валидность и возможность автоматизации и включения в дата-контракт. Если потребитель самостоятельно выявит ошибку в данных, то он обязан зарегистрировать инцидент на источник, чтобы тот разобрался и предпринял нужные действия.
Мы сформулировали три базовых требования для сервиса данных:
Объект должен содержать актуальные данные в соответствии с установленными правилами обновления. Если в нем нет бизнес-даты, например, это справочник регионов, то допускается проверка актуальности по технической дате создания или обновления данных. Эту проверку можно пропустить, если бизнес- или техническую дату невозможно добавить.
Отсутствие дублей. В объект нужно прописать бизнес-ключ: одно или несколько полей, которые позволяют однозначно определить запись. Не должно быть более одной записи в объекте по бизнес-ключу. Например, если говорить про курсы валют, то бизнес-ключом будет являться связка полей «Код валюты» и «Дата». Мы также не рекомендуем добавлять в него технические идентификаторы, которые формируются автоматически и ни при каких условиях не могут быть задублированы. Возвращаясь к курсам валют, мы бы ошиблись, добавив в бизнес-ключ ИД записи курса, который генерирует система автоматически.
Полнота. Данные должны быть без лишних пропусков в полях. Все атрибуты, которые по бизнес-логике несут ценность, нужно заполнять. Как минимум необходимо проверять на актуальность атрибуты бизнес-ключа и даты.
Подробно об этих требованиях мы говорили в статье о data-service.
Что мы получили от внедрения дата-контрактов
Сейчас для нас это важный инструмент управления данными. Они минимизируют риски, связанные с изменениями в структуре данных, и обеспечивают четкость взаимодействия между поставщиками и потребителями. Благодаря дата-контрактам мы получили:
Контроль распространения и использования данных: так мы отслеживаем поставщиков и потребителей, формализуем ожидания и требования — это ключевой аспект, который повышает доверие к данным. Оценка качества также важна для обеспечения надежности: так мы видим наиболее востребованные данные.
Наладили коллективное использование данных: мы смогли перейти к децентрализованной модели (data mesh) и улучшили контролируемость ландшафта, сохранив общую архитектуру. Продукты экосистемы сами отвечают за свои данные, понимают, кто и зачем пользуется ими и какие данные наиболее востребованы в других продуктах.
Повысили качество данных: без базового контроля своих данных источник не сможет опубликовать дата-контракт, а узнавать о снижении уровня качества данных будет не только источник, но и его потребители.
Определили владельцев данных: если источник не может уведомить об изменениях в данных, то, скорее всего, он ими не владеет.
На этом у нас все, мы готовы ответить на ваши вопросы по дата-контрактам.
