datahandyman 3 мая в 18:15

Data сontract: давайте попробуем договориться

Средний

10 мин

3.7K

Блог компании ДомкликPython*Data Engineering*

«Единственное, что есть в нашей жизни постоянного, — это изменения» (цитата из книги «Конвоиры зари» Дона Уинслоу). Фраза чуть отредактирована, но не об этом пойдёт речь. Любые изменения касающиеся условий и семантики обмена данными должны явно отслеживаться. На практике зачастую это работает вот так:

— Санечка, нужно поменять тип колонки в таблице. Как думаешь, это заденет кого‑нибудь?
— Дядь, меняй! Проверим как раз, кто этой таблицей пользуется.

P.S. Ситуация вымышленная, любые совпадения случайны.

Нужна какая-то отправная точка! Как раз тут и появляются контракты данных для соблюдения сторонами условий взаимодействия, чтобы исключить какие-либо неопределённости. Но сам data-контракт в разных сценариях может трактоваться по-разному.

Тема горячая, и даже, сказал бы, наболевшая, что говорит о большом количестве её упоминаний в data-мире. Контроль согласованности обмена данными между поставщиком и потребителем всегда был и остаётся интересным вопросом. Стремительный темп роста количества производителей и пользователей данных начинает диктовать новые правила для работы с ними. И, разумеется, любой уважающий себя data-инженер хочет добиться унификации работы с данными, но при этом сохранить совместимость процессов принимающей и отдающей стороны. Идея контрактов данных очевидна и на рынке уже не нова. А чтобы разобраться в этой теме, попробуем ответить на несколько вопросов:

Что такое data contract?
Есть ли единый стандарт?
Может быть, вы уже используете контракты данных?
Когда их нужно использовать?
Как мы используем контракт данных?

Что такое контракт данных?

Data contract — это соглашение между поставщиком и потребителем об условиях обмена данными. В качестве сторон взаимодействия выступают владельцы и аналитики данных, data-инженеры, BI-аналитики, исследователи данных (data scientists), разработчики, сервисы, ERP-, CRM-системы и другие заинтересованные стороны. Имеется в виду не только взаимодействие пользователей по какому‑либо data‑SLA (Service Level Agreement), но и прозрачная работа самих продуктов данных. Концепция встраивания контрактов в data pipeline обусловлена обеспечением целостности данных. Сам же контракт может существовать в виде описания всей необходимой информации на страничке в Confluence, но чаще всего эта история не поддерживается. Многое зависит от культуры работы с данными в компании.

Обычно спецификация контракта данных включает в себя:

Общую информацию.
Модель данных.
Биллинговую информацию.
Проверки качества данных.
И другое опционально.

Информация необходима для соблюдения регламентов работы с данными. Способы реализации контракта индивидуальны в определённых ситуациях. Йохен Крист и доктор Саймон Харрер представили свой вариант спецификации Data Contract. Коллеги проделали огромную работу и реализовали инструмент для работы с контрактами Data Сontract CLI. Проект набирает обороты, но начинает ли он потихоньку закрывать эту нишу? Постараемся ответить на этот вопрос позже. Пока отметим, что на рынке это не единственный продукт для работы с контрактами. Узнать чуть больше можно по ссылкам, а здесь мы выделим лишь несколько важных аспектов:

Есть версионирование контрактов данных.
Data quality по спецификациям Soda, Monte Carlo, Great Expectations и др.
Генерация схемы для спецификации на основе существующих данных, например на основе DDL.
Есть движки для Postgres, Kafka, S3, Snowflake.
Возможность работы со стандартом.
Интеграция с Data Mesh Manager & OpenTelemetry.

Помимо отслеживания изменений в data pipeline через контракт, хорошей практикой будет их хранение в каталогах данных для централизованной работы всех заинтересованных пользователей, а также мониторинг проверок в соответствии со спецификацией контракта по качеству данных. Всё это прекрасно и выглядит как решение проблемы несогласованности, регулирования взаимодействия по обмену данными. Да и уже существуют стандарты контрактов, они развиваются, вокруг этого всего складывается активное сообщество, но до сих об этом больше говорят, чем используют. Даже есть проекты книг по контрактам данных, наиболее известная — «Data Contracts — Developing Production Grade Pipelines at Scale by Chad Sanderson, Mark Freeman». Контракт данных становится похож на таблетку от всех болезней!

Есть ли единый стандарт?

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

нужен один стандарт — Нужен один стандарт.

Лучшее решение — это использование совокупности практик. Но нужно стремиться к централизованному обеспечению совместимости контрактов данных с помощью управления единым стандартом, например к Open Data Contract Standard или Data Product Descriptor Specification. Ссылки на подобные ресурсы оставим ниже, чтобы вы нашли подходы для решения своих задач и поняли, каким должен быть для вас стандарт контракта данных.

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

Может быть, вы уже используете контракты данных?

Некоторые архитектурные решения предполагают на этапах переноса данных тестирование схем, валидацию типов и другие проверки. DBT позволяет проверять входящие и исходящие данные, что помогает предотвратить регрессии при изменении вашего кода. То есть прежде чем данные перенесутся из промежуточной схемы в схему для эксплуатации, пройдёт проверка согласованности. Оказывается, контракты данных от вас не так далеко?

Проверка данных с помощью моделей pydantic также может быть частью соблюдения регламентов контракта. Использование решений для построения data lineage неотделимо от контрактов, поддержания каталога данных и тракта работы продуктов данных. Например, использование OpenLineage в связке с Airflow или комплексных решений OpenMetadata, DataHub, Airbyte для управления данными позволяет прозрачнее выстроить data-процессы.
Поэтому выстраивание культуры работы с данными, неважно какими инструментами, включает в себя на каком-либо уровне уже неявное внедрение контрактов.

Когда нужно использовать контракты данных?

Контракт не должен применяться как панацея. Ключевая проблема, которую он решает, — это возможность инициативно влиять на любые изменения данных. В компании, где правильно выстроены процессы data governance, использование контракта может быть излишним. С другой стороны, команда может быть просто недостаточно зрелая и у неё просто нет необходимости в этом, или соглашения на уровне договорённости могут быть достаточными.

Ответственность за любые изменения в данных, как правило, ложится на владельца данных совместно со специалистом по качеству данных. Но зачастую это один разработчик, создавший data-продукт, да и в мире превалирует микросервисная архитектура со своими особенностями. Она порождает data mesh, и тут меняются подходы к работе с децентрализованным хранением данных. В подобной парадигме затруднительно отслеживать любые изменения, а значит появляется необходимость эту ситуацию решать — возможно, контрактами. Их применение во многом зависит от выбранного технологического стека, архитектуры данных и культуры работы с ними. В конечном счёте можно понаделать контрактов, но на деле их никто реализовывать не будет, так как выполнение самого контракта не так сложно, как встраивание в pipeline. И, бесспорно, нужно задумываться о целесообразности их использования, например в работе с real-time данными внедрение контрактов может повлиять на скорость загрузки.

Обеспечение согласованности обмена данными на уровне соглашений пользователей с помощью контрактов хорошо описано в книге Джеймса Денсмора «Data Pipelines Pocket Reference». Идея заключается в автоматическом уведомлении всех заинтересованных сторон при изменении контракта с помощью встраивания хуков в CI/CD-процессы для отслеживания состояния контрактов. Концепция ясна, но в действительности построение процесса, скорее всего, будет сопровождаться сложностями с синхронизацией версий контрактов, разделением ролей по доступу и подобными штуками. В свою очередь Чад Сандерсон и Адриан Крейцигер в серии статей «An Engineer's Guide to Data Contracts» описали внедрение контрактов данных в data pipeline. Они предложили отслеживание изменений в продукте данных с помощью сравнения спецификаций контрактов на основе CDC и потоковой обработки. Получается баланс между технической сложностью внедрения и прозрачностью data-процессов.

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

Как мы используем контракт данных?

Есть задача создания data pipeline для переноса предрасчитанных данных в горячее хранилище. Данные используются для инференса модели. Хотелось бы построить универсальный тракт, который требует минимальные изменения в процессе поставки новых источников, а также проверяет качество данных перед отправкой или обновлением целевой таблицы. Концептуальная архитектура выглядит так:

Реализация заключается в создании дага, который будет запускаться с помощью Rest API Airflow после подготовки данных для горячего хранилища. Шаг сбора и подготовки данных из внешнего источника в слоях Greenplum мы опустим, так как нам он не так интересен, но он инициализирует запуск дага по завершении предрасчёта. Даг для переливки подготовленных витрин из источника в целевую БД состоит из 5 шагов:

Проверка наличия контракта для переноса данных.
Проверка схемы данных источника и целевой таблицы.
Проверка качества данных в таблице источнике.
Обновление данных в целевой таблице.
Удаления неактуальных данных в целевой таблице.

Последние четыре шага являются задачами в рамках выполнения дага. Каждая задача работает на основе KubernetesPodOperator c переданными параметрами и собранным Docker-образом. Код задачи на Python пишется в соответствии с DDD (Domain Driven Design). Все настройки для подключений хранятся в соединениях Airflow, при конфигурировании самого дага все они пробрасываются в под. Первый шаг выполняется для каждой из четырёх предыдущих задач. Это основной шаг, который формирует все конфиги для подключения к базам данных и настройки для работы с Soda, а также проверяет наличие контракта на перенос данных.

Ключевой компонент репозитория — proxy mapping data contract, он же мэтчинг контрактов для передачи данных. Представлен в виде словаря, ключом которого является data_contract_id (например, hot_storage1), а значением — модель ContractMapping, содержащая сущности для переноса данных по конкретному контракту:

from types import MappingProxyType

from dag.domain import (
    HotStorageSchema1,
)
from dag.domain.contract_map import ContractMapping
from dag.repos import (
    HOT_STORAGE_COLLECT1,
    HOT_STORAGE_DELETE1,
    HOT_STORAGE_INSERT1,
)

DATA_CONTRACTS = MappingProxyType(
    {
        'hot_storage1': ContractMapping(
            conn_target_name='target_db1',
            schema_validation=HotStorageSchema1,
            query_collect=HOT_STORAGE_COLLECT1,
            query_insert=HOT_STORAGE_INSERT1,
            query_delete=HOT_STORAGE_DELETE1,
        ),
    },
)

Описание сущностей ContractMapping:

from pydantic.main import BaseModel

class ContractMapping(BaseModel):
    conn_target_name: str
    schema_validation: type[BaseModel]
    query_collect: str
    query_insert: str
    query_delete: str

conn_target_name — наименование подключения к целевой базе данных (должно соответствовать наименованию соединения необходимой целевой БД в Airflow);
schema_validation — pydantic model для проверки переносимых данных;
query_collect — запрос для сбора данных из Greenplum;
query_insert — запрос для вставки и обновления данных в горячем хранилище;
query_delete — запрос для удаления неактуальных данных.

После подготовки образа с контрактом данных создаётся конфиг для запуска дага. Он включает в себя, помимо основных параметров, ключ conf, который должен содержать:

data_contract_id — наименование контракта, соответствующего одному из наименований в DATA_CONTRACTS — proxy mapping data contract;
validation_checks — конфиг для проверок качества данных (Soda) в таблице источника, если нужно пропустить шаг validation_checks = "skip";
target_table — наименование целевой таблицы;
target_schema — наименование целевой схемы;
gp_table — наименование таблицы источника;
gp_schema — наименование схемы источника.

Даг запускается с конкретным конфигом для переноса данных из источника в целевое место, с нужными проверками качества по конкретному data_contract_id. В процессе выполнения отслеживается:

отсутствие запрашиваемого data_contract_id;
отсутствие одной из таблиц (источника, целевой);
соответствующие контракту проверки качества данных в источнике;
атрибутный состав с типами используемых данных в источнике и целевой таблице;
пропуск проверок качества данных;
валидация данных pydantic.

Перенос данных, в принципе, можно выполнять любым возможным способом: batches, fwd, через unlogged table, temp, copy или используя другие прелести БД. В текущем случае работает классический batch-upsert-трансфер. Любое падение дага и разбор инцидента проводится по data_contract_id, в котором произошла ошибка. Proxy mapping data contract является некоторой общей точкой взаимодействия, объединяющая все контракты для миграции данных. Она позволяет инициативно реагировать на изменения данных, не соответствующие регламенту контракта.

Заключение

Немного обсудили тему контрактов данных. Пытались договориться о регламентах работы с данными и о самом использовании контрактов. Увидели большой пласт проделанной работы в этом направлении. Поблагодарили авторов. Посмотрели на контракты с другой стороны. И на этом не остановимся

Всем спасибо за уделённое время! Буду рад обсудить эту тему в комментариях! Всем добра!

Полезные ссылки:

Теги:

Хабы: