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

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/онлайн: диапазоны фич, согласованность оффлайн↔онлайн.
6. BI/API: подсчеты и фильтры, SLAs на latency/freshness, k-анонимность.

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

Схемные: тип/nullable/enum/regex/JSON-shape; несовместимые изменения → стоп.
Доменные: суммы ≥0, валюта ∈ {EUR, USD, TRY, BRL}, ставка ≤ лимита, страна∈лицензии.
Идентичность/ключи: первичный ключ уникален, 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 превращают данные в надежный актив: отчеты корректны, модели устойчивы, платежи безопасны, комплаенс спокоен.