kafka Presentation PDF

[email protected] Tasnim Abar 1  Présentation Apache Kafka® est une plate-forme de streaming d'événements distribués utilisée pour créer des pipelines de données en temps réel et des applications de streaming. Kafka est conçu pour gérer de gros volume...

[email protected] Tasnim Abar 1  Présentation Apache Kafka® est une plate-forme de streaming d'événements distribués utilisée pour créer des pipelines de données en temps réel et des applications de streaming. Kafka est conçu pour gérer de gros volumes de données de manière évolutive et tolérante aux pannes, ce qui le rend idéal pour des cas d'utilisation tels que l'analyse en temps réel, l'ingestion de données et les architectures basées sur les événements. Il prend en charge les abonnés multiples et a été développé à l'origine par Linkedin en 2009 et est maintenu depuis 2012 par la fondation Apache. Kafka est un système de messagerie distribué, partitionné, répliqué et basé sur ZooKeeper. Tasnim Abar 2  Système de messagerie Est responsable du transfert de données d'une application à une autre. La messagerie distribuée est basée sur le concept de mise en file d'attente de messages fiable. Les messages sont mis en file d'attente de manière asynchrone entre les applications clientes et le système de messagerie. Deux types de modèles de messagerie sont disponibles :  Point à point  Publication-abonnement (pub-sub) Tasnim Abar 3  Système de messagerie Point à Point Un message particulier ne peut être consommé que par un seul consommateur au maximum. Une fois qu'un consommateur lit un message dans la file d'attente, il disparaît de cette file. Tasnim Abar 4  Système de messagerie pub-sub Les messages sont conservés dans un sujet (topic). Contrairement au système point à point, les consommateurs peuvent s'abonner à un ou plusieurs sujets et consommer tous les messages de ce sujet. Tasnim Abar 5  Système de messagerie pub-sub Plateforme de médias sociaux : Lorsqu'un utilisateur publie un nouveau contenu (comme une photo ou un article), tous les abonnés de cet utilisateur reçoivent une notification ou peuvent voir le contenu dans leur fil d'actualités. Capteurs environnementaux : Des capteurs peuvent publier des données (comme la température ou l'humidité) sur des canaux. Les applications ou autres appareils abonnés peuvent recevoir ces données en temps réel pour l'analyse ou la surveillance. Solution d'agrégation de journaux : Kafka peut être utilisé dans une organisation pour collecter les journaux de plusieurs services et les rendre disponibles dans un format standard à plusieurs consommateurs. Tasnim Abar 6  Système de messagerie pub-sub C’est un mécanisme de publication et d'abonnement. Les publishers ont pour rôle d'envoyer des messages dans des topics. Les consumers (abonnés) peuvent donc régulièrement aller regarder dans les topics si de nouveaux messages sont arrivés. Les publishers n'ont donc jamais connaissance des consumers, l'inverse étant également vrai. La mise en place d'un tel système permet à deux consumers de profiter des mêmes informations, ou permet à deux publishers de remplir le même topic de manière transparente Tasnim Abar 7  Kafka Apache Kafka est un système de messagerie de publication-abonnement distribué et une file d'attente robuste capable de gérer un volume élevé de données et permet de transmettre des messages d'un point de terminaison à un autre. Kafka convient à la fois à la consommation de messages hors ligne et en ligne. Les messages Kafka sont conservés sur le disque et répliqués au sein du cluster pour éviter toute perte de données. Kafka est construit sur le service de synchronisation ZooKeeper. Il s'intègre très bien avec Apache Storm et Spark pour l'analyse des données en streaming en temps réel. Kafka offre un débit élevé. (Même sur des machines commerciales peu couteuses, un système à nœud unique peut transmettre 100 000 messages par seconde.) Kafka prend en charge le partitionnement des messages et la consommation distribuée, et garantit que les messages sont transmis en séquence dans chaque partition. Kafka prend en charge l'évolutivité horizontale. Tasnim Abar 8  Terminologie Dans le vocabulaire Kafka, on nomme :  Producer : tout système qui envoie des données dans un ou plusieurs topics Kafka. (Publisher dans pub-sub.) ;  Consumer : tout système qui lit des données dans un ou plusieurs topics Kafka. (Subscriber dans pub-sub.) ;  Broker : tout serveur Kafka ;  Cluster : ensemble de brokers.  Topic : Chaque message publié sur le cluster Kafka possède une catégorie, appelée Topic.  Partition : Kafka divise un topic en une ou plusieurs partitions. Chaque partition correspond physiquement à un répertoire de stockage de tous les messages de la partition. Tasnim Abar 9  Topic Chaque message publié sur Kafka appartient à une catégorie, qui s'appelle Topic. Le Topic peut également être interprété comme une file d'attente de messages. Par exemple, la météo peut être considérée comme un topic (file d'attente) qui stocke des informations de température quotidiennes Les producers envoient donc des messages dans des topics, les consumers vont chercher des messages dans ces mêmes topics Tasnim Abar 10  Partition Pour améliorer le débit de Kafka, chaque topic est physiquement divisée en une ou plusieurs partitions. Chaque partition est une séquence ordonnée et immuable de messages. Chaque partition correspond physiquement à un répertoire pour stocker tous les messages et fichiers d'index de la partition. Lorsqu'un producer envoie un nouveau message dans un topic, il sera assigné à une partition et ajouté uniquement à cette partition. Chaque message partitionné possède un identifiant de séquence unique appelé offset. Tasnim Abar 11  Broker et Cluster Les brokers sont des systèmes simples chargés de maintenir les données publiées. Chaque broker peut avoir zéro ou plusieurs partitions par sujet. Les clusters Kafka qui possèdent plusieurs brokers sont appelés clusters Kafka. Un cluster Kafka peut être étendu sans interruption de service. Ces clusters sont utilisés pour gérer la persistance et la réplication des données de message. Tasnim Abar 12  Leader et Follower Le leader est le nœud responsable de toutes les lectures et écritures pour la partition donnée. Chaque partition possède un serveur agissant en tant que leader. Les nœuds qui suivent les instructions du leader sont appelés followers. Si le leader échoue, l'un des follower deviendra automatiquement le nouveau leader. Un follower agit comme un consommateur normal, récupère les messages et met à jour son propre magasin de données. Tasnim Abar 13  Producer et Consumer Les Producers sont les éditeurs (publieurs) de messages sur un ou plusieurs topics. Les producers envoient des données aux borkers. Chaque fois qu'un producer publie un message à un broker, le broker ajoute simplement le message au dernier fichier de segment => le message sera ajouté à une partition. Le producer peut également envoyer des messages à une partition de son choix. Les consumers lisent les données des borkers. Les consumers s'abonnent à un ou plusieurs topics et consomment les messages publiés en extrayant les données des brokers. Tasnim Abar 14  Log Chaque message envoyé par un producer dans un topic et reçu par un consumer sera encapsulé au sein d'un log. Il s'agit plus d'un modèle de données ressemblant à une file d'attente (ou queue). À la manière d'une file d'attente, le log est un tableau de messages ordonnés par rapport à leur ordre de réception. La position de chaque message dans un log est appelée offset, qui est un entier long qui identifie de manière unique un message. Les consommateurs utilisent les offsets, partitions et topics pour suivre les enregistrements. Tasnim Abar 15  Architecture Kafka Le cluster Kafka se compose généralement de plusieurs brokers pour maintenir l'équilibre de charge. Les brokers Kafka sont en mode stateless, ils utilisent donc ZooKeeper pour maintenir leur état de cluster. Une instance de broker peut gérer des centaines de milliers de lectures et d'écritures par seconde et chaque broker peut gérer des To de messages sans impact sur les performances. L'élection du leader peut être effectuée par zookeeper. ZooKeeper est utilisé pour gérer et coordonner les brokers. Le service ZooKeeper est principalement utilisé pour informer le producer et le consumer de la présence de tout nouveau broker dans le système ou de la défaillance du broker dans le système. Selon la notification reçue par zookeeper concernant la présence ou l'échec du broker le producer et le consumer prennent une décision et commencent à coordonner leur tâche avec un autre broker. Puisque les brokers sont sans état, donc le consumer doit conserver le nombre de messages consommés en utilisant le offset. La valeur de l’offset d’un consumer est notifié parAbar Tasnim le zookeeper. 16  Architecture Kafka Les producers et les consumers n'interagissent qu'avec le leader, et le reste des répliques agissent en tant que followers pour copier les messages du leader. Chaque consommateur appartient à un consumer groupe. Chaque message peut être consommé par plusieurs groupes de consommateurs mais un seul consommateur dans un groupe de consommateurs. C'est-à-dire que les données sont partagées entre les groupes, mais exclusives au sein d'un groupe. Tasnim Abar 17  Kafka Workflow Kafka fournit à la fois un pub-sub messaging system et un queue based messaging system de manière rapide, fiable, persistante, tolérante aux pannes et sans temps d'arrêt. Dans les deux cas, les producers envoient simplement le message à un topic et le consumer peut choisir n'importe quel type de système de messagerie en fonction de ses besoins. 1. Les producers envoient un message à un topic à intervalles réguliers. 2. Le broker stocke tous les messages dans les partitions configurées pour ce topic particulier. Il garantit que les messages sont également partagés entre les partitions (équilibrage de charge). 3. Le consumer s'abonne à un sujet (topic) spécifique. 4. Une fois que le consumer s'est abonné à un topic, Kafka lui fournira le offset actuel du topic et enregistrera également le offset dans Zookeeper. 5. Le consumer demandera Kafka dans un intervalle régulier (comme 100 Ms) pour les nouveaux messages. 6. Une fois que Kafka reçoit les messages des producers, il transmet ces messages aux consumers. Le consumer recevra le message et le traitera. 7. Une fois les messages traités, le consumer enverra un accusé de réception au broker Kafka. 8. Une fois que Kafka reçoit un accusé de réception, il modifie le offset en fonction de la nouvelle valeur et le met à jour dans zookeeper. 9. le consumer peut lire correctement le message suivant même pendant les attaques du serveur puisque les offset sont stocker dans Zookeeper. 10. Ce flux se répétera jusqu'à ce que le consumer arrête la demande. Le consumer a la possibilité de revenir en arrière / de passer au offset souhaité d'un sujet à tout moment et de lire tous les messages 18 suivants.  KafKa :Mécanisme de Stockage Lorsque le consommateur lit à nouveau la partition, la lecture commence à partir du message suivant. Cette fonctionnalité garantit qu'un même consommateur ne consomme pas à plusieurs reprises les données de Kafka. Les offsets des groupes de consommateurs sont stockés dans le répertoire __consumer_offsets. Si on a un cluster Kafka avec deux brokers hébergés sur deux machines distinctes. Lorsque l'on va partitionner le topic, nous allons configurer deux partitions et deux réplicas, chaque broker ayant sa partition ainsi que le réplica de la partition de l'autre. Chaque broker est donc « maitre » d'une partition. Lorsqu'un producer va envoyer un message, il va l'envoyer au maitre de la partition. Le maitre va enregistrer le message dans son log en local. Le second broker ira, de manière passive, répliquer le contenu du maitre dans son propre log. Si jamais le maitre de la première partition tombe, le deuxième prendra le relais et deviendra alors le nouveau maitre. Le mécanisme est le même pour les consumers. Tasnim Abar 19  KafKa :Mécanisme de Stockage Le partitionnement d'un topic est très bénéfique, car il permet d'effectuer du load-balancing du côté des brokers et des clients avec assez peu de travail. Kafka est fortement distribué et tolérant à la panne grâce à ce mécanisme. Une partition peut avoir plusieurs répliques (équivalent à default.replication.factor=N dans la configuration server.properties). S'il n'y a pas de réplique, une fois que le borker tombe en panne, toutes les données de partition sur ce broker ne peuvent pas être consommées et le producer ne peut pas stocker de données dans la partition. Une fois la réplication introduite, une partition peut avoir plusieurs répliques. L'une de ces répliques est élue pour agir en tant que leader. Tasnim Abar 20 KafKa :Mécanisme de Stockage Tasnim Abar 21  Reliability Assurance - Acks Mechanism Le producer a besoin du signal d'accusé de réception (ACK) envoyé par le broker après avoir reçu les données. Cette configuration fait référence au nombre de ces signaux ACK dont le producer a besoin. Cette configuration représente en fait la disponibilité de la sauvegarde des données. Les paramètres suivants sont des options courantes : acks=0 : indique que le producer n'attendra aucun accusé de réception du broker. L'enregistrement sera immédiatement ajouté au tampon de socket et considéré comme envoyé. Il n'y a aucune garantie que le serveur a bien reçu l'enregistrement. acks = 1: Cela signifie que le leader écrira l'enregistrement dans son journal local mais répondra sans attendre l'accusé de réception complet de tous les followers. Dans ce cas, si le leader échoue immédiatement après avoir accusé réception de l'enregistrement mais avant que les followers ne l'aient répliqué, l'enregistrement sera perdu. acks = all: Cela signifie que le leader attendra que l'ensemble complet des répliques synchronisées accuse la réception de l'enregistrement. Cela garantit que l'enregistrement ne sera pas perdu tant qu'au moins un réplica synchronisé reste actif. C'est la garantie la plus solide disponible. Tasnim Abar 22  Quiz Qu'est-ce qu'on appelle un broker dans Kafka?  Subscriber  Server  Zookeeper  Message Why is replication necessary in Kafka? Because it ensures that...  A published message will not be lost  A published message will not be saved  A published message will not be deleted  A published message will not be sent Quel est le facteur de réplication par défaut dans Kafka  1  2  3  4 Tasnim Abar 23  Quiz To improve the fault tolerance of Kafka, Kafka supports the replication policy of partitions. Which of the following statements about the leader partition and follower partition is false?  Kafka needs to select a leader for partition replication.  The leader is responsible for partition read and write operations. Other replica nodes are responsible for data synchronization.  If the leader fails, other followers become new leaders. The leader server bears all request pressure, therefore, the Kafka cluster distributes leaders horizontally on each instance to ensure stable performance.  Nodes in a Kafka cluster cannot serve as leaders and followers of each other. Which of the following statements about the basic concepts of Kafka is incorrect?  A Kafka cluster contains one or more service instances, which are called brokers.  Each message published to the Kafka cluster has a category called topic.  Each consumer belongs to multiple consumer groups.  The Kafka divides a topic into one or more partitions. Each partition physically corresponds to a folder that stores all messages of the partition. Tasnim Abar 24  Quiz Quelle pourrait être la valeur maximale possible du facteur de réplication d'une partition de sujet dans un cluster kafka composé de 7 borkers  2  7  14  6 Comment Kafka garantit l’ordre des messages  En utilisant des partitions  En stockant tous les messages dans un seul fichier  En utilisant des identifiants uniques pour chaque message  En répliquant les messages sur plusieurs brokers Quelle est la taille de message maximale que Kafka peut l’accepter par défaut  1Mo  10Mo  1Go  10Go Tasnim Abar 25