Introduction
Les « données en temps réel » ont transformé la façon dont les gens vivent et dont les entreprises opèrent. La capacité à délivrer des données dès qu'elles sont collectées a touché et amélioré tant de nos fonctions les plus élémentaires — de la consultation de la météo à la commande de nourriture en passant par l'envoi d'argent — et, en apparence du jour au lendemain, a changé des attentes séculaires sur la rapidité avec laquelle l'information, les produits et les services peuvent être fournis et consommés. Aux fins de ce billet de blog, nous définissons les données en temps réel comme toute donnée pouvant être ingérée, traitée et exploitée avec une faible latence, et la diffusion de données (data streaming) comme l'ensemble des capacités nécessaires pour intégrer les données en temps réel dans un écosystème de données d'entreprise.
Pour les entreprises, les technologies de données en temps réel ont mis plus de temps à produire pleinement leurs effets mais n'en sont pas moins transformatrices pour l'efficacité globale d'une activité donnée. À mesure que les écosystèmes de données ont évolué pour traiter les données de plus en plus rapidement, les attentes organisationnelles quant à l'utilisation de ces flux pour éclairer des décisions critiques ont évolué de concert. Concrètement, les fabricants de produits alimentaires et de boissons peuvent désormais arrêter la production d'un produit donné quelques minutes après l'identification d'un défaut. Les compagnies aériennes peuvent échanger des avions et ajuster les plannings d'équipage quelques minutes après avoir identifié une perturbation météorologique. Les banques peuvent suspendre un compte pour examen quelques secondes après avoir signalé une transaction suspecte. En réduisant l'écart entre la collecte des données et la prise de décision à presque zéro, les données en temps réel ont apporté des améliorations matérielles à d'innombrables processus métier et, dans certains cas, permis des capacités entièrement nouvelles.
Comme tant d'autres technologies transformatrices, le fossé entre les promesses des données en temps réel et leur mise en œuvre peut être assez vaste. Cela est particulièrement vrai dans le contexte des RFP, où les promesses de « débit en gigaoctets » et de « latences en millisecondes » sont courantes mais impossibles à vérifier sur le papier. Dans ce billet, nous explorons certaines des considérations importantes liées aux données en temps réel et aux technologies de diffusion qui les rendent possibles, en nous appuyant sur notre expérience d'aide à de nombreuses organisations industrielles et gouvernementales pour générer de la valeur à partir des données en temps réel.
Qu'est-ce que la diffusion de données (Data Streaming) ?
La diffusion de données (data streaming) renvoie à l'ensemble des capacités nécessaires pour traiter des informations en temps réel au sein d'un écosystème de données.¹ Le streaming peut désigner un grand nombre d'opérations, notamment la collecte de données, l'ingestion, la transformation, la modélisation, la contextualisation, la rétroécriture, l'analyse et les actions — et il est crucial que les organisations définissent précisément ce qu'elles entendent par diffusion de données avant de rechercher des solutions possibles. Après tout, « diffusion de données » et « données en temps réel » peuvent signifier des choses très différentes selon les contextes. Ce qui est considéré comme un « retard acceptable » pour commander un déjeuner ou transférer de l'argent à un ami est très différent des retards acceptables pour dépêcher des ambulanciers ou signaler un dysfonctionnement dans le système GPS d'un sous-marin. Pour chaque cas d'usage, les sources de données, les architectures systèmes et les attentes des consommateurs varient largement, ce qui modifie à son tour la définition même de la diffusion de données lorsqu'elle est appliquée à ces contextes.
Les sources de données diffusées (streamées) sont généralement différenciées des sources de données « traitées par lots », qui, comme leur nom l'indique, décrivent des données traitées par groupements discrets et selon un calendrier spécifique.² De manière générale, les éléments définissant les flux de données sont la vitesse et la continuité. Les pipelines de diffusion de données traitent les données avec de faibles latences (souvent en quelques secondes ou moins) et à intervalles rapides et continus. Les données en streaming entrent généralement dans l'écosystème de données sous forme d'une série continue d'« événements » horodatés, raison pour laquelle on parle souvent de « traitement de flux d'événements » et de « flux de données en temps réel ».
En ce sens, la définition de la diffusion de données est simple — déplacer l'information dans un écosystème de données rapidement et en continu. Mais définir la diffusion de données dans le contexte des écosystèmes de données réels peut être difficile lorsqu'on considère toutes les opérations qui composent un pipeline de streaming, et plus généralement tout ce que fait un écosystème de données. Jusqu'à présent dans cette série RFx, nous avons abordé quelques composants clés d'un écosystème de données — ontologie, intégration de données, contrôle de version des pipelines de données, interopérabilité, sécurité opérationnelle, confidentialité, modélisation IA/ML — et pour qu'un écosystème de données intègre véritablement des données diffusées, il doit être capable d'appliquer chacune de ces capacités (et d'autres) à des données à fort volume et à faible latence. Le tableau ci-dessous met en évidence certaines des capacités clés d'une architecture de diffusion de données fonctionnelle, réparties en trois phases : ingestion des données, transformation des données et consommation des données.
Du point de vue de l'architecture de plateforme, la grande question n'est pas de concevoir un système autonome pour les données diffusées, mais plutôt de concevoir un système permettant aux utilisateurs finaux d'interagir avec des sources de données diffusées aux côtés de sources de données par lots classiques. En d'autres termes, la solution de diffusion de données la plus efficace est celle où les utilisateurs du système peuvent interagir avec toutes les sources de données intégrées de la même manière, avec les mêmes politiques de gouvernance, sans se soucier de savoir si les données proviennent d'un type de source ou d'un autre. Ce qui rend cela difficile, c'est que les données diffusées et les données par lots nécessitent des technologies backend très différentes. On ne peut pas simplement canaliser des données en streaming dans une plateforme conçue pour des sources de données conventionnelles pas plus qu'on ne peut fixer des moteurs plus puissants sur un 737 et s'attendre à ce qu'il vole en toute sécurité à vitesse supersonique.
Étant donné la large gamme de cas d'usage et de sources de données liés au streaming, il existe différentes façons de construire une architecture de diffusion de données efficace. Mais les principaux composants fonctionnels ont tendance à être similaires d'un système à l'autre. Le schéma ci-dessus présente certains de ces composants clés et la manière dont ils s'articulent.
- L'ingestion de données amène les données en streaming depuis les systèmes sources dans l'écosystème de données. L'API de connexion de données (Data Connection API) exécute des tâches d'ingestion de longue durée, tandis que le proxy de flux (Stream Proxy) expose des points de terminaison pour recevoir de nouveaux enregistrements depuis des systèmes externes avant de valider et d'ingérer l'information dans la plateforme pour un traitement ultérieur.
- La transformation des données applique plusieurs processus aux données ingérées. Les données sont stockées dans une solution de stockage de données en cluster et hautement disponible telle que Kafka. Un moteur de calcul (Compute Engine) tel qu'Apache Flink est utilisé pour exécuter des transformations et des calculs de streaming distribués sur les données stockées. Ce moteur est composé d'un gestionnaire de travaux (Job Manager) pour coordonner le travail effectué dans le cluster et d'un gestionnaire de tâches (Task Manager) pour exécuter directement les transformations sur les données. Le gestionnaire de cluster (Cluster Manager) gère des tâches de cycle de vie telles que la mise à jour des versions de Flink et le téléchargement des JAR de code utilisateur, et le travailleur de flux (Stream Worker) aide à lancer de nouveaux clusters. L'archivage de flux (Stream Archiver) lit les données en streaming vers un stockage froid, en organisant l'information en sujets connus et leurs jeux de données correspondants. La manière dont le système équilibre les considérations de stockage (stockage chaud à faible latence mais coûteux vs. stockage froid lent mais économique) est une considération critique pour toute solution de streaming, comme discuté dans le dernier point de la section Exigences ci-dessous. Le catalogue de flux (Stream Catalog) maintient une cartographie des données entre le stockage de streaming (chaud) et l'archivage (froid) afin d'assurer des opérations de stockage efficaces.
- La consommation de données inclut des mécanismes permettant aux utilisateurs d'interagir avec les données en streaming selon leurs besoins et flux de travail spécifiques. Des puits (sinks) enfichables fournissent un cadre prescriptif pour des flux de données à très faible latence, recevant des données du moteur de calcul et les envoyant vers une destination définie pour une utilisation dans des applications en aval. La rétroécriture vers l'ontologie (ontology write-back) connecte les données en streaming aux objets et actions d'une ontologie, permettant aux utilisateurs finaux de comprendre les données en streaming dans leur contexte. Les règles et alertes constituent un flux de travail de streaming populaire, car les organisations établissent une logique pour surveiller des systèmes ou des actifs et alerter les utilisateurs lorsqu'un certain seuil est atteint. Les utilisateurs peuvent configurer des puits pour écrire les données en streaming directement vers des bases cibles telles que des bases de données de séries temporelles et d'autres data stores clients.
Définir la diffusion de données s'avère assez difficile et vaste parce qu'elle renvoie à « toutes les choses » qu'un écosystème de données fait, mais avec des données diffusées. Et parce que la plupart des écosystèmes de données ont été conçus pour des sources de données plus courantes, traitées par lots, la capacité à intégrer des données diffusées de manière fluide constitue un défi majeur pour de nombreuses entreprises. Pour cette raison, il est important d'évaluer les technologies de streaming non seulement sur leur capacité à répondre à des normes strictes liées à la latence, à la disponibilité et à la scalabilité, mais aussi sur la qualité de leur interaction avec les autres actifs de données et composants de la plateforme.
Pourquoi la diffusion de données est-elle importante ?
Le streaming compte lorsque les secondes comptent. Plus une entreprise peut traiter un flux de données en temps réel rapidement, plus elle peut façonner une réponse rapidement à ce que lui dit ce flux de données.
La manière exacte dont les flux de données en temps réel sont intégrés, transformés et exploités varie bien sûr selon les organisations et les secteurs. Une société de transport maritime pourrait utiliser des données météorologiques émergentes pour informer la route et le calendrier d'une flotte particulière de porte-conteneurs ; une entreprise de services financiers pourrait utiliser des données de transactions en temps réel pour estimer la probabilité de fraude ou de blanchiment d'argent pour un ensemble donné de comptes ou de transactions ; un constructeur automobile pourrait utiliser des données de capteurs provenant de robots de soudage sur la chaîne de production afin d'identifier un défaut particulier et de mettre la production en pause en conséquence. Pour nombre de nos clients, la diffusion de données a considérablement réduit les délais de workflows critiques. Pour d'autres, elle a permis des workflows entièrement nouveaux qui n'étaient pas possibles auparavant.
Prenons la construction de plateformes pétrolières offshore comme exemple. La mise en service d'une plate-forme pétrolière est une entreprise dangereuse et à forte intensité de capital. Elle nécessite de nombreuses équipes d'ingénieurs et d'ouvriers pour établir le puits lui-même et l'écosystème de tuyaux, grues, stockage et quartiers de vie situés au-dessus. Les plateformes modernes sont équipées de capteurs tout au long du pipeline principal du puits et sur la plate-forme elle-même, qui diffusent de grandes quantités de données horodatées liées aux températures, pressions et limites d'exploitation. Les technologies de diffusion de données permettent aux sociétés pétrolières et gazières d'ingérer, d'harmoniser et d'exécuter des tâches computationnelles complexes sur ces données, offrant des capacités de surveillance en direct pour identifier les problèmes de performance du puits en temps réel. Combinée à une infrastructure robuste de tableaux de bord et d'alertes, la diffusion de données rend les plateformes pétrolières significativement plus sûres et plus efficaces en prévenant les blessures, les accidents environnementaux et les arrêts de puits.
Plus largement, les organisations en sont venues à attendre le traitement des données en temps réel. Tout comme les consommateurs individuels ont adopté « l'économie du maintenant » pour des choses comme l'actualité, la nourriture et le covoiturage, les entreprises aussi exigent un accès immédiat à toutes les informations les plus récentes sur leur activité, quelle qu'en soit l'échelle ou la complexité. Pour reprendre l'exemple ci-dessus, les clients du secteur pétrolier et gazier s'appuient désormais sur des données de capteurs diffusées pour assurer la sécurité et la performance le long de leurs réseaux de pipelines, car ces capacités représentent un changement transformateur dans leur capacité à protéger les travailleurs et à maintenir les puits en fonctionnement. De même, les clients d'autres secteurs ont désormais intégré les attentes liées à la diffusion de données dans leurs workflows les plus critiques, car elles permettent des workflows et des résultats jugés essentiels.
La diffusion de données peut être considérée comme une étape nécessaire et inévitable vers des écosystèmes de données modernes. La technologie s'améliore ; les ordinateurs deviennent plus rapides ; les données deviennent plus variées et plus complexes, ce qui nécessite un calcul et une livraison plus immédiats.
Exigences
D'abord, une note sur les exigences de latence. L'exigence technique la plus courante (et parfois la seule) liée à la diffusion de données concerne les SLA de latence (Service Level Agreements, accords de niveau de service). Par exemple, les RFP incluent couramment une exigence de streaming rédigée comme suit : « la solution doit présenter une latence de bout en bout inférieure à deux secondes pour les sources de données en streaming. » Bien que ce « besoin de vitesse » soit réel et important, il ignore certaines considérations essentielles qui affectent l'efficacité d'une solution de streaming. Plus précisément, les SLA de latence doivent être spécifiques et réalistes quant aux opérations attendues dans une délimitation temporelle donnée. Les deux secondes incluent-elles la lecture, l'ingestion et l'harmonisation des données avec une ontologie ? Incluent-elles les transformations, les jointures et l'écriture de retour vers l'ontologie ? À mesure que les pipelines de données se développent et que la liste des attentes opérationnelles s'allonge, les SLA inférieurs à la seconde peuvent manquer d'utilité au mieux ou devenir prohibitifs au pire, évinçant des fonctions importantes du pipeline de données qui ne peuvent raisonnablement pas tenir dans une fenêtre temporelle arbitraire.
- La solution de streaming doit prendre en charge une intégration complète avec des sources de données structurées/par lots. Si l'un des objectifs principaux d'un écosystème de données est d'unifier tous les actifs de données de l'entreprise et de fournir un point d'accès harmonisé aux utilisateurs du système, ce système doit être capable d'intégrer les données diffusées avec les données par lots. Cette fusion des sources de données aide les utilisateurs à explorer les données en temps réel dans leur contexte avec d'autres sources, offrant la vision la plus complète possible pour l'action ou la prise de décision ultérieure.
- La solution doit fournir un accès immédiat à l'historique complet des données diffusées. Un défi majeur pour les données en streaming est le coût du stockage ; les volumes de données et les fréquences de mise à jour sont si élevés qu'il devient souvent prohibitif de rendre l'intégralité de l'historique des données disponible aux utilisateurs du système. Pourtant, les organisations ont besoin d'un accès fiable et persistant aux versions historiques des sources de données diffusées, faute de quoi le système de streaming deviendra cloisonné d'une manière que l'écosystème de données a précisément été conçu pour éviter. Pour rendre les versions historiques des données en streaming disponibles de manière persistante, les solutions de streaming devraient inclure des processus automatiques qui déplacent les données du stockage chaud vers le stockage froid, ainsi qu'une bibliothèque bien définie permettant une lecture fluide des données entre les deux.
- La solution doit permettre des politiques flexibles de rétention et de suppression des données en streaming. La nature des données en streaming — massives, bruyantes et souvent pertinentes pour une courte période — renforce la nécessité d'un service de rétention robuste. Pour cette raison, les solutions de streaming doivent inclure un service de rétention basé sur des règles, configurable pour identifier automatiquement et, si souhaité, supprimer des informations selon des exigences spécifiques au client. Ce service doit permettre des politiques granulaires (c'est-à-dire spécifier quelles politiques s'appliquent à quelles sources de données) et une gamme entièrement personnalisable de politiques de rétention/suppression des données. Par exemple, un utilisateur devrait pouvoir mettre en œuvre une politique automatique de rétention des données qui identifie un sous-ensemble spécifique des données en streaming avec des caractéristiques de métadonnées particulières, rende ce sous-ensemble inaccessible à des groupes spécifiques d'utilisateurs pendant une période définie, puis purge définitivement ces données du système.
- La solution doit connecter les flux de données aux objets de l'ontologie. La contextualisation des données en temps réel exige plus que la simple combinaison des flux de données avec d'autres sources ; les flux doivent également être cartographiés de manière systématique à des concepts sémantiques significatifs via une ontologie. Dans un billet précédent, nous avons expliqué en quoi la notion d'ontologie — une carte qui relie données et sens en définissant des objets, des propriétés et des liens qui sont significatifs pour une organisation — est un élément fondamental de tout écosystème de données efficace. Par extension, le processus de contextualisation des données diffusées au sein de l'écosystème plus large implique de lier les données en temps réel à leurs objets ontologiques pertinents — tels qu'une plate-forme pétrolière, un aéronef ou une personne. Ce n'est qu'alors que les organisations peuvent avoir une vue contextuelle complète de leurs données en temps réel.
- La solution doit prendre en charge le versionnage et le branchement des données diffusées, y compris les relectures granulaires d'événements temporels. Dans le contexte d'un pipeline de données, le contrôle de version fait référence à un système aidant à suivre et à gérer les modifications apportées aux données, tandis que le branchement renvoie à un environnement séparé (ou « branché ») où un développeur peut écrire, tester et réviser du code avant qu'il ne soit approuvé pour la production et fusionné à nouveau dans la branche principale. Dans un billet précédent, nous avons expliqué à quel point ces technologies sont importantes pour un écosystème de données, permettant la collaboration, l'expérimentation et des historiques granulaires de toutes les modifications tout en suscitant une confiance collective dans l'écosystème lui-même. Tous ces arguments sur l'importance des capacités de versionnage et de branchement s'appliquent aux sources de données diffusées — peut-être même particulièrement, puisque les données en streaming se présentent souvent en séries temporelles, ce qui rend les relectures d'événements temporels d'autant plus utiles et importantes.
- La solution doit permettre la transformation des données en temps réel sur des données diffusées, permettant une intégration rapide et des builds continus. Les pipelines de données impliquent plusieurs transformations, où une série de changements incrémentaux est appliquée aux données brutes afin de les rendre utiles aux utilisateurs du système en aval. Les données en streaming présentent de multiples défis de transformation en raison du volume et de la fréquence des mises à jour entrantes. Pour qu'une architecture de streaming soit efficace, elle doit permettre des transformations de données complexes et persistantes qui prennent un ou plusieurs jeux de données en streaming comme entrée et produisent un ou plusieurs jeux de données en streaming comme sortie. Les développeurs ont également besoin d'un environnement d'authoring robuste pour définir ces builds continus et créer des fonctions définies par l'utilisateur (UDF).
- La solution doit inclure des connecteurs préconstruits et prêts à l'emploi vers des sources de données en streaming courantes. Les flux de données proviennent de nombreuses sources différentes. Les types de systèmes courants incluent Apache Kafka, Google Pub/Sub, OSI PI, Amazon Kinesis et Azure Event Hub. L'un des coûts majeurs de l'intégration de sources diffusées dans un écosystème de données est le développement personnalisé requis pour établir une connexion de données. Ces coûts peuvent être réduits ou éliminés par un système avec des connecteurs préconstruits vers des sources de données en streaming courantes et une interface utilisateur guidée qui accompagne les utilisateurs tout au long du processus d'intégration.
Conclusion
L'évaluation des technologies de streaming peut être très difficile étant donné la large gamme de composants nécessaires dans une solution robuste et la difficulté d'évaluer ces composants sur le papier. Des solutions efficaces nécessitent à la fois une architecture de streaming dédiée pour exécuter des tâches d'ingestion, de transformation et de consommation, ainsi qu'un mécanisme pour intégrer ces données dans l'écosystème plus large. Ce composant d'intégration — où les organisations doivent connecter les données en streaming à d'autres sources de données non diffusées via un modèle de données défini — est central pour la solution de streaming et souvent négligé dans les RFP, qui ont tendance à se concentrer sur les latences temporelles et les compatibilités de sources de données. Les évaluateurs gagneraient à acquérir une compréhension approfondie de la manière dont les systèmes de streaming contextualisent les données en temps réel au sein de l'écosystème de données plus large, et de la manière dont ces technologies de streaming ont eu un impact dans des environnements réels.
[1] Les « données en temps réel » sont, bien sûr, un abus de langage puisqu'il est impossible de traiter des données avec zéro latence. L'un de nos objectifs en écrivant ce billet est de définir plus précisément ce terme largement accepté. « Données quasi temps réel » ou « données à faible latence » sont des formulations plus exactes (bien que moins accrocheuses) car elles impliquent un décalage minimal entre le moment où les données sont collectées et celui où elles sont utilisées.
[2] Cette distinction entre données diffusées et données par lots n'est pas toujours exacte ou utile, car les données en streaming sont également livrées par lots et selon un calendrier défini — seulement, ces lots sont généralement plus petits et bien plus fréquents. Pour cette raison, il est généralement plus utile de considérer les données diffusées et les données par lots comme un continuum, plutôt que comme une différence de nature.