Перейти к содержанию

Data Quality и Data Contracts

Раздел 04 · Типы достоверности

Тип материала: инженерный разбор. Схемы и примеры иллюстративные. Рекомендации — INFERENCE; учебные параметры — HYPOTHETICAL.

Проверка источников: 2026-11-02. Версии и границы первоисточников перечислены в конце. Documented contracts не означают выполненный runtime test.

Принцип работы и границы

Contract описывает не только schema: owner, identity, units, timezone, currency, разрешённые transitions, freshness/completeness expectations и evolution policy. Data Quality проверяет определённые predicates на доступном наборе данных. Прошедшая проверка non-null не доказывает, что источник доставил все проводки.

INFERENCE: расположите проверки на приёме, перед финансовым effect и перед публикацией dataset. Критичные checks блокируют publication; наблюдательные checks создают incident. Для каждого check зафиксируйте denominator, cut и действие при нарушении. Случай «нет входных данных» должен отличаться от «все строки валидны».

FACT: Schema Registry различает режимы compatibility; schema compatibility не задаёт бизнес-семантику amount. Confluent documentation. Смена amount_minor на major units без смены типа успешно проходит structural validation и всё равно ломает ledger.

Иллюстративная архитектура

flowchart LR
 P[Producer contract owner] --> V[Schema and semantic validation]
 V -->|valid| S[Staging generation]
 V -->|invalid| Q[Quarantine with reason]
 S --> C[Quality and completeness gates]
 C --> R[Published dataset]

Failure scenarios

Producer меняет единицу суммы, но оставляет integer. Empty source partition даёт ноль invalid rows и ложный green. Check запущен по разным snapshots source и target и создаёт шум. Неизвестный enum молча приводится к default и становится неверной business operation.

Recovery protocol

  1. Заблокировать affected generation; сохранить source bytes и contract/code versions.
  2. Согласовать owner correction: новый schema/semantic version либо reader fix.
  3. Пересобрать из неизменяемого input cut, не исправлять сырые данные без provenance.
  4. Проверить ключи, units, transition legality и независимую reconciliation.
  5. Publish после прохождения gates, с явной причиной прошлой блокировки.

Trade-offs и критерии выбора

Жёсткий ingress gate защищает инварианты, но снижает availability при ложных срабатываниях. Warning-only подходит exploratory analytics, но недостаточен перед списанием. Полный contract дороже поддерживать, чем JSON schema; цена ошибки units обычно выше.

FinTech и iGaming

Для payments сохраняйте currency scale и signed direction. Для iGaming market status, odds representation и settlement revision должны иметь owner; одинаковый decimal тип не делает decimal odds и fractional odds совместимыми.

Практический пример

Используйте существующие JSON schemas и reconciliation. Учебный тест: валидный по schema amount с неправильной валютной единицей; schema check должен пройти, а business contract/reconciliation — обнаружить расхождение.

Типичные ошибки проектирования

Считать schema реестром всех бизнес-правил; отключать gate при пустом input; хранить только процент success без объёма; применять quality проверку после необратимого effect.

Вопросы на собеседовании

Может ли DQ быть green при потере денег? Да: все полученные строки валидны, но одна операция отсутствует.

Кто владеет contract? Producer/domain owner совместно с consumers определяет семантику; platform обеспечивает enforcement и evolution tooling.

Дополнительные источники