[Big Data] Kafka : concepts généraux

Ce billet présente Apache Kafka.

Pour comprendre les concepts associés aux Big Data, à Hadoop,… vous pouvez aller ici.

 

Présentation de Kafka

Kafka : késako ?

Kafka est un système de messagerie distribué, initialement développé par l’équipe de Jay Kreps chez LinkedIn, et plus tard publié, en 2011, en tant que projet open-source Apache. Kafka est un service réputé rapide, scalable, partionné et répliqué.

 Caractéristiques principales de Kafka

Kafka possède les caractéristiques principales suivantes :

  • Scalabilité à Il a été conçu en tant que système distribué facile à monter en charge, sans arrêt de production.
  • Performance à Il offre un haut niveau de performances I/O, que ce soit pour la publication de messages ou leur abonnement (plusieurs millions de lectures/écritures par seconde).
  • Durabilité à Il permet de persister des messages sur disque, aidant ainsi à leur consommation en mode batch (comme dans un contexte ETL), en addition des opérations temps-réel.
  • Fiabilité à Il permet de répliquer des messages, de supporter des abonnements multiples et de rééquilibrer automatiquement les consommateurs en cas de panne.
Pour connaître quelques cas d’utilisation de Kafka, comme le stream processing, l’analyse de logs Web,… vous pouvez aller ici : http://kafka.apache.org/08/uses.html.

 

Fonctionnement général de Kafka

Architecture de Kafka

Kafka possède un ensemble de composants assurant son fonctionnement en tant que système de messagerie distribué :


En clair :

  • Un topic (ou sujet), qui est une chaîne de messages d’un type particulier. Un message est vu comme un ensemble d’octets, et un topic, une catégorie définie par un utilisateur.
  • Un ou plusieurs producteurs, qui peuvent publier des messages à un topic.
  • Un ou plusieurs brokers, qui sont un ensemble de serveurs (ou nœuds) formant un cluster Kafka, et permettant de stocker et gérer les messages publiés.
  • Un ou plusieurs consommateurs qui peuvent s’abonner à un ou plusieurs topics, et consommer les messages publiés à partir du cluster.

 

Au cœur du moteur de stockage Kafka

Kafka étant un système distribué, les topics sont partitionnés à travers plusieurs nœuds du cluster.

Kafka diffère des systèmes de messagerie traditionnels par sa capacité à traiter chaque topic comme un log, c’est-à-dire un ensemble ordonné de messages.

Kafka possède une interface de stockage très simple. Chaque partition d’un topic correspond à un log logique. Physiquement, un log est implémenté comme un ensemble de segments de fichiers de taille égale. Voici ci-dessous un exemple d’anatomie d’un topic dans l’univers Kafka :


Chaque fois qu’un producteur publie un message, un broker enregistre ledit message dans le dernier segment de fichier. Le segment de fichier (et de facto, les messages qui y sont localisés) sont, par la suite, déplacés vers le disque du cluster Kafka après un certain temps écoulé ou après qu’un nombre (prédéfini) de messages ont été publiés.

Contrairement à ce qu’on retrouve dans les systèmes de messagerie traditionnels, un message stocké dans un cluster Kafka ne possède pas d’identifiant. En fait, chaque message d’une partition se voit assigné un offset (ou position) unique permettant de le localiser au sein d’un log.

Chaque broker Kafka ne capture pas les messages lus par chaque consommateur de façon à ne retenir que les messages non-lus, comme c’est le cas dans les systèmes de messagerie traditionnels. Au contraire, Kafka retient tous les messages publiés et charge ensuite les consommateurs de capturer leur position dans chaque log lors de leur consommation.

C’est notamment de cette manière qu’un cluster Kafka peut ainsi supporter un nombre très large de consommateurs tout en retenant un très gros volume de messages.


Dans notre exemple de schéma ci-dessus, le topic T1 contenant N messages est partitionné à travers 3 brokers du cluster Kafka.x

Les consommateurs consomment toujours les messages à partir d’une partition spécifique, de façon séquentielle. Cela joue un rôle non-négligeable dans les bonnes performances des traitements effectués par Kafka, grâce notamment à la réduction des opérations de recherche de type hard disk seeks, qui ont tendance à augmenter les temps de latence.

Avant toute consommation d’un message, chaque consommateur lance une requête asynchrone de type pull au broker afin que celui-ci lui alloue un tampon d’octets prêts à être consommés. Chaque requête pull asynchrone contient la position du (ou des) message(s) à consommer.

Pour assurer au mieux la transition de messages entre brokers et consommateurs, Kafka utilise l’API sendfile.

 

Pour aller plus loin…

Gardez un œil ici. D’autres articles autour du Big Data y seront pondus, y compris de nouvelles démonstrations techniques, comme l’utilisation de Kafka.

Si vous souhaitez approfondir votre lecture, vous pouvez également consulter la documentation officielle : http://kafka.apache.org/documentation.html.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s