Streaming et analyse en streaming
1) Destination et valeur
Le circuit de streaming permet de prendre des décisions « à la volée » :- Antifrod/AML : détection de la structuration des dépôts, des attaques velocity, des anomalies des fournisseurs.
- Jeu responsable (RG) : dépassement des limites, modèles de risque, auto-exclusion.
- Opérations/SRE : dégradation des SLA, surtensions d'erreurs, premiers signaux d'incident.
- Produit/marketing : événements de personnalisation, missions/quêtes, segmentation temps réel.
- Rapports en temps réel : vitrines GGR/NGR, panneaux d'exploitation.
Caractéristiques cibles : p95 end-to-end 0. 5-5 s, exhaustivité ≥ 99. 5%, coût géré.
2) Architecture de référence
1. Ingest/Edge
`/events/batch` (HTTP/2/3), gRPC, OTel Collector.
Validation des schémas, anti-duplication, géo-routage.
2. Bus d'événements
Kafka/Redpanda (lot par 'user _ id/tenant/market').
Retraite 3-7 jours, compression, DLQ/« quarantaine »pour les messages« battus ».
3. Traitement en continu
Flink / Spark Structured Streaming / Beam.
Opérateurs Stateful, CEP, watermark, lateness allowed, déduplication.
Enrichissement (Redis/Scylla/ClickHouse-Lookup), I/O asynchrone avec des temporisations.
4. Serving/vitrines opérationnelles
ClickHouse/Pinot/Druid pour l'agrégation minute/seconde et dashboards.
Feature Store (en ligne) pour l'analyse des modèles.
Alert topics → SOAR/tiketing/webhooks.
5. Stockage à long terme (Lakehouse)
Bronze (raw), Silver (clean), Gold (serve) — Parquet + Delta/Iceberg/Hudi.
Replay/backtest, time-travel.
6. Observabilité
Métriques de pipline, tracing (OTel), logs, lineage.
3) Régimes et contrats
Schema-first : JSON/Avro/Protobuf + Registry, 'schema _ version' dans chaque événement.
Évolution : back-compatible - nouveaux champs nullables ; breaking - '/v2 '+ double publication.
Champs obligatoires : 'event _ time' (UTC), 'event _ id', 'trace _ id', 'user. pseudo_id`, `market`, `source`.
4) Fenêtres, watermarks et données tardives
Fenêtres :- Tumbling (fixe), Hopping (avec chevauchement), Session (par inactivité).
- Watermark : seuil de « connaissance » par event-time ; par exemple, 2 à 5 minutes.
- Late data : pré-émission des corrections, « late = true », DLQ en retard important.
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);
5) Stateful-agrégation et PPE
Clé : 'user _ id', 'device _ id', 'payment. account_id`.
État : montants glissants/compteurs, sessions, filtres bloom pour le dédupit.
Modèles PPE : structuration (<seuil, pour la ≥N fois, par la fenêtre T), périphérique-switch, RG-fatigue.
python if deposits.count(last=10MIN) >= 3 and deposits.sum(last=10MIN) > THRESH and all(d.amount < REPORTING_THRESHOLD):
emit_alert("AML_STRUCTURING", user_id, window_snapshot())
6) Exactly-Once, ordre et idempotence
Bus : at-least-once + clés de lot fournissent un ordre local.
Idempotence : 'event _ id' + dedup state (TTL 24-72 h).
Sink : commits transactionnels (2-phase) ou upsert/merge-idempotence.
Outbox/Inbox : Publication garantie des événements de domaine à partir d'OLTP.
7) Enrichissement en temps réel
Lookup : Redis/Scylla (limites RG, statut KYC, BIN→MCC, IP→Geo/ASN).
Appels asynchrones : API de sanction/RER avec temporisation et fallback (« unknown »).
FX/temporisation : normalisation des montants et heure locale du marché ('fx _ source', 'tz').
8) Serving et vitrines de temps réel
ClickHouse/Pinot/Druid : agrégations par minute/seconde, vues materialized.
Gold-stream : les tableaux rapides GGR/RG/AML, SLA sur le retard ≤ 1-5 minutes
API/GraphQL : faible latence pour les dashboards et les intégrations externes.
Exemple de ClickHouse (GGR par minute) :sql
CREATE MATERIALIZED VIEW mv_ggr_1m
ENGINE = AggregatingMergeTree()
PARTITION BY toDate(event_time)
ORDER BY (toStartOfMinute(event_time), market, provider_id) AS
SELECT toStartOfMinute(event_time) AS ts_min,
market,
provider_id,
sumState(stake_base) AS s_stake,
sumState(payout_base) AS s_payout
FROM stream.game_events
GROUP BY ts_min, market, provider_id;
9) Observabilité et SLO
SLI/SLO (repères) :- p95 ingest→alert ≤ 2 s (critique), ≤ 5 s (le reste).
- Fenêtre complète T ≥ 99. 5%.
- Erreurs de schéma ≤ 0. 1%; proportion d'événements avec 'trace _ id' ≥ 98 %.
- Disponibilité du service de stream ≥ 99. 9%.
- Lagi par lots/points de repère, busy time opérateurs, taille de l'état.
- Entonnoir « sobytiye→pravilo→keys », carte des clés « chaudes », late-ratio.
- Coût : cost/GB, cost/query, coût des checkpoints/relais.
10) Vie privée et conformité
Minimisation PII : pseudonyme ID, masquage des champs, tokenisation PAN/IBAN.
Résidence des données : convoyeurs régionaux (EEE/UK/BR), clés de cryptage séparées.
Opérations légales : DSAR/RTBF à downstream vitrines, Legal Hold pour les cas/rapports.
Audit : logs d'accès, archives de solutions immuables.
11) Économie et productivité
Clés et sharding : évitez les clés « chaudes » (salting/composite key).
Condition : TTL raisonnable, snapshots, tuning RocksDB/state backend.
Préagrégation : up-front reduce pour les flux bruyants.
Sampling : admettons sur des métriques non critiques (pas sur les transactions/la conformité).
Chargeback : budgets par thème/jobs, quotas et allocations par équipe.
12) Streaming DQ (qualité)
Ingest-validation (schema, enums, size), dedup '(event_id, source)'.
Sur le flux : completeness/dup-rate/late-ratio, contrôle des fenêtres (pas de double comptage).
Politiques de réaction : Critique → DLQ + alert ; major/mineur → balise et nettoyage ultérieur.
yaml stream: payments rules:
- name: schema_valid type: schema severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
- name: dedup_window type: unique keys: [event_id]
window_minutes: 1440
13) Sécurité d'accès et release-control
RBAC/ABAC : rôles distincts sur la lecture des flux, modification des règles/modèles.
Contrôle double : jetez les règles et les modèles via « 2 clés ».
Canary/A/B : lancements sombres des règles et des modèles, contrôle de precision/recall.
Secrets : KMS/CMK, rotation régulière, interdiction des secrets dans les loges.
14) Processus et RACI
R (Responsible) : Streaming Platform (infra/release), Domain Analytics (Regles/Fichi), MLOps (Scoring).
A (Comptable) : Head of Data/Risk/Compliance par domaine.
C (Consulté) : DPO/Legal (PII/retraite), SRE (SLO/incidents), Architecture.
I (Informed) : Produit, Support, Marketing, Finance.
15) Feuille de route pour la mise en œuvre
MVP (2-4 semaines) :1. Kafka/Redpanda + deux axes critiques ('payments', 'auth').
2. Flink-joba avec watermark, dedup et une règle CEP (AML ou RG).
3. ClickHouse/Pinot vitrine 1-5 min, dashboards lag/completeness.
4. Canal incident (webhooks/Jira), SLO de base et alertes.
Phase 2 (4-8 semaines) :- Enrichissement en ligne (Redis/Scylla), Feature Store, lookups asynchrones.
- Gestion des règles en tant que code, versions canaries, A/B.
- Diffusion DQ, régionalisation des convoyeurs, procédures DSAR/RTBF.
- Multi-région active-active, simulateur « what-if », auto-calibrage des seuils.
- Vitrines Gold-stream à part entière (GGR/RG/AML), reporting near-real-time.
- Dashboards de valeur, chargeback, exercice DR.
16) Exemples (fragments)
Flink CEP — device switch:sql
MATCH_RECOGNIZE (
PARTITION BY user_id
ORDER BY event_time
MEASURES
FIRST(A.device_id) AS d1,
LAST(B.device_id) AS d2,
COUNT() AS cnt
PATTERN (A B+)
DEFINE
B AS B.device_id <> PREV(device_id) AND B.ip_asn <> PREV(ip_asn)
) MR
Kafka Streams est un filtre idempotent :
java if (seenStore.putIfAbsent(eventId, now()) == null) {
context.forward(event);
}
17) Chèque-liste avant la vente
- Régimes et contrats dans Registry, back-compat tests sont verts.
- Inclus watermark/allowed lateness, dedup et DLQ.
- Les SLO et les alertes (lag/late/dup/state size) sont configurés.
- Enrichissement avec les caches et les timeouts, fallback « unknown ».
- RBAC/dual-control sur les règles/modèles, toutes les modifications sont logées.
- Documentation sur les règles, les vitrines et le runbook "et le repli/retour.
18) Erreurs fréquentes et comment les éviter
Ignorer l'event-time : sans watermarks, les métriques « flottent ».
Pas de grand-père : faux alertes et double comptage.
Clés chaudes : distorsion des lots → salting/resharding.
API externes synchrones dans le chemin chaud : async + cache uniquement.
Coût non géré : préagrégations, TTL d'état, quotas, cost-dashboards.
Absence de simulateur : Les décharges sans « replay » entraînent des régressions.
19) Glossaire (bref)
PPE - Complex Event Processing (modèles d'événements).
Watermark est la limite de disponibilité des fenêtres par event-time.
Allowed Lateness est la tolérance des événements tardifs.
L'opérateur Stateful est un opérateur avec un état enregistré.
Feature Store - Serving harmonisé des caractéristiques (en ligne/hors ligne).
20) Résultat
Le streaming et l'analyse en streaming sont des systèmes gérables : contrats, fenêtres et watermarks, stateful-logic et CEP, vitrines d'enrichissement et de temps réel, SLO et observabilité, intimité et coût sous contrôle. En suivant les pratiques décrites, la plate-forme obtient des détecteurs de risques fiables, des panneaux opérationnels et une personnalisation avec une latence et des coûts prévisibles.