Traitement en continu

Qu'est-ce que le streaming

Le traitement en continu est une réponse continue à des séquences infinies d'événements (journal des transactions, clics, paiements, télémétrie), avec un délai minimum et une garantie de l'exactitude des états. Contrairement au batch, où « nous prenons tout ce que nous avons accumulé pendant la période », le flux traite les données au fur et à mesure de l'arrivée, maintient l'état et prend en compte le temps de l'événement.

Concepts clés

L'événement (event) est un fait immuable avec 'event _ time' et l'unique 'event _ id'.
L'heure de l'événement (event time) vs le temps de traitement (processing time) - le premier vient de la source, le second - quand l'opérateur a vraiment vu l'événement.

Fenêtres (Windows) : Regroupe les événements par heure :

Tumbling, Hopping/Sliding (avec chevauchement), Session (discontinuité par inactivité).
Filigranes (watermarks) - évaluation que « les événements avant l'instant T sont déjà arrivés », vous permettant de fermer les fenêtres et de limiter l'attente des données tardives.
Données en retard (lateness) : Événements avec 'event _ time' inférieur au watermark actuel ; les règles de la main-d'œuvre sont souvent appliquées.
État (state) : Tables/stockages d'opérateurs locaux (keyed state) pour les agrégats, join's, déduplication.
Backpressure : Pression en cas de dépassement de la bande passante downstream ; il est contrôlé par protocole et tampons.

Bases architecturales

1. Source (source) : courtier d'événements (Kafka/NATS/Pulsar), CDC de la base de données, files d'attente, fichiers/logs collecteurs.
2. Moteur de streaming : calcule les fenêtres, les agrégats, les joyaux, les schémas, contrôle l'état et checkpoint'ami.
3. Récepteur (sink) : OLTP/OLAP OBD, moteur de recherche, cache, tops, stockage pour vitrines/rapports.
4. Registre des schémas : contrôle de l'évolution de la payload et de la compatibilité.
5. Observabilité : métriques, tracing, logs, dashboards et filigranes.

Sémantique du temps et ordre

Préférez toujours le temps de l'événement : c'est le seul invariant pour les retards et les interruptions.
Les événements peuvent être hors d'ordre ; l'ordre n'est garanti que dans la clé du lot.

Watermarks permet :

fermer les fenêtres et émettre les résultats ;
Limiter le nombre d'événements en retard ('allowed _ lateness').
Pour les événements tardifs, utilisez retractions/upserts : recalculer les agrégats et les événements correctifs.

État et fiabilité

État keyed : les données des agrégats (montants, compteurs, structures pour le dédupit) sont réparties par clé.
Checkpoint/Savepoint : instantanés périodiques de l'état à restaurer ; savepoint est un instantané contrôlé pour les migrations de version de code.

Exactly-once par effet est atteint :

transactionnel « lu-traité-enregistré » (commit sink + position de lecture) ;
Les selles idempotentes (upsert/merge) + tables de dédoublement ;
par le versioning des agrégats (concurrency optimistic).

Fenêtres, agrégations, join's

Fenêtres :

Tumbling : rapports périodiques simples (minutes, heures).
Hopping/Sliding : métriques « glissantes » (en 5 min avec pas de 1 min).
Session : naturel pour les sessions personnalisées et l'antifrode.
Aggregations: sum/count/avg/approx-distinct (HyperLogLog), percentiles (TDigest/CKMS).
Stream-Stream join : nécessite la mise en tampon des deux côtés par clé et par temps, respecter 'allowed _ skew'.
Stream-Table join (KTable) : attache un répertoire ou un état courant (par exemple, « limites d'utilisateur actives »).

Travailler avec des données en retard et en double

Déduplication : Par 'event _ id' ou '(producer_id, sequence)' ; gardez les clés « visibles » avec la TTL ≥ la fenêtre de répétition.
Late events : permettre l'achèvement de la fenêtre pendant « X » après la fermeture (retractions/upserts).
Faux doublons : Ajustez les unités idempotent et fixez « ALREADY_APPLIED » dans les logs.

Mise à l'échelle et performances

Chardonnages par clé : assure le parallélisme ; surveillez les clés « chaudes ».
Backpressure : limitez les parallèles, utilisez batchi et compression lors de la publication.
Filigranes : ne mettez pas trop agressivement - les watermarks durs réduisent l'attente, mais augmentent la proportion de mises à jour late.
État : sélectionner le format (RocksDB/state store/en mémoire) en fonction de la taille et des patterns d'accès ; nettoyer la TTL.
Auto-échelle : par lagune, CPU, taille state, temps GC.

Fiabilité et redémarrage

Le sink idempotent ou le commit transactionnel avec fixation offset est la base de l'exactitude.
Le traitement répété après le redémarrage est autorisé ; l'effet doit rester « exactement une fois ».
DLQ/parking lot : envoyer les dossiers problématiques dans un flux séparé avec des raisons ; assurer le réemploi.

Observabilité (que mesurer)

Lag par source (par heure et par communication).
Watermark/current event time et part des événements late.
Opérateurs throughput/latency, p95/p99 end-to-end.
State size/rocksdb I/O, fréquence checkpoint 's/durée.
Taux DLQ, pourcentage de déduplications/retraits.
CPU/GC/heap, temps de pauses.

Sécurité et conformité

Classification des données : Marquer PII/PCI dans les schémas, stocker le minimum, crypter l'état et les snapshots.
Contrôle d'accès : ACL séparées sur les tops/tables d'état et sur les sinks.
Retences : sont conformes aux exigences légales (RGPD/droit à l'oubli).
Audit : loger 'event _ id', 'trace _ id', résultat : 'APPLIED/ALREADY _ APPLIED/RETRIED'.

Modèles d'implémentation

1. CDC → la normalisation des événements → du domaine : ne diffusez pas les modifications brutes de la base de données, mapez aux faits commerciaux compréhensibles.
2. Outbox chez les producteurs : fait de la transaction + événement - en une seule transaction OBD.
3. Core vs Enriched : minimum payload dans le flux critique, l'enrichissement est asynchrone.
4. Replay-convivialité : les projections/vitrines doivent être recoupées depuis la loge.
5. Idempotency by design : opération/event key, schémas upsert, versions d'agrégats.

Tests

Unit/Property-based : invariants d'agrégats et de transformations.
Tests Stream : Flux d'événements fixe avec out-of-order et duplications → vérification des fenêtres et du dédoublement.
Windows Golden : fenêtres/agrégats de référence et réglages tardifs valides.
Fault-injection : une chute entre « enregistrer l'effet » et « échanger offset ».
Tests de replay : recalculer une vitrine à partir du début du journal = état actuel.

Coût et optimisation

Les fenêtres et le watermark affectent la latence/les ressources : plus la fenêtre est longue et plus 'allowed _ lateness', plus l'état est grand.
Codecs et compressions : Équilibrer votre CPU/réseau.
Batching à la sortie : moins d'appels réseau et de transactions.
Filtration précoce (« pushdown ») : jeter l'excès aussi près que possible de la source.

Anti-modèles

Nouez le temps de traitement là où vous avez besoin du temps d'événement → un analyste incorrect.
L'absence d'idempotence dans sink → des effets doubles dans les restarts.
Les « clés méga » mondiales : une section chaude brise le parallélisme.
Les CDC bruts comme événements publics : fuite de circuits OBD, fragilité dans l'évolution.
Pas de DLQ : les messages « toxiques » bloquent tout le convoyeur.
Un délai fixe et dur au lieu de watermark : une attente perpétuelle ou une perte de données.

Exemples de domaines

Paiements/finances

Flux 'payment.', fenêtres pour antifrod (session + CEP), déduplication par 'opération _ id'.
Effet exactly-once lors de la diffusion dans le ledger comptable (upsert + version).

Marketing/publicité

Fenêtre de sliding CTR/conversions, clics Join et impressions avec tolérance '± Δ t', aggrégation pour bidding.

iGaming/Services en ligne

Équilibre temps réel/limites, missions/actions (fenêtre de session), modèles antifrod et alertes.

Mini-modèles (pseudo-code)

Fenêtre avec filigrane et late-updates

pseudo stream
.withEventTime(tsExtractor)
.withWatermark(maxAllowedLag=2m)
.window(TUMBLING, size=1m, allowedLateness=30s)
.keyBy(user_id)
.aggregate(sum, retractions=enable)
.sink (upsert_table )//idempotent upsert by (user_id, window_start)

Sink transactionnel avec fixation offset

pseudo begin tx upsert target_table using event, key=(k)
update consumer_offsets set pos=:pos where consumer=:c commit

Chèque-liste de production

L'heure de l'événement et la stratégie de watermark ont été définies ; les fenêtres et 'allowed _ lateness'sont sélectionnées.
Sink idempotent ou commit transactionnel avec offset.
Le registre des schémas et les modes d'interopérabilité sont inclus ; l'évolution additive.
Métriques : lag, watermark, p95/p99, DLQ, taille state, durée checkpoint.
Tests : out-of-order, duplicata, redémarrage, replay.
Politiques PII/rétroaction pour l'État et les snapshots.
Plan de mise à l'échelle et stratégie de backpressure.
Documentation sur les contrats de fenêtres et les ajustements (late updates).

FAQ

Le temps de l'événement est-il obligatoire ?
Si l'exactitude des mesures et la cohérence sont importantes, oui. Le temps de traitement est approprié pour les calculs techniques/la surveillance, mais fausse l'analyse.

Ai-je besoin d'exactly-once ?
Point : pour les effets critiques. Plus souvent, at-least-once + sink idempotent suffit.

Comment choisir les fenêtres ?
Éloignez-vous de la SLA d'affaires : « dans les 5 dernières minutes » → hopping, « session utilisateur » → session, « rapports de minutes » → tumbling.

Que faire des données tardives ?
Autoriser le « allowed _ lateness » limité et émettre des ajustements (upsert/retract). La vitrine du client doit pouvoir être mise à jour.

Résultat

Le traitement en continu est non seulement une faible latence, mais aussi une discipline du temps, de l'état et des contrats. Le bon choix du temps de l'événement, des fenêtres et des filigranes, ainsi que les effets idempotent, l'observation et les tests rendent la chaîne fiable, reproductible et économique - et donnent aux entreprises des solutions « ici et maintenant » plutôt que « toute la nuit ».