Data Lake и DWH для казино: схемы, SLA загрузок

Полный текст статьи

💡 18+. Технический материал для платформ/операторов, студий и аналитических команд. Не призыв к игре. Под платформой понимаем PAM/кошелёк/кассу/бонусы/RG, под провайдерами — RGS/live/джекпоты/платёжные интеграции.

1) Зачем казино Data Lake и DWH

Отчётность и комплаенс: регуляторные выгрузки (GGR/NGR, KYC/AML, RG), аудит денег.

Продукт/маркетинг: LTV/retention, сегментация, A/B, рекомендации.

Операции: мониторинг провайдеров, PSP, SLA live-игр и кассы.

Решения на данных: быстрые витрины (DWH) поверх дешёвого долговременного хранения (Lake).

Итог: Lake хранит сырые и очищенные слои, DWH даёт быстрые запросы и управляемые модели.

2) Референс-архитектура (lakehouse)


Sources (OLTP, Kafka, Webhooks, CDC)
│
├─Bronze (raw, append-only; Parquet/Delta/Iceberg)
│   ingestion_time, source_metadata, no schema changes in place
├─Silver (cleaned, conformed; dedup, PII masking, SCD2)
│   business keys, constraints, quality checks
└─Gold (marts; star/snowflake; cube tables, aggregates)
└─DWH/Query Engines (Snowflake/BigQuery/Trino/Spark SQL)

Форматы: Delta Lake / Apache Iceberg / Hudi (ACID в lake, time travel, MERGE).

Файлы: Parquet + ZSTD/Snappy, таргет ~128–512 МБ; компакция «мелких файлов».

Каталог: Hive/Unity/Iceberg Catalog; зоны `bronze/silver/gold` на бакетах per region/tenant.

3) Доменные схемы (концептуально)

3.1 Кошелёк/бухгалтерия

`wallet_entry`: `entry_id`, `account_id`, `direction (debit	credit)`, `amount_minor`, `currency`, `reason`, `reference_id`, `occurred_at`, `region`, `tenant_id`, `trace_id`, `idempotency_key`.
Инвариант: сумма по счёту = баланс (через snapshot + change log).

3.2 Ставки/сеттлмент (RGS/live)

`bet`: `bet_id`, `round_id`, `player_id`, `game_id`, `stake_minor`, `currency`, `placed_at`, `brand/region`, `provider_id`, `in_bonus`.

`settlement`: `settlement_id`, `bet_id`, `round_id`, `win_minor`, `settled_at`, `jackpot_hit`, `bonus_state`.

3.3 Платежи (касса/PSP/крипто)

`payment_intent`: `intent_id`, `player_id`, `method`, `status`, `amount`, `currency`, `psp`, `created_at`.

`capture/refund/chargeback`: отдельные таблицы со ссылками на `intent_id`, `psp_ref`, кодами причин.

Крипто: `txid`, `network`, `confirmations`, `finalized_at`.

3.4 Бонусы/вэйджер/джекпоты

`bonus_grant`, `bonus_progress (wager)`, `jackpot_contribution`, `jackpot_payout`.

3.5 Справочники и измерения

`dim_player` (псевдо-ID, гео, каналы, статусы RG — без PII в аналитике), `dim_game`, `dim_provider`, `dim_psp`, `dim_brand`, `dim_region`, календарные измерения.

Ключи и совместимость: в моделях Silver/Gold — стабильные бизнес-ключи (`bet_id`, `round_id`, `payout_id`, `intent_id`) и семантика «идемпотентных» событий.

4) Потоки загрузки: стриминг + микробатчи

Стриминг (Kafka/Pulsar → Bronze): события OLTP и вебхуков, outbox/CDC, гарантии «по крайней мере один раз» с дедупликацией в Silver.

CDC (Debezium/лог репликации): изменение OLTP-таблиц (wallet/payments) → Bronze.

Микробатчи: отчёты PSP/банков/кастоди (SFTP/API) → Bronze Raw Files → нормализация.

MERGE в Silver: дедуп по `idempotency_key/event_id`, устранение опоздавших (`watermark`), SCD2 на измерениях.

5) SLA загрузок и окно опозданий (watermarks)

5.1 Типовые SLA (ориентиры)

Wallet/ledger events: Bronze ≤ 1–2 мин, Silver ≤ 5–10 мин, Gold marts ≤ 15 мин.

Bets/settlements: Bronze ≤ 1–2 мин, Silver ≤ 10 мин, Gold ≤ 30 мин.

Payments (PSP webhooks): Bronze ≤ 5 мин, Silver ≤ 15 мин, Gold ≤ 30–60 мин.

Крипто финальность: зависит от сети; витрины с lag N подтверждений.

Ежедневные отчёты PSP/банков: T+1 до 09:00 локального времени региона.

5.2 Окна опозданий

Watermark по времени события (`occurred_at`) + допуски:

кошелёк/ставки: 24–48 часов, платежи/PSP: 72 часа (бывают ретро-вебхуки), крипто: до 24 часов на редкие реорги.
Поздние события reprocess: пересчёт витрин Gold инкрементально (MERGE), журнал коррекций.

5.3 Коммуникация SLA

Каталог данных содержит SLA-атрибуты: `freshness_target`, `freshness_status`, `expected_lag_p95`, `watermark`.

Дашборды «свежести» с алертами при нарушении.

6) Качество данных (DQ) и контракты

Data Contracts для каждой темы: схемы Avro/JSON, semver, обязательные поля, бизнес-инварианты (например, `win_minor ≥ 0`, `currency ∈ ISO-4217`).

DQ-проверки Silver: уникальность ключей, референциальная целостность, балансная проверка (сверка кошелька), валидность кодов PSP/причин, диапазоны дат.

Severity: `ERROR` (блокирующее), `WARN` (маркируем), `INFO`.

Monitoring: % нарушений, топ причин, автоматические тикеты.

Sampling & replay: хранить сырые Bronze для повторной переработки.

7) PII, резидентность и безопасность

PII-витрина отделена от аналитики: в Silver/Gold — псевдоним, маскирование/хеши, токенизация.

Data residency: EU/UK/BR и др. — физически отдельные бакеты/каталоги; никакого кросс-регионального чтения без согласия и проксей.

Доступ: RBAC/ABAC (Lake/DWH), row-level security по `tenant/brand/region`.

Шифрование: at-rest (KMS) и in-transit, ключи per region/brand, аудит WORM доступа и изменений политик.

Право на забвение: механизм локализации игровых данных без удаления финансовых записей (де-идентификация).

8) Моделирование витрин Gold (звезда)

8.1 Факт-таблицы

`fact_bets` (ставка и сеттлмент на строку/или две таблицы), `fact_wallet_entries`, `fact_payments` (депозиты/кэшауты/возвраты), `fact_bonus_wager`, `fact_jackpot`.

8.2 Измерения

`dim_date/time`, `dim_player` (pseudonymous), `dim_game`, `dim_provider`, `dim_psp`, `dim_brand`, `dim_region`, `dim_currency`.

8.3 Метрики и расчёты

GGR/NGR, удержание/частота, RTP (по игре/провайдеру/региону), конверсия депозита, settle lag, success-rate PSP, cost-per-success, FX-PnL, jackpot contributions/payouts.

9) Производительность и стоимость

Партиционирование: по `occurred_date` + `region/tenant`, иногда `game_id` для Gold-агрегатов.

Кластеризация/Z-Order: по `player_id`, `game_id`, `psp`, `currency`.

Компакция и вакуум: плановые `OPTIMIZE/COMPACT`, удаление «висячих» версий (с учётом правовых ретеншенов).

Кэши: result-cache/warehouse cache, materialized views для горячих панелей.

Индексы в DWH: кластерные/сегментные (Snowflake clustering keys, BigQuery partition+cluster).

Стоимость: холодные Bronze в объектном хранилище, горячие Gold/март-агрегаты — в DWH; авто-паркинг/авто-скейл.

10) Линейдж, каталоги и документация

Data Catalog (OpenMetadata/Amundsen/Collibra): описание таблиц, владелец, SLA, поля PII, политики доступа.

Линейдж: от источника (событие/CDC) до витрины и отчёта; видимость зависимостей для безопасных изменений.

Changelog схем: semver и журнал депрекейтов; тесты совместимости в CI пайплайнов.

11) Reconciliation (сверки данных)

Ежедневно:

`wallet_entry` ↔ итоговые балансы (накопление ≡ снапшот), платежи: отчёты PSP/банков ↔ `fact_payments`, крипто: `txid/network` ↔ `fact_payments`.
Категории: `match`, `timing`, `missing_source`, `missing_platform`, `amount_mismatch`.
Алерты: доля `mismatch` > порога; aging несверенных > N дней.

12) Экземплярные SLA-таблицы (пример)

Домен	Bronze (ингест)	Silver (очистка)	Gold (март)	Поздние события (watermark)
Wallet	≤2 мин	≤10 мин	≤15 мин	48 ч
Bets/Settlements	≤2 мин	≤10 мин	≤30 мин	48 ч
Payments (PSP)	≤5 мин	≤15 мин	≤60 мин	72 ч
Crypto	realtime→финальность	≤15 мин	≤60 мин	24 ч
Reports (T+1)	06:00–08:00	≤09:00	≤10:00	7 д

13) Пайплайны: из чего собираем

Ingestion: Kafka Connect/Debezium, облачные ingestion-сервисы, SFTP pullers.

ETL/ELT: Spark/DBT/Trino/Beam/Flink (стриминговые Silver), Airflow/Argo для оркестрации.

Качество: Great Expectations/Deequ/dbt tests.

Мониторинг: OpenTelemetry + метрики Lake/DWH (freshness delay, job latency, cost).

Аварии и повтор: reprocess из Bronze, дедуп ключами, версионированные пайплайны.

14) Чек-листы

Архитектура и безопасность

Lakehouse-формат (Delta/Iceberg/Hudi) с ACID и time travel.
Разделение `bronze/silver/gold`, outbox/CDC как главные источники.
PII-изоляция, токенизация, RLS по `tenant/brand/region`.
Резидентность на уровне бакетов/каталогов, ключи/секреты per region.
WORM-аудит изменений схем/политик/правил доступа.

Качество и SLA

Data Contracts и semver-схемы; тесты совместимости.
Watermarks и reprocess, витрины инкрементальные MERGE.
Дашборды свежести и SLA-алерты; owner у каждой таблицы.
Reconciliation по кошельку/платежам/крипто.

Производительность и стоимость

Партиционирование и кластеризация; компакция «мелких файлов».
Материализованные витрины под ключевые отчёты.
Автоскейл/автопаркинг, политикa ретеншена и архивов.

15) Красные флаги (анти-паттерны)

BI и регуляторные отчёты бьют по OLTP напрямую.

Bronze «переписывается» и теряет сырые данные.

Нет watermarks, поздние события «обрезаются».

Отсутствие дедупа по `idempotency_key`/`event_id` → дубли в Gold.

PII и деньги разных регионов хранятся вместе без RLS и резидентности.

Схемы меняются «тихо» (без semver/контрактов), ломая витрины.

Миллионы мелких Parquet-файлов без компакции → дорогие запросы.

Нет SLA/дашбордов свежести; «сюрпризы» в квартальной отчётности.

16) Заключение

Data Lake + DWH в iGaming — это не просто хранилище, а контролируемая экосистема: стандартизированные схемы и контракты, ACID-lakehouse, чёткие SLA свежести и окна опозданий, качество и линейдж, безопасность PII и резидентность. Добавьте reconciliation и экономию на партиционировании/компакции — и у вас появится фундамент для отчётности, продуктовых решений и масштабирования бизнеса без ночных миграций и «ручных Excel».