Convoyeurs analytiques et ETL

(Section : Technologie et infrastructure)

Résumé succinct

La chaîne d'analyse transforme les événements opérationnels « bruts » d'iGaming (paris, dépôts, webhooks PSP, logs de jeux) en des vitrines de métriques durables (GGR/NGR, LTV, rétention, antifrod). Principes de référence : modèle de couche unique (Bronze/Argent/Or), discipline instrumentale DQ/lignage, incrémentalité et idempotence, observabilité et SLO, contrôle des coûts. Les décisions sont prises en tenant compte du profil de charge (pics de tournois), de la réglementation (PII/localisation) et des exigences de l'entreprise en matière de fraîcheur des données.

1) Architectures : ETL vs ELT, batch vs stream

ETL (Extract → Bou → Load) : transformations avant chargement en DWH. Convient lorsque les transformations nécessitent un environnement contrôlé/secrets jusqu'au « nuage ».
ELT (Extract → Load → Bou) : matière première dans Lake/Lakehouse/DWH, SQL/moteur (scripts dbt/SQL). Pratique pour les moteurs de colonne et les itérations flexibles.
Batch : fenêtres planifiées (toutes les 5/15/60 minutes, nightly). Bon marché et prévisible.
Stream: почти real-time (Kafka → Flink/ksqlDB → OLAP). Pour les vitrines de temps proche-réel (5-60 secondes) et les signaux antifrod/CRM.
Hybride : Bronze se remplit de strim, Silver/Gold est un modèle de batch incrémental.

Recommandation : Dans iGaming garder ELT + streaming : événements à travers CDC/outbox → Bronze (minute de fraîcheur), transformations incrémentielles en Argent/Or.

2) Modèle stratifié (Medallion)

Bronze (Raw) : événements bruts/CDC sans logique d'entreprise. Formats Parquet/ORC, schémas tels quels, validation minimale.
Silver (Conformed) : nettoyage, déduplication, normalisation des identifiants, mesures SCD, unification des monnaies/fuseaux horaires.
Gold (Marts) : vitrines commerciales (faits/mesures, cubes), vues materialisées, préagrégations (jours/pays/produits).

Avantages : reproductibilité, évolution transparente, SLO et TTL différents par couches.

3) Sources et chargement : CDC, outbox, fichiers

CDC (Change Data Capture) : flux de modification à partir de l'OLTP (Postgres/MySQL) avec une garantie d'ordre et d'idempotence.
Modèle Outbox : les événements sont enregistrés dans la table/collection outbox dans la transaction de service → le connecteur publie dans le bus/lac.
Téléchargement de fichiers : Déchargement PSP, rapports d'affiliation ; utilisez les manifestes, le contrôle des prises (checksum) et les catalogues de réception.

Pratiques : les sources sont converties (schema version), pour chaque source, un contrat de champs et des attentes de qualité.

4) Orchestration : DAG, dépendances, dépliant

DAGi : dépendances évidentes (raw → staging → dims → facts → marts).
Idempotence des tâches : redémarrage sans effets secondaires (partition-overwrite, 'MERGE '/upsert).
Séparation des environnements : Dev/Stage/Prod, promotion d'artefacts, « porte manuelle » (manual approval) pour backfill coûteux.
Planification : cron/fenêtres temporelles + déclencheurs d'événements (à l'arrivée des fichiers/lots).
Secrets : du gestionnaire secret ; interdiction des secrets dans le code DAG.

python with DAG("dwh_daily", schedule="0  ") as dag:
bronze = ingest_cdc(source="payments", partition=hour())
silver = dedup_normalize(input=bronze)
dims  = build_dimensions(input=silver)
facts = build_facts(input=silver, dims=dims)
marts = build_marts(input=facts)
bronze >> silver >> [dims, facts] >> marts

5) Qualité des données (DQ) et lignage

Chèques DQ : exhaustivité (count, late arrivals), unicité des clés, gammes/règles de domaine (somme ≥ 0, devise dans l'annuaire).
Seuil de déclenchement : stop dur/soft-fail avec alert en fonction de la criticité de la table.
Lineage/catalogue : De retour à la source (tableaux, colonnes, métriques), propriétaires, documentation, classification PII.
Contrôle des schémas : tests de compatibilité automatiques (backward/forward-compatible), alert sur les modifications « cassantes ».

6) Simulation : SCD, surrogate keys, normalisation

SCD2 pour les mesures : 'valid _ from/valid _ to/is _ current', surrogate key ('_ sk') et naturel ('_ id').
SCD1 : réécriture pour les attributs non essentiels (par exemple, interface locale).
Surrogate keys : stable '_ sk' pour join, naturel keys - pour l'unicité.
Normaliser les mesures : snowflake là où les hiérarchies sont profondes ; sinon, star pour la vitesse.

7) Modèles incrémentiels et lot

Filigrane ('updated _ at',' ingest _ ts') : lire uniquement les lignes nouvelles/modifiées.
Stratégies incrémentielles : 'MERGE' par clé d'entreprise, 'INSERT OVERWRITE' par lot, 'DELETE + INSERT' pour les petits lots.
Répartition par date/heure/région ; clustering (sort keys/Z-order) par clés de filtrage et join.
Représentations matérialisées : préagrégation GGR/NGR, cache de sections populaires.
Apparx-agrégats : HLL/approx_distinct pour les vitrines bon marché top-N.

sql
MERGE INTO fact_deposits f
USING staging_deposits s
ON (f. deposit_id = s. deposit_id)
WHEN MATCHED THEN UPDATE SET amount = s. amount, status = s. status, updated_at = s. updated_at
WHEN NOT MATCHED THEN INSERT (...)
VALUES (...);

8) Backfill, reprocessing et gestion de l'histoire

Backfill : DAGs séparés avec limites de ressources et fenêtres ; une « fenêtre de vérité » claire (par exemple 2024-01-01.. 2025-11-05).
Reprise : les transformations déterministes → la reprise donnent le même résultat. Logage des versions du code du modèle.
Time-travel/tables versions : pratique pour les enquêtes et DR « erreurs logiques ».
Retraction : stratégie de révocation de données (suppression/correction) avec protocole.

9) convoyeur CLO/SLA/SLO

Fraîcheur (freshness) : Bronze ≤ 1-5 min, Argent ≤ 15 min, Or ≤ 60 min (exemple).
Fiabilité : pourcentage de tests DAG réussis ≥ 99. x%.
Performances : p95/p99 durées nœuds ; budget temps par parti.
Surveillance Lag : retard de l'ingest-strim, profondeur des files d'attente, proportion de « données late ».
Alerts : perturbation de la fraîcheur/du volume, faïences DQ, augmentation du coût des scans, dégradation des VM.

10) Coût : Prévision et optimisation

Les lots et les grappes minimisent le volume des scans.
Matérialisation des marqueurs chauds (jours/pays/produits).
Cache de résultats/MVs pour les dashboards fréquemment utilisés.
Contrôle de la fréquence des redémarrages (pas de « toutes les 5 minutes » sans raison).
TTL : Bronze agressif, argent moyen, or long (unités seulement).
Capacity planning : métriques de catalogue, prévisions des pics de tournois/campagnes.

11) Sécurité, PII et localisation

Classification des données : IPI/finances/opérations.
Cryptage : au repos et en transit ; KMS/rôle-accès basé.
De-identification : hachage/masquage, colonnes séparées avec des clés.
RLS/wuhi pour multi-tenance (par 'tenant _ id').
Localisation : zones de stockage et de traitement par région (EU/TR/LATAM) ; Exporter uniquement vers les emplacements autorisés.
Audit : lecture/écriture dans les tables critiques, accès au catalogue.

12) Observabilité : métriques, logs, tracés

Métriques du pipeline : durée des tâches, file d'attente, erreurs, retraits, volume des octets/lignes traités, coût.
Logs : structurés ; corrélation par 'trace _ id '/' run _ id'.
Tracing : de la source à la vitrine (ingest → bou → load → BI).
Dashboards : fraîcheur des couches, succès des DAGs, demandes top cher, p95/p99.

13) Outils (repères par rôle)

Orchestration : orchestrateurs DAG (avec planificateur, retraits, alertes, secrets).
Transformations : modélisation SQL (« modèles comme code »), tests unitaires de modèles, documentation.
DQ/contrats : cadres de vérification et SLA sur les ensembles de données.
Lineage/répertoire : Construction automatique du graphe de dépendance, recherche du propriétaire.
Streaming : processeurs de fenêtres/agrégations, connecteurs sink/source.

(Les fournisseurs spécifiques sont choisis pour la pile de l'entreprise et les exigences de sécurité.)

14) Exemples de modèles

Modèle de vitrine GGR (généralisé par SQL)

sql
CREATE OR REPLACE TABLE mart_ggr_daily AS
SELECT
DATE(b. ts) AS d,
c. country_code,
SUM(b. stake) AS stake_sum,
SUM(b. win)  AS win_sum,
SUM(b. stake - b. win) AS ggr
FROM fact_bets b
JOIN dim_country c ON c. country_sk = b. country_sk AND c. is_current
WHERE b. ts >= DATE_SUB(CURRENT_DATE, INTERVAL 60 DAY)
GROUP BY d, c. country_code;

Modèle incrémental avec filigrane

sql
INSERT INTO fact_bets PARTITION (dt)
SELECT
FROM staging_bets
WHERE updated_at > (SELECT COALESCE(MAX(watermark), '1970-01-01') FROM _meta_watermarks WHERE table='fact_bets');
-- then update watermark

Vérifications DQ (idée)

sql
-- 1) key uniqueness
SELECT deposit_id FROM fact_deposits GROUP BY deposit_id HAVING COUNT()>1;

-- 2) negative amounts (error)
SELECT FROM fact_deposits WHERE amount < 0;

15) Chèque de mise en œuvre

1. Identifiez le dictionnaire des métriques (GGR/NGR/LTV/Retraite) et des propriétaires.
2. Fixez le SLO de fraîcheur sur les couches Bronze/Argent/Or.
3. Uniformiser les contrats sources (schémas, DQ, SLA).
4. Construisez un graphe DAG avec des étapes idempotentes et des secrets isolés.
5. Implémentez l'incrémentalité (MERGE/overwrite par lots) et les filigranes.
6. Incluez le DQ (Critique/Soft Check), la ligne et le catalogue de données.
7. Ajustez l'observabilité (métriques, logs, trajets) et les alertes.
8. Entrez la stratégie Retensh/TTL et backfill/reprocessing.
9. Assurez le contrôle PII, le cryptage, le RLS et la localisation.
10. Réalisez un game-day : simulation d'une chute de source « cassant » des schémas, backfill de masse.

16) Anti-modèles

« Un ETL de nuit pour tout » sans partis et incrémentalité.
L'absence de DQ et de lignage → les rapports conflictuels et la « chasse aux fantômes ».
Recyclage complet des tables à chaque démarrage (explosion du coût).
Ligament dur en temps réel sans tampons/retraits.
Mélange de PII et de vitrines publiques sans segmentation et masquage.
Aucune stratégie de retraction/suppression (impossible de corriger les erreurs).

Résultats

Le pipeline d'analyse durable d'iGaming est un téléchargement ELT + en continu dans un modèle stratifié avec DQ/lineage rigide, modèles incrémentiels, orchestrateur transparent et SLO mesurable. Ajoutez le contrôle des coûts, la politique PII/localisation, les exercices réguliers backfill/DR - et votre plate-forme d'analyse s'adaptera de manière fiable aux pics de tournoi, répondant aux données de l'entreprise avec la fraîcheur et la qualité souhaitées.