Analyse en temps réel

1) La destination et la valeur commerciale

• AML/Antifrod : structuration des dépôts, attaques de velocity, transactions à risque.
• Jeu responsable (RG) : dépassement des limites, schémas de risque, auto-exclusion.
• SRE/Opérations : détection précoce des dégradations de SLA, éclats d'erreur, surchauffe des clusters.
• Produit et marketing : déclencheurs de personnalisation, missions/quêtes, segmentation temps réel.
• Rapports opérationnels : GGR/NGR, dashboards de salles/fournisseurs.

Repères cibles : p95 end-to-end 0. 5–5 с, completeness ≥ 99. 5 %, disponibilité ≥ 99. 9%.

2) Architecture de référence

1. Ingest/Edge — `/events/batch` (HTTP/2/3), gRPC, OTel Collector; validation des circuits, anti-doublage, géo-routage.
2. Bus d'événements - Kafka/Redpanda (lot par 'user _ id/tenant/market', DLQ, rétention 3-7 jours).
3. Traitement stream - Flink/Spark Structured Streaming/Beam : opérateurs stateful, CEP, watermarks, allowed lateness, dedup.
4. Enrichissement en ligne - Redis/Scylla/ClickHouse lookups (limites RG, KYC, BIN→MCC, IP→Geo/ASN), appels asynchrones avec temporisation et fallback.
5. Serving - ClickHouse/Pinot/Druid (vitrines opérationnelles de 1 à 5 minutes), Feature Store (signes en ligne), webhooks/tiketing/SOAR.
6. Lakehouse - Bronze/Argent/Or pour la consolidation à long terme, le repli et la sverka.
7. L'observation est des métriques de piplines, de tracing (OTel), de logs, de lineage et de cost-dashboards.

3) Signaux et taxonomie

Paiements : 'payment. deposit/withdraw/chargeback`.
Jeux : 'jeu. bet/payout ', sessions.
Authentification et comportement : 'auth. login/failure`, device-switch, velocity.
Opérations : latency, error-rate, redémarrage des pods, saturation.
Conformité : dépistage des sanctions, drapeaux RG, événements DSAR.

Chaque type a un propriétaire (domain owner), un schéma, un SLO de fraîcheur et une politique de données late.

4) Fenêtres, watermarks et données lattes

Fenêtres : tumbling (fix.) , hopping (chevauchement), session (par inactivité).
Watermark : limite de la « connaissance du temps » (généralement 2-5 min).
Événements tardifs : pré-émission des ajustements, drapeau 'late = true', DLQ en cas de 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) PPE et stateful-agrégation

Clé : 'user _ id', 'device _ id', 'payment. account_id`.
État : compteurs glissants/montants, filtres bloom pour le dédupit, TTL.
Modèles PPE : Structuring (<seuil, pour la ≥N fois, par la fenêtre T), device-switch, RG-fatigue.

python if cnt_deposits(last=10MIN) >= 3 and sum_deposits(last=10MIN) > THRESH and all(d.amount < REPORTING_THRESHOLD):
emit_alert("AML_STRUCTURING", user_id, snapshot())

6) Exactly-Once, ordre et idempotence

Livraison at-least-once dans le bus + dedup par 'event _ id'sur le traitement (TTL 24-72 h).
Ordre : lot par clé (ordre local garanti).
Sink : commits transactionnels (2-phase) ou idempotent upsert/merge.
Outbox/Inbox : publication transactionnelle d'événements de domaine à partir d'OLTP.

7) Online-Enrichissement et Feature Store

Lookup : limites RG, statuts KYC, BIN→MCC, IP→Geo/ASN, marchés/taxes, FX au moment de l'événement.
Appels asynchrones : API de sanction/RER avec temporisation ; en cas d'erreur - 'unknown' + retray/cache.
Feature Store : négociation en ligne/hors ligne ; une base de code pour les transformations.

8) Vitrines en temps réel et serving

ClickHouse/Pinot/Druid : unités de secondes/minutes, vues materialized, SLA pour un retard de 1-5 min.
API/GraphQL : faible latence pour les dashboards/widgets.
Alert : webhooks/Jira/SOAR avec contexte enrichi (trace_id, derniers événements).

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) Métriques, SLI/SLO et dashboards

• p95 ingest→alert ≤ 2 s (règles critiques), ≤ 5 s (autres).
• Fenêtre complète T ≥ 99. 5%; Schema validity ≥ 99. 9%; Trace coverage ≥ 98%.
• Disponibilité du service de stream ≥ 99. 9%; late-ratio ≤ 1%.

• Par lots/points de repère ; busy time opérateurs ; taille de l'état.
• Entonnoir « sobytiye→pravilo→keys », precision/recall par domaine.
• Caloricarta late/completeness ; carte des clés « chaudes ».

10) Streaming DQ (qualité)

Validation d'Ingest : schema/enums/size-limits, anti-doublures.
Sur le flux : completeness/dup-rate/late-ratio, correct des fenêtres (sans double comptage).
Politiques de réaction : Critique → DLQ + pager ; major/mineur → tag + rapport.

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

11) Vie privée, sécurité et résidence

Minimisation PII : pseudonyme ID, masquage des champs sensibles, tokenisation PAN/IBAN.
Résidence de données : convoyeurs régionaux (EEE/UK/BR), clés KMS séparées.
DSAR/RTBF : édition sélective sur les vitrines downstream ; Legal Hold pour les cas/rapports.
Audit : logs d'accès/modifications de règles immuables, journalisation des versions.

12) Économie et productivité

Charding/clés : éviter les clés « chaudes » (salting/composite), équilibre des lots.
État : TTL, compact snapshots, tuning RocksDB/state backend.
Préagrégation : reduce dans les premières étapes pour les sujets bruyants.
Sampling : seulement pour les mesures non critiques (pas de transaction/conformité).
Chargeback : Budgets par thème/jobs, quotas de relais et demandes lourdes.

13) Processus et RACI

R : Streaming Platform (infra/releases), Domain Analytics (règles/fiches), MLOps (scoring/Feature Store).
A : Head of Data/Risk/Compliance par domaine.
C : DPO/Legal (PII/retraite), SRE (SLO/incidents), Architecture.
I : Produit, Support, Marketing, Finance.

14) Feuille de route pour la mise en œuvre

1. Kafka/Redpanda + 2 axes critiques (par exemple « payments », « auth »).

2. Flink-joba avec watermark, dedup et 1 CEP (AML ou RG).

3. Vitrine opérationnelle à ClickHouse/Pinot (1-5 min), dashboards lag/completeness.

4. Canal incident (webhooks/Jira), SLO de base et alertes.

• Enrichissement en ligne (Redis/Scylla), Feature Store, lookups asynchrones.
• Gérer les règles en tant que code, canary/A-B, streaming DQ.
• Régionalisation des convoyeurs, procédures DSAR/RTBF, Legal Hold pour les cas.

• Multi-région active-active, simulateur « replay & what-if », auto-calibrage des seuils.
• Vitrines Gold-stream (GGR/RG/AML), rapports en temps quasi réel.
• Cost-dashboards, chargeback, exercice DR.

15) Exemples (fragments)

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

java if (seenStore.putIfAbsent(eventId, now()) == null) {
context.forward(event);
}

16) Chèque-liste avant la vente

• Régimes/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 temporoutes ; fallback «unknown».
• RBAC/dual-control sur les règles/modèles ; le journal des modifications est inclus.
• Documentation des règlements/vitrines ; runbook 'et repli/retour.

17) Erreurs fréquentes et comment les éviter

Ignorer l'event-time : sans watermarks, les métriques « flottent ».
Pas de grand-père : faux alertes, double comptage.
Clés chaudes : distorsion des lots → salting/resharding.
API externes synchrones dans le chemin chaud : async + cache uniquement.
Coût non gérable : préagrégations, TTL d'état, quotas, cost-monitoring.
Absence de simulateur : jeté sans « replay » → régression.

18) Résultat

L'analyse en temps réel n'est pas une « BI rapide », mais une boucle gérée avec des contrats, de la logique stateful, des CPE, des watermarks, de l'enrichissement en ligne et des SLO stricts. En suivant ces pratiques, la plate-forme reçoit des signaux et des solutions précis en quelques secondes, en maintenant la conformité, les scénarios de produits et la durabilité opérationnelle à un coût contrôlé.