Liebling, ich habe die Topics geschrumpft: Kafka und Kompression

Kompression findet heutzutage oft unsichtbar im Hintergrund statt, etwa bei der Übertragung von Webseiten. Da kann es überraschen, dass Kafka die Daten in der Standardeinstellung unkomprimiert überträgt und speichert. Mit wenigen Handgriffen lassen sich hier viele GB an Daten einsparen, und damit auch Energie und Geld.

Konfiguration #

Kafka-Kompression lässt sich einfach am Producer oder am Topic konfigurieren, hier kann man den compression.type setzen.

compression.type=snappy   # eines von mehreren unterstützten Komprimierungsverfahren

Der Code im Producer und im Consumer muss nicht angepasst werden, die Daten werden im Hintergrund komprimiert und dekomprimiert.

Wenn man die Konfiguration im Producer setzt, wird entsprechend schon beim Absenden komprimiert. Wenn beim Producer der Default “none” gesetzt ist, und man dann eine konkrete Kompression nur im Topic setzt, komprimiert der Broker die Daten selbst. Entsprechend erhöht sich beim Producer oder beim Broker die CPU-Last.

Achtung: Wenn am Producer und im Topic verschiedene konkrete compression.type konfiguriert wären, würde der Broker den Batch noch einmal auspacken und in den anderen Typ umwandeln, ein unnötiger Aufwand.

letters from printing press

Foto © Fabian Nilius

Batches #

Wie bei Kompressionsverfahren üblich, ist die Kompression bei größeren Datenmengen besonders effektiv. Dazu können mehrere Records beim Producer in Batches gesammelt werden und dann zusammen komprimiert werden. Praktisch bedeutet das, dass die ersten Records oft etwas später abgesendet werden, weil ja auf weitere Records gewartet werden kann, konfigurierbar mit linger.ms.

batch.size=32768
linger.ms=10
compression.type=lz4

Dieses Batching lässt sich nur am Producer konfigurieren, nicht bei der Topic-Konfiguration.

Erfahrungen #

Bei einem unserer Topics haben wir im Producer Kompression eingeführt mit folgender Konfiguration

batch.size=65536         # max batch size of 64 KiB
linger.ms=1000           # wait up to 1 second to allow batching
compression.type=snappy  # use "snappy" compression

In diesem Fall war uns eine gute Komprimierung wichtig, die Daten hatten aber keine besondere Dringlichkeit, da sie an ein Archivsystem gingen, deshalb der sehr hohe Wert von 1000 ms.

Das Topic enthielt gut komprimierbare JSON-Daten. Mit dieser Konfiguration sank der Speicherbedarf von 16 auf 4 GB (pro Broker), eine große Ersparnis bei minimalem Aufwand.

Wer noch tiefer in das Thema einsteigen möchte, dem sei dieser Artikel empfohlen.

kafka devops