Entrepôts de données et modèles OLAP
(Section : Technologie et infrastructure)
Résumé succinct
L'entrepôt de données (DWH) est la couche de référence de l'analyse iGaming : rapports aux régulateurs, rentabilité par produit/marché, LTV de cohorte, analyse antifrod, segmentation CRM et dashboards temps réel. Le DWH durable repose sur un modèle de données clair (Star/Snowflake/Data Vault), une intégration fiable (ETL/ELT + CDC), des performances réfléchies (moteurs de colonne, lots, MVs), une sémantique rigoureuse des métriques, une sécurité/PII et une gestion des coûts.
Approches architecturales
DWH classique (Kimball vs Inmon)
Kimball (Dimensional/Star/Snowflake) : vitrines rapides des rapports ; focus sur les faits et les dimensions, histoire SCD. Une temporisation rapide.
Inmon (Corporate Information Factory) : noyau normalisé + vitrines ; plus lourd dans le temps, mais strictement et centralement.
Data Vault 2. 0
Hubs-Links-Satellites : un modèle « brut » évolutif pour l'intégration des sources et l'audit des changements. Des vitrines Star sont construites au-dessus.
Data Lake / Lakehouse
Data Lake : fichiers bruts (Parquet/ORC) + répertoires (Hive/Glue/Unity/Metastore).
Lakehouse : couche unique pour batch/stream, tables ACID (Delta/Iceberg/Hudi), temps-voyage, upsert/merge, fichiers compacts, Z-order/Clustering.
Medallion (Bronze–Silver–Gold)
Bronze : données brutes (raw) + CDC.
Argent : nettoyé et conformé.
Gold : vitrines d'affaires/métriques/cubes.
Convient aux hybrides (Kafka → Bronze ; Silver в Lakehouse; Gold в ClickHouse/BigQuery/Snowflake).
Modèles OLAP : Star, Snowflake, Data Vault
Star Schema (star)
Tableau fact : transactions (taux, dépôts, sessions).
Dimensions : joueur, jeu, fournisseur, date/heure, géo, canal d'attraction.
Avantages : joyaux simples, performances prévisibles.
Snowflake
Normalisation des mesures (hiérarchies pays/régions/villes, hiérarchies de produits).
Avantages : moins de chevauchements ; moins - plus de joyaux.
Data Vault → Star
Les changements bruts sont mis en DV (audit, reproductibilité complète), les vitrines de rapports sont construites comme Star/Snowflake.
Intégration : ETL/ELT, CDC, changements lents
Pipline
Outbox/CDC de OLTP (Postgres/MySQL) → Kafka/connecteurs → Bronze.
ELT : nettoyage, dedup, normalisation en argent.
Logique d'entreprise et agrégations en or/vitrines.
SCD (Slowly Changing Dimensions)
Type 1 : réécriture (pour les champs non essentiels).
Type 2 : historique (versions datées) est la norme pour les profils/canaux/prix.
Type 3 : stocker une paire de valeurs (rarement).
sql
-- insert new dimension version
INSERT INTO dim_player (player_sk, player_id, country, valid_from, valid_to, is_current)
SELECT gen_sk(), s. player_id, s. country, now(), '9999-12-31', true
FROM staging_player s
LEFT JOIN dim_player d ON d. player_id = s. player_id AND d. is_current = true
WHERE d. player_id IS NULL OR d. country <> s. country;
-- closing the old version
UPDATE dim_player d
SET valid_to = now(), is_current = false
FROM staging_player s
WHERE d. player_id = s. player_id AND d. is_current = true AND d. country <> s. country;Couche sémantique et métriques « vraies »
Entrez une seule couche de métriques (semantic layer) : définitions GGR, NGR, Net Deposits, ARPPU, LTV, Churn, Retentation Cohorts.
Les métriques en tant que code (dbt metrics/LookML/Semantic Layer) → les mêmes formules dans tous les rapports.
Calendrier : table des dates/heures avec les attributs TZ/régions/week-end/campagnes.
Stockages et moteurs : sélection pour le profil
Colonnes et cloud DWH
ClickHouse : scans/agrégations ultra-rapides, représentations matérialisées, projections ; excellent pour événements/télémétrie et vitrines marketing.
BigQuery : serveur, échelle, caches/clusters automatiques ; le prix par scan ; Pratique pour les charges mixtes et ad hoc.
Snowflake : division compute/storage, clusters à la demande, time-travel ; transparent pour les différentes équipes.
Redshift/Vertica/Pinot/Druid : variantes sous OLAP/temps réel.
Tuning sous le profil
Lot par date/région/canal.
Clustering/triage par clés de filtrage/joyaux.
Compression et codage par dictionnaire.
Préagrégations (rollup, cubes), représentations matérialisées.
Approx fonction (HyperLogLog/approx_distinct) pour les notes bon marché.
Conception des performances
Groupement et regroupement
Le lot est la limite du compartiment. Lots journaliers/horaires pour les événements.
Clustering (sort keys/Z-order) : accélère les gammes et les join.
Représentations matérialisées (MV)
Pré-décompte GGR/NGR par jour/pays/produits.
Mise à jour incrémentale à partir de la bande CDC.
sql
CREATE MATERIALIZED VIEW mv_ggr_daily
ENGINE = SummingMergeTree()
PARTITION BY toYYYYMMDD(ts)
ORDER BY (country, product_id, toDate(ts)) AS
SELECT toDate(ts) AS d,
country,
product_id,
sum(stake) AS stake_sum,
sum(win) AS win_sum,
sum(stake - win) AS ggr
FROM bets
GROUP BY d, country, product_id;Modèles incrémentiels (dbt/ELT)
Stratégies 'insert _ overwrite' par lot, 'merge' par CDC, 'watermark' par 'updated _ at'.
Stratégies Join
Réplique des mesures dans chaque segment de lot (denorm).
Broadcast small dims; shuffle large facts avec tri par clé.
Coût : contrôle et optimisation
BigQuery/Snowflake : limitez la taille du scan (concevez des lots/clusters), incluez result cache/materialized views, limitez les auto-quêtes BI.
ClickHouse : taille des lots, fréquence des Merges, budget de stockage (TTL pour les événements bruts, les agrégations sont durables).
La sémantique des métriques réduit les calculs « doubles ».
Data pruning : rétention pour Bronze, agrégation pour Or.
Qualité des données (DQ), catalogue, lien
Chèques DQ : exhaustivité (completeness), unicité, fourchettes, règles commerciales (par exemple, GGR ≥ 0 dans les agrégats).
Data Catalogue & Lineage : descriptions des tables/champs, propriétaires, classification PII, trace du rapport à la source.
Contrôle des schémas : contrat d'événements/CDC, alertes en cas de modifications incompatibles.
Sécurité, conformité et multi-ténacité
Segmentation PII : zones séparées, masquage/pseudonyme, colonnes avec cryptage KMS.
RBAC/ABAC : rôles au niveau du projet/schémas/tables/lignes (RLS), bugs pour « need-to-know ».
Localisation des données : buckets/warehouses régionaux (EU/TR/LATAM).
Vérification de l'accès : qui a lu/changé les vitrines et les modèles.
DR, backups et reproductibilité
Versioner le code de données (dbt/git), environnement Dev/QA/Prod.
Snapshots de métastore/catalogue + versioning de table (time-travel).
Retensh/TTL des couches Bronze/Silver/Gold ; exportation de vitrines critiques.
Game-day : restauration des vitrines, vérification de l'intégrité des métriques.
Temps réel et vitrines hybrides
Stream-to-OLAP : Kafka → ClickHouse/Pinot/Druid pour les vitrines minutes.
Materialized views + CDC pour des mises à jour presque en ligne (5-15 min).
La couche sémantique reste unie : les métriques sont identiques en temps réel et en batch.
Exemple de vitrine « GGR par jour et par pays » (généralisé par SQL)
sql
CREATE TABLE fact_bets (
bet_id BIGINT,
player_sk BIGINT,
game_sk BIGINT,
country_sk BIGINT,
stake DECIMAL(18,2),
win DECIMAL(18,2),
ts TIMESTAMP
) PARTITION BY DATE(ts);
CREATE TABLE dim_country (
country_sk BIGINT PRIMARY KEY,
iso2 STRING,
region STRING,
valid_from TIMESTAMP,
valid_to TIMESTAMP,
is_current BOOL
);
-- Showcase
CREATE MATERIALIZED VIEW mart_ggr_daily AS
SELECT
DATE(ts) as d,
c. region,
SUM(stake) AS stake_sum,
SUM(win) AS win_sum,
SUM(stake - win) AS ggr
FROM fact_bets f
JOIN dim_country c ON c. country_sk = f. country_sk AND c. is_current
GROUP BY d, c. region;Chèque d'implémentation
1. Identifiez les sources et les domaines, fixez le dictionnaire des métriques.
2. Sélectionnez le modèle : DV pour les couches brutes/auditées + Star pour les vitrines.
3. Concevoir des lots/clusters pour les requêtes clés et les fenêtres.
4. Configurez CDC/ELT, stratégie SCD et clés surrogate.
5. Entrez le calque sémantique (métriques en tant que code) et le calendrier des dates/heures.
6. Créez des MVs/préagrégations pour les rapports coûteux.
7. Activez le DQ/catalogue/lineage et le contrôle des schémas.
8. Identifier RBAC/PII/localisation, cryptage, audit.
9. Personnalisez la surveillance p95/p99, le coût, les alertes sur les dégradations et les dépassements.
10. Exercices de DR réguliers et reproductibilité des environnements.
Anti-modèles
« Un fait géant sans lots » → des scans de téraoctets et la facture augmente.
Définitions incohérentes des métriques dans différents dashboards.
L'absence de SCD2 là où l'entreprise exige une histoire.
Normalisation prématurée des mesures : joyaux superflus et rapports lents.
Données brutes sans chèques DQ et lineage → rapports « rien ».
L'absence de rétraction/TTL → le stockage des ordures et l'explosion des coûts.
Résultats
L'iGaming-DWH robuste est un modèle clair (DV→Star), un dictionnaire de métriques unique, des lots/clusters corrects, des vitrines matérialisées, des DQ/lineage rigoureux, ainsi que des RBAC/PII/localisation. Ajoutez le streaming hybride pour la fraîcheur, géré par ELT et la discipline du coût - et obtenez une plate-forme d'analyse durable qui s'adapte aux tournois, aux rapports réglementaires et à l'étude ad hoc sans surprise dans p99 et budget.