Дата-контракты: Новый подход к управлению данными

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

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

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

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

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

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

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

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

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

🔐 Новый подход: дата-контракты

Мы поставили перед собой несколько ключевых задач:

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

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

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

Важно отметить, что мы заключаем дата-контракты не для всех таблиц, а только для тех данных, которые являются дата-сервисами с определенными свойствами. Если коротко, то источник данных должен быть подключен к Каталогу данных, чтобы данные стали видимыми, на сами данные должны быть настроены DQ-контроли, чтобы обеспечить качество данных, и данные должны быть доступны, то есть должно быть обозначено как получить к ним доступ. ▎Если подводить итог

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

Если эта тема интересна – то поставь 🐳, и мы рассмотрим детально методологию дата-контракта и способы автоматизации в следующих постах.