Les bons et les mauvais cas d’usage d’Apache Kafka

Kafka au meilleur de sa forme 

La gestion de streams configurables et scalables. « Kafka est idéal pour construire des solutions de traitement de données qui peuvent monter en charge rapidement, tout en restant efficientes et résilientes », estime Kiran Chitturi, architecte CTO chez Sungard Availability Services, un éditeur d’outils de reprise d’activité. Cela comprend l’agrégation de logs, de métriques opérationnelles ou le traitement de flux IoT, des tâches qui nécessitent une faible latence, l’accès à des sources variées ainsi que des associations avec des consommateurs multiples.

Le traitement de messages à grande échelle. « L’argument principal de vente de Kafka, c’est le traitement de messages à grande échelle et le suivi d’activité des sites web », assure Heikki Nousiainen.

« L’argument principal de vente de Kafka, c’est le traitement de messages à grande échelle et le suivi d’activité des sites web. »

Les cas d’usage les plus courants identifiés par le directeur technique sont l’analyse de sentiments des clients par les acteurs de la grande distribution et le traitement de flux de messages par les FAI. Kafka est alors déployé pour stocker et corréler des données en temps réel. Évidemment, une telle approche convient également aux applications IoT qui collectent des informations depuis plusieurs objets, pour les renvoyer vers des systèmes tiers capables de les lire et de les interpréter.

L’un des principaux avantages de Kafka par rapport aux courtiers de messages traditionnels réside dans la réutilisation des données en réorientant les flux existants. 

Un bon middleware de gestion de flux de données. Les entreprises se tournent de plus en plus vers des solutions de dataflow telles qu’Apache NiFi pour augmenter leur capacité d’ingestion. NiFi doit simplifier la collecte d’informations issues de 100 000 machines en continu (100 000 événements par seconde). Mais le fait de connecter ce service peut submerger les applications en aval comme les entrepôts de données ou les moteurs d’analyse, selon Dinesh Chandrasekhar, responsable marketing produit pour la division Data-in-Motion de Cloudera.

Dinesh Chandrasekhar considère que Kafka a sa place entre ces systèmes et NiFi. NiFi peut envoyer des données dans Kafka à grande vitesse. Toutes les autres applications qui ont besoin de ces informations peuvent extraire des topics à leur propre rythme.

« Kafka peut facilement transférer des millions de messages par seconde. »

« Kafka peut facilement transférer des millions de messages par seconde », assure le responsable marketing produit chez Cloudera. De plus, les composants logiciels peuvent recevoir les mêmes données simultanément. Le pipeline est alors plus ouvert et la gestion des connexions plus aisée.

Réaliser des analyses complexes. Différents types d’analyses réclament de combiner des données en temps réel et des informations historiques structurées. Ces cas d’usage requièrent une architecture persistante et redondante en plus des capacités analytiques, d’après les dires de Keith Kohl, SVP chargé de la gestion de produits chez Information Builders, un éditeur d’outils BI.

Kafka se comporte en partie comme une base de données de logs, et permet l’introspection d’un ou d’un ensemble de messages récents. Cela signifie qu’en plus de rechercher des valeurs aberrantes, vous pouvez effectuer des analyses complexes sur les données relatives aux messages précédents.

« L’architecture de Kafka facilite ce type d’exécution, sans les lourdes exigences de traitement qui seraient nécessaires après le chargement des données dans un data store ou dans un data lake », estime Keith Kohl.

Une base de données de messagerie hybride. Une autre des principales forces de Kafka réside dans la combinaison des qualités d’un service de file d’attente de messages et celles d’une base de données, toujours selon Keith Kohl. Cela facilite la mise en place de deux types de cas d’usage :

• Des processus analytiques ou opérationnels – tels que le traitement d’événements complexes – qui utilisent des données en continu, mais qui ont besoin de flexibilité pour analyser la tendance plutôt que l’événement isolé.
• Des flux de données avec plusieurs abonnés.

« L’architecture qui sous-tend Kafka est conçue pour régler les problèmes associés avec ces types d’usages qui requièrent un système de stockage tolérant aux pannes, des fonctionnalités de haute performance et d’élasticité », affirme Keith Kohl. En outre, cette architecture doit faciliter la gestion des données via la compression.

Là où Kafka ne brille pas

Mises à jour aléatoires. Le système de messagerie gère correctement les événements traités au sein d’un pipeline de données. En revanche, il n’est pas efficace pour les mises à jour ou l’accès aléatoire aux enregistrements individuels, déclare Heikki Nousiainen. Kafka a pourtant son propre moteur SQL : KSQL.

Pour ce faire, Kafka peut être appairé avec une base de données transactionnelle ou NoSQL. Bien qu’il puisse gérer des logs, les utilisateurs le déploient généralement pour des besoins de traitement de données, dans un environnement cloud, afin de garantir un stockage évolutif. Exécuter Kafka comme un système de stockage n’est ni courant, ni son point fort.

Kafka ne renvoie pas la balle. Kafka n’est pas une bonne solution pour l’utilisation du blocking et l’obtention de réponses en temps réel, relate Nacho Solis, responsable de l’ingénierie chez LinkedIn. Kafka n’offre pas la possibilité de représenter la relation entre les messages ou de fournir un canal de retour pour les accusés de réception. Par conséquent, il ne peut pas garantir la livraison à un ensemble spécifique de destinataires. Il est de la responsabilité de chaque client – producteur ou consommateur – de s’assurer qu’il obtient ce dont il a besoin du service de messagerie.

L’exécution en mode edge computing. Kafka n’est pas fait pour être exécuté en périphérie d’un système informatique, d’après Dinesh Chandrasekhar. Cela inclut le traitement local dans un projet IoT. De même, Kafka n’est pas idéal pour transférer des données à la manière d’un ETL ou administrer des informations par lots.

En théorie, Kafka Connect devrait pouvoir aider dans ces scénarios. Mais selon le responsable, il peut être difficile de bâtir des connecteurs pour différents protocoles adaptés à l’edge computing. Par ailleurs, la conception d’agents légers à embarquer dans les capteurs ou le traitement au niveau de ces dispositifs implique un niveau de complexité élevé.

Remplacer des middlewares ou des bases de données. Le système de messagerie ne devrait pas remplacer complètement les middlewares ou les bases de données traditionnelles, selon Keith Kohl. Bien qu’il soit possible d’effectuer des requêtes comme avec une base de données, Kafka n’est clairement pas optimisé pour le stockage d’historique d’événements. Par ailleurs, il fournit des flux de données, mais il ne les transforme pas et il ne les analyse pas. Pour cela, il faut écrire du code ou utiliser un service supplémentaire.

Traiter des données dans leur ordre d’apparition. Déployer Kafka pour traiter des informations dans l’ordre d’arrivée ou les requêter comme dans une base de données a peu d’intérêt, assure Kiran Chitturi. Enfin, l’outil n’est pas idéal pour acheminer des contenus audio ou vidéo en temps réel ou bien des images.