Traitement par lots de données

1) Destination et valeur

• Rapports réglementaires et financiers (GGR/NGR, impôts, registres RG/AML).
• BI et analyses de produits (cohortes, LTV, entonnoirs de conversion).
• Sverok de précision (OLTP↔DWH, fournisseurs/PSP), historique (SCD).
• Préparation des fiches et des ensembles de formation pour ML.

Propriétés clés : prévisibilité, exhaustivité, reproductibilité, faible coût par unité de données.

2) Architecture (référence)

1. Ingest (raw capture) : HTTP/gRPC, CDC de l'OLTP, déchargement du fournisseur → Bronze.
2. Lakehouse: Bronze (raw, append-only) → Silver (clean/conform) → Gold (serve).
3. Orchestration : Airflow/Dagster/Prefect (DAG 'et, dépendances, retraits, SLA).
4. Traitement : Moteurs Spark/Trino/DBT/SQL ; le lot et les formats ACID (Delta/Iceberg/Hudi).
5. DQ et contrats : Schema Registry, règles DQ (YAML/SQL), tests de consommation.
6. Serving : couche BI/sémantique, déclarations d'exportation (CSV/PDF/JSON + hash), API/GraphQL.
7. Observabilité : métriques des pipelines, lineage, logs, coût (cost/GB, cost/query).

3) Fréquences et SLAs

Tous les jours (D + 1 à 06:00 lok.) : Rapports GGR, décharges réglementaires, rapprochements.
Horaire/quasi-horaire : panneaux opérationnels pour Ops/Finance.
Semaine/mois : finconsolidation, modèles et retroprocess.

• Les vitrines sont prêtes jusqu'à 06:00 heure locale.
• Freshness Silver p95 ≤ 15 min pour les microbatches/ ≤ 2 h pour les journées.
• Completeness ≥ 99. 5 %, Validation (schéma) ≥ 99. 9%.

4) Téléchargements incrémentiels et CDC

• CDC (Change Data Capture) : Debezium/log-réplication → Bronze → incréments dans Silver.
• Watermark par heure : 'updated _ at> max_loaded_ts'.
• Comparaison hash : 'md5 (row)' pour le détail des modifications.
• Upsert/Merge : mises à jour idempotentes Silver/Gold.

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

5) SCD (historique des mesures)

SCD I : réécriture (orthographe, corrections mineures).
SCD II : historique complet ('valid _ from/valid _ to/is _ current').
SCD III : « avant/après » pour de brèves comparaisons.

sql
MERGE INTO dim. users_scd t
USING stage. users u
ON t. user_pseudo_id = u. user_pseudo_id AND t. is_current = TRUE
WHEN MATCHED AND (t. country <> u. country OR t. rg_status <> u. rg_status)
THEN UPDATE SET t. is_current = FALSE, t. valid_to = CURRENT_TIMESTAMP
WHEN NOT MATCHED
THEN INSERT (user_pseudo_id, country, rg_status, valid_from, valid_to, is_current)
VALUES (u. user_pseudo_id, u. country, u. rg_status, CURRENT_TIMESTAMP, NULL, TRUE);

6) Backfill и Reprocessing

Backfill : remplissage primaire/dogme historique.
Reprocessing : recalculer les vitrines après modification de la logique/correction des données.

• Idempotence (MERGE/upsert), invariabilité Bronze, versioning logique.
• Time-travel pour les essais répétés ; snapshot de métadonnées.
• Guardrails : limitation des fourchettes, quotas et jobs compétitifs.
• Documentation : runbook avec étapes et critères d'achèvement.

7) Modélisation des couches

• Append-only, lots 'event _ date', 'jurisdiction', 'tenant'.
• Nous stockons le payload d'origine (pour forenser), nous fixons 'ingested _ at'.

• Normalisation et standardisation : FK/handbook, dedup, FX/timesons.
• Tableaux de faits/mesures (3NF/BCNF), DCS pour les mesures clés.

• Vitrines dénormalisées sous BI/Régulateur/Finance, SLA prêt.
• Matérialisation des agrégats ; artefacts d'exportation immuables (hash + WORM).

8) Qualité des données (DQ-comme-code)

yaml table: silver. payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: amount_positive type: range column: amount_base min: 0. 01 severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
severity: major
- name: unique_tx type: unique columns: [transaction_id]
severity: critical
- name: fk_user type: foreign_key column: user_pseudo_id ref_table: dim. users_scd severity: critical

Politiques de réaction : Critique → fail job + DLQ ; major/mineur → balise + rapport.

9) Couche sémantique et rapports

Définitions de métriques uniques (GGR/NGR, ARPPU, Retraite) dans semantic-layer/metrics-store.
La versionation des métriques ; intégration avec les paquets BI/exportation.
Rapports : CSV/JSON/PDF + sha256, journal de déchargement et Legal Hold si nécessaire.

10) Vie privée, résidence, sécurité

Minimisation des PII : pseudonyme des utilisateurs ; mapping - dans un circuit sécurisé séparé.
Résidence de données : catalogues/clés séparés selon l'EEE/UK/BR ; interdiction des join croisés sans fondement juridique.
Cryptage : TLS en transit ; KMS/CMK at-rest; contrôle des exportations.
DSAR/RTBF : projections déduites, édition sélective ; audit des accès.
Legal Hold : Archives WORM pour les artefacts réglementaires.

11) Productivité et coût

Répartition par date/marché/tenant ; Z-order/cluster selon les prédicats fréquents.
Formats : Parquet + tables ACID ; compression/statistiques, OPTIMIZE/VACUUM.
Matérialisation : agrégations stables en or ; éviter les jobs « monolithiques ».
Quotas/budgets : chargeback par équipe ; limites de backfill/demandes lourdes.
Planification : fenêtres à faible charge (nuit/week-end), priorités des files d'attente.

12) Observation et gestion

Métriques de pipline : durée, taux de réussite, retries, processed rows, cost/query.
Métriques DQ : completeness, validity, uniqueness, erreurs FK, drift.
Freshness heatmap : par domaines et marchés ; SLA-dashboards.
Lineage : origine de Bronze aux rapports ; analyse d'impact avant les changements.
Alert : Budgets SLO, dégradation du QD, retards, augmentation des coûts.

13) Exemples SQL/modèles

sql
CREATE OR REPLACE TABLE silver. payments AS
SELECT p. transaction_id,
p. user_pseudo_id,
p. currency,
p. amount_orig,
r. rate AS fx_rate_used,
p. amount_orig r. rate AS amount_base,
p. market,
CAST(p. event_time AS TIMESTAMP) AS event_time
FROM bronze. payment_events p
JOIN dim. fx_rates r
ON r. date = DATE(p. event_time)
AND r. ccy_from = p. currency AND r. ccy_to = 'EUR';

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;

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

14) Processus et RACI

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

15) Feuille de route pour la mise en œuvre

1. Lakehouse Bronze/Silver (format ACID), CDC/incréments pour 2-3 domaines.

2. DQ-comme-code : 10-15 règles pour Payments/Gameplay + CI-validation.

3. Première vitrine Gold (GGR Daily) avec SLA jusqu'à 06:00 ; exportations déclarées + hash.

4. Dashboards Freshness/Completeness/Cost, alertes de base.

• SCD II для users/games/providers; extension des domaines.
• Une couche sémantique de métriques ; rapprochement avec OLTP/fournisseurs (accuracy).
• Backfill/reprocessing, lineage et analyse d'impact, régionalisation (EEE/Royaume-Uni).

• Auto-simulation de changement (dry-run), budgets/quotas, chargeback.
• Documentation automatique (data product pages), exercice DR et récupération de temps de voyage.
• Optimisation des coûts (clustering, matérialisation, TTL, vide).

16) Chèque-liste avant la vente

• Contrats et schémas dans Registry, tests de compatibilité sont verts.
• Les téléchargements incrémentiels/CDC fonctionnent, MERGE est idempotente.
• Les règles DQ sont actives ; critical → fail + DLQ; signalement des infractions.
• SLA/dashboards de fraîcheur/plénitude ; les alerts sont faits.
• Les politiques PII/DSAR/RTBF/Legal Hold sont confirmées par Legal/DPO.
• Runbook 'et backfill/reprocessing/DR testés.
• Coût sous contrôle (cost/query, cost/GB, quouts).

17) Anti-modèles et comment éviter

Jobs de nuit monolithiques : fractionner en pas indépendants, parallèles par lots.
Full-reload sans besoin : utilisez des incréments/CDC/Merji.
Mélange de PII dans l'analyse : garder les mappings séparés, appliquer CLS/RLS.
Absence de DQ/lineage : entrez le DQ-as-code et suivez l'origine.
Backfill « manuel » : automatiser et documenter, limiter les gammes.
Coûts non gérables : clustering, matérialisation, rétentions politiques.

18) Glossaire (résumé)

CDC - Capture des changements de l'OLTP.
SCD - Mesures à évolution lente (I/II/III).
Lakehouse - data lake + tables ACID.
MERGE/Upsert sont des opérations de mise à jour idempotent.
Time-travel - lecture des versions historiques des tables.
WORM est un stockage invariable d'artefacts.

19) Résultat

Le traitement par lots est une discipline de convoyeurs prévisibles, reproductibles et composites. En suivant les principes de schema-first, incréments/CDC, historification SCD, DQ-as-code, observabilité et économie consciente, vous obtiendrez des vitrines d'or stables et des rapports vérifiés par des scintillants et prêts à être audités à tout moment.