Par Chris Latimer, vice-président, gestion des produits, DataStax
On parle beaucoup de l'importance des flux de données et des architectures pilotées par les événements en ce moment. Vous en avez peut-être entendu parler, mais savez-vous vraiment pourquoi c'est si important pour de nombreuses entreprises ? Les technologies de streaming débloquent la capacité de capturer des informations et d'agir instantanément sur les données qui circulent dans votre organisation ; ils constituent un élément essentiel du développement d'applications capables de répondre en temps réel aux actions des utilisateurs, aux menaces de sécurité ou à d'autres événements. En d'autres termes, elles jouent un rôle clé dans la création d'expériences client exceptionnelles et la génération de revenus.
Voici une brève description de ce que font les technologies de streaming et pourquoi elles sont si importantes pour les entreprises.
Données en mouvement
. ]Les organisations sont devenues assez douées pour créer une vue relativement complète de ce que l'on appelle les "données au repos" – le type d'informations souvent capturées dans les bases de données, les entrepôts de données et même les lacs de données à utiliser immédiatement (en "temps réel") ou pour alimenter des applications et des analyses ultérieures.
De plus en plus, les données générées par des activités, des actions et des événements qui se produisent en temps réel dans une organisation affluent à partir d'appareils mobiles, de systèmes de vente au détail, de réseaux de capteurs et de systèmes de routage d'appels de télécommunications. .
Bien que ces « données en mouvement » puissent finalement être capturées dans une base de données ou un autre magasin, elles sont extrêmement précieuses tant qu'elles sont toujours en mouvement. Pour une banque, les données en mouvement pourraient lui permettre de détecter une fraude en temps réel et d'agir en conséquence instantanément. Les détaillants peuvent faire des recommandations de produits en fonction de l'historique de recherche ou d'achat d'un consommateur, à l'instant où quelqu'un visite une page Web ou clique sur un article particulier.
Pensez à Overstock, un détaillant en ligne américain. Elle doit constamment proposer des expériences client attrayantes et tirer des revenus des opportunités de monétisation instantanées. En d'autres termes, Overstock recherchait la capacité de prendre des décisions ultra-rapides sur la base de données qui arrivaient en temps réel (généralement, les marques ont 20 secondes pour se connecter avec les clients avant qu'ils ne passent à un autre site Web).
"C'est comme une voiture autonome", déclare Thor Sigurjonsson, responsable de l'ingénierie des données chez Overstock. "Si vous attendez des commentaires, vous allez quitter la route."
L'architecture basée sur les événements
Pour maximiser la valeur de leurs données au fur et à mesure de leur création, au lieu d'attendre des heures, des jours, voire plus pour l'analyser une fois qu'il est au repos—Overstock avait besoin d'une plate-forme de streaming et de messageriequi leur permettrait d'utiliser la prise de décision en temps réel pour offrir des expériences personnalisées et recommander des produits susceptibles d'être bien accueillis par les clients à la temps parfait (vraiment rapide, en d'autres termes).
La messagerie et le streaming de données sont un élément clé d'une architecture événementielle, qui est une architecture logicielle ou une approche de programmation construite autour de la capture, de la communication, du traitement et de la persistance des événements — clics de souris, sorties de capteurs, etc. La capacité d'interroger ce flux non-stop et de trouver des anomalies, de reconnaître que quelque chose d'important s'est produit et d'agir rapidement et de manière significative, c'est ce que permet la technologie de streaming.
Cela contraste avec le traitement par lots, où un l'application stockerait une donnée après l'avoir saisie, la traiterait, puis stockerait le résultat traité ou le transmettrait à une autre application ou à un autre outil. Le traitement peut ne pas commencer avant, par exemple, que 1000 points de données aient été collectés. C'est trop lent pour le type d'applications qui nécessitent un engagement réactif au point d'interaction.
Il vaut la peine de s'arrêter pour détailler cette idée :
- Le point d'interaction pourrait être un système effectuant un appel d'API ou une application mobile.
- L'engagement est défini comme l'ajout de valeur à l'interaction. Il peut s'agir de donner un numéro de suivi à un client après avoir passé une commande, une recommandation de produit basée sur l'historique de navigation d'un utilisateur, ou une autorisation de facturation ou une mise à niveau de service.
- Réactif signifie que l'action d'engagement se produit en temps réel ou en temps quasi réel ; cela se traduit par des centaines de millisecondes pour les interactions humaines, tandis que les interactions de machine à machine qui se produisent dans le réseau de capteurs d'un service public d'énergie, par exemple, peuvent ne pas nécessiter une telle réponse en temps quasi réel.
Lorsque la file d'attente des messages ne l'est pas. assez
Certaines entreprises ont reconnu qu'elles devaient tirer de la valeur de leurs données en mouvement et ont assemblé leurs propres architectures pilotées par les événements à partir d'une variété de technologies, y compris des systèmes middleware orientés message comme le service de messagerie Java (JMS) ou plates-formes de file d'attente de messages (MQ).
Mais ces plates-formes ont été construites sur le principe fondamental que les données qu'elles traitaient étaient transitoires et devaient être immédiatement supprimées une fois que chaque message avait été livré. Cela jette essentiellement un atout très précieux : des données identifiables comme arrivant à un moment particulier dans le temps. Les informations de séries chronologiques sont essentielles pour les applications qui impliquent une analyse asynchrone, comme l'apprentissage automatique. Les data scientists ne peuvent pas créer de modèles de machine learning sans elle. Un système de streaming moderne doit non seulement transmettre les événements d'un service à un autre, mais également les stocker de manière à conserver leur valeur ou leur utilisation ultérieure.
Le système doit également pouvoir évoluer pour gérer des téraoctets de données et millions de messages par seconde. Les anciens systèmes MQ ne sont conçus pour faire ni l'un ni l'autre. en ce qui concerne la technologie de messagerie et de streaming.
Ils incluent divers projets open source tels que RabbitMQ, ActiveMQ et NATS, ainsi que des solutions propriétaires telles qu'IBM MQ ou Red Hat AMQ. Ensuite, il y a les deux plates-formes bien connues et unifiées pour gérer les données en temps réel : Apache Kafka, une technologie très populaire qui est devenue presque synonyme de streaming ; et Apache Pulsar, une nouvelle plate-forme de diffusion en continu et de mise en file d'attente de messages.
Ces deux technologies ont été conçues pour gérer le débit élevé et l'évolutivité requis par de nombreuses applications basées sur les données.
Kafka a été développé par LinkedIn pour faciliter la communication de données entre différentes services de la société de mise en réseau de l'emploi et est devenu un projet open source en 2011. Au fil des ans, il est devenu une norme pour de nombreuses entreprises à la recherche de moyens de tirer de la valeur des données en temps réel.
Pulsar a été développé par Yahoo! pour résoudre les problèmes de messagerie et de données rencontrés par des applications comme Yahoo! Poster; il est devenu un projet open source de haut niveau en 2018. Tout en rattrapant Kafka en popularité, il a plus de fonctionnalités et de fonctionnalités. Et cela porte une distinction très importante : les solutions MQ sont uniquement des plates-formes de messagerie, et Kafka ne gère que les besoins de streaming d'une organisation – Pulsar gère ces deux besoins pour une organisation, ce qui en fait la seule plate-forme unifiée disponible.
Pulsar peut gérer de vrai- temps, des cas d'utilisation à haut débit comme Kafka, mais c'est aussi une solution plus complète, durable et fiable par rapport à l'ancienne plate-forme. Pour avoir le streaming et la mise en file d'attente (un protocole de communication asynchrone qui permet aux applications de se parler), par exemple, un utilisateur de Kafka devrait s'équiper de quelque chose comme RabbitMQ ou d'autres solutions. Pulsar, d'autre part, peut gérer de nombreux cas d'utilisation d'un système de file d'attente traditionnel sans modules complémentaires. en cas de défaillance d'un centre de données ou d'une région cloud. La géoréplication permet à une application de publier des événements dans un autre centre de données sans interruption, empêchant l'application de tomber en panne et empêchant une panne d'affecter les utilisateurs finaux. (Voici une comparaison plus technique de Kafka et Pulsar).
En conclusion
Dans le cas d'Overstock, Pulsar a été choisi comme plateforme de streaming du détaillant. Avec lui, l'entreprise a construit ce que son chef de l'ingénierie Sigurjonsson décrit comme une "couche intégrée de données et de processus connectés régis par une couche de métadonnées prenant en charge le déploiement et l'utilisation de données réutilisables intégrées dans tous les environnements".
En d'autres termes, Overstock now a un moyen de comprendre et d'agir sur les données en temps réel à l'échelle de l'organisation, permettant à l'entreprise d'impressionner ses clients avec des offres magiquement rapides et pertinentes et des expériences personnalisées.
En conséquence, les équipes peuvent transformer de manière fiable les données en vol d'une manière qui est facile à utiliser et nécessite moins d'ingénierie de données. Il est ainsi beaucoup plus facile de satisfaire leurs clients et, au final, de générer davantage de revenus.
Pour en savoir plus sur DataStax, rendez-nous visite ici.
À propos de Chris Latimer
Chris Latimer est un cadre technologique dont la carrière s'étend sur plus de vingt ans dans une variété de rôles, y compris l'architecture d'entreprise, les avant-ventes techniques et la gestion des produits. Il est actuellement vice-président de la gestion des produits chez DataStax, où il se concentre sur l'élaboration de la stratégie produit de l'entreprise autour de la messagerie cloud et de la diffusion d'événements. Avant de rejoindre DataStax, Chris était chef de produit senior chez Google, où il s'est concentré sur les API et la gestion des API dans Google Cloud. Chris est basé près de Boulder, CO, et lorsqu'il ne travaille pas, il est un skieur et musicien passionné et apprécie la variété sans fin d'activités de plein air que le Colorado a à offrir avec sa famille.
Source link