Apache Kafka est une plate-forme de diffusion de données chargée de diffuser des données à partir d'un certain nombre de sources à beaucoup de cibles. Les sources sont aussi appelées producteurs. Les données produites sont nécessaires à un groupe complètement différent appelé consommateurs à des fins diverses. Kafka est la couche qui se situe entre les producteurs et les consommateurs et agrège les données dans un pipeline utilisable. Aussi Kafka lui-même est une plate-forme distribuée, donc la couche Kafka est composée de divers serveurs exécutant un kafka, ces serveurs ou nœuds sont donc connus sous le nom de Kafka Courtiers.

Cet aperçu est un peu abstrait, alors analysons-le dans un scénario du monde réel, imaginons que vous deviez surveiller plusieurs serveurs Web. Chacun gère son propre site Web et de nouveaux journaux sont constamment générés dans chacun d'eux à chaque seconde de la journée. En plus de cela, vous devez également surveiller un certain nombre de serveurs de messagerie.

Vous devrez peut-être stocker ces données à des fins de tenue de dossiers et de facturation, ce qui est un travail par lots qui ne nécessite pas une attention immédiate. Vous souhaiterez peut-être exécuter des analyses sur les données pour prendre des décisions en temps réel, ce qui nécessite une saisie précise et immédiate des données.  Soudain, vous vous retrouvez dans le besoin de rationaliser les données de manière judicieuse pour tous les différents besoins. Kafka agit comme cette couche d'abstraction sur laquelle plusieurs sources peuvent publier différents flux de données et un consommateur peut s'abonner aux flux qu'il juge pertinents. Kafka s'assurera que les données sont bien ordonnées. C'est le fonctionnement interne de Kafka que nous devons comprendre avant d'aborder le sujet du partitionnement et des clés.

Sujets Kafka, courtier et partitions

Kafka Les sujets sont comme les tables d'une base de données. Chaque sujet se compose de données provenant d'une source particulière d'un type particulier. Par exemple, la santé de votre cluster peut être un sujet composé d'informations sur l'utilisation du processeur et de la mémoire. De même, le trafic entrant à travers le cluster peut être un autre sujet.

Kafka est conçu pour être évolutif horizontalement. C'est-à-dire qu'une seule instance de Kafka se compose de plusieurs Kafka courtiers s'exécutant sur plusieurs nœuds, chacun peut gérer des flux de données parallèles à l'autre. Même si quelques nœuds échouent, votre pipeline de données peut continuer à fonctionner. Un sujet particulier peut alors être divisé en plusieurs partitions. Ce cloisonnement est l'un des facteurs cruciaux de l'évolutivité horizontale de Kafka.

Plusieurs producteurs, sources de données pour un sujet donné, peuvent écrire sur ce sujet simultanément car chacune écrit sur une partition différente, à un moment donné. Maintenant, généralement les données sont affectées à une partition de manière aléatoire, à moins que nous ne lui fournissions une clé.

Partitionnement et commande

Pour récapituler, les producteurs écrivent des données sur un sujet donné. Ce sujet est en fait divisé en plusieurs partitions. Et chaque partition vit indépendamment des autres, même pour un thème donné. Cela peut conduire à beaucoup de confusion lorsque l'ordre des données est important. Vous avez peut-être besoin de vos données dans un ordre chronologique, mais le fait d'avoir plusieurs partitions pour votre flux de données ne garantit pas un ordre parfait.

Vous ne pouvez utiliser qu'une seule partition par sujet, mais cela va à l'encontre de l'objectif de l'architecture distribuée de Kafka. Nous avons donc besoin d'une autre solution.

Clés pour les partitions

Les données d'un producteur sont envoyées aux partitions de manière aléatoire, comme nous l'avons mentionné précédemment. Les messages étant les véritables morceaux de données. Ce que les producteurs peuvent faire en plus d'envoyer des messages, c'est d'ajouter une clé qui va avec.

Tous les messages fournis avec la clé spécifique iront à la même partition. Ainsi, par exemple, l'activité d'un utilisateur peut être suivie chronologiquement si les données de cet utilisateur sont étiquetées avec une clé et se retrouvent donc toujours dans une partition. Appelons cette partition p0 et l'utilisateur u0.

La partition p0 récupérera toujours les messages liés à u0 car cette clé les lie ensemble. Mais cela ne signifie pas que p0 n'est lié qu'à cela. Il peut également prendre en charge les messages de u1 et u2 s'il en a la capacité. De même, d'autres partitions peuvent consommer des données d'autres utilisateurs.

Le point selon lequel les données d'un utilisateur donné ne sont pas réparties sur différentes partitions, ce qui garantit un ordre chronologique pour cet utilisateur. Cependant, le thème général de données d'utilisateur, peut toujours tirer parti de l'architecture distribuée d'Apache Kafka.

Conclusion

Alors que les systèmes distribués comme Kafka résolvent certains problèmes plus anciens comme le manque d'évolutivité ou le fait d'avoir un seul point de défaillance. Ils viennent avec un ensemble de problèmes qui sont uniques à leur propre conception. Anticiper ces problèmes est un travail essentiel de tout architecte système. Non seulement cela, parfois vous devez vraiment faire une analyse coûts-avantages pour déterminer si les nouveaux problèmes sont un compromis valable pour se débarrasser des anciens. La commande et la synchronisation ne sont que la pointe de l'iceberg.

Espérons que des articles comme ceux-ci et la documentation officielle peuvent vous aider en cours de route.