Что произойдёт, если поле *first_name* в таблице *Customer* сегодня после обеда начнёт приходить NULL? Маркетинг отправит 12 000 людям письма «Уважаемый ,». Большинство таких поломок — результат молчаливого ожидания между producer-ом и consumer-ом, которое тихо нарушено. Data contracts превращают это ожидание в письменное.
Что такое data contract?
SLA на данные между producer-системой (CRM) и consumer-ами (DWH, ML, дашборд). Схема, freshness, пороги качества, семантика, владение, change policy — в одном YAML/JSON-документе.
Пример (сокращ.):
yaml contract: customer.v3 owner: crm-team schema: customer_id: string, not_null, unique first_name: string, not_null, max_len=100 email: string, format=email, nullable=true freshness: max_lag=15m quality: uniqueness_customer_id: 100% null_rate_first_name: <1% breaking_change_policy: 30d_notice
Как ломается молчаливое ожидание?
Реальные сценарии:
- CRM-команда мерджит middle name в first_name; длина с 100 растёт до 200; DWH-ETL не падает, но BI ломает перенос текста.
- В справочнике
statusгодами 1-5, апдейт добавляет 6; ML-модель не видела 6 — сегмент классифицируется неверно. - Hotfix меняет
order_idс int на string; сверка платежей тихо смещается.
Каждое — инцидент на часы. Data contracts ловят их на деплое.
Пять компонентов
- Гарантии схемы
- Freshness (макс. лаг)
- Пороги качества
- Семантика
- Change policy (обычно 30 дней уведомления)
Энфорсмент в продакшене
Контракт — статический файл в репо. Три точки исполнения:
- CI-гейт: PR producer-а, конфликтующий с контрактом, блокируется.
- Pipeline-тест: каждый ETL-запуск меряет метрики через Soda Core / dbt-test / custom asserts.
- Catalog UI: активные контракты видно на таблице в каталоге.
Привязка к SLA
Нарушение контракта открывает инцидент, привязанный к SLA producer-команды. Это единственный надёжный способ держать контракты живыми.
Версионирование
customer.v1, v2, v3. Если breaking-изменение принято как v3:
- v2 и v3 параллельно публикуются 60 дней.
- Consumer-ы переезжают на v3 под телеметрией.
- v2 retire после полного перехода.
CentraQL и data contracts
Модуль DataQuality читает файл контракта, автоматически генерирует правила и взвешенно учитывает их в Trust Score. На дашборде CFO видна строка «Customer-таблица Trust 87 — 2 нарушения freshness на contract.v3 за 7 дней».
С чего начать
Прагматичный 3-месячный план:
- Недели 1-2: собрать consumer-ов 5 критичных таблиц; зафиксировать молчаливые ожидания.
- Недели 3-6: написать первые 5 контрактов; producer и consumer подписывают.
- Недели 7-10: CI-гейт + Soda Core; первые алерты нарушений.
- Недели 11-12: ежемесячный review; расширение за пределы пяти.
Через 12 недель: ~80% меньше сюрприз-поломок и время обнаружения остального падает с часов до минут.
Заключение
Data contracts не магия; они превращают молчаливое соглашение между producer и consumer в письменный, измеримый и аудируемый документ. Надёжность пайплайна растёт по мере живой энфорс-практики; разговор смещается из «хорошо или плохо» к «contract.v3 freshness violations: 2 / 7 days». Trust Score, MDM и фреймворк governance становятся единым целым только тогда, когда стоят на контрактах.
