Qu’est-ce que la transmission d’événements en continu ?

Fonction clé du traitement de flux d’événements (ESP), la transmission d’événements en continu permet aux infrastructures informatiques de gérer des flux d’événements volumineux et continus en traitant les données dès qu’un événement ou un changement survient. La transmission d’événements en continu se distingue du traitement de flux. La transmission d’événements en continu fournit l’infrastructure qui achemine et stocke les événements. Le traitement de flux peut appliquer des opérations de filtrage, d’agrégation ou d’enrichissement à ces événements.

La transmission d’événements en continu complète souvent le traitement par lots, qui porte sur de grands jeux de données statiques, ou « données au repos ». Toutefois, au lieu de traiter des données bornées par lots, elle peut gérer des données non bornées au fur et à mesure de leur arrivée. Cette approche permet aux logiciels de l’architecture d’interpréter les flux de données, ou « données en mouvement », et d’y réagir en temps réel.

Les services de transmission d’événements en continu à hautes performances peuvent prendre en charge diverses tâches, des fonctions simples, comme l’envoi de notifications lorsque le cours des actions ou le prix des produits change, aux workloads plus complexes. Ils peuvent également prendre en charge des modèles d’intelligence artificielle (IA) et de machine learning en temps réel qui détectent les activités suspectes des utilisateurs. 

Même dans le cas du traitement par lots, la transmission d’événements en continu peut enrichir l’analyse des données en associant les événements à leurs horodatages respectifs. Elle permet également d’identifier les tendances historiques, fournissant ainsi des informations précieuses au fil du temps.

La transmission d’événements en continu repose sur un flux continu et potentiellement non borné d’enregistrements de données appelés « événements ». Ces structures de données fondamentales consignent tout fait survenant dans le système ou son environnement. Un événement est un enregistrement immuable attestant qu’un fait s’est produit, comme la passation d’une commande ou l’autorisation d’un paiement. Un « flux », également appelé « flux de données » ou « données en continu », désigne la transmission continue de ces événements.

Chaque événement comprend généralement une clé qui identifie l’événement ou l’entité à laquelle il se rapporte, ainsi qu’une valeur contenant les données proprement dites de l’événement. Il comporte aussi un horodatage indiquant quand l’événement s’est produit ou a été enregistré, et parfois des métadonnées sur la source des données, la version du schéma ou d’autres attributs.

À l’aide de moteurs spécialisés dans le traitement de flux, les événements peuvent faire l’objet de différents traitements au sein d’un flux. Les « agrégations » effectuent des calculs sur les données, comme des moyennes, des sommes et des écarts types. L’« ingestion » ajoute des données en continu aux bases de données. Le traitement analytique utilise les régularités observées dans les données en continu pour prévoir des événements futurs, tandis que le traitement d’enrichissement associe les points de données à d’autres sources de données pour leur apporter du contexte et du sens.

Les entreprises qui génèrent d’importants volumes de données d’événements peuvent recourir à l’analyse en temps réel pour repérer des régularités, des anomalies et des tendances dès leur apparition. L’IA s’appuie sur ces enseignements en temps réel pour détecter des relations complexes dans les flux d’événements, établir des prévisions et recommander des actions.

Cette capacité devient un prérequis pour les systèmes d’IA : selon IDC, 80 % des cas d’utilisation de l’IA agentique nécessitent des données en temps réel, contextuelles et largement accessibles. Qu’ils servent à l’analyse, à l’IA ou aux workflows automatisés, ces systèmes reposent sur un flux continu d’événements qui représentent l’activité de l’ensemble de l’entreprise.

Les événements sont liés aux opérations de l’entreprise ou aux parcours de navigation des utilisateurs et déclenchent généralement une autre action, un autre processus ou une série d’événements. Prenons l’exemple de la banque en ligne. Lorsqu’un utilisateur clique sur « Transférer » pour envoyer de l’argent d’un compte bancaire à un autre, les fonds sont débités du compte de l’émetteur et crédités sur celui du bénéficiaire. Des notifications par e-mail ou SMS sont envoyées à l’une des parties ou aux deux et, si nécessaire, des protocoles de sécurité et de prévention de la fraude sont déployés.

Les événements sont le composant central de la transmission d’événements en continu. Cependant, une série d’autres composants permettent aux services de transmission en continu de traiter les événements de manière rapide et efficace, notamment :

Les brokers reçoivent les événements des producteurs, les organisent, les stockent et les mettent à la disposition des consommateurs. En jouant le rôle d’intermédiaires, les brokers permettent aux producteurs et aux consommateurs de communiquer sans connexion directe, et donc de fonctionner et d’être mis à l’échelle indépendamment les uns des autres. 

Dans les systèmes distribués de transmission d’événements en continu, les brokers garantissent une faible latence et une haute disponibilité en répliquant les événements sur plusieurs nœuds. Les brokers peuvent également former des clusters, c’est-à-dire des ensembles de brokers qui travaillent ensemble pour faciliter l’équilibrage de charge et l’évolutivité.

Les sujets sont des catégories ou des noms de flux auxquels les événements sont rattachés, offrant un moyen d'organiser et de filtrer les événements au sein de la plateforme. Ils agissent comme « objet » pour les événements, ce qui permet aux consommateurs de s’abonner à des sujets et de ne recevoir que des événements pertinents.

Les sujets peuvent être divisés en partitions, ce qui permet à plusieurs consommateurs de lire simultanément à partir d'un sujet sans perturber l'ordre de chaque partition.

Un décalage est un identifiant unique qui identifie chaque événement au sein d'une partition, indiquant sa position dans la séquence. Les consommateurs utilisent les décalages pour organiser les événements qu'ils ont traités. Si, par exemple, un consommateur se déconnecte d'un événement et se reconnecte par la suite, il peut reprendre le traitement à partir du dernier décalage connu.

Compte tenu de la prolifération des données et de l’explosion du trafic de données qui en résulte, la transmission d’événements en continu est un composant essentiel des architectures de données modernes. Cela est particulièrement vrai dans les environnements qui nécessitent des capacités de prise de décision extrêmement rapides ou dans les entreprises qui cherchent à automatiser les responsabilités décisionnelles.

Voici comment les services de transmission d’événements en continu gèrent les données d'événements :

1. Génération des événements. La transmission d’événements en continu commence lorsque les producteurs, par exemple des microservices, des systèmes backend, des écosystèmes IdO ou des API orientées événements, envoient des événements à la plateforme de transmission d’événements en continu.
   
   
2. Publication d’événements. À l’aide de bibliothèques clientes, les producteurs publient l’événement sur un sujet spécifique au sein de la plateforme, et à partir de ce moment, il devient disponible pour les consommateurs (les applications et les services qui s’abonnent au sujet).
   
   
3. Stockage des événements. La plateforme stocke les événements pendant une durée prédéfinie, tandis que les brokers gèrent leur stockage et leur récupération.
   
   
4. Consommation d’événements. Les consommateurs traitent les données d’événement pour initier d’autres événements. En fonction de leur objectif ou de leur configuration, les consommateurs peuvent traiter les événements immédiatement à leur arrivée (traitement en temps réel), les stocker pour un traitement ultérieur ou les compiler pour un traitement par lots. Ils utilisent également des décalages pour suivre leur progression dans le pipeline de données, ce qui leur permet de reprendre le traitement à partir de l’endroit où ils se sont arrêtés, en cas de panne ou de redémarrage.
   
   
5. Distribution des événements. Le broker d’événements met les événements à la disposition des consommateurs. Il peut assurer leur distribution selon la sémantique « au moins une fois », qui garantit que chaque événement atteint sa destination, même en cas de doublons. Le processus peut également appliquer la sémantique de distribution « exactement une fois », qui garantit que chaque événement est distribué une fois et une seule, ou une autre sémantique.
   
   
6. Traitement des événements. Une fois l’événement initial consommé et distribué, ses données sont traitées pour effectuer plusieurs actions en aval, notamment leur transformation, leur agrégation et le déclenchement de workflows de traitement des événements complexes (CEP). Les entreprises utilisent couramment des technologies de traitement de flux comme Apache Flink, Apache Spark Structured Streaming et Kafka Streams pour effectuer ces opérations en temps réel dans des systèmes distribués orientés événements. Les flux de données en temps réel qui en résultent peuvent également fournir le flux continu de données que les systèmes d’IA utilisent pour faciliter la prise de décision en temps réel.

La transmission d’événements en continu est généralement mise en œuvre sous la forme d’une architecture distribuée conçue pour capturer, stocker, traiter et distribuer des flux continus de données d’événements entre plusieurs systèmes. Plutôt que de reposer sur des connexions directes point à point, les architectures de transmission d’événements en continu utilisent une infrastructure partagée qui découple les producteurs de données des consommateurs. Les applications peuvent ainsi être mises à l’échelle indépendamment et échanger des informations en temps réel. Ce cadre repose sur plusieurs composants essentiels de l’architecture :

Le broker d’événements est un composant clé de la plupart des architectures de transmission d’événements en continu. Il sert de socle de stockage persistant et évolutif pour les données d’événements. Les événements sont écrits dans les rubriques d’un journal distribué, où ils sont stockés dans leur ordre de réception et restent disponibles pour une consommation ultérieure.

Cette architecture permet à plusieurs applications d’accéder indépendamment au même flux d’événements, sans nécessiter d’intégration directe avec les systèmes qui ont produit les données. Des technologies comme Apache Kafka, Amazon Kinesis et Apache Pulsar offrent couramment cette capacité.

Pour prendre en charge des workloads à grande échelle, les flux d’événements sont généralement organisés en rubriques et divisés en partitions qui peuvent être réparties sur plusieurs serveurs. Le partitionnement permet un traitement parallèle et un débit plus élevé, tandis que la réplication crée des copies des données sur différents nœuds pour améliorer la tolérance aux pannes et la disponibilité en cas de défaillance de certains composants.

Les architectures de transmission d’événements en continu séparent les systèmes qui génèrent les données de ceux qui les utilisent. Les producteurs publient des événements dans des rubriques, tandis que les consommateurs s’abonnent à ces rubriques et traitent les événements indépendamment. Cette conception découplée permet d’ajouter de nouvelles applications et de nouveaux services sans modifier les systèmes qui génèrent les données.

De nombreuses architectures de transmission d’événements en continu intègrent une couche de traitement de flux qui analyse et transforme les événements à mesure qu’ils traversent le système. Parmi les technologies courantes de traitement de flux figurent Apache Flink, Kafka Streams, ksqlDB et Apache Spark Structured Streaming. Ces technologies prennent en charge des opérations comme le filtrage, l’enrichissement, les jointures et les agrégations sur des données qui arrivent en continu.

Certaines workloads de traitement en continu nécessitent que les applications conservent des informations sur les événements passés. Par exemple, une plateforme d’e-commerce peut analyser tous les achats effectués au cours de la dernière heure pour identifier les produits tendance et actualiser les recommandations en temps quasi réel. La gestion de l’état permet au système de conserver et d’actualiser ces informations au fil du temps, tandis que le fenêtrage organise les flux de données continus en intervalles temporels ou fondés sur les événements à des fins d’analyse.

Les architectures de transmission d’événements en continu intègrent généralement des mécanismes qui contribuent à prévenir les pertes de données et facilitent la reprise après une défaillance. Selon les exigences des applications, les systèmes peuvent offrir des garanties de traitement « au plus une fois », « au moins une fois » ou « exactement une fois ». La création de points de contrôle, la réplication et le suivi des décalages des consommateurs contribuent à maintenir la cohérence des données pendant les interruptions ou les redémarrages du système.

Les événements traités sont généralement transmis à des destinations en aval, comme des bases de données, des entrepôts de données, des lacs de données, des index de recherche, des systèmes de machine learning ou d’autres flux d’événements. Ces intégrations permettent d’utiliser les données d’événements pour l’analyse en temps réel, les applications opérationnelles, les workflows d’automatisation et les applications d’IA.

Outre les fonctions standard de transmission en continu et de traitement, les plateformes de transmission d’événements en continu comme Amazon Kinesis, Google Cloud Pub/Sub, Azure Event Hubs et IBM® Event Automation facilitent diverses pratiques de transmission en continu qui enrichissent leurs fonctionnalités. IBM Event Automation, en particulier, utilise la puissance de traitement de la plateforme open source Apache Kafka pour optimiser les workflows orientés événements. Ces capacités aident également les entreprises à mettre en place les pipelines de données en temps réel dont dépendent les systèmes d’analyse et d’IA.

Le traitement « exactement une fois » signifie que chaque événement d’un flux est traité une fois et une seule. Cette fonctionnalité est essentielle pour éviter la duplication ou la perte d’événements du flux. La plupart des systèmes de transmission d’événements en continu intègrent des mécanismes qui assurent la sémantique « exactement une fois », même en cas de défaillances ailleurs dans le système.

Lorsque les composants en aval ne parviennent pas à suivre le rythme des événements entrants, la contre-pression empêche les flux de saturer le système. Grâce à ce mécanisme de contrôle du flux de données, les consommateurs surchargés par le traitement des données ou incapables de suivre le rythme des événements entrants peuvent demander aux producteurs de ralentir ou d’arrêter la production de données.

Ce mécanisme permet aux systèmes de gérer la charge de travail en mettant en mémoire tampon ou en supprimant les événements entrants, sans perturber l’ensemble du système. Le traitement des événements reste ainsi stable malgré les fluctuations de charge.

Les consommateurs d’événements travaillent souvent au sein d’un groupe de consommateurs pour accélérer la consommation des événements. Chaque consommateur d’un groupe se voit attribuer un sous-ensemble de partitions, ce qui permet une consommation parallèle pour plus d’efficacité. En cas de défaillance, d’ajout ou de suppression d’un consommateur au sein du groupe, la plateforme peut réaffecter dynamiquement les partitions pour maintenir l’équilibre et la tolérance aux pannes.

La transmission d’événements en continu implique souvent un traitement des données soumis à des contraintes de temps. Un filigrane indique jusqu’où le temps des événements a progressé selon l’estimation du système. L’utilisation de filigranes impose un seuil d’exhaustivité qui indique quand le système peut considérer les données d’événements comme entièrement traitées. Elle peut également être utile pour garantir l’exactitude des traitements fondés sur le temps et rétablir la cohérence des événements reçus dans le désordre.

La plupart des plateformes de transmission d’événements en continu offrent des politiques de rétention de données personnalisables qui permettent aux développeurs de déterminer la durée de disponibilité des événements pour consommation. Toutefois, le compactage des données consiste à éliminer les données redondantes ou obsolètes des sujets, optimisant ainsi l’utilisation de l’espace de stockage tout en garantissant la conservation des données cruciales.

Rappelons que les architectures standard de transmission en continu découplent généralement les producteurs d’événements, les brokers d’événements et les consommateurs, afin de permettre la mise à l’échelle et la maintenance de chaque composant indépendamment des autres. Cette flexibilité permet aux entreprises de prendre en charge de nombreuses applications en aval, notamment l’analyse en temps réel, la prise de décision fondée sur l’IA et les workflows automatisés. Cette flexibilité permet aux entreprises de prendre en charge de nombreuses applications en aval, notamment l’analyse en temps réel, la prise de décision fondée sur l’IA et les workflows automatisés.

La différence entre la transmission d’événements en continu et le traitement par lots tient au fait que la première traite les données en continu, à mesure que les événements se produisent, tandis que le second traite les données accumulées, soit périodiquement, soit à la suite d’un déclenchement.

La transmission d’événements en continu et le traitement par lots acheminent et traitent tous deux des données, mais diffèrent principalement par le moment et la manière dont ces données sont traitées. La transmission d’événements en continu capture et achemine en permanence les événements provenant de sources comme les applications, les bases de données et les appareils IdO, dès qu’ils se produisent. Au lieu d’attendre un jeu de données complet, les systèmes traitent les événements individuellement ou en petits groupes dès leur arrivée, ce qui permet des analyses et des réponses à faible latence.

Cette approche convient bien aux cas d’utilisation dans lesquels la valeur des données dépend de leur fraîcheur. Il s’agit notamment de la détection des fraudes, de la surveillance opérationnelle, des recommandations en temps réel et des systèmes d’IA qui reposent sur des informations à jour.

Le traitement par lots collecte les données sur une période définie et les traite ensemble comme une workload distincte. Comme les résultats n’ont pas besoin d’être produits immédiatement, le traitement par lots convient à des tâches comme la génération de rapports quotidiens, le rapprochement des comptes ou l’actualisation des tableaux de bord analytiques.

Les deux approches sont d’ailleurs complémentaires et ne s’excluent pas mutuellement : une entreprise peut utiliser la transmission d’événements en continu pour détecter l’activité et y réagir à mesure qu’elle se produit, puis recourir au traitement par lots pour effectuer une analyse historique complète des données accumulées.

La transmission d'événements en continu est un concept puissant qui permet aux organisations d'utiliser les données dès leur génération, créant ainsi des systèmes plus réactifs et intelligents. Avec l'essor de la prise de décision fondée sur les données, la transmission d'événements en continu est un composant de plus en plus important dans les architectures logicielles modernes.

Par conséquent, les technologies de transmission d'événements en continu sont utilisées dans différents secteurs d'activité, notamment :

Au-delà des usages propres à certains secteurs, la transmission d’événements en continu peut aussi être utile lorsqu’elle est déployée avec d’autres technologies et architectures. Par exemple, la transmission d’événements en continu est parfois associée à des modèles comme l’event sourcing et la séparation des responsabilités entre commandes et requêtes (CQRS).

L’event sourcing est un modèle d’architecture dans lequel les modifications de l’état de l’application sont stockées sous forme de séquence d’événements. Associé aux flux d’événements, l’event sourcing permet au système de transmission en continu de rejouer les événements. Cette capacité peut servir à reconstituer l’état d’une entité à n’importe quel moment ou à piloter d’autres composants du système.

Dans un modèle architectural CQRS, le système est composé de deux modèles distincts : l'un qui gère les commandes (écriture) et l'autre qui gère les requêtes (lecture). Dans le modèle CQRS, la transmission d'événements en continu permet de propager les modifications du modèle d'écriture vers le modèle de lecture en temps réel, facilitant ainsi une intégration asynchrone entre les deux.

La transmission d’événements en continu est également une technologie fondamentale pour construire des architectures orientées événements. Une architecture orientée événements permet à des composants faiblement couplés de communiquer par l’intermédiaire d’événements. Au lieu de publier des flux d’événements vers un broker, elle publie un événement dédié à une fonction précise, qu’une autre application ou un autre service peut utiliser pour exécuter à son tour des actions.

La puissance de traitement en flux des architectures orientées événements, associée aux capacités de transmission d’événements en continu, peut permettre aux entreprises de réagir aux données en mouvement et de prendre rapidement des décisions fondées sur des données actuelles et historiques. Cette réactivité en temps réel sert également aux applications d’analyse et d’IA qui dépendent de données actualisées en continu.

Ces dernières années, les fournisseurs de cloud ont commencé à proposer des services reposant sur les principes de la transmission d’événements en continu. La transmission d’événements en continu en tant que service facilite l’adoption de cette technologie par les entreprises sans qu’elles aient à gérer l’intégralité de l’infrastructure sous-jacente, ce qui élargit encore ses cas d’utilisation.