Data Lake et DWH pour le casino : schémas, téléchargements SLA

Texte intégral de l'article

💡 18+. Matériel technique pour plates-formes/opérateurs, studios et équipes d'analyse. Pas un appel au jeu. La plate-forme comprend PAM/portefeuille/caisse/bonus/RG, les fournisseurs sont RGS/live/jackpots/intégrations payantes.

1) Pourquoi Data Lake et DWH Casino

Rapport et conformité : décharges réglementaires (GGR/NGR, KYC/AML, RG), vérification de l'argent.

Produit/marketing : LTV/retraite, segmentation, A/B, recommandations.

Opérations : surveillance des fournisseurs, PSP, SLA des jeux en direct et de la caisse.

Solutions de données : vitrines rapides (DWH) au-dessus du stockage à long terme bon marché (Lake).

Résultat : Lake stocke les couches crues et nettoyées, DWH donne des requêtes rapides et des modèles contrôlés.

2) Architecture de référence (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).

Fichiers : Parquet + ZSTD/Snappy, cible ~ 128-512 Mo ; compaction de « petits dossiers ».

Catalogue : Catalogue Hive/Unity/Iceberg ; les zones 'bronze/argent/or' sur les bacs per region/tenant.

3) Schémas de domaine (conceptuels)

3. 1 Portefeuille/Comptabilité

`wallet_entry`: `entry_id`, `account_id`, `direction (debit	credit)`, `amount_minor`, `currency`, `reason`, `reference_id`, `occurred_at`, `region`, `tenant_id`, `trace_id`, `idempotency_key`.
Invariant : somme par compte = solde (via snapshot + change log).

3. 2 Paris/settlment (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 Paiements (caisse/PSP/crypto)

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

'Capture/refund/chargeback ': tables séparées avec des références à' intent _ id ',' psp _ ref ', codes de cause.

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

3. 4 Bonus/Wager/Jackpots

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

3. 5 Manuels et mesures

« bou _ player » (pseudo-ID, géo, canaux, états RG - sans PII dans l'analyse), « bou _ game », « bou _ provider », « bou _ psp », « bou _ brand », « bou _ region », mesures de calendrier.

Clés et compatibilité : dans les modèles Silver/Gold, les clés commerciales stables ('bet _ id', 'round _ id', 'payout _ id', 'intent _ id') et la sémantique des événements « idempotent ».

4) Flux de téléchargement : streaming + microbatches

Streaming (Kafka/Pulsar → Bronze) : événements OLTP et webhooks, outbox/CDC, garanties « au moins une fois » avec déduplication dans Silver.

CDC (Debezium/logue de réplication) : modification des tables OLTP (wallet/payments) → Bronze.

Microbatches : rapports PSP/banques/castodi (SFTP/API) → Bronze Raw Files → normalisation.

MERGE dans Silver : dedup par 'idempotency _ key/event _ id', élimination des retardataires ('watermark') SCD2 sur les mesures.

5) téléchargements SLA et fenêtre de retard (watermarks)

5. 1 SLA type (repères)

Wallet/ledger events : Bronze ≤ 1-2 min, Argent ≤ 5-10 min, Marts d'or ≤ 15 min.

Bets/settlements : Bronze ≤ 1-2 min, Argent ≤ 10 min, Or ≤ 30 min.

Payments (PSP webhooks) : Bronze ≤ 5 min, Argent ≤ 15 min, Or ≤ 30-60 min.

Crypto finalité : dépend du réseau ; vitrines avec lag N de confirmation.

Rapports quotidiens PSP/banques : T + 1 à 09:00 heure locale de la région.

5. 2 fenêtres de retard

Watermark par heure d'événement ('occurred _ at') + tolérances :

portefeuille/taux : 24-48 heures, paiements/PSP : 72 heures (il y a des webhooks rétro), crypto : jusqu'à 24 heures pour les reorgs rares.
Événements tardifs reprocess : recalculer les vitrines Gold incrémentalement (MERGE), journal des corrections.

5. 3 Communication SLA

Le répertoire de données contient les attributs SLA : 'freshness _ target', 'freshness _ status', 'expected _ lag _ p95', 'watermark'.

Dashboards de « fraîcheur » avec alerts en cas de violation.

6) Qualité des données (QD) et contrats

Contrats de données pour chaque sujet : schémas Avro/JSON, semver, champs obligatoires, invariants professionnels (par exemple, 'win _ minor ≥ 0', 'currency ∈ ISO-4217').

Vérification DQ Silver : unicité des clés, intégrité référentielle, vérification d'équilibre (rapprochement porte-monnaie), validation des codes PSP/causes, plages de dates.

Severity : 'ERROR' (bloquant), 'WARN', 'INFO'.

Monitoring :% de violations, causes principales, tickets automatiques.

Sampling & replay : Stocker les bruts de Bronze pour les recycler à nouveau.

7) PII, résidence et sécurité

La vitrine PII est séparée de l'analyse : dans Silver/Gold - alias, masquage/hachage, tokenisation.

Résidence de données : EU/UK/BR et al. - réservoirs/catalogues physiquement séparés ; pas de lecture croisée régionale sans consentement et sans proxénétisme.

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

Cryptage : at-rest (KMS) et in-transit, clés per region/brand, audit WORM d'accès et de modification des politiques.

Droit à l'oubli : mécanisme de localisation des données de jeu sans suppression des dossiers financiers (de-identification).

8) Simulation de vitrines Gold (étoile)

8. 1 Tableau des faits

'fact _ bets '(mise et settlement par ligne/ou deux tables),' fact _ wallet _ entries ',' fact _ payments ',' fact _ jackpot '.

8. 2 Mesures

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

8. 3 Mesures et calculs

GGR/NGR, rétention/fréquence, RTP (par jeu/fournisseur/région), conversion de dépôt, settle lag, taux de succès PSP, cost-per-success, FX-PnL, jackpot contributions/payouts.

9) Performance et coût

Lot : par 'occurred _ date' + 'région/tenant', parfois 'game _ id'pour les agrégats Gold.

Clustering/Z-Order : par 'player _ id', 'game _ id', 'psp', 'currency'.

Compaction et vide : planifié 'OPTIMIZE/COMPACT', suppression des versions « suspendues » (compte tenu des rétentions légales).

Caches : result-cache/warehouse cache, vues materialized pour les panneaux chauds.

Index en DWH : cluster/segment (Snowflake clustering keys, BigQuery partition + cluster).

Coût : Bronze froid dans le stockage d'objets, unités d'or/mars chaudes - en DWH ; auto-parking/auto-skale.

10) Ligne, catalogues et documentation

Catalogue de données (OpenMetadata/Amundsen/Collibra) : description des tables, propriétaire, SLA, champs PII, politiques d'accès.

Linéaire : de la source (événement/CDC) à la vitrine et au rapport ; visibilité des dépendances pour des changements sécurisés.

Changelog schémas : semver et deprecate journal ; tests de compatibilité dans les pipelines CI.

11) Reconnaissance (rapprochements de données)

Tous les jours :

'Wallet _ entry '↔ bilans totaux (accumulation de ≡ snapshot), paiements : rapports PSP/banques ↔' fact _ payments ', crypto :' txid/network '↔' fact _ payments '.
Категории: `match`, `timing`, `missing_source`, `missing_platform`, `amount_mismatch`.
Alertie : fraction « mismatch »> seuil ; aging non fidèles> N jours.

12) Tables SLA en instance (exemple)

Domaine	Bronze (ingest)	Silver (nettoyage)	Gold (mars)	Événements tardifs (watermark)
Wallet	≤2 min	≤10 min	≤15 min	48 h
Bets/Settlements	≤2 min	≤10 min	≤30 min	48 h
Payments (PSP)	≤5 min	≤15 min	≤60 min	72 h
Crypto	realtime→finalnost	≤15 min	≤60 min	24 h
Reports (T+1)	06:00–08:00	≤09:00	≤10:00	7 d

13) Piplines : De quoi récoltons-nous

Ingestion : Kafka Connect/Debezium, services d'ingestion dans le cloud, SFTP pullers.

ETL/ELT : Spark/DBT/Trino/Beam/Flink (streaming Silver), Airflow/Argo pour l'orchestration.

Qualité : Grandes expositions/Deeq/dbt tests.

Surveillance : OpenTelemetry + métriques Lake/DWH (freshness delay, job latency, cost).

Accidents et répétitions : reprise de Bronze, déduplication par clés, piplines versionnées.

14) Chèques-feuilles

Architecture et sécurité

Format Lakehouse (Delta/Iceberg/Hudi) avec ACID et voyage temporel.
Séparation 'bronze/argent/or', outbox/CDC comme sources principales.
Isolation PII, Tokenization, RLS par « tenant/brand/region ».
Résidence au niveau des réservoirs/répertoires, clés/secrets par région.
Audit WORM des modifications des schémas/politiques/règles d'accès.

Qualité et SLA

Contrats de données et schémas semver ; tests de compatibilité.
Watermarks et reprocess, vitrines incrémentales MERGE.
Dashboards de fraîcheur et alertes SLA ; owner à chaque table.
Reconnaissance par portefeuille/paiements/crypto.

Productivité et coût

Répartition et regroupement ; compaction de « petits dossiers ».
Vitrines matérialisées sous des rapports clés.
Auto-Skale/Auto-Marking, Politique de Retensh et Archives.

15) Drapeaux rouges (anti-modèles)

BI et les rapports réglementaires frappent l'OLTP directement.

Bronze « réécrit » et perd les données brutes.

Pas de watermarks, les événements tardifs sont « circoncis ».

Aucune déduplication par 'idempotency _ key '/' event _ id' → prise en or.

L'IPI et l'argent des différentes régions sont stockés ensemble sans RLS ni résidence.

Les schémas changent « tranquillement » (pas de semver/contrats), brisant les vitrines.

Des millions de petits fichiers Parquet sans compaction → des demandes coûteuses.

Pas de SLA/dashboards de fraîcheur ; « surprises » dans le rapport trimestriel.

16) Conclusion

Data Lake + DWH dans iGaming n'est pas seulement un stockage, mais un écosystème contrôlé : schémas et contrats standardisés, ACID-lakehouse, SLA clair de fraîcheur et fenêtres de retard, qualité et linéarité, sécurité PII et résidence. Ajoutez la récupération et les économies de lot/compactage - et vous aurez les bases de la reddition de comptes, des solutions de produits et de l'échelle de l'entreprise sans migration nocturne et « Excel manuel ».