Spark Streaming et Kafka Streams : un rapide tour d’horizon

SPARK STREAMING ET KAFKA STREAMS : UN RAPIDE TOUR D'HORIZON

L’information arrive maintenant en temps réel, c’est un fait. Les systèmes d’information se sont dotés de composants d’infrastructure qui assurent la collecte et le stockage de ces données de façon scalable et distribuée. Ils doivent maintenant intégrer des composants capables de traiter en temps réel ces données.

Après une brève introduction des concepts du streaming, nous allons présenter les caractéristiques principales des fonctionnalités de streaming de Apache Kafka et de Apache Spark.

Qu’est-ce que le streaming ?  

Le streaming est la capacité d’un système à traiter en temps réel les informations qui arrivent dans ce système. Outre le traitement fonctionnel à appliquer sur ces données, le système doit prendre en compte plusieurs exigences non fonctionnelles. On peut citer, par exemple :

  • Le débit : les flux de données, notamment dans l’IoT, atteignent des débits importants allant de quelques centaines à plusieurs milliers de messages par seconde ;
  • La latence : cela correspond à la période de temps entre le moment où le message arrive dans le système et le moment où il sera traité ; en fonction des cas métier, cette latence peut être plus ou moins importante ;
  • La tolérance aux pannes : en cas de dysfonctionnement d’un élément dans la chaîne de traitements, le système doit être capable de reprendre là où il s’était arrêté ;
  • La gestion de la « backpressure » : il s’agit de la capacité d’un élément de la chaîne à s’adapter aux capacités de traitement de l’élément suivant : si un élément ne tient pas le débit de messages, il informe l’élément précédent pour qu’il adapte le débit pour ne pas surcharger le traitement.

À l’intérieur du système de streaming, les éléments de la chaîne de traitements sont de différentes natures. On retrouve notamment :

  • Les « sources », également appelés « producer » ou « publisher », sont des éléments qui émettent des données à traiter ; ce sont les points d’entrée de la chaîne.
  • Les « sinks », également appelés « consumer » ou « subscriber », sont des éléments qui traitent les données ; ce sont les points de terminaison de la chaîne.
  • Les « flows », également appelés « processor » ou « stream », sont à la fois des « sources » et des « sinks » : ils consomment des données venant de « sources » et génèrent d’autres données à destination d’autres « sink ».

Un système est donc un ensemble de sources et de sinks interconnectés par des flows.

Apache Kafka  

À la base, Apache Kafka est un bus de messages distribué à haute performance. Ce n’est qu’à partir de la version 0.10, sortie en 2016, que les API de streaming ont été introduites dans le logiciel.

Ces API sont complétées par la notion de connecteurs qui permettent de s’interfacer avec tout type de « sources » ou de « sink ». Par ce biais, il est possible, par exemple, de se connecter aux flux Twitter pour alimenter un système de mesure de capteurs sociaux qui traite en temps réel les tweets pour en faire une analyse de sentiments.

Les hauts débits sont assurés par une distribution des traitements d’une part et des messages d’autre part.
Le déploiement des traitements est à la charge de l’applicatif : la capacité de traitement est définie par les instances de l’application sur l’environnement d’exécution et pour chaque instance, le nombre de threads alloués pour traiter les messages.
Quant à Kafka, il va assurer la distribution des messages entre toutes les instances de l’application. Kafka intègre un mécanisme de coordination qui garantit une répartition des messages sur les instances de l’application

Un des points forts de Kafka est sa faible latence, de l’ordre de la milliseconde, pour traiter un message. Le traitement se fait en continu : dès sa réception, le traitement du message peut être exécuté.

Quant à la tolérance aux pannes, elle est assurée par un mécanisme de transactions intégré à Kafka.

La gestion de la « backpressure » est intrinsèquement intégrée dans les fonctionnalités de Kafka. Naturellement, Kafka va réguler le débit de messages en fonction des capacités de traitements de chaque élément de la chaîne.

Apache Spark 

Spark est avant tout un framework de traitements batch distribués. Il met à disposition une API de haut niveau pour des tâches de transformation ou d’agrégation sur un ensemble de données.

Ce paradigme a été conservé pour la construction du module de streaming de Spark. En effet, à partir de flux de messages, Spark les regroupe par paquet pour en faire des micro-batchs. Ces micro-batchs peuvent être ensuite traités avec les mêmes API de haut niveau que les batchs classiques.

Ce choix de conception implique des latences importantes, de l’ordre de la seconde. Cette latence correspond, en fait, au temps de construction d’un micro-batch. À noter que ce temps de construction est configurable.

En revanche, le débit reste assez élevé grâce aux mécanismes de distribution du traitement intégrés à Spark. Couplé à YARN, les ressources de traitement pour les applications batchs et celles pour les flux temps réel peuvent être gérées de façon unifiée.

Pour la tolérance aux pannes, Spark s’appuie sur un mécanisme de « checkpoint » : Spark stocke les informations sur le dernier micro-batch complètement traité. En cas de panne, Spark reprend à ce « checkpoint ».

À noter que, même si Spark met en avant les APIs pour le traitement et la manipulation de la donnée, il est tout à fait possible de développer des « sources » et des « sink » spécifiques.

Bien que désactivée par défaut, la gestion de la « backpressure » est intégrée dans Spark et peut être mise en place par configuration. Spark adapte le nombre d’exécuteurs en temps réel pour assurer une activité continue des micro-batchs.

Même si Kafka et Spark ont un recouvrement sur des fonctions temps réel, ils sont avant tout complémentaires.

Kafka, grâce à son interopérabilité avec des systèmes externes, sera plutôt positionné comme un logiciel d’infrastructure. Ainsi, il sera plus facile d’interconnecter des sources hétérogènes de données avec Kafka qu’avec Spark. Aussi, l’intégration d’un web service sera plus facile et plus simple à gérer avec Kafka.

Spark, quant à lui, sera plutôt positionné comme un élément dans la chaîne de traitement s’appuyant si nécessaire sur Kafka pour la réception des données à traiter.

Outre les considérations techniques, il faut également prendre en compte les compétences des profils qui développeront les traitements temps réel. Les data scientists préféreront Spark alors que les développeurs seront sûrement plus à l’aise avec Kafka.