Les pipelines de données en temps réel

Illustration de l'article: Pipelines de données en temps réel

Traitement par lots et temps réel : quelles différences ?

Le traitement par lots (batch) et le traitement en temps réel (streaming) représentent deux approches complémentaires pour déplacer et transformer des données. Dans un pipeline batch, les données sont accumulées sur une période définie — une heure, une nuit, une journée — puis traitées en un seul lot. C'est le modèle classique des entrepôts de données qui rafraîchissent leurs tables via des tâches planifiées, par exemple un chargement quotidien à 2 h du matin. À l'inverse, un pipeline en temps réel traite chaque événement au fil de l'eau, quelques millisecondes ou secondes après sa création.

La différence fondamentale se situe au niveau de la latence. Le batch privilégie le débit : il excelle pour traiter d'énormes volumes en une passe, souvent à moindre coût, car les ressources ne sont mobilisées qu'au moment de l'exécution. Le streaming privilégie la fraîcheur : il maintient une infrastructure active en permanence pour réagir instantanément. Cette distinction a des conséquences concrètes sur l'architecture, les outils et le budget.

Il faut aussi noter que la frontière n'est pas toujours nette. Le micro-batch, popularisé par certains moteurs de traitement, découpe le flux en très petits lots traités toutes les quelques secondes. Il offre un compromis entre la simplicité du batch et la réactivité du streaming. Comprendre où se situe votre besoin sur cet axe latence/débit est la première étape avant de choisir une approche.

Comment fonctionne un pipeline en streaming

Un pipeline en streaming repose généralement sur trois composants : une source d'événements, un système de transport (le bus de messages) et un moteur de traitement. La source peut être une application web qui émet des clics, un capteur IoT, une base de données qui publie ses changements via un mécanisme de capture (CDC), ou une file d'attente applicative. Chaque changement devient un événement, une petite unité de données horodatée.

Le bus de messages, souvent une plateforme de type journal distribué, joue un rôle central. Il découple les producteurs des consommateurs : les applications qui émettent les données n'ont pas besoin de connaître celles qui les consomment. Ce bus conserve les événements dans des partitions ordonnées, ce qui permet de rejouer un flux depuis un point donné en cas d'incident. Cette capacité de relecture est un atout majeur pour la résilience.

Le moteur de traitement consomme ensuite les événements et applique la logique métier : filtrage, enrichissement, agrégation ou jointure. Ici intervient la notion de fenêtrage (windowing). Comme un flux est théoriquement infini, on regroupe les événements par tranches temporelles — par exemple « le nombre de commandes par minute glissante ». Le moteur doit aussi gérer les événements en retard, ceux qui arrivent après leur fenêtre logique à cause de la latence réseau. On distingue le temps de l'événement (event time), moment réel de sa création, du temps de traitement (processing time), moment où le système le reçoit. Bien gérer cette différence évite des agrégats faussés.

Enfin, le résultat est écrit vers une destination : un tableau de bord, une base de données analytique, un système d'alerte ou un autre flux. La garantie de livraison — au moins une fois, au plus une fois, ou exactement une fois — détermine le niveau de fiabilité et la complexité de mise en œuvre.

Quand privilégier le temps réel plutôt que le batch

Le temps réel n'est pas toujours la meilleure réponse, et le choisir par défaut est une erreur fréquente. La bonne question à se poser est : quelle est la valeur d'une donnée fraîche par rapport à une donnée légèrement vieillie ? Si une décision doit être prise en quelques secondes — bloquer une transaction suspecte, ajuster un prix, envoyer une notification pertinente — alors le streaming se justifie pleinement.

À l'inverse, si les données alimentent un rapport consulté une fois par jour, ou un modèle réentraîné chaque semaine, un pipeline batch suffit largement et coûtera bien moins cher à opérer. Maintenir une infrastructure streaming implique une surveillance permanente, une gestion des pannes plus fine et des compétences spécifiques dans l'équipe.

Un critère pratique consiste à évaluer le coût de la latence. Prenons un exemple : une plateforme e-commerce qui recalcule ses recommandations produits. Si le recalcul quotidien génère des ventes satisfaisantes, le passage au temps réel n'apportera qu'un gain marginal difficile à justifier. En revanche, un système de détection de fraude bancaire perd tout intérêt s'il détecte l'anomalie le lendemain. Entre ces deux extrêmes, beaucoup de cas relèvent du micro-batch, qui offre une fraîcheur de quelques minutes sans la complexité du streaming pur. Commencez toujours par le besoin métier, pas par la technologie.

Les cas d'usage typiques du streaming

Plusieurs domaines tirent une valeur claire du traitement en temps réel. La détection de fraude et de sécurité en est l'exemple emblématique : analyser les transactions ou les connexions au fil de l'eau permet de bloquer une action malveillante avant qu'elle ne cause des dommages. Chaque seconde compte, et un traitement différé serait inutile.

La surveillance opérationnelle et l'observabilité constituent un autre terrain naturel. Les métriques d'infrastructure, les logs applicatifs et les traces sont ingérés en continu pour déclencher des alertes dès qu'un seuil est franchi. Une équipe d'exploitation veut savoir qu'un service est saturé maintenant, pas dans une heure.

La personnalisation en direct fait aussi bon usage du streaming : adapter le contenu affiché à un visiteur en fonction de son comportement immédiat, ou mettre à jour un panier et des recommandations pendant la navigation. Dans l'IoT et l'industrie, les capteurs génèrent des flux constants que l'on analyse pour la maintenance prédictive ou le pilotage d'équipements. Enfin, la synchronisation de données entre systèmes via la capture de changements (CDC) permet de propager instantanément les modifications d'une base source vers des systèmes analytiques, gardant plusieurs environnements cohérents sans exports lourds. Ces cas partagent un point commun : la donnée perd rapidement de sa valeur avec le temps.

Points d'attention avant de mettre en place un pipeline temps réel

Se lancer dans un pipeline temps réel demande d'anticiper plusieurs défis. Le premier est la gestion des pannes et des reprises. Contrairement au batch qu'on peut relancer intégralement, un flux continu impose de savoir reprendre exactement là où le traitement s'est arrêté. Cela suppose de gérer des points de contrôle (checkpoints) et de choisir une garantie de livraison adaptée. Viser le « exactement une fois » est séduisant mais coûteux ; parfois « au moins une fois » couplé à une logique idempotente suffit.

Le deuxième point concerne l'ordre et les événements en retard. Sur un réseau, rien ne garantit que les événements arrivent dans l'ordre de leur création. Votre logique de fenêtrage doit tolérer des arrivées tardives sans corrompre les agrégats, ce qui implique de définir une tolérance (watermark) et une stratégie pour les retardataires.

La qualité et l'évolution du schéma des données méritent une attention particulière. Un producteur qui modifie la structure de ses événements peut casser tous les consommateurs en aval. Mettre en place un registre de schémas et des règles de compatibilité protège le pipeline. Il faut aussi surveiller la qualité en continu, car un événement malformé peut se propager en quelques secondes.

Enfin, ne sous-estimez pas le coût opérationnel humain et financier. Un système streaming tourne 24 h/24 et exige une observabilité solide : métriques de latence, de débit, de retard de consommation (lag). L'équipe doit être prête à intervenir. Une bonne pratique consiste à démarrer petit, avec un cas d'usage à forte valeur, à mesurer les gains réels, puis à étendre progressivement plutôt que de reconstruire toute l'architecture d'un coup.

Exemple

Comparaison entre traitement par lots, micro-batch et temps réel

Critère	Batch	Micro-batch	Temps réel (streaming)
Latence typique	Heures à jours	Secondes à minutes	Millisecondes à secondes
Priorité	Débit et volume	Compromis	Fraîcheur des données
Coût d'opération	Faible (ressources ponctuelles)	Moyen	Élevé (infrastructure permanente)
Complexité	Faible	Moyenne	Élevée
Cas d'usage type	Rapports quotidiens	Tableaux de bord quasi temps réel	Détection de fraude, alertes

FAQ

Quelle est la différence entre streaming et micro-batch ? Le streaming traite chaque événement individuellement au fil de l'eau, offrant la latence la plus faible. Le micro-batch découpe le flux en très petits lots traités toutes les quelques secondes. Le micro-batch est plus simple à opérer et suffit à de nombreux besoins de fraîcheur de l'ordre de la minute, tandis que le streaming pur s'impose quand chaque milliseconde compte.

Faut-il toujours privilégier le temps réel pour un projet de données ? Non. Le temps réel ajoute de la complexité et du coût opérationnel. Il se justifie uniquement quand la valeur d'une donnée fraîche dépasse clairement celle d'une donnée légèrement vieillie. Pour un rapport quotidien ou un modèle réentraîné chaque semaine, un pipeline batch reste souvent le choix le plus raisonnable.

Qu'est-ce que la différence entre event time et processing time ? L'event time est le moment où un événement a réellement été créé à la source. Le processing time est le moment où le système le reçoit et le traite. À cause de la latence réseau, un événement peut arriver après sa fenêtre logique. Bien gérer cet écart, notamment avec des watermarks, évite des agrégats faussés.

Comment gérer les pannes dans un pipeline en streaming ? On s'appuie sur des points de contrôle (checkpoints) qui enregistrent la position de traitement, et sur la capacité du bus de messages à rejouer les événements depuis un point donné. Le choix d'une garantie de livraison adaptée — au moins une fois avec une logique idempotente, par exemple — permet de reprendre sans perte ni double comptage.