GH GambleHub

Traitement des signaux en temps réel

1) La destination et la valeur commerciale

Le flux temps réel est nécessaire pour réagir « ici et maintenant » :
  • Antifrod/AML : structuration des dépôts, « molling », attaques velocity.
  • Jeu responsable (RG) : dépassement des limites, comportements à risque.
  • Risque/Conformité : contrôle des sanctions lors de l'enregistrement/transaction en ligne.
  • Personnalisation : déclencheurs de bonus/missions, campagnes réactives.
  • Opérations/SRE : dégradations de SLA, grappes d'erreurs, anomalies métriques.

Objectifs clés : faible retard (p95 0. 5-5 s), haute plénitude (≥99. 5 %), résistance aux surtensions.

2) Taxonomie des signaux

Transactionnel : 'payment. deposit/withdraw/chargeback`.
Jeux : 'jeu. bet/payout`, `game. session_start/stop`.
Authentification : 'auth. login/failure ', changement d'appareil/geo.
Comportemental : taux de mise, croissance exponentielle de la somme, activité nocturne.
Opérations : 'api. latency`, `error. rate ', la « tempête » des redémarrages des pods.

Chaque type a un schéma, propriétaire (domain owner), criticité, SLO et règles « late data ».

3) Architecture de référence du contour temps réel

1. Ingest et bus : HTTP/gRPC → Edge → Kafka/Redpanda (lot par 'user _ id/tenant').
2. Streaming-движок: Flink/Spark Structured Streaming/Beam; opérateurs stateful, PPE.
3. Enrichissement en ligne : tables lookup (Redis/Scylla/ClickHouse Read-Only), cash des fournisseurs (sanctions/CUS).

4. Sinki :
  • Alert-topics/kew (gestion de cas, SOAR).
  • Fichestor en ligne (scoring de modèles).
  • Gold-stream-vitrines (dashboards opérationnels).
  • Stockage « chaud » pour l'analyse rapide (ClickHouse/Pinot/Druid).
  • 5. Archive/forensica : pliage immuable dans le lac (Parquet, temps-voyage).
  • 6. Observabilité : Tracing/métriques/logs + lineage.

4) Fenêtres, watermarks et « late data »

Vues des fenêtres :
  • Tumbling : fenêtres fixes (par exemple, 1 min) sont des agrégats simples.
  • Hopping : chevauchement (par exemple, étape 30 s, fenêtre 2 min) - métriques « lisses ».
  • Session : discontinuité par inactivité - analyse comportementale.
  • Watermarks : limite de la « connaissance du temps » pour l'event-time ; nous admettons le retard (allowed lateness, par exemple, 2 min).
  • Stratégies tardives : pré-émission des ajustements, référence « late = true », DLQ.

5) Opérateurs Stateful et déduplication

Clé : Par 'user _ id', 'payment. account_id`, `device_id`.
État : additionneurs, compteurs coulissants, filtres bloom pour idempotency.
Dedup : Stocker '(event_id, seen_at)' dans state/kv ; TTL = 24-72 h.
Exactly-Once : opérations transactionnelles sink 'et (2-phase), upsert idempotent.

6) Enrichissement du flux

Lookup-joyaux : limites RG, risque-score de l'utilisateur, niveau KYC, géo/ASN.
Appels asynchrones : registre des sanctions/fournisseurs antifrod (async I/O, timeouts et fallback).
Normalisation des monnaies/temporisation : unification à l'UTC et à la monnaie de base ; fixer « fx _ source ».

7) PPE : détection de patterns complexes

Exemples de règles :
  • Structuration : ≥3 de dépôt en 10 min, chaque seuil de déclaration, total> X.
  • Appareil-switch : 3 appareils différents en 15 min + changement d'IP/ASN.
  • RG-fatigue : paris cumulés en 1 heure> limite + perte ≥ Y.
  • Ops-storm : p95 latency> 2 × de base, 5xx> 3 % dans une fenêtre de 5 min.

Le PPE est commode à exprimer dans Flink CEP/SQL ou les bibliothèques de modèles d'événements.

8) Fiches et modèles en ligne

Fonctionnalités pipelines : compteurs, métriques de velocity, « heure du dernier événement », share-of-wallet.
Cohérence en ligne/hors ligne : une base de codes pour les transformations ; tests de rectitude.
Scoring : les modèles light (logit/GBDT) sont synchrones ; lourd - asynchrone via la file d'attente.
Contrôle de la dérive : PSI/KS et alertes ; « lancements sombres » pour les nouveaux modèles.

9) Les garanties de livraison et l'ordre

At-least-once dans le bus + idempotence à la réception.
Le lot par clé fournit un ordre local.
Retries & backpressure : retraits exponentiels avec jitter, contrôle automatique de la pression.

10) SLO/SLI (recommandé)

IndicateurObjectif
p95 end-to-end latency (ingest → alert)≤ 2 s (Crète.) , ≤ 5 s (nécrite.)
Completeness par la fenêtre T≥ 99. 5%
Erreurs de schémas/validateurs≤ 0. 1 % d'événements
Proportion d'événements avec trace_id≥ 98%
Alert precision/recall (objectifs par domaine)≥ 0. 8 / ≥ 0. 7
Disponibilité du service de stream≥ 99. 9%

11) Observabilité du contour temps réel

Métriques de pipline : throughput, lag per partition, busy time, checkpoint duration.
Qualité des signaux : compléteness, taux de duplication, late ratio.
Dashboards : carte thermique des lagunes selon les sommets, entonnoir alert (sobytiye→pravilo→keys), carte des clés chaudes.
Tracing : relier l'alert aux événements originaux (trace_id).

12) Sécurité et vie privée

Minimisation des PII : Tokénisation des identifiants, masquage des champs sensibles.
Géo-résidence : convoyeurs régionaux (EEE/UK/BR).
Audit : logs de décision immuables (qui, quoi, pourquoi), Legal Hold pour les cas.
Accès : RBAC aux règles/modèles, double contrôle à jeter.

13) Coût et performance

Clés chaudes : redistribution (salting de clés), clés composites.
Condition : TTL raisonnable, matérialisation incrémentale, tuning RocksDB.
Fenêtres : dimensions optimales et lateness allowed ; couches de pré-aggregation pour les flux « bruyants ».
Sample : sur les flux non critiques et au niveau des métriques (pas sur les transactions/la conformité).

14) Exemples (simplifiés)

Flink SQL - dépôt structurant (fenêtre de 10 min, étape 1 min) :
sql
CREATE VIEW deposits AS
SELECT user_id, amount, ts
FROM kafka_deposits
MATCH_RECOGNIZE (
PARTITION BY user_id
ORDER BY ts
MEASURES
FIRST(A. ts) AS start_ts,
SUM(A. amount) AS total_amt,
COUNT() AS cnt
ONE ROW PER MATCH
AFTER MATCH SKIP PAST LAST ROW
PATTERN (A{3,})
WITHIN INTERVAL '10' MINUTE
) MR
WHERE total_amt > 500 AND cnt >= 3;
Pseudo-code anti-velocity par taux :
python key = event. user_id window = sliding(minutes=5, step=30)   # hopping window count = state. counter(key, window)
sum_amt = state. sum(key, window)
if count > 30 or sum_amt > THRESH:
emit_alert("RG_VELOCITY", key, snapshot(state))
Dedup par event_id (Kafka Streams) :
java if (!kvStore.putIfAbsent(event. getId(), now())) {
forward(event); // unseen -> process
}

15) Processus et RACI

R (Responsible) : Streaming Platform (infra, état, versions), Domain Analytics (règles/fiches).
A (Comptable) : Head of Data/Risk/Compliance par leurs domaines.
C (Consulté) : DPO/Legal (PII/retraite), SRE (SLO/incidents), Architecture.
I (Informed) : Produit/Support/Marketing.

16) Feuille de route pour la mise en œuvre

MVP (2-4 semaines) :

1. 2 à 3 signaux critiques (par exemple 'paiement. deposit`, `auth. login`, `game. bet`).

2. Kafka + Flink, dedup de base et watermark ; une règle du PPE pour l'antifrod et une règle du RG.

3. ClickHouse/Pinot pour les vitrines opérationnelles ; dashboards lag/completeness.

4. Incident de canal (webhook/Jira) et triage manuel.

Phase 2 (4-8 semaines) :
  • Fichestor en ligne, scoring de modèle light ; lookups asynchrones (sanctions/CUS).
  • Gestion des règles en tant que code, Canaries, A/B règles.
  • Régionalisation et contrôles PII, Legal Hold pour les cas.
Phase 3 (8-12 semaines) :
  • Catalogue de signaux, autogénération de la documentation, simulateur « replay & what-if ».
  • Auto-calibrage des seuils (bayésien/quantile), métriques de precision/recall en ligne.
  • Exercice DR, multi-région active-active, chargeback modèles par équipe.

17) Chèque de qualité avant la vente

  • Régimes et contrats, validation en ingest.
  • Les fenêtres, watermarks, allowed lateness + DLQ sont personnalisés.
  • Dedup et sink'i idempotent.
  • Métriques lag/throughput/state size, alertes SLO.
  • Sécurité : RBAC sur les règles/modèles, masque PII.
  • Documentation : owner, SLO, exemples, cartes de dépendance.
  • Procédures rollback et bouton frise.

18) Erreurs fréquentes et comment les éviter

Ignorer l'event-time : utilisez watermarks, sinon les métriques « glissent ».
Pas de déduplication : les doublons donneront de faux alertes → entrez idempotency.
Clés chaudes : distorsion des lots → salting/resharding.
Fenêtres trop rigides : perte d'émissions tardives → allowed lateness + correctives.
Mélange PII : Séparez la tokenisation et le flux analytique.
Pas de simulateur : testez les règles sur le « repli » avant de rouler.

19) Glossaire (bref)

CEP - Complex Event Processing, détection de patterns.
Watermark est le seuil de temps pour la disponibilité de la fenêtre.
Allowed Lateness est la tolérance des événements tardifs.
L'opérateur Stateful est un opérateur à état persistant.
Feature Store - Stockage des caractéristiques en ligne/hors ligne pour ML.

20) Résultat

Le traitement du signal en temps réel est un convoyeur contrôlé avec des schémas clairs, des fenêtres et des watermark'ami, une logique stateful, un enrichissement en ligne et des SLO rigoureux. En suivant ces pratiques, vous obtenez des détecteurs de risque rapides et fiables, des déclencheurs de personnalisation durables et des dashboards opérationnels qui évoluent de manière économique et compacte.

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.