Контроль якості даних

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 детекторів ризику.