Валідація даних

1) Навіщо це потрібно iGaming-платформі

Довіра до звітів та KPI: GGR/NET, конверсії, утримання, RG-сигнали.
Надійність ML/скорингу: коректні фічі для антифроду/рекомендацій/RG.
Операції в реальному часі: алерти при дрейфі/втраті подій до того, як постраждають виплати/UX.
Комплаєнс: відсутність PII/секретів там, де їх бути не повинно; доказова трассируемость.

2) Де валідувати: рівні контролю

1. Інжест (batch/stream): схема, типи, обов'язкові поля, idempotency/дедуп.
2. Стрім-процесинг: вікна/водяні знаки, порядок, пропуски/запізнення, exactly-once.
3. ETL/ELT та трансформації: посилання/джойни, агрегати, бізнес-баланси.
4. DWH/вітрини (Gold): консистентність між таблицями, свіжість, унікальність ключів.
5. Feature Store/онлайн: діапазони фіч, узгодженість offlayn↔onlayn.
6. BI/API: підрахунки та фільтри, SLAs на latency/freshness, k-анонімність.

3) Типи перевірок (каталог)

Схемні: тип/nullable/enum/regex/JSON-shape; несумісні зміни → стоп.
Доменні: суми ≥0, валюта ∈ {EUR, USD, TRY, BRL}, ставка ≤ ліміту, strana∈litsenzii.
Ідентичність/ключі: первинний ключ унікальний, foreign key не «висячий».
Якість полів: заповненість, довжини, формат (IBAN, BIN, e-mail токен).
Статистика/базові лінії: частоти, розподілу, квантильні коридори.
Аномалії: різкі стрибки обсягу/часток, нулі/дублікати, schema drift.
Свіжість: max (ts) не старше X; лаг ingest→gold ≤ T.
Консистентність: сума за деталями = зведений; multi-table reconciliation.
Приватність/безпека: Zero-PII поза дозволеними зонами; токенізація/маски.
Регуляторика: RG/AML поля присутні і правдоподібні (дати, ознаки).

4) Data Contracts (контракти даних)

Контракт фіксує схему + правила якості + SLO між джерелом і споживачами.

yaml dataset: payments_ingest_v2 owner: team-payments schema:
id: {type: string, pattern: "^[a-f0-9]{32}$", unique: true}
ts: {type: timestamp, timezone: "UTC", nullable: false}
amount: {type: decimal(18,2), min: 0. 00}
currency: {type: string, enum: ["EUR","USD","TRY","BRL"]}
psp: {type: string, required: true}
quality:
freshness_max: "PT5M"
completeness_min: 0. 995 duplicate_rate_max: 0. 001 pii_allowed: false slo:
p95_ingest_latency_ms: 30000 success_rate: 0. 995

Зміни контракту - через semver і міграції: 'MAJOR'ламає,'MINOR'додає поле,'PATCH'виправляє опис.

5) «Очікування» (expectations) і політики

Очікування - декларативні перевірки, що виконуються в пайплайнах (batch/stream).

yaml expectations:
- name: unique_primary_key check: "unique(id)"
severity: "error"
- name: amount_non_negative check: "amount >= 0"
severity: "error"
- name: currency_enum check: "currency in ['EUR','USD','TRY','BRL']"
severity: "error"
- name: ts_fresh_enough check: "now() - max(ts) <= interval '5 minutes'"
severity: "warn"
- name: pii_absent check: "no_plain_pii(columns: ['email','card','iban'])"
severity: "error"

• «error» → карантин партії/батча, оповіщення + тікет; блок downstream.
• 'warn'→ проходить, але створює задачу на розбір; позначка якості.
• 'info'→ тільки моніторинг.

6) Стрімінг: специфіка перевірок

Watermarks/late data: допускаємо запізнення'≤ 120s', інакше - карантин; компенсуємо кінцевими вікнами.
Idempotency: ключ події + hash payload → дедуп на брокері/в потоці.
Exactly-once: транзакційний синг (+ ідемпотентні sinks) для критичних потоків (платежі/раунди).
Лічильники обсягу: «очікувалося» vs «отримано» за вікно; розбіжність → алерт.

scala val deduped = stream
.keyBy(_.id)
.process(new DeduplicateWithin(Time. minutes(10)))

val validated = deduped
.filter(_.amount >= 0)
.filter(_.currency in Set("EUR","USD","TRY","BRL"))

emitToQuarantineIfLate(validated, allowedLateness = 120. seconds)

7) DWH/SQL: інваріанти та звірки

sql
-- uniqueness
SELECT id, COUNT() c FROM gold. payments GROUP BY 1 HAVING c>1;

-- freshness
SELECT NOW() - MAX(ts) AS lag FROM gold. payments;

-- reconciliation of totals
SELECT
SUM(amount) AS by_rows,
(SELECT total_amount FROM gold. payments_summary WHERE date=CURRENT_DATE) AS by_summary
FROM gold. payments
WHERE date = CURRENT_DATE;

Матчинг з вітринами: щоденні звірки'detail → summary', звіти розбіжностей, автоматичний тікет.

8) Приватність і безпека

Типова PII-редакція: маски/токени на вході; забороняємо «сирі» e-mail/карти/телефони в логах.
Політика дозволів: таблиці з PII - окремий шар/каталог, доступ за ролями (RBAC/ABAC).
K-анонімність звітів: мінімум N рядків у зрізі.
Leak-детектори: регулярні перевірки на шаблони PII, «секрети» (ключі/токени).
Юрисдикції: geo/tenant-ізоляція (країна/бренд/ліцензія), роздільні ключі.

9) Метрики якості та SLO

• Freshness - відставання max (ts).
• Completeness - частка непустих/очікуваних записів.
• Uniqueness - дублікати ключів.
• Consistency - інваріанти і баланси (міжтаблично).
• Accuracy - перевірка із зовнішнім джерелом/правилами домену.
• Validity - відповідність типам/enum/regex.

• `Freshness payments_gold ≤ 5 мин` (p95).
• `Completeness game_rounds ≥ 99. 7 %/день'.
• `Duplicate_rate ≤ 0. 1‰`.
• `PII_leak = 0`.

10) Алерти, тікети і runbook

Роутинг: Slack/PagerDuty → власник домену; автоматично прикладаємо семпли і diff.
Групування: один інцидент на набір "labels: dataset=payments, brand=TR».

1. Перевірити лаг ingest і чергу брокера.

2. Порівняти «очікувалося vs отримано» по PSP.

3. Увімкнути ретраї/перемкнути маршрут PSP.

4. Анотувати причину; рестарт бектів; провести пост-мортем.

11) Версіонування, тести і waiver-процес

Semver правил якості: `quality@MAJOR. MINOR. PATCH`.
Юніт-тести трансформацій (SQL/DBT/пайтон) і контракт-тести для джерел.
GOLDEN-сети: відомі кейси розбіжностей/витоків - обов'язкові в регресі.
Waiver (виняток): короткостроковий дозвіл порушити правило (опис, власник, термін, компенсуючі заходи).

12) Каталоги/артефакти (готові шаблони)

12. 1 Паспорт датасета

yaml dataset: gold. game_rounds owner: team-games steward: data-governance contracts: ["games_rounds_v3"]
quality_slo:
freshness_p95: "PT10M"
completeness_min: 0. 997 uniqueness_max_dup: 0. 0005 alerts:
channels: ["#dq-incidents","#games-ops"]
severity_map: {error: "P1", warn: "P2"}

12. 2 Політика карантину

yaml quarantine:
storage: "s3://quarantine/payments/"
retention: "P30D"
access: ["team-payments","data-governance"]
auto_reprocess:
cron: "/15  "
max_attempts: 3

12. 3 Expectation для Feature Store

yaml featureset: fs_payments_online_v1 checks:
- name: feature_freshness check: "now() - max(feature_ts) <= interval '60 seconds'"
severity: "error"
- name: range_amount_avg check: "amount_avg in [0, 2000]"
severity: "warn"
- name: enum_device check: "device in ['ios','android','web']"
severity: "error"

13) Специфіка iGaming: готові кейси

Платежі/PSP: звірка суми депозитів/висновків зі звітами PSP; відсутні статуси → карантин батча; алерт на ріст'decline _ rate'.
Ігрові провайдери: падіння'rounds _ per _ min'vs baseline + schema drift від провайдера → блок трансформації провайдера А, банер статусу.
RG/AML: обов'язкові поля (ліміти, self-exclusion, KYC-статуси); прострочені KYC → прапор на блок виплат, тікет в комплаєнс.
Маркетинг/CRM: валідність параметрів кампаній, UTM, дедуп подій; k-анонімність у вітринах.

14) Дорожня карта впровадження

0-30 днів (MVP)

1. Включити контракти на ключові набори: payments, game_rounds, users, features.
2. Каталог очікувань (10-15 базових) + карантин + алерти.
3. Дашборд Freshness/Completeness/Uniqueness; звіт інцидентів.
4. Runbook’и для `Freshness`, `Duplicates`, `Schema drift`.

30-90 днів

1. Міжтабличні звірки і баланси; waiver-процес і semver правил.
2. Стрім-валідація (late data, дедуп, watermarks); PII-детектори.
3. Інтеграція з CI/CD: контракт-тести джерел і трансформацій.
4. SLO якості в OKR команд доменів.

3-6 місяців

1. AIOps-підказки порогів; авто-локалізація причин.
2. Крос-бренд/гео політика якості та звіти комплаєнсу.
3. Пост-мортеми P1 інцидентів → поповнення golden-сетів і правил.
4. Зв'язка з алертингом потоків і аналізом аномалій (єдиний контур).

15) RACI

Data Governance (A/R): стандарти, контракти, аудит правил.
Domain Owners (R): доменні очікування та інваріанти.
Data Platform (R): фреймворк очікувань, карантин, альберти, моніторинг.
Security/DPO (A/R): приватність/PII/k-анонімність, geo/tenant-ізоляція.
SRE/Observability (C): маршрутизація інцидентів, SLO/SLI.
Product/Finance (C): бізнес-баланси, пріоритети інцидентів.

16) Анти-патерни

Валідація «тільки в DWH» - пізно, дорого, боляче.
Немає карантину - «бруд» йде в Gold/ML і ламає довіру.
Жорсткі пороги без сезонності/годин/ринків → шторм алертів.
Відсутність власника і semver правил → хаос винятків.
Логи з PII і «скріншоти в загальний канал».
Разові «санітарні дні» замість постійного контуру.

17) Пов'язані розділи

DataOps-практики, Аудит даних і версійність, Походження і шлях даних, Алерти з потоків даних, Аналіз аномалій і кореляцій, Контроль доступу, Безпека даних і шифрування, Політики зберігання даних, MLOps: експлуатація моделей.

Підсумок

Валідація - це не фільтр на кінці, а наскрізний контракт якості: від інжесту і стріму до вітрин і онлайн-фіч. Чіткі очікування, карантин, алерти і SLO перетворюють дані в надійний актив: звіти коректні, моделі стійкі, платежі безпечні, комплаєнс спокійний.