Introduction
Un topic est bien plus qu'un nom transmis à un producteur. Ses partitions organisent le journal des événements, ses réplicas correspondent aux copies stockées et ses paramètres de rétention déterminent pendant combien de temps les enregistrements peuvent être conservés. La progression de lecture relève des consommateurs et constitue une notion distincte.
Vous allez créer deux topics, inspecter leurs métadonnées, leur attribuer une politique de rétention explicite, puis modifier un seul des deux. Vous pourrez ainsi comprendre la portée d'un paramètre propre à un topic sans attendre une suppression réelle ni modifier la configuration globale du broker.
Le broker unique préparé pour ce lab est prêt à l'emploi et les noms des deux topics sont indépendants des labs précédents. Des connaissances élémentaires du terminal suffisent ; aucune programmation en Python ou en Java n'est nécessaire. Un seul réplica convient à cet environnement d'apprentissage doté d'un seul broker. Utilisez le terminal.
Créer deux topics et lire leurs métadonnées
Dans cette étape, vous allez comparer deux nombres de partitions définis explicitement. Placez-vous dans votre espace de travail :
cd /home/labex/project
L'option --bootstrap-server indique l'adresse du broker préparé. Créez orders-retained avec deux partitions et orders-control avec une seule. Les deux utilisent un réplica, car cet environnement contient un seul broker :
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders-retained --partitions 2 --replication-factor 1
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders-control --partitions 1 --replication-factor 1
Affichez la liste des topics et enregistrez leur description. L'opérateur > du shell crée un fichier local ou remplace son contenu précédent :
kafka-topics.sh --bootstrap-server localhost:9092 --list
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders-retained > /home/labex/project/output/orders-retained-description.txt
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders-control > /home/labex/project/output/orders-control-description.txt
cat /home/labex/project/output/orders-retained-description.txt
cat /home/labex/project/output/orders-control-description.txt
Repérez PartitionCount: 2 pour le premier et 1 pour le second, ainsi que ReplicationFactor: 1 dans les deux descriptions. Chaque partition possède une entrée indiquant son leader. L'identifiant du broker leader n'est pas le nombre de partitions, et deux partitions ne signifient pas qu'il existe deux machines hébergeant des brokers.
Un topic peut avoir plusieurs partitions sur le même broker. Le facteur de réplication décrit les copies de chaque partition réparties entre les brokers, et non des copies indépendantes pour chaque consommateur. Vous allez maintenant modifier la rétention des données stockées sans changer ces deux propriétés.
Définir une rétention explicite d'un jour pour chaque topic
Dans cette étape, vous allez distinguer une valeur par défaut héritée d'un paramètre propre à un topic. kafka-configs.sh gère les ressources de configuration. --entity-type topics sélectionne les ressources de type topic, tandis que --entity-name désigne le seul topic concerné. --describe affiche normalement les paramètres explicitement définis pour le topic ; l'absence d'un tel paramètre ne signifie pas que le broker n'a aucune valeur par défaut.
Inspectez le topic orders-retained avant de le modifier :
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --describe
retention.ms est une durée en millisecondes. Un jour correspond à 24 × 60 × 60 × 1000 = 86400000 millisecondes. --alter --add-config définit explicitement le paramètre nommé. Appliquez la même politique aux deux topics, indépendamment :
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --alter --add-config retention.ms=86400000
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-control --alter --add-config retention.ms=86400000
Lisez les paramètres réellement définis pour chacun et enregistrez vos observations :
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --describe > /home/labex/project/output/retained-one-day-config.txt
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-control --describe > /home/labex/project/output/control-one-day-config.txt
cat /home/labex/project/output/retained-one-day-config.txt
cat /home/labex/project/output/control-one-day-config.txt
Repérez retention.ms=86400000 pour chaque topic nommé. Un client peut aussi afficher des informations sur la source de configuration ou le caractère sensible des paramètres ; ces détails et leur mise en forme peuvent varier.
La rétention est une politique de stockage du broker, pas une instruction de suppression immédiate d'un enregistrement dès qu'un consommateur le lit. L'âge des enregistrements et le nettoyage des segments du journal déterminent quels enregistrements peuvent être supprimés et à quel moment ; cette durée ne garantit pas qu'un message précis disparaîtra à un instant exact. Cet exercice vérifie le paramètre configuré sans attendre le nettoyage.
Modifier un seul topic et confirmer la portée du changement
Dans cette étape, vous allez attribuer une rétention de deux jours à orders-retained tout en conservant un jour pour orders-control. Anticipez les métadonnées qui doivent changer : le paramètre de rétention du topic orders-retained, sans modification des nombres de partitions ni des facteurs de réplication.
Deux jours correspondent à 172800000 millisecondes. Appliquez cette valeur uniquement au topic orders-retained :
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --alter --add-config retention.ms=172800000
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --describe > /home/labex/project/output/retained-final-config.txt
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-control --describe > /home/labex/project/output/control-final-config.txt
cat /home/labex/project/output/retained-final-config.txt
cat /home/labex/project/output/control-final-config.txt
Vous devez obtenir retention.ms=172800000 pour orders-retained et retention.ms=86400000 pour orders-control. L'utilisation de la même adresse de broker ne rend pas un paramètre propre à un topic global.
Affichez une nouvelle fois la description du topic orders-retained :
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders-retained
Il doit toujours avoir deux partitions et un réplica. La modification de la rétention n'a créé aucun topic, ajouté aucune partition, copié aucune progression de consommateur ni consommé aucun événement. Vous avez vérifié le changement attendu et l'absence de modification du topic voisin. Vous allez ensuite utiliser des clés pour associer les identifiants de commande aux partitions.
Résumé
Vous avez créé des topics avec des nombres explicites de partitions et de réplicas, inspecté leurs métadonnées et défini leur rétention en millisecondes. La modification d'un topic a laissé l'autre inchangé, ce qui distingue la politique de stockage d'un topic de la progression des consommateurs. Vous allez ensuite acheminer des événements liés à l'aide de clés et examiner leurs offsets propres à chaque partition.
