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→finalnost	≤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 за гаманцем/платежами/крипто.

Продуктивність і вартість

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

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».