Контроль качества данных

1) Назначение и принципы

Зачем: надежные отчеты (GGR/налоги), антифрод и RG-модели, комплаенс-выгрузки, продукты и персонализация.

• Schema-first & Contracts: все источники обязаны публиковать данные по контракту.
• DQ-как-код: правила в репозитории, версии, тесты и ревью.
• Observability-by-default: метрики/логирование/линейдж.
• Privacy-by-design: минимум PII, маскирование и RLS/CLS.
• Cost-aware: приоритизация критичных правил, умные выборки.

2) Таксономия измерений качества

Completeness (Полнота): доля обязательных полей/строк.
Validity (Допустимость): соответствие типам/диапазонам/справочникам.
Uniqueness (Уникальность): отсутствие дубликатов ключей/событий.
Consistency (Согласованность): референтная целостность, бизнес-инварианты.
Accuracy (Точность): приближение к «истинному» источнику (сводные сверки).
Timeliness/Freshness (Своевременность): задержка материала.
Lineage Integrity: сохранение происхождения/версий трансформаций.

Для каждого домена определяются KPI качества и критичность (critical/major/minor).

3) Контракты и схемы (источник истины)

Контракты данных: JSON Schema/Avro/OpenAPI/AsyncAPI, размещены в Registry.
Стабильность: backward-совместимые изменения — добавление nullable; breaking — новая версия + двойная запись.
Трассируемость: в событиях — `event_id`, `trace_id`, `schema_version`, `source`.

4) DQ-как-код: структура артефактов

/dq/
rules/
silver. payments. yaml gold. ggr_daily. yaml checks/
sql/
python/
policies/
severities. yaml notifications/
routes. yaml

Правила: декларативные YAML/SQL;

Серьезность: mapping → алерт-каналы/уровни эскалации;

CI: линтеры схем, тесты совместимости, «dry-run»/симулятор.

5) Примеры правил (YAML)

yaml table: silver. payments owner: data-payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: amount_positive severity: critical type: range column: amount min: 0. 01
- name: currency_in_whitelist severity: major type: in_set column: currency set: [EUR, USD, GBP, TRY, BRL]
- name: unique_tx severity: critical type: unique columns: [transaction_id]
- name: fk_user_exists severity: critical type: foreign_key column: user_pseudo_id ref_table: dim. users ref_column: user_pseudo_id
- name: ts_monotonicity severity: minor type: temporal expression: "ts between date_sub(now(), interval 90 day) and now()"

6) SQL-тесты (образцы)

Уникальность ключей

sql
SELECT transaction_id, COUNT() AS c
FROM silver. payments
GROUP BY transaction_id
HAVING COUNT() > 1;

Полнота обязательных полей

sql
SELECT COUNT() AS nulls
FROM silver. payments
WHERE amount IS NULL OR currency IS NULL OR ts IS NULL;

Справочники/консистентность

sql
SELECT p. currency
FROM silver. payments p
LEFT JOIN ref. currencies r ON p. currency = r. code
WHERE r. code IS NULL;

7) Потоковая DQ (real-time)

Ingest-валидация: schema validation, size-limits, типы и enum’ы.
On-stream проверки: дедуп `(event_id, source)`, allowed lateness, валидность валют/сумм.
Границы: критичные ошибки → DLQ + алерт; не критичные → тегировать, но пропускать (с флагом `dq_flag`).
Метрики: completeness/lag/dup-rate по партициям.

8) Работа с ошибками и исключениями

DLQ/Quarantine: «больные» записи удерживаются, доступны для исправления.
Exception records: карточка исключения (owner, срок, причина, область).
Auto-fallback: использование последнего корректного снапшота витрины.
SLA закрытия: критичные — ≤ 24–48 ч; major — ≤ 5 раб. дней.

9) Согласование с приватностью и комплаенсом

PII-минимизация: не проверяйте «сырые» PII в аналитических слоях; применяйте псевдонимы.
RLS/CLS: проверки выполняются с учетом маскирования полей.
Регионализация: правила учитывают `jurisdiction` (EEA/UK/BR).
Legal Hold: запрет на перезапись архивов в рамках удержания.

10) Наблюдаемость, SLI/SLO и алерты

• Freshness p95 (Silver): ≤ 15 мин.
• Completeness (critical types): ≥ 99.5%.
• Validity (schema): ≥ 99.9%.
• Duplicate rate: ≤ 0.1%.
• DQ incident MTTR: ≤ 24–48 ч.

Алерты: маршрутизация по серьезности (pager для critical), сглаживание (дедуп алертов), «maintenance windows».

11) Дашборды (минимальный набор)

Тепловая карта Freshness/Completeness по доменам и рынкам.
Топ-N таблиц по incident rate и по стоимости исправлений.
Воронка DQ: ingest → silver → gold (потери/исправления).
Карта линейджа для критичных отчетов (регуляторка/GGR/RG/AML).
Карта «устаревших» схем и клиентов (версии SDK/схем).

12) Процессы и RACI

R (Responsible): Data Engineering (правила на таблицы), Domain Owners (семантика).
A (Accountable): Head of Data/CDO.
C (Consulted): Compliance/Legal/DPO, Архитектура, SRE.
I (Informed): BI/Продукт/Маркетинг/Финансы/Операции.

Жизненный цикл правила: предложение → ревью → «темный запуск» → включение → мониторинг → ретроспектива.

13) Сверки и точность (Accuracy)

Контрольные суммы/транзакции: свод с OLTP/провайдерами (PSP/KYC).
Двухконтурные сравнения: независимый pipeline для выборочной валидации.
Допуски: процентные пороги по метрикам (например, расхождение GGR ≤ 0.2%).
Ежедневные акты: отчеты сверок для аудита.

14) Стоимость и приоритизация

Критичные правила запускайте чаще (streaming/часовые), minor — daily.
Используйте выборки и materialized checks для тяжелых таблиц.
Отслеживайте cost/query и cost/GB, применяйте кластеризацию/индексацию.
Выделяйте бюджет на DQ в разрезе команд (chargeback).

15) Шаблоны для Gold-витрин (пример GGR Daily)

yaml table: gold. ggr_daily owner: fin-analytics slo:
ready_by_local_time: "06:00"
rules:
- name: ggr_not_negative severity: critical type: range column: ggr min: 0. 0
- name: market_known severity: major type: in_set column: market set_ref: ref. markets
- name: fx_source_present severity: major type: not_null column: fx_source
- name: completeness_by_market severity: critical type: completeness partition_keys: [event_date, market]
expected_rows_expression: "ref. expected_activity(event_date, market)"

16) Инциденты качества: управление и коммуникация

Ticketing: авто-создание задач с прикрепленными выборками и метриками.
Комм-шаблоны: уведомление владельцев продуктов/регуляторки при влиянии.
Пост-мортем: корневая причина (schema drift, upstream bug, нагрузка), действия CAPA, контроль «возврата регрессий».

17) Дорожная карта внедрения

1. Каталог критичных таблиц (Payments, Gameplay, GGR, Compliance).

2. YAML-правила для 10–15 ключевых проверок + CI-валидация.

3. Дашборд Freshness/Completeness и алерты для critical.

4. DLQ/Quarantine + runbook исправлений.

• Расширение правил (FK/accuracy), симулятор «dry-run», A/B включений.
• Интеграция с lineage, договоренности по исключениям и SLA.
• Потоковая DQ на ingest для «шумных» источников.

• Автогенерация документации по правилам, метрики стоимости.
• «Контрольные контуры» (independent reconciliation), weekly ретроспективы.
• Rule-as-Code платформенные SDK, реестр стандартных проверок домена.

18) Чек-лист перед продом

• Контракты и схемы в Registry, тесты совместимости проходят.
• YAML-правила смержены, severity/эскалации назначены.
• Дашборды и алерты активны; SLO определены и согласованы.
• DLQ/Quarantine доступен, runbooks задокументированы.
• Процедуры исключений/актов сверок согласованы с Legal/Compliance.
• Замеры стоимости проверок и лимиты на тяжелые запросы.

19) Частые ошибки и как их избежать

Сырые данные без контрактов: вводите schema-first и consumer-tests.
Проверки «вручную»: переводите в DQ-как-код и CI.
Нет приоритизации: разделяйте critical/major/minor и каналы алертов.
Отсутствует DLQ: нечем работать с ошибками — добавьте карантин.
Игнор стоимости: профилируйте запросы, используйте материализацию.
Нет пост-мортемов: ошибки повторяются — вводите CAPA и контроль регрессий.

20) Итог

Система контроля качества данных — это не набор разрозненных проверок, а управляемая программа: контракты и схемы, DQ-как-код, наблюдаемость и SLO, дисциплина инцидентов и сверок. Следуя этой статье, вы получите воспроизводимые, проверяемые и экономичные данные, достаточные для регуляторной отчетности, продуктовых решений и real-time детекторов риска.