GH GambleHub

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.
Exemple de Flink SQL (dépôts velocity 10 min) :
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.

Pseudo-code CEP :
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%.
Dashboards :
  • 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.

Règles minimales (YAML, exemple) :
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.
Phase 3 (8-12 semaines) :
  • 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.

Contact

Prendre contact

Contactez-nous pour toute question ou demande d’assistance.Nous sommes toujours prêts à vous aider !

Commencer l’intégration

L’Email est obligatoire. Telegram ou WhatsApp — optionnels.

Votre nom optionnel
Email optionnel
Objet optionnel
Message optionnel
Telegram optionnel
@
Si vous indiquez Telegram — nous vous répondrons aussi là-bas.
WhatsApp optionnel
Format : +code pays et numéro (ex. +33XXXXXXXXX).

En cliquant sur ce bouton, vous acceptez le traitement de vos données.