Comparaison des codecs de compression Kafka : Zstd vs Snappy vs Gzip

La compression Kafka déplace le goulot d'étranglement : moins de trafic réseau et disque, plus de travail CPU sur les producteurs et consommateurs. Bien que Kafka excelle dans le traitement de volumes massifs de données, l'optimisation des performances implique souvent le réglage de plusieurs paramètres clés. L'un des domaines les plus critiques pour le réglage, en particulier dans les environnements à fort volume ou à bande passante limitée, est la compression des messages.

Le meilleur codec de compression Kafka dépend de ce qui vous manque : CPU, bande passante réseau, disque du broker ou capacité du consommateur.

Comprendre la compression dans Kafka

Kafka permet aux producteurs de compresser les messages avant de les envoyer au broker. Le broker stocke le lot compressé, et les consommateurs récupèrent et décompressent les données. Ce processus déplace la charge de calcul de la couche réseau/disque vers la couche CPU. Le choix du codec est crucial car il détermine l'équilibre entre ces ressources.

Kafka prend généralement en charge none, gzip, snappy, lz4 et zstd, bien que la prise en charge exacte dépende des versions du broker et du client.

Configuration de la compression

La compression est généralement configurée côté producteur à l'aide de la propriété compression.type. Le broker doit être capable de lire le codec utilisé par le producteur.

# Exemple de configuration du producteur
compression.type=zstd

Analyse approfondie des codecs de compression Kafka

Nous allons comparer les trois codecs principaux couramment utilisés en fonction de leurs profils de performance typiques : Gzip, Snappy et Zstd.

1. Gzip (GNU Zip)

Gzip est un algorithme de compression généraliste bien établi basé sur l'algorithme DEFLATE. Il offre souvent une forte compression, mais Zstd peut l'égaler ou le surpasser sur de nombreuses charges utiles d'événements selon le niveau et la forme des données.

Taux de compression : Élevé, en particulier pour les charges utiles textuelles.
Utilisation CPU : Élevée (nécessite un temps CPU important pour la compression et la décompression).
Impact sur la latence : Peut introduire une latence notable en raison de l'utilisation intensive du CPU, en particulier lors de la compression de gros lots.

Meilleur usage : Scénarios où les économies de stockage et la conservation de la bande passante réseau sont primordiales, et où les ressources CPU sont abondantes, ou lorsque les exigences de débit de messages sont relativement faibles.

2. Snappy

Snappy, développé par Google, est conçu pour la vitesse plutôt que pour une compression maximale. Il privilégie des taux de compression et de décompression très rapides, même si la taille du fichier résultant est plus grande qu'avec Gzip ou Zstd.

Taux de compression : Modéré à Faible.
Utilisation CPU : Faible (temps d'exécution très rapide).
Impact sur la latence : Minime. Snappy est connu pour son impact quasi nul sur la latence de bout en bout.

Meilleur usage : Systèmes à haut débit où la faible latence est la priorité absolue. C'est souvent le choix par défaut pour de nombreux déploiements Kafka car il minimise le goulot d'étranglement informatique tout en offrant des économies de réseau.

3. Zstandard (Zstd)

Zstandard, développé à l'origine par Facebook (Meta), est le concurrent moderne. Zstd vise à offrir des performances supérieures à Snappy tout en atteignant des taux de compression proches ou meilleurs que Gzip, selon le niveau de compression choisi.

Zstd prend en charge des niveaux de compression réglables. Les clients Kafka exposent cela via une configuration spécifique au codec dans les clients qui le prennent en charge.

Niveau 1 (Rapide) : Surpasse souvent Snappy en termes de vitesse tout en offrant une meilleure compression que Snappy.
Niveau 3-5 (Équilibré) : Un point idéal courant, offrant de bons taux de compression avec une faible surcharge CPU.
Niveau 10+ (Élevé) : Se rapproche du taux de compression de Gzip mais reste généralement plus rapide en décompression.
Taux de compression : Variable (de modéré à très élevé).
Utilisation CPU : Très variable selon le niveau choisi (peut être faible ou élevée).
Impact sur la latence : Généralement très faible aux niveaux inférieurs ; comparable à Snappy.

Meilleur usage : Presque tous les déploiements Kafka modernes. Zstd offre la flexibilité de régler précisément l'équilibre. Si vous avez besoin d'une faible latence, utilisez le niveau 1 ou 3. Si vous avez besoin d'économies de stockage, utilisez un niveau plus élevé (par exemple, 9 ou 11).

Analyse comparative : Choisir votre codec

Le codec optimal dépend entièrement du goulot d'étranglement dans l'architecture de votre cluster spécifique.

Codec	Taux de compression	Vitesse de compression	Vitesse de décompression	Surcharge CPU	Cas d'utilisation idéal
Snappy	Faible	Très rapide	Très rapide	La plus faible	Sensible à la latence, haut débit
Zstd (Niveau 1-3)	Moyen	Rapide	Très rapide	Très faible	Moderne, performances équilibrées
Zstd (Niveau 5-11)	Élevé	Modéré	Rapide	Moyen	Compromis flexible stockage/performance
Gzip	Le plus élevé	Lent	Lent	Le plus élevé	Archivage de stockage, faible débit

Guide de décision pratique

Utilisez ces directives pour faire correspondre vos exigences à un codec :

Si la latence est critique (par exemple, flux financiers en temps réel) : Choisissez Snappy ou Zstd au niveau 1. Ceux-ci offrent la plus faible résistance CPU.
Si le coût de stockage est critique (par exemple, conservation des données pendant des mois) : Choisissez Gzip ou Zstd à un niveau élevé (15+). Soyez prêt à allouer plus de ressources CPU.
Pour les systèmes à haut débit à usage général : Zstd (Niveau 3 ou 5) est fortement recommandé. Il offre souvent une meilleure efficacité (moins de CPU par octet compressé) que Snappy sans sacrifier beaucoup de vitesse.

Exemple de configuration : Optimisation pour la vitesse (Zstd)

Si vous utilisez Zstd et souhaitez des performances proches de Snappy avec une compression légèrement meilleure, définissez explicitement le niveau dans votre configuration de producteur :

# Configuration du producteur priorisant la vitesse avec Zstd
compression.type=zstd
compression.zstd.level=3

Avertissement sur les niveaux de compression : Les clients Kafka exposent des paramètres de niveau spécifiques au codec tels que compression.zstd.level et compression.gzip.level là où ils sont pris en charge ; Snappy n'est pas réglable en niveau de la même manière. Soyez conscient que l'augmentation du niveau augmente considérablement le temps passé à compresser, ce qui se produit avant l'envoi du lot.

Considérations de performance pour les producteurs et les consommateurs

Il est crucial de se rappeler que la compression a un impact sur les deux côtés de la connexion :

Impact sur le producteur (Temps de compression)

Le producteur doit attendre que l'ensemble du lot d'enregistrements soit prêt avant de le compresser et de l'envoyer. Si le temps de compression dépasse le linger.ms, le producteur pourrait envoyer un lot prématurément ou trop tard. Une compression très lente (comme Gzip de haut niveau) peut forcer les producteurs à envoyer des lots plus petits plus fréquemment, augmentant ainsi la surcharge des requêtes.

Impact sur le consommateur (Temps de décompression)

Les consommateurs doivent dépenser des cycles CPU pour décompresser les données avant de les traiter. Si les CPU des consommateurs sont saturés, la décompression peut devenir le goulot d'étranglement, entraînant un retard du consommateur, même si le débit réseau est suffisant. La vitesse de décompression est souvent plus critique que la vitesse de compression car elle affecte directement la latence du consommateur.

Pour cette raison, les codecs comme Snappy et Zstd (qui ont des routines de décompression exceptionnellement rapides) sont favorisés par rapport à Gzip, dont la routine de décompression est relativement lente.

À retenir

Commencez avec Zstd à un niveau bas ou modéré pour les nouvelles charges de travail Kafka, puis effectuez des tests de performance avec vos charges utiles réelles. Utilisez Snappy lorsque le CPU du producteur ou du consommateur est limité et que la latence est primordiale. Utilisez Gzip uniquement lorsque la compatibilité ou la réduction du stockage l'emporte sur le coût CPU supplémentaire.