Cet aperçu est un peu dans l'abstrait, alors la mise à la terre dans un scénario du monde réel, imaginez que vous devez surveiller plusieurs serveurs Web. Chacun exécutant 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, il existe un certain nombre de serveurs de messagerie que vous devez également surveiller.
Vous devrez peut-être stocker ces données à des fins de tenue de dossiers et de facturation, qui est un travail par lots qui ne nécessite pas une attention immédiate. Vous voudrez peut-être exécuter des analyses sur les données pour prendre des décisions en temps réel, ce qui nécessite une entrée précise et immédiate des données. Soudain, vous vous trouvez dans la nécessité de rationaliser les données de manière sensée pour tous les différents besoins. Kafka agit comme cette couche d'abstraction à laquelle plusieurs sources peuvent publier différents flux de données et un consommateur peut s'abonner aux flux qu'il trouve pertinents. Kafka s'assurera que les données sont bien ordonnées. C'est les internes de Kafka que nous devons comprendre avant d'arriver au sujet du partitionnement et des clés.
Kafka Les sujets sont comme des tables d'une base de données. Chaque sujet se compose de données d'une source particulière d'un type particulier. Par exemple, la santé de votre cluster peut être un sujet composé de CPU et d'informations sur l'utilisation de la mémoire. De même, le trafic entrant vers le cluster peut être un autre sujet.
Kafka est conçu pour être évolutif horizontalement. C'est-à-dire qu'un seul cas de kafka se compose de plusieurs kafka courtiers En courant sur plusieurs nœuds, chacun peut gérer des flux de données parallèles à l'autre. Même si quelques-uns des nœuds échouent, votre pipeline de données peut continuer à fonctionner. Un sujet particulier peut ensuite être divisé en un certain nombre de partitions. Ce partitionnement est l'un des facteurs cruciaux derrière l'évolutivité horizontale de Kafka.
Plusieurs producteurs, Les sources de données pour un sujet donné peuvent écrire à ce sujet simultanément parce que chacune écrit à une partition différente, à un moment donné. Maintenant, généralement les données sont affectées à une partition au hasard, sauf si nous lui fournissons une clé.
Partitionnement et commande
Juste 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 sujet donné. Cela peut conduire à beaucoup de confusion lorsque l'ordre des données est important. Peut-être avez-vous besoin de vos données dans un ordre chronologique, mais avoir plusieurs partitions pour votre datasteream ne garantit pas une commande parfaite.
Vous ne pouvez utiliser qu'une seule partition par sujet, mais cela bat le but 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 au hasard, comme nous l'avons mentionné précédemment. Les messages étant les morceaux réels de données. Ce que les producteurs peuvent faire en plus d'envoyer des messages, c'est d'ajouter une clé qui va de pair avec.
Tous les messages qui accompagnent 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 marquées avec une clé et donc elle se retrouve toujours dans une partition. Appelons cette partition P0 et l'utilisateur U0.
La partition P0 ramassera toujours les messages liés à U0 parce que cette clé les réalise ensemble. Mais cela ne signifie pas que P0 n'est lié qu'avec ça. Il peut également prendre des messages de U1 et U2 s'il a la capacité de le faire. De même, d'autres partitions peuvent consommer des données d'autres utilisateurs.
Le point que les données d'un utilisateur donné ne sont pas réparties sur différentes partitions assurant une commande chronologique pour cet utilisateur. Cependant, le sujet global de données d'utilisateur, peut encore tirer parti de l'architecture distribuée d'Apache Kafka.
Alors que des systèmes distribués comme Kafka résolvent certains problèmes plus anciens comme le manque d'évolutivité ou le point de défaillance unique. 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, vous devez parfois faire une analyse coûts-avantages pour déterminer si les nouveaux problèmes sont un compromis digne pour se débarrasser des plus âgés. 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.