Entrepôts de données

1) Le but et le rôle de DWH dans iGaming

• Définitions de métriques uniques (GGR/NGR, ARPPU, Retraite, Churn).
• Rapports récupérables à l'intention des organismes de réglementation et des opérateurs internes.
• Vitrines rapides pour BI/panneaux d'exploitation et sources pour les modèles.
• Contrôle de qualité, lineage et sécurité au niveau de la plateforme.

2) Options architecturales

2. 1 Classic DWH

ETL → DWH (étoile/flocon de neige) → BI.
Avantages : modèles guidés, cohérence forte.
Inconvénients : téléchargements coûteux, backfill complexe, flexibilité limitée.

2. 2 Lakehouse DWH

Bronze/Argent/Or sur les tables ACID (Delta/Iceberg/Hudi) + moteur SQL/MPP.
Avantages : un seul storedge, time-travel, simple reprocessing.
Inconvénients : nécessite la discipline des couches et du DQ, une orchestration mature.

2. 3 Hybride

Lakehouse en tant que « source de vérité » (Bronze/Silver), DWH-mars en MPP (ClickHouse/Pinot/Druid/Cloud DWH) pour la lecture à grande vitesse.
Avantages : équilibre des coûts et des performances, vitrines flexibles.
Inconvénients : double support des circuits et du rouleau, besoin de synchronisation.

Recommandation : pour iGaming - Lakehouse + DWH-mars (hybride). Bronze/Silver - standardisé, Gold/Real-time marts - sert les charges de lecture.

3) Modélisation des données

3. 1 L'étoile et le flocon de neige

Tables factuelles : étroites, événements : 'fact _ bets', 'fact _ payouts', 'fact _ payments'.
Dimensions : 'bou _ users' (SCD), 'bou _ games', 'bou _ providers', 'bou _ markets'.
Le flocon de neige est approprié dans Silver (normalisation), l'étoile dans Gold (lecture).

3. 2 Data Vault 2. 0 (noyau d'intégration)

Hubs (clés d'affaires), Liens (relations), Satellites (contexte/histoire).
Appliquer dans Silver pour les intégrations de fournisseurs/PSP à longue durée de vie.

3. 3 SCD I/II/III

SCD II pour RG/KYC/canaux et attributs de jeu (RTP/volatilité).
Intervalles stricts 'valid _ from/valid _ to', join-temps correct.

4) Téléchargement : ETL/ELT, CDC et incréments

Approche ELT : chargement dans Silver du → de transformation en DWH.
CDC : Debezium/réplication du journal à partir de l'OLTP ; les merges sont idempotentes.
Incréments : par l'eau du temps ('updated _ at> max_loaded_ts') et/ou le hash delta.
Backfill/Reprocessing : temps-voyage, fourchettes, quotas, comparaison dry-run.

sql
MERGE INTO silver. payments s
USING stage. payments_delta d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

5) Couche sémantique et métriques

Metrics Store/Semantic Layer : formule unique GGR/NGR/Conversion/LTV.
La versionation des métriques et le calcul « as-of » pour la reproductibilité.
Accords : noms des métriques, unités, monnaie (base EUR) et 'fx _ source'.

6) Vitrines et Serving

Vitrines d'or : dénormalisées, prêtes à l'emploi (par exemple, jusqu'à 06:00 lok.) .
Marts opérationnels : ClickHouse/Pinot/Druid pour les panneaux de 1 à 5 minutes.
Exportation : CSV/JSON/PDF + hash ; Paquets immuables (WORM) pour les régulateurs.

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) AS event_date,
b. market,
g. provider_id,
SUM(b. stake_base) AS stakes_eur,
SUM(p. amount_base) AS payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) AS ggr_eur
FROM silver. fact_bets b
LEFT JOIN silver. fact_payouts p
ON p. user_pseudo_id = b. user_pseudo_id
AND p. game_id = b. game_id
AND DATE(p. event_time) = DATE(b. event_time)
JOIN dim. games g ON g. game_id = b. game_id
GROUP BY 1,2,3;

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

Schema-first : JSON/Avro registry + tests de compatibilité (consumer-driven).
DQ-как-код: completeness/validity/uniqueness/FK/range/temporal.
Politiques de réaction : Critique → fail + DLQ ; major/mineur → balise et rapport.
Observation DQ : dashboards Freshness/Completeness/Validity, entonnoir d'enregistrements perdus.

8) Sécurité, vie privée et résidence

Minimisation des PII : utilisateurs via pseudo-ID ; les mappings séparément.
RLS/CLS : accès bâti/post-olbtso par rôle et par juridiction.
Cryptage : TLS en transit ; at-rest - KMS/CMK avec rotation.
Data Residency : catalogues et clés distincts pour l'EEE/UK/BR ; interdiction des join's cross-régionaux sans raison.
DSAR/RTBF : projections et édition sélectives ; Legal Hold pour les artefacts.

9) Performance et coût (Cost Engineering)

Lot : par date/marché/tenant ; clustering/Z-order par 'market', 'provider _ id', 'game _ id', 'user _ pseudo _ id'.
Formats : Parquet + statistiques et compression ; OPTIMIZE/VACUUM comme prévu.
Matérialisation : agrégats stables et tableaux sommaires ; évitez les join's « gras » à la volée.
Quotas/Chargeback : budgets pour les demandes lourdes/répliques ; rapports cost/query, cost/GB.
Tiered storage: hot/warm/cold; un SLA clair de récupération.

10) Observation et gestion

Métriques de pipline : durée, volumes, retraits, lagas, tolérance aux pannes.
Métriques DWH : temps de réponse/concurrence/cash hits/coût.
Lineage : graphique des sources aux rapports ; analyse d'impact en cas de changement.
SLO: Freshness Silver p95 ≤ 15 мин; Gold Daily - prêt avant 06:00 ; Validity ≥ 99. 9%; Completeness ≥ 99. 5%; disponibilité ≥ 99. 9%.

11) Multitenance et isolation de domaine

Division par schema/database/catalogue en tenant/marché.
Quotas et groupes de ressources ; limitation des « voisins bruyants ».
Politiques d'exportation/d'importation entre tenants, contrats normalisés.

12) Registre des données et documentation

Data Catalogue : owner, SLA, schéma, exemples, règles DQ, ligne.
Métriques/dashboards : cartes avec formules et responsables.
Change Log : versions logique, migration, impact (impact).

13) Processus et RACI

R (Responsible) : Data Engineering (modèles Silver/Gold, DAG 'et), Data Platform (infra, registry, DQ).
A (Accountable): Head of Data/CDO.
C (Consulted): Compliance/Legal/DPO, Finance (FX/GGR), Risk (RG/AML), SRE (SLO/стоимость).
I (Informed) : BI, Produit, Marketing, Opérations.

14) Feuille de route pour la mise en œuvre

1. Lakehouse Bronze/Silver (tables ACID), CDC/Incréments pour Paiements/Gameplay.

2. Premières vitrines dorées (GGR Daily, conversion), SLA jusqu'à 06:00.

3. DQ-comme-code (10-15 règles) + dashboards Freshness/Completeness.

4. Catalogue de données et couche sémantique de base des métriques.

• SCD II для users/games/providers; extension des domaines.
• Marts opérationnels (ClickHouse/Pinot) pour les panneaux real-time/near-real-time.
• Lineage/impact-analyse, procédures DSAR/RTBF, régionalisation (EEE/Royaume-Uni).

• Auto-simulation des changements (dry-run), repliement et comparaison des métriques.
• Chargeback/quotas, cost-dashboards ; Exercice DR et récupération du temps de voyage.
• Autogénération de la documentation des vitrines et des cartes métriques.

15) Exemples de modèles SQL

sql
CREATE TABLE silver. fact_bets (
bet_id STRING PRIMARY KEY,
user_pseudo_id STRING NOT NULL,
game_id STRING NOT NULL,
stake_ccy DECIMAL(18,2) NOT NULL,
currency CHAR(3) NOT NULL,
stake_base DECIMAL(18,2) NOT NULL,
market CHAR(2) NOT NULL,
event_time TIMESTAMP NOT NULL
);

sql
SELECT b. bet_id, u. rg_status
FROM silver. fact_bets b
JOIN dim. users_scd u
ON u. user_pseudo_id = b. user_pseudo_id
AND b. event_time >= u. valid_from
AND (u. valid_to IS NULL OR b. event_time < u. valid_to);

sql
SELECT market, DATE(event_time) d, COUNT() n
FROM silver. fact_bets
GROUP BY market, DATE(event_time)
HAVING n = 0;

16) Chèque-liste avant la vente

• Régimes et contrats dans le registre, tests d'interopérabilité verts.
• Les procédures CDC/incréments et MERGE sont idempotentes.
• Les vitrines d'or ont des SLA, des formules de métriques fixes.
• Les règles DQ sont actives (critical → fail + DLQ), dashboards Freshness/Completeness.
• RBAC/ABAC, chiffrement, résidence par région, journaux d'accès.
• Lineage/impact inclus ; temps-voyage/backup/DR vérifié.
• Coût sous contrôle : lots, regroupement, matérialisation, quotas.

17) Anti-modèles et risques

« Un DWH gras sans couches » : un mélange de données brutes et de rapports → chaos et des corrections coûteuses.
Reload complet tous les jours sans besoin : utilisez les incréments/CDC.
Or sans propriétaire et sans formules : l'absence d'une version unique de la vérité → la controverse et la régression.
PII dans les couches analytiques : garder les mappings séparés, CLS/RLS.
Absence de DQ/lineage : aucune preuve pour les régulateurs/auditeurs.
Coût non géré : pas de lots/optimisations/quotas.

18) Glossaire (résumé)

DWH est un entrepôt de données pour la consolidation et l'analyse.
Lakehouse - data lake + tables ACID et moteur SQL.
CDC - Capture des changements de l'OLTP.
SCD - Mesures à évolution lente (I/II/III).
Gold-vitrine - Tableau/présentation prêt à consommer.
Semantic Layer est une définition unique des métriques et des attributs.

19) Résultat

DWH moderne pour iGaming n'est pas une « grande table », mais une plate-forme gérable : couches Bronze/Silver/Gold, contrats stricts et DQ, métriques et lineage uniques, intimité et résidence, performance et rentabilité. En construisant l'hybride Lakehouse + DWH-Mars, vous obtiendrez une prise de décision rapide et vérifiable, prête à l'audit, à l'échelle et à de nouveaux marchés.