Аудит данных и версионность

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 Политика версионности (фрагмент)

МАJOR: ломает совместимость; 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 с полным набором связей «данные→фичи→модель→инференс».

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, устойчивости комплаенса и скорости безопасных релизов.