Coût d'un sujet/partition Kafka non utilisé

Question

Lors de la conception d'un pipeline de traitement en continu, quel coût pourrait être encouru si je devais avoir de nombreux sujets qui auraient au moins une partition mais potentiellement aucune donnée y entrant ?

Par exemple, avec un consommateur, je peux choisir d'avoir un "méga sujet" qui contient toutes les données et de nombreuses partitions ou je peux choisir de diviser ces données (par locataire, compte ou utilisateur, etc.) en plusieurs sujets avec, par défaut, une seule partition. Dans le second cas, je crains que de nombreux sujets/partitions ne contiennent aucune donnée. Alors, est-ce que cette partition inutilisée coûte quelque chose ou est-ce qu'un sujet inutilisé n'entraîne aucun coût ?

Answer 1

Tout d'abord, il n'y a pas de différence entre un seul gros sujet et beaucoup de partitions et plusieurs sujets qui contiennent quelques partitions. Le sujet est juste une distinction logique entre les événements. Kafka ne se soucie que du nombre de partitions.

Deuxièmement, le fait d'avoir beaucoup de partitions peut entraîner certains problèmes :

• Trop de dossiers ouverts :

Chaque partition correspond à un répertoire dans le système de fichiers du courtier. Dans ce répertoire de journal, il y aura deux fichiers (un pour l'indice et un autre pour les données réelles) par segment de journal.

• Plus de partitions nécessitent plus de mémoire tant du côté du courtier que du consommateur. côtés :

Les courtiers allouent une mémoire tampon de la taille de replica.fetch.max.bytes pour chaque partition qu'ils répliquent. Si replica.fetch.max.bytes est défini à 1 MiB, et que vous avez 1000 partitions, environ 1 GiB de RAM est nécessaire.

• Plus de partitions peuvent augmenter l'indisponibilité :

Si un broker qui est contrôleur est défaillant, alors zookeeper élit un autre broker comme contrôleur. À ce moment-là, le courtier nouvellement élu doit lire les métadonnées pour chaque partition de Zookeeper pendant l'initialisation.

Par exemple, s'il existe 10 000 partitions dans le cluster Kafka et que l'initialisation des métadonnées depuis ZooKeeper prend 2 ms par partition, cela peut ajouter 20 secondes supplémentaires à la fenêtre d'indisponibilité.

Vous pouvez obtenir plus d'informations à partir de ces liens :
https://www.confluent.io/blog/how-choose-number-topics-partitions-kafka-cluster/ https://docs.cloudera.com/documentation/kafka/latest/topics/kafka_performance.html

Answer 2

En supposant que les sujets mentionnés ne soient pas compactés, il y a une surcharge initiale de conservation de toutes les données initialement produites, mais après quoi, un sujet vide est juste

1. les métadonnées dans zookeeper
2. les métadonnées dans n'importe quel coordinateur de groupe de consommateurs, et le traitement gaspillé par n'importe quel fil de consommateurs actif.
3. répertoires vides sur le disque

Pour les deux premiers, le fait d'avoir beaucoup de sujets peut augmenter la latence des requêtes, provoquant un cluster malsain.