Аудит даних і версійність

1) Навіщо це потрібно

Аудит і версійність створюють відтворюваність: ви можете пояснити будь-яку цифру, повторити розрахунок і безпечно розвивати моделі/вітрини. У iGaming це критично для фінансів (GGR/NET), платежів, KYC/AML, Responsible Gaming і регуляторної звітності.

• Трасування: хто змінив дані/схему/логіку і чому.
• Відтворюваність: яка версія даних/коду/моделі породила звіт.
• Безпека релізів: оборотність (rollback) і передбачуваність змін.
• Відповідність: доказові журнали для регуляторів і внутрішніх аудитів.

2) Поняття та рівні версійності

1. Версія схеми (Schema Version): еволюція полів/типів/семантики (SEMVER).
2. Версія набору даних (Dataset Version): знімок/зріз в момент часу; «істина» для звіту/навчання.
3. Версія вітрини/моделі BI (Data Product Version): формули, фільтри, агрегування.
4. Версія фіч/моделі ML: дата/код/гіперпараметри/фічі/дані (end-to-end).
5. Версія пайплайна: код трансформацій, конфіги, залежності.
6. Версія контракту даних: вимоги до продюсера/споживача (схема, SLA, якість).

3) Аудит: що логувати

Хто: суб'єкт (користувач/сервіс), роль/атрибути (RBAC/ABAC).
Що: таблиця/вітрина/модель/схема/контракт.
Коли: точний час, tz, кореляційний id.
Чому: посилання на таск/тікет/реліз-ноту, причина.
Чим: версія коду/моделі, commit hash, образ контейнера.
Як змінилося: до/після (diff), обсяг рядків (rows affected), контроль цілісності (хеш/підпис).
Контекст: середовище (prod/stage), домен, чутливість даних (клас).

Аудит-журнали незмінні (append-only/WORM), підписані і доступні в SIEM.

4) Політика версійності (рекомендації)

SEMVER: `MAJOR. MINOR. PATCH`

MAJOR - несумісні зміни схеми/семантики.
MINOR - обернено сумісні додавання (нові поля/колонки з nullable, нові вітрини vNext).
PATCH - виправлення без зміни контракту (quality-fix, backfill).
Deprecation-процедура: вікно застарівання, попередження в каталозі/CI, дата відключення.
Release Notes: одна сторінка на реліз: що, навіщо, ризики, план відкату.

5) Техніки в сховищі і потоках

Time-travel / Snapshots: зберігання версій таблиць; можливість виконати запит «як було на T-0».
SCD (Slowly Changing Dimensions): типи 1/2/3 для вимірювань (ігри, провайдери, гравці).
CDC/CDF (Change Data/Capture & Feed): інкрементальні зміни для фактів (ставки, виплати, KYC).
Журнал операцій (Audit Fact): окрема факт-таблиця з подіями правок/додавань/видалень.
Контроль цілісності: хеші партій/файлів, підпис пакетів, звірки агрегатів.

6) Еволюція схем і Data Contracts

Контракт як код: схема, типи, обов'язковість полів, допустимі значення, SLA свіжості, DQ-правила.
Сумісність: додали поле → MINOR; поміняли тип/семантику → MAJOR з міграцією і dual-write.
CI-гейт: PR змінює схему блокується, якщо порушена сумісність чи ні Release Notes.
Каталог/Registry: зберігає активні/застарілі версії та власників.

7) Версійність в BI і метриках

Сертифіковані «золоті» вітрини: закріплена семантика KPI (GGR, ARPPU, утримання).
Dual-run: нова версія вітрини будується паралельно (v2), порівняння метрик (tolerance bands).
Фіксація звітів: кожен експорт/дашборд посилається на'dataset _ version'і'definition _ version'.
Календарні зрізи: «дей-кат», «місяць-к-дате» - фіксуються на версію даних.

8) Версійність в ML/MLOps

Model Registry: модель, дата, метрики якості, дані навчання (dataset_version), версії фіч (feature_set_version).
Feature Store: версіоновані фіч-групи; заборона «гарячих» полів без явної версії.
Repro набір: код тренування (commit), оточення (Docker/conda lock), сід.
Champion–Challenger: паралельні версії в проді, звіти по якості, fairness і приватності.
Rollback: швидкий відкат на попередню стабільну модель і фіч-набір.

9) Роллбек, backfill і виправлення

Rollback-план: на кожну MAJOR/MINOR версію - чіткі кроки повернення.
Backfill-плейбук: джерело істини, діапазон дат, порядок перерахунку, контрольні суми, мітки «recomputed = true».
Видимість редагувань: v2 замінює v1 тільки після проходження порівняння; всі «історичні» звіти продовжують посилатися на свої версії.

10) Безпека і комплаєнс в аудиті

Підпис подій/пакетів: продюсер підписує, споживач перевіряє.
PII-санітайзинг: аудит зберігає токени, не сирої PII.
Legal Hold: заборона видалення версії/логів на період розслідування.
DSAR: версії знаходять і вивантажують записи суб'єкта по токену; враховуються історичні знімки.

11) Метрики та SLO

Repro Rate: частка звітів, відтворюваних з версії даних/коду ≥ цільового порогу.
Coverage: % таблиць з включеним time-travel/журналом аудиту.
Schema Compatibility Pass: частка успішних перевірок сумісності в CI.
Dual-run Delta: розбіжність v1/v2 в межах допусків.
Rollback MTTR: середній час відкату версії.
Audit Integrity: частка підписаних і перевірених подій.
Backfill Success: частка коректно завершених перерахунків.

12) Патерни для iGaming (кейси)

Корекція GGR заднім числом: постачальник перерахував RTP - робимо backfill фактів за період, фіксуємо'recomputed _ at', публікуємо Release Notes, порівнюємо v1/v2; звіти за минулі місяці не переписуємо, а позначаємо «виправлена версія доступна».
Антифрод-правила: змінюємо семантику фічі - MAJOR, dual-run моделі і вітрини, ролбек на champion при регресі.
KYC/AML: додали нові статуси провайдера - MINOR з nullable; включаємо тести сумісності в контрактах.
RG-сигнали: уточнили логіку «серій програшів» - MINOR + Release Notes і моніторинг впливу.

13) Інструменти та артефакти (категорії)

Catalog/Lineage/Registry: версії наборів/схем/вітрин, власники, зв'язки, контракти.
Orchestrator & CI/CD: гейти сумісності, прогін dual-run, публікація реліз-нот.
Storage с time-travel: зберігання знімків/журналів.
Signing & Checksums: підпис пакетів, контрольні суми партій.
Model/Feature Registry: версії фіч/моделей, звіти champion-challenger.

14) Шаблони (готово до використання)

14. 1 Release Notes (ескіз)

Версія: `payments_gold v2. 1. 0`

Тип: MINOR (нові поля'psp _ country','method _ group')

Причина: уніфікація звітності по PSP/країнам

Ризики: вплив на джойни з вітриною'risk _ signals '

Валідація: dual-run 14 днів, delta ≤ 0. 2% по GGR

Rollback: перемикання на'v2. 0. 3'через прапор оркестратора

Дата деплоя/власник/тікет

14. 2 Паспорт версії набору

Dataset: `game_rounds_silver`

Версія: `2025-11-01T00:00:00Z` (snapshot id)

Схема: `schema@1. 7. 0'( посилання на контракт)

Джерело: провайдерські фіди A/B (commit...)

Контроль цілісності: checksum, підписаний маніфест

DQ: повнота 99. 9%, свіжість ≤ 15 хв

Використання: `games_perf_gold v3. x`, `rg_signals v1. x`

14. 3 Акт аудиту зміни

Подія: update schema `kyc_status` → `kyc_status,v2`

Хто: user/service, роль `Data-Engineer`

Коли: `2025-11-01 09:32:10+02`

Чому: тікет # 3421 (нові статуси провайдера)

Diff: +'status _ reason'( nullable), enum розширений

Перевірки: CI semver pass, контракт MINOR

Підпис: 'sig =...', хеш diff: `sha256=…`

14. 4 Політика версійності (фрагмент)

MAJOR: ламає сумісність; dual-write ≥ 30 днів; обов'язковий rollback-план.
MINOR: оборотно сумісно; попередження в каталозі; A/B вітрин 7-14 днів.
PATCH: фікси якості/перерахунки; Release Notes обов'язково.
Архівація: зберігаємо ≥ N місяців снапшоти для регуляторики; WORM для аудиту.

15) Процеси (end-to-end)

1. Ініціатива: тікет зміни + оцінка імпакту по лінійджу.
2. Проектування: оновлення контракту/схеми + Release Notes.
3. Валідація: CI-перевірки сумісності, тести DQ, dual-run.
4. Деплою: по прапору, канарка; публікація версії в каталозі.
5. Моніторинг: delta v1/v2, KPI, скарги.
6. Відкат/Backfill: по плейбуку при регресі.
7. Пост-мортем: якщо інцидент, оновлення політики/тестів.

16) RACI (приклад)

Політика та стандарти: CDO (A), Data Governance Council (R/A), DPO/Sec (C).
Контракти/схеми: Domain Owners (A), Data Stewards (R), Platform/Eng (C).
Оркестрація/сховище: Platform/Eng (R), SRE (C).
BI/метрики: Analytics Lead (R), Product/Finance (C).
ML-версії: ML Lead (A), DS (R), Platform (C).
Аудит/журнали: SecOps (R), Internal Audit (C).

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

0-30 днів (MVP)

Увімкнути time-travel/знімки для критичних таблиць (payments, game_rounds, kyc).
Запустити незмінні аудит-журнали та підпис пакетів ingestion.
Прийняти SEMVER-політику і шаблон Release Notes.
Каталог: додати'owner','schema _ version','dataset _ version'до топ-вітрин.

30-90 днів

Ввести dual-run для всіх MINOR/MAJOR; автоматичне порівняння v1/v2.
Зв'язати контракти з CI-гейтами сумісності і DQ.
Регламент backfill/rollback; навчити команди.
Model/Feature Registry з повним набором зв'язків «dannyye→fichi→model→inferens».

3-6 місяців

Повне покриття журналами аудиту, WORM-сховище, звіти для регуляторів.
Автоматизовані Release Notes з diff + лінійдж.
Звіти Repro Rate/Schema Compatibility/Rollback MTTR в дашбордах.
Щоквартальні рев'ю версій KPI і «заморожування» визначень.

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

Зміна семантики KPI без нової версії/реліз-ноти.
Перерахунки «по-тихому» без backfill-плану і відміток'recomputed'.
Зберігання сирих PII в аудит-логах.
Відсутність dual-run і миттєва заміна вітрин.
«Вічні» моделі/вітрини без вказівки версії і джерел.

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

Управління даними, Походження і шлях даних, Контроль доступу, Токенізація, Безпека і шифрування, Моніторинг моделей, Етика і DSAR, Federated Learning, Конфіденційне ML.

Підсумок

Аудит і версійність перетворюють дані і моделі в надійний продукт: кожна зміна прозора, відтворювана і оборотна. Для iGaming це фундамент довіри до KPI, стійкості комплаєнсу і швидкості безпечних релізів.