Analyse Stream vs Batch

1) Une brève essence

Stream - traitement continu des événements en quelques secondes : antifrod/AML, déclencheurs RG, alertes SLA, panneaux opérationnels.
Batch - recalculations périodiques avec reproductibilité complète : rapports réglementaires (GGR/NGR), Finsverks, ML-datacets.

Repères : Stream p95 e2e 0. 5-5 s, Batch D + 1 à 06:00 (lok.) .

2) Matrice de sélection (TL ; DR)

Règle 80/20 : tout ce qui ne nécessite pas de réaction <5 minutes est dans Batch ; le reste est à Stream, avec la validation nocturne de Batch.

3) Architectures

3. 1 Lambda

Stream pour en ligne + Batch pour la consolidation. Plus : flexibilité. Moins : deux logiques.

3. 2 Kappa

Tout comme les flux ; Batch = « repli » à travers le journal. Plus : code unique. Moins : complexité des relais/coût.

3. 3 Lakehouse-Hybride (recommandé)

Stream → OLAP-marts opérationnels (minutes) et Bronze/Argent ; Batch revisite Gold (D + 1) et publie des rapports.

4) Données et temps

Stream

Fenêtres : tumbling/hopping/session.
Watermarks : 2-5 min ; late data est marquée et finie.
Stateful : CEP, dedup, TTL.

Batch

Incréments/CDC : 'updated _ at', réplication log.
SCD I/II/III : historique des attributs.
Snapshots : couches diurnes/mensuelles pour « as-of ».

5) Modèles d'application dans iGaming

AML/Antifrod : Stream (velocity/structuration) + Batch rapprochements et cas.
Responsible Gaming : Contrôle stream des limites/auto-exceptions ; Registres de rapports Batch.
Opérations/SRE : Stream alerte SLA ; Batch post-analyse des incidents et des tendances.
Produit/marketing : Personnalisation de flux/missions ; Cohortes Batch/LTV.
Finances/rapports : Batch (Gold D + 1, paquets WORM), Stream - panneaux opérationnels.

6) DQ, reproductibilité, repli

Stream DQ : validation des schémas, dédup' (event_id, source) ', fenêtre complète, late-ratio, dup-rate ; un → critique de DLQ.
Batch DQ : unicité/FK/range/temporal, rapprochement avec les fournisseurs/OLTP ; critique → rapport fail job +.

• Stream : repliement des tops par gamme de transformation + deterministic.
• Batch : time-travel/version logique ('logic _ version') + snapshots Gold.

7) Intimité et résidence

Stream : pseudonymisation, masquage en ligne, convoyeurs régionaux (EEE/UK/BR), temporisation sur les PII-lookups externes.
Batch : isolation des mappings PII, RLS/CLS, DSAR/RTBF, Legal Hold, archives WORM.

8) Cost-engineering

Stream : éviter les clés « chaudes » (salting), limiter async lookups, TTL d'état, pré-agrégation.
Batch : lot/clustering, compaction de petits fichiers, matérialisation d'agrégats stables, quotas/fenêtres de démarrage.

9) Exemples

9. 1 Stream - Flink SQL (10 min de dépôts velocity)

sql
SELECT user_id,
TUMBLE_START(event_time, INTERVAL '10' MINUTE) AS win_start,
COUNT() AS deposits_10m,
SUM(amount_base) AS sum_10m
FROM stream. payments
GROUP BY user_id, TUMBLE(event_time, INTERVAL '10' MINUTE);

9. 2 Stream - CEP (pseudo-code AML)

python if count_deposits(10MIN) >= 3 and sum_deposits(10MIN) > THRESH \
and all(d. amount < REPORTING_LIMIT for d in window):
emit_alert("AML_STRUCTURING", user_id, snapshot())

9. 3 Batch - MERGE (Incrément Silver)

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

9. 4 Batch — Gold GGR (D+1)

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) event_date,
b. market, g. provider_id,
SUM(b. stake_base) stakes_eur,
SUM(p. amount_base) payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) 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;

10) Métriques et SLO

Stream (repères)

p95 ingest→alert ≤ 2–5 c completeness окна ≥ 99. 5%

schema-errors ≤ 0. 1%

late-ratio ≤ 1%

disponibilité ≥ 99. 9%

Batch (repères)

Gold. daily prêt jusqu'à 06:00 lok.

completeness ≥ 99. 5%

validity ≥ 99. 9%

Incident DQ MTTR ≤ 24-48 h

11) Tests et releases

Contrats/schémas : tests de consommation ; back-compat CI.
Stream : règles canaries, démarrage sombre, simulateur de replay.
Batch : dry-run sur les échantillons, comparaison des métriques, sommation de contrôle (reconciliation).

12) Anti-modèles

Duplication logique : différents calculs Stream et Batch sans alignement de formules.
API externes synchrones dans le chemin d'accès Stream chaud sans cache/temporisation.
Reload complet « au cas où » au lieu d'incréments.
Pas de stratégie watermarks/late.
PII dans les couches analytiques ; absence de CLS/RLS.
Des vitrines dorées qui « mutent » rétroactivement.

13) Hybride recommandé (Pleybuk)

1. Circuit Stream : ingest → pneu → Flink/Beam (watermarks, dedup, CEP) →

OLAP (ClickHouse/Pinot) pour panneaux 1-5 min + Bronze/Argent (append).
2. Contour de batch : incréments/CDC → Normalisation de l'argent/SCD → Gold vitrines/rapports journaliers (WORM).
3. Alignement : une seule couche sémantique de métriques ; le rapprochement nocturne des Stream↔Batch ; écarts> seuil → tiquets.

14) RACI

R (Responsible) : Streaming Platform (Stream infra), Data Engineering (Batch Model), Domain Analytics (métriques/règles), MLOps (fiches/Feature Store).
A (Accountable): Head of Data / CDO.
C (Consulted): Compliance/Legal/DPO, Finance (FX/GGR), Risk (RG/AML), SRE (SLO/стоимость).
I (Informed) : BI/Produit/Commercialisation/Opérations.

15) Feuille de route

1. Kafka/Redpanda + 2 axes critiques ('payments', 'auth').

2. Flink-joba : watermark + dedup + 1 règle CEP (AML ou RG).

3. OLAP-vitrine 1-5 min + dashboards lag/late/dup.

4. Lakehouse Silver (ACID), le premier Gold. ggr_daily (D + 1 à 06:00).

• Incréments/CDC par domaine, SCD II, couche sémantique de métriques.
• Le streaming DQ et les rapprochements nightly sont Stream↔Batch.
• Régionalisation (EEE/Royaume-Uni/BR), DSAR/RTBF, Legal Hold.

• Simulateur de relais, versions canary/A-B des règles/métriques.
• Cost-dashboards et quotas ; tiered storage; Exercice DR.
• Autogénération de la documentation vitrine/métriques et lineage.

16) Chèque de mise en œuvre

• Régimes/contrats dans le Registre ; les tests back-compat sont verts.
• Stream: watermarks/allowed-lateness, дедуп, DLQ; Panneaux OLAP dans la vente.
• Batch : incréments/CDC, SCD II, Gold D + 1 avec exportations WORM.
• Une seule couche sémantique de métriques ; nightly rapprochement Stream↔Batch.
• DQ-dashboards Freshness/Completeness/Validity ; alerte lag/late/dup.
• RBAC/ABAC, cryptage, résidence ; DSAR/RTBF/Legal Hold.
• Coût sous contrôle (cost/GB, cost/query, taille de l'état, les replis sont quantifiés).

17) Résultat

Stream et Batch ne sont pas des concurrents, mais deux engrenages d'un même moteur. Stream donne la réaction « ici et maintenant », Batch est la vérité vérifiable « pour le matin ». L'approche hybride Lakehouse, une seule couche de métriques et la discipline DQ/lineage permettent de construire des boucles analytiques rapides, reproductibles et compressives, optimales en SLA et en coût.