Apache Kafka : tout savoir sur le Data Streaming

Apache Kafka est une plateforme open source d'agents de messages (brokers) en temps réel. Cette plateforme permet à la fois de diffuser des données à grande échelle (event streaming) et d'effectuer des traitements sur ces données en temps réel (stream processing). Depuis plusieurs années, Kafka s'impose comme la référence pour diffuser et traiter des centaines de Go de données à grande échelle, tout en assurant une haute disponibilité de services.

Dans cet article, nous allons détailler les principales composantes pour tout savoir sur l'architecture d'Apache Kafka, et pourquoi cette solution est aussi populaire parmi de nombreux développeurs.

Apache Kafka en quelques mots

Développée en Java et Scala, Apache Kafka est rapidement devenue la solution incontournable pour le traitement streaming temps réel à grande échelle, et dispose de nombreuses implémentations dans la plupart des langages.

À l'origine, c'est LinkedIn qui a développé Apache Kafka en 2011, historiquement pour centraliser chaque log qui les sytèmes et services produisaient. En effet, les flux de données étaient tellement important que les développeurs de LinkedIn ont cherché à développer une plateforme Big Data qui puisse gérer des millions d'événements par minute. Quelques mois plus tard, le projet a été rendu open source et incubé par la fondation Apache.

Kafka fonctionne sous forme de clusters : pour assurer une haute disponibilité (le moins d'interruption de service possible), on utilise plusieurs brokers, c'est-à-dire plusieurs machines qui exécutent Kafka. Il s'agit donc d'une plateforme distribuée et scalable, tout en assurant la plus faible latence possible.

Cette architecture par cluster en distribué permet d'ajouter ou supprimer des brokers en fonction de la demande : cela permet d'assurer un système toujours opérationnel, de gérer les pics de demande, et de n'utiliser que la puissance de calcul nécessaire (optimisation des coûts).

---

À lire aussi : découvrez notre formation Data Engineer

---

Apache Kafka dispose de plusieurs API avec des objectifs différents.

• Producer pour permettre à un application d'envoyer des données sur Kafka.
• Consumer pour permettre à une application de recevoir des données depuis Kafka.
• Streams pour créer des pipelines de transformations sur les données Kafka.
• Connect pour connecter Kafka à des systèmes sources et des bases de données.

Les concepts d'Apache Kafka

Un sujet essentiel sous Kafka est la notion de topic. Un topic est une catégorie où des messages (appelés records ou enregistrements) sont produits, similaire à une messagerie où chaque mail arriverait par ordre d'envoi. Chaque message contient une donnée envoyée sur Kafka, et peut être vu comme une unité atomique par rapport à un contexte, comme

• les événements utilisateurs sur un site Web (page visitée, clic sur un bouton, défilement de la page) ;
• les transactions financières (un virement, un prélèvement, un ajout de bénéficiaire) ;
• les événements d'un réseau social (une vue, un like, un commentaire, un clic) ;
• les capteurs IoT (température, humidité, luminosité).

Une des différences majeures de Kafka avec un autre outil est la manière dont les messages sont stockés. Chaque topic est constitué de partitions, qui représentent des piles (au sens du stockage) de messages. Puisqu'il s'agit de piles, les nouveaux messages sont toujours ajoutés aux partitions, et un identifiant (appelé offset) leur est attribué en fonction de leur position dans la pile.

Cette notion de pile est importante, car elle permet de gérer l'ordonnancement des messages et donc leur priorité de traitement. Chaque partition est hébergé sur un broker Kafka différent, permettant d'assurer un équilibrage de charge pour un topic. Par exemple, dans un cluster à 4 brokers, plutôt que d'avoir 100% du trafic d'un topic sur un seul broker, avec 5 partitions, chaque broker supportera 25% du trafic du topic.

La gestion d'offset est un enjeu crucial dans un cluster Kafka, car c'est ce qui permet de gérer l'ordre d'apparition des enregistrements. Puisque chaque partition gère son propre système d'offset, il est donc nécessaire de coordonner les différentes partitions entre-elles.

Les applications qui vont agir sur les topics sont les producers (produceurs) et les consumers (consommateurs), codés principalement en Java ou en Python. Cette représentation se base sur le modèle publish-subscribe : des applications vont envoyer des données sur des topics (publish), et d'autres vont consommer ces données depuis des topics (subscribe), sans avoir de couplage direct de part et d'autre.

Cette représentation est doublement efficace.

• Le couplage est faible entre les applications, ce qui permet de plus facilement de rajouter, modifier ou supprimer des applications, sans avoir besoin de tout adapter à chaque modification.
• Elle permet de mettre à l'échelle de manière importante, car en l'absence de couplage faible, l'ajout d'une nouvelle application peut se faire de manière la plus fluide possible.

Les producers vont produire des messages sur un ou plusieurs topics, où le choix de la partition leur est laissé. Ces producers peuvent être des serveurs Web, des appareils IoT ou n'importe quel script exécuté sur une machine. Par exemple, sur une plateforme Web, chaque événement utilisateur (page vue, bouton cliqué, etc) pourra être intercepté et envoyé vers un topic Kafka. Les consumers viendront ensuite prendre le relai.

La création d'un producteur est bien plus facile qu'un consommateur. En effet, il s'agit d'une fonctionnement similaire à celle d'une messagerie : le producteur envoie des événements, et attend une réponse de l'outil pour chacun de ces événements.

Les consumers vont quant à eux consommer chaque message dans un ou plusieurs topics : ces derniers sont multi-subscribers et peuvent consommer plusieurs topics en même temps. Il peut s'agir d'applications écrites en Java, Python ou en Scala, qui vont par exemple effectuer des traitements et envoyer le résultat vers une base de données cible (Data Lake ou Data Warehouse).

En pratique, la consommation des enregistrements est un sujet difficile. Par exemple, comment savoir qu'un message qui a été traité, ne le sera pas une seconde fois par un autre consommateur ? Que faire un un consommateur plante lors du traitement d'un message ?

---

À lire aussi : découvrez notre formation Data Engineer

---

De nombreuses applications internes à Kafka vont justement permettrent d'apporter des solutions à chacune de ces questions.

Dans le cas où il y a beaucoup de messages à traiter, on peut utiliser des frameworks comme Apache Spark ou Apache Flink pour paralléliser les calculs.

Chaque consumer peut appartenir à un consumer group : l'idée principale est que chaque consumer group gère lui-même l'offset de chaque topic auxquels les consumers ont souscrit. En d'autres termes, chaque consumer group lira tous les messages d'un topic depuis le début.

Enfin, pour être tolérant à la faute dans le cas où un broker Kafka viendrait à ne plus fonctionner, il est conseillé de créer des replicas de topics. En définissant un facteur de replica, le topic et ses partitions seront dupliqués dans autant de brokers que précisé.

Cela permet ainsi de fonctionner constamment à flux tendu avec une consommation de messages effective 100% du temps, où aucun message ne serait perdu et le traitement serait assuré.

Quand utiliser Apache Kafka ?

Cet outil doit être utilisé dans les situations où les trois besoins suivants sont réunis.

• Il faut être capable de supporter une forte vélocité (vitesse) de données.
• Il faut être capable de diffuser et faire le traitement d'une forte volumétrie (taille) de données.
• Il faut assurer une latence la plus faible possible, quasi-temps réel pour assurer le streaming de données et traiter chaque message le plus rapidement possible.

Ce n'est donc pas étonnant que LinkedIn, où Kafka a été crée, utilise de nombreux clusters Kafka. Avec ce modèle publish-subscribe, Kafka s'impose comme la solution privilégiée. De leur point de vue, la consommation est cruciale car les opérations associées ont un réel impact sur la plateforme.

On retrouve donc Kafka comme système de diffusion de messages dans les situations où la volumétrie des données est importante et où la latence est critique.

• Les plateformes et sites avec beaucoup d'interactions (réseaux sociaux, sites ECommerce, moteurs de recherche). En particulier avec la possibilité de travailler directement sur les streams de messages.
• Les plateformes financières (bourses, marchés d'échanges, crypto-monnaies).
• Les capteurs et applications IoT, dont la production de log est très importante et orientée Big Data.

Enfin, Kafka peut aussi être utilisé pour faire une migration de données depuis un système source vers une base de données. En effet, la gestion de topics permet de ne pas saturer la base de données cible en créant un tampon entre les deux systèmes.

Quand ne pas utiliser Apache Kafka ?

Apache Kafka ne doit pas être utilisé comme une base de données. En effet, les données stockées sur les topics Kafka ne le sont que temporairement, même si cela peut s'étendre à plusieurs jours. Les streams de données des topics ont vocation à être traités à un moment ou un autre, et en cas de traitement réussi, ces données doivent être supprimées du topic.

L'API Connect API permet alors de migrer les données traitées vers une base de données pour assurer un stockage persistant à long terme.

Apache Kafka n'est pas non plus un outil adapté pour les faibles volumétries de données. En général, lorsque l'on traite un message de l'ordre de quelques Mo par secondes, d'autres systèmes comme RabbitMQ ou Amazon Kinesis seront non seulement plus adaptés, mais également plus faciles à mettre en place.

---

À lire aussi : découvrez notre formation Data Engineer

---

Enfin, Apache Kafka ne suffit pas pour faire des traitements et analyses de données en temps réel. En effet, il est préférable d'utiliser des frameworks et librairies adaptés comme Spark, Flink ou encore Storm, qui évoluent indépendamment de Kafka et qui fonctionnent eux aussi en mode cluster, permettant de scaler à n'importe quelle échelle.

Cet article détaille plus précisément les situations où Kafka peut être utilisé, et les autres situations où il ne faut pas utiliser Kafka.