Utilisation d'Apache Kafka
Apache Kafka est une plate-forme de messagerie de publication-abonnement distribuée open source spécialement conçue pour gérer les données de diffusion en continu en temps réel pour la diffusion en continu distribuée, le pipelinage et la réexécution des flux de données pour des opérations rapides et évolutives. Kafka est une solution basée sur un broker qui gère des flux de données sous forme d'enregistrements au sein d'un cluster de serveurs.
Dans les clusters Big Data Service, Kafka peut être utilisé des manières suivantes.
- Créez un cluster de profils Kafka :
- Création d'un cluster.
- Dans le champ Profil de cluster, sélectionnez Kafka.
- Créez un cluster de profils Hadoop_Extended et ajoutez Kafka au cluster :
- Création d'un cluster.
- Dans le champ Profil de cluster, sélectionnez Hadoop_Extended.
- Ajoutez Kafka au cluster.
Propriétés de configuration Kafka
Propriétés de configuration Kafka incluses dans Big Data Service 3.1.1 ou version ultérieure.
| Configuration | Propriété | Description |
|---|---|---|
kafka-env |
kafka_opts |
Options Kafka |
kerberos_param |
Paramètre Kerberos Kafka | |
kafka_jmx_opts |
Options JMX Kafka | |
kafka_classpath |
Classpath de Kafka |
Meilleures pratiques d'Apache Kafka
Configuration matérielle
Apache Kafka, pour son fonctionnement régulier, nécessite une petite quantité de ressources, en particulier avec certains réglages de configuration. Par défaut, Kafka peut s'exécuter sur 1 coeur et 1 Go de mémoire avec un stockage redimensionné en fonction des exigences de conservation des données.
La CPU est rarement un goulet d'étranglement, car Kafka est lourde d'E/S. Cependant, une CPU de taille modérée avec suffisamment de threads est importante pour gérer les connexions simultanées et les tâches en arrière-plan.
- Noeud de broker Kafka : huit coeurs, 64 Go à 128 Go de RAM, deux disques de 2 To ou plus (standard2,8 ou supérieur, de préférence DenseIO ou équivalent)
- Trois noeuds de broker Kafka au minimum
- Profil matériel : plus de RAM et de disques haute vitesse sont meilleurs
- Installez les brokers Kafka sur les noeuds de processus actifs car ils peuvent augmenter horizontalement en taille
Topologie de cluster Kafka recommandée
- Retirer le gestionnaire de noeuds du noeud de processus actif
- Etant donné que les brokers Kafka ont besoin d'au moins trois noeuds pour la réplication/la haute disponibilité, vous pouvez envisager de provisionner des noeuds de processus actifs supplémentaires pour Kafka.
- Provisionner des noeuds de processus actif HDFS supplémentaires et mettre hors service le noeud de données et le gestionnaire de noeuds. Remarque
Les noeuds de processus actif en cours sont modélisés après les noeuds de processus actif HDFS, qui sont réaffectés aux noeuds de broker Kafka. Par conséquent, si les noeuds de broker Kafka sont exécutés avec les noeuds de données HDFS, HDFS perd un stockage effectif.
Voici quelques paramètres courants à régler lors de la configuration de Kafka :
| Fonctionnalités à régler | Paramètres à ajuster |
|---|---|
| Conservation des messages | Taille du disque |
| Débit client (producteur et consommateur) | Capacité réseau |
| Débit de l'émetteur | Disk I/O |
| Débit des consommateurs | mémoire, |
Ces paramètres varient d'un cas à l'autre et doivent être définis avec soin pour obtenir de meilleures performances. Aucun paramètre unique ne convient à tous les cas d'utilisation.
ZooKeeper
ZooKeeper est un composant important d'un cluster Kafka qui agit en tant que service de coordination distribué. ZooKeeper est en charge de la surveillance et de la conservation des métadonnées du cluster, de la coordination des opérations de nombreux noeuds et de l'assurance de la stabilité et de la cohérence générales du cluster Kafka.
Les clusters de haute disponibilité Big Data Service incluent trois hôtes Zookeeper. Toutefois, pour les cas d'utilisation de production plus importants, nous vous recommandons de redimensionner horizontalement les hôtes Zookeeper car ils sont partagés entre d'autres services avec le cluster Big Data Service.
Considérations sur les performances
Kafka est optimisé prêt à l'emploi. Toutefois, certains réglages sont nécessaires pour améliorer les performances du cluster. Prenons deux mesures principales :
- Débit : nombre de messages qui arrivent dans un certain laps de temps.
- Latence : temps nécessaire au traitement de chaque message.
Réglage des courtiers
Vous contrôlez le nombre de partitions dans une rubrique. L'augmentation du nombre de partitions et du nombre de brokers dans un cluster entraîne une augmentation du parallélisme de la consommation des messages, ce qui améliore le débit d'un cluster Kafka. Toutefois, le temps nécessaire pour répliquer des données entre des ensembles de répliques augmente également.
Régler les émetteurs
Vous pouvez exécuter un émetteur dans deux modes différents : synchrone et asynchrone. En mode synchrone, dès qu'un message est publié, l'émetteur envoie une demande au broker. Par conséquent, si vous générez 100 messages par seconde, le fournisseur envoie 100 demandes par seconde au broker. Cela réduit le débit et agit comme une opération de blocage. Ainsi, lors de la publication d'un grand nombre de messages, il est préférable d'exécuter les émetteurs en mode asynchrone.
En mode asynchrone, vous devez régler deux paramètres pour obtenir de meilleures performances : batch.size et linger.ms (heure de début). La taille du lot correspond à la taille des données à envoyer dans un lot, mesurée en octets. Par exemple, si vous définissez la taille de batch sur 100, le fournisseur attend que les messages ajoutent jusqu'à 100 octets avant d'appeler le broker. Si la production de messages est faible et que vous définissez une taille de lot élevée, l'émetteur attend longtemps avant de générer des messages. Cela réduit le débit et augmente la latence de distribution des messages. Par conséquent, en fonction du nombre de messages générés, cette valeur doit être optimisée. La taille de batch par défaut est 16 384.
L'heure de retard est une autre mesure basée sur le moment où un émetteur décide d'envoyer une demande à un courtier. Dans l'exemple précédent, si la taille du lot est définie sur 100 octets et que vous ne produisez que 50 octets par seconde, le producteur doit attendre deux secondes avant de publier ces messages. Pour éviter ce délai, vous pouvez régler le temps d'attente (mesuré en millisecondes) pour vous assurer que le producteur n'attend pas trop longtemps avant d'envoyer des messages. Dans cet exemple, si vous définissez le temps d'attente sur 500 ms, le producteur attend une demi-seconde au maximum.
La compression peut également améliorer la latence. Par défaut, les messages Kafka ne sont pas compressés, mais vous pouvez configurer des émetteurs pour les compresser. Les courtiers et les consommateurs ont alors la surcharge supplémentaire de décompression des messages, mais la latence globale doit être réduite car la taille physique des données transmises sur le réseau est plus petite.
Régler les consommateurs
Les destinataires reçoivent des messages par lots, de la même manière que les émetteurs publient par lots. Si vous extrayez de nombreux messages et que vous prenez beaucoup de temps pour les traiter, le débit en souffre. De même, si vous interrogez le broker pour un seul message à chaque fois, le nombre de demandes adressées au broker peut diminuer le débit.
Le fait d'avoir plus de partitions et de consommateurs au sein d'un groupe de consommateurs peut aider à améliorer le débit. Mais n'oubliez pas qu'à mesure que le nombre de consommateurs augmente, le nombre de demandes de validation offset adressées au broker augmente également. Etant donné que la validation d'un décalage envoie un message Kafka à une rubrique interne, cela augmente indirectement la charge sur le broker. Il est donc essentiel d'avoir un nombre optimal de consommateurs.
MirrorMaker Optimisation des performances
Kafka MirrorMaker est un outil utilisé pour mettre en miroir les messages Kafka d'un centre de données ou d'un cluster vers un autre. Parce que cela produit en interne des messages à Kafka, la plupart des techniques d'optimisation déjà discutées sont également vraies ici. Etant donné que cela implique également la transmission de messages sur de longues distances, il existe quelques paramètres de configuration supplémentaires qui peuvent être réglés pour améliorer les performances.
Lors du réglage, veillez à baser vos actions sur les besoins de votre cas d'emploi professionnel.
- MirrorMaker2 Emplacement : MirrorMaker peut être installé au niveau de la source ou de la destination. Cependant, nous recommandons l'installation à la destination car la production de messages sur de longues distances augmente les chances de perdre des données lors de la transmission.
- Compression : par défaut, la compression des messages dans les émetteurs Kafka est définie sur none. Toutefois, pour compresser les messages sortant de la source vers la destination, remplacez la compression par gzip. Cela aide avec des tailles de lots plus grandes.
- Taille du lot : l'augmentation de la taille du lot de messages augmente le débit. Cette combinaison avec la compression garantit qu'un grand nombre de messages sont transmis rapidement. Si la taille du lot cible prend plus de temps que la durée de persistance configurée, les lots envoyés ne sont pas complètement remplis. Cela réduit l'efficacité de compression et gaspille la bande passante. Par conséquent, il est important de régler la taille des lots et d'activer la compression et le réglage du temps de persistance.
- Temps de persistance : Il est important d'augmenter le temps de persistance pour permettre le remplissage complet des lots. Cela peut augmenter la latence, mais le débit global s'améliore. Vous devez tenir compte de l'importance de la latence pour votre cas d'emploi professionnel.
- Augmenter le parallélisme : pour augmenter encore le débit, vous pouvez déployer plusieurs instances de MirrorMaker sous le même groupe de destinataires. Cela facilite la réception de plusieurs destinataires MirrorMaker à partir de la même source et la production vers la destination en parallèle.
Configurations de serveur de production dans le réglage de Kafka
Plusieurs autres paramètres de configuration peuvent être réglés pour améliorer les performances de Kafka dans un environnement de production. Les paramètres suivants améliorent les performances de réplication des messages au sein des partitions :
num.replica.fetchers: indique le nombre de threads utilisés pour répliquer les messages du leader vers les abonnés. Un plus grand nombre d'extracteurs de réplique améliore le parallélisme dans la réplication.replica.fetch.max.bytes: indique le nombre d'octets de données à extraire du leader. Un nombre plus élevé indique qu'un plus grand volume de données est extrait, ce qui améliore le débit de réplication.num.partitions: indique le nombre maximal de destinataires qu'un sujet peut avoir dans un groupe d'utilisateurs spécifique, qui est égal au nombre de partitions disponibles dans ce sujet. L'augmentation des partitions augmente le parallélisme et donc le débit. Cependant, de nombreuses partitions consomment également plus de ressources. Vous devez donc également augmenter les ressources.
Equilibrage des clusters Apache Kafka
Chaque fois qu'un nouveau broker est ajouté à un cluster Kafka, les partitions existantes ne sont pas distribuées via le nouveau broker. Cela signifie que le nouveau courtier n'est pas occupé, et si un ou plusieurs anciens courtiers tombent en panne, la réplication et les leaders potentiels sont réduits. C'est ce qu'on appelle le leader skew. Vous pouvez éviter cela en vous assurant que tout courtier nouvellement ajouté obtient un partage des partitions. Il est important de rééquilibrer le cluster. De même, si un broker a plus que le nombre moyen de partitions pour une rubrique, appelé écart de broker, cela peut entraîner des problèmes de performances.
Optimisation des performances Kafka
Lors de l'exécution de Kafka en tant que cluster, il existe plusieurs façons d'optimiser ses performances. Vous pouvez régler différents paramètres de configuration pour trouver un équilibre entre le débit et la latence. L'ingénierie est impliquée pour calculer les meilleures valeurs pour certains de ces paramètres, tels que le temps de persistance, la taille du lot, le nombre de partitions, etc. Selon le cas d'utilisation, vous pouvez décider que le débit est plus important que la latence, que la latence est plus importante que le débit ou qu'un équilibre entre les deux est préférable.