Comparaison entre la suppression de sujet Kafka et les commandes de politique de rétention

La suppression de données dans Kafka se présente sous deux formes très différentes : supprimer un sujet entier, ou laisser la rétention supprimer les anciens segments de journal d'un sujet actif. Gérer efficacement les sujets Kafka est crucial pour maintenir la santé du système, optimiser le stockage et garantir l'intégrité des données. Cela implique non seulement de créer et de surveiller les sujets, mais aussi de comprendre comment supprimer gracieusement les données qui ne sont plus nécessaires. Deux mécanismes principaux existent pour la suppression de données : la suppression immédiate de sujet et les politiques de rétention basées sur le temps. Bien que les deux mènent finalement à la suppression des données, leurs différences fonctionnelles, leurs cas d'utilisation et leurs implications varient considérablement.

Utilisez la suppression de sujet lorsque le sujet lui-même doit disparaître. Utilisez les paramètres de rétention lorsque le sujet doit rester mais que les anciennes données doivent vieillir automatiquement.

Comprendre la suppression de sujet Kafka (`kafka-topics.sh --delete`)

La suppression de sujet dans Kafka est une action directe et immédiate destinée à supprimer complètement un sujet, y compris toutes ses partitions, données et métadonnées, du cluster Kafka. Cela est généralement utilisé lorsqu'un sujet est obsolète, créé par erreur, ou ne sert plus à rien dans votre système.

Comment fonctionne la suppression de sujet

Lorsque vous exécutez une commande de suppression de sujet, Kafka marque le sujet pour suppression. Le processus de suppression réel implique plusieurs étapes :

Marquage pour suppression : Les métadonnées du sujet dans ZooKeeper (ou le quorum Raft Kafka pour les clusters KRaft) sont mises à jour pour le marquer comme supprimé.
Action du contrôleur : Le contrôleur Kafka (un courtier avec un rôle spécial) orchestre la suppression. Il ordonne aux autres courtiers d'arrêter de produire ou de consommer sur les partitions du sujet marqué.
Nettoyage du répertoire de journal : Chaque courtier hébergeant des partitions pour le sujet supprimé finira par supprimer les segments de journal et les fichiers d'index associés de son disque. Ce nettoyage est asynchrone et dépend de la coordination courtier/contrôleur et du nettoyage du système de fichiers sur les courtiers qui hébergeaient les partitions.

Activer la suppression de sujet

Avant de pouvoir supprimer des sujets, la suppression de sujet doit être explicitement activée sur tous les courtiers Kafka. Il s'agit d'une mesure de sécurité critique pour éviter une perte de données accidentelle.

Pour activer la suppression de sujet, définissez la propriété suivante dans votre fichier server.properties sur chaque courtier Kafka :

delete.topic.enable=true

Après avoir modifié server.properties, redémarrez vos courtiers Kafka pour que le changement prenne effet.

Exemple pratique : Supprimer un sujet

Pour supprimer un sujet nommé my-obsolete-topic :

kafka-topics.sh --bootstrap-server localhost:9092 --delete --topic my-obsolete-topic

Exemple de sortie :

Deleting topic my-obsolete-topic.

Vous pouvez vérifier que le sujet est marqué pour suppression en listant les sujets :

kafka-topics.sh --bootstrap-server localhost:9092 --list

En cas de succès, my-obsolete-topic pourrait initialement encore apparaître dans la liste (marqué pour suppression) mais devrait disparaître complètement après la fin du processus de nettoyage sur tous les courtiers.

Avertissement : La suppression d'un sujet est une opération destructive et irréversible. Une fois supprimée, les données sont perdues. Faites toujours preuve d'une extrême prudence et assurez-vous d'avoir des sauvegardes ou d'être certain que les données ne sont plus nécessaires.

Configurer les politiques de rétention des sujets Kafka

Les politiques de rétention Kafka offrent une manière plus granulaire et automatique de gérer le cycle de vie des données en définissant combien de temps les messages doivent être conservés dans un sujet ou combien d'espace ils doivent occuper. Cela est idéal pour les sujets qui stockent des flux continus d'événements, de journaux ou de métriques, où les anciennes données perdent naturellement leur pertinence avec le temps.

Comment fonctionnent les politiques de rétention

Les courtiers Kafka exécutent en continu un processus de nettoyage des journaux qui vérifie périodiquement les segments de sujet pour les données qui ont dépassé les limites de rétention définies. Il existe deux configurations de rétention principales :

retention.ms (Rétention basée sur le temps) : Cette configuration spécifie le temps maximum (en millisecondes) pendant lequel Kafka conservera un segment de journal avant qu'il ne soit éligible à la suppression. Par exemple, si retention.ms est défini sur 604800000 (7 jours), tous les messages plus anciens que 7 jours seront supprimés.
retention.bytes (Rétention basée sur la taille) : Cette configuration spécifie la taille maximale (en octets) que les partitions d'un sujet peuvent atteindre sur le disque avant que les segments de journal plus anciens ne soient supprimés pour libérer de l'espace. Si retention.bytes est atteint, Kafka supprimera les segments les plus anciens jusqu'à ce que la taille du sujet soit dans la limite, indépendamment de retention.ms.

Si retention.ms et retention.bytes sont tous deux configurés, la politique qui se déclenche en premier prendra le pas. Par exemple, si les données atteignent leur limite de temps avant la limite de taille, elles seront supprimées par retention.ms. Si la limite de taille est atteinte avant la limite de temps, retention.bytes déclenchera la suppression.

Remarque : Une valeur de retention.ms de -1 indique une rétention infinie (les données ne sont jamais supprimées par le temps).

Exemple pratique : Créer un sujet avec rétention

Pour créer un sujet my-event-stream avec une période de rétention de 24 heures (86 400 000 millisecondes) :

kafka-topics.sh --bootstrap-server localhost:9092 \
                --create \
                --topic my-event-stream \
                --partitions 3 \
                --replication-factor 1 \
                --config retention.ms=86400000

Exemple pratique : Modifier la rétention pour un sujet existant

Pour changer la rétention d'un sujet existant my-log-topic à 7 jours (604 800 000 millisecondes) et ajouter une limite de taille de 1 Go (1 073 741 824 octets) :

kafka-configs.sh --bootstrap-server localhost:9092 \
                 --entity-type topics \
                 --entity-name my-log-topic \
                 --alter \
                 --add-config retention.ms=604800000,retention.bytes=1073741824

Pour supprimer un paramètre de rétention spécifique (par exemple, pour revenir à la valeur par défaut du courtier pour retention.bytes) :

kafka-configs.sh --bootstrap-server localhost:9092 \
                 --entity-type topics \
                 --entity-name my-log-topic \
                 --alter \
                 --delete-config retention.bytes

Afficher les configurations des sujets

Vous pouvez inspecter la configuration actuelle d'un sujet, y compris ses paramètres de rétention :

kafka-configs.sh --bootstrap-server localhost:9092 \
                 --entity-type topics \
                 --entity-name my-event-stream \
                 --describe

Différences clés et cas d'utilisation

Caractéristique	Suppression de sujet (`--delete`)	Politique de rétention (`retention.ms`/`retention.bytes`)
Type d'action	Manuelle, immédiate, irréversible	Automatique, continue, configurable
Portée	Supprime le sujet entier (toutes les données et métadonnées)	Supprime les segments de données anciens dans un sujet actif
Objectif	Éliminer les sujets obsolètes, corriger les erreurs	Gérer le cycle de vie des données pour les sujets actifs, contrôler l'utilisation du stockage
Risque de perte de données	Élevé (toutes les données perdues instantanément)	Contrôlé (seules les données dépassant la politique sont supprimées)
Configuration	`delete.topic.enable` au niveau du courtier, puis exécution de commande	Configurations au niveau du sujet (`--config` ou `--alter`)
Réversibilité	Non	Peut être modifié ou désactivé pour les données futures, mais les suppressions passées sont permanentes

Quand utiliser la suppression de sujet

Sujets obsolètes : Lorsqu'un projet ou un service est décommissionné et que ses sujets Kafka associés ne sont plus nécessaires.
Nettoyage de développement/test : Nettoyer les sujets temporaires créés lors des cycles de développement ou de test.
Correction d'erreurs : Si un sujet a été créé avec des configurations incorrectes (par exemple, trop de partitions, mauvais facteur de réplication) et qu'il est plus facile de le recréer à partir de zéro.

Quand utiliser les politiques de rétention

Données de journalisation/surveillance : Pour les sujets collectant des journaux d'application, des métriques ou des événements d'audit où les anciennes données perdent finalement de la valeur.
Flux d'événements : Dans les architectures pilotées par les événements où les événements doivent être accessibles pendant une certaine période pour la relecture ou la synchronisation des consommateurs, mais pas indéfiniment.
Gestion des ressources : Pour empêcher les sujets de consommer un espace disque excessif sur les courtiers Kafka, garantissant la stabilité du cluster et l'efficacité des coûts.
Conformité : Pour respecter les réglementations de rétention des données qui imposent la suppression des données après une période spécifique.

Meilleures pratiques et considérations

Activez delete.topic.enable=true avec prudence : Bien que nécessaire pour la suppression, soyez conscient de qui a accès pour effectuer des opérations de suppression dans un environnement de production.
Automatisez la rétention : Pour la plupart des sujets actifs, établissez des politiques de rétention sensées dès le départ pour éviter des problèmes d'espace disque inattendus.
Surveillez l'utilisation du disque : Surveillez régulièrement l'utilisation du disque des courtiers Kafka. Si les sujets croissent de manière inattendue, examinez leurs politiques de rétention ou enquêtez sur le comportement des producteurs.
Testez la suppression/rétention : Dans des environnements non productifs, simulez des suppressions de sujets et observez comment les politiques de rétention se comportent pour comprendre pleinement leur impact.
Sauvegardez les données critiques : Pour les sujets contenant des données critiques ou d'archivage à long terme, envisagez des solutions d'archivage externes (par exemple, S3, HDFS) plutôt que de compter uniquement sur la rétention infinie de Kafka, ou assurez-vous que votre retention.ms est défini sur -1 et que retention.bytes est suffisamment grand ou -1.
Sujets compactés : Pour les sujets avec compactage de journal activé (cleanup.policy=compact), retention.ms s'applique toujours pour supprimer les anciens segments (pas les messages individuels) qui ont été compactés, et min.cleanable.dirty.ratio contrôle quand le compactage s'exécute. Il s'agit d'un mécanisme distinct de la rétention standard et est utilisé pour les sujets où la dernière valeur pour une clé donnée est importante (par exemple, les journaux de modification de base de données, les profils utilisateur).

Conclusion

Supprimez un sujet Kafka uniquement lorsque les producteurs, les consommateurs et les dépendances en aval n'en ont plus besoin. Pour les sujets actifs, définissez retention.ms et retention.bytes délibérément et surveillez l'utilisation du disque du courtier afin que les anciennes données expirent avant que la pression de stockage ne devienne un incident.