Wie viele Partitionen brauche ich in Apache Kafka?

Apache Kafka ist wie eine Rakete. Aber jede Rakete wird am Boden entworfen. Nicht nach dem Start. Das Thema Partitionen ist dabei untrennbar mit dem Aufbau der Rakete selbst verbunden. Und jedem ist klar, dass nach der Zündung – also quasi im laufenden Betrieb von Apache Kafka – nur unter Aufwand und Risiko neue Partitionen hinzugefügt werden können. Wie viele Partitionen sollte man also zu Beginn einrichten? Das ist die Frage aller Fragen, die ich in meinen Schulungen kontinuierlich zu hören bekomme. Und ich verrate noch etwas: Der folgende Beitrag gibt keine Antwort auf diese Frage, liefert jedoch die nötigen Informationen, damit man selbst darauf kommen kann. Und zwar vor dem Start der Rakete. Das ist doch was.

In Kafka nutzen wir Partitionen, um die Verarbeitung großer Datenmengen zu beschleunigen. Statt also alle unsere Daten eines Topics in eine Partition (und damit einen Broker) zu schreiben, teilen wir unsere Topics in unterschiedliche Partitionen auf und verteilen diese Partitionen auf unsere Broker. Im Gegensatz zu anderen Messaging-Systemen sind unsere Producer für die Entscheidung verantwortlich, in welche Partition unsere Nachrichten geschrieben werden. Nutzen wir Keys, dann verteilt der Producer die Daten so, dass Daten mit dem gleichen Key auf derselben Partition landen. Somit können wir garantieren, dass die Reihenfolge zwischen Nachrichten mit demselben Key korrekt eingehalten wird. Nutzen wir keine Keys, dann werden Nachrichten per Round-Robin-Verfahren, also reihum, auf die Partitionen verteilt.

Weiterhin können wir sinnvollerweise höchstens so viele Consumer in einer Consumer Group haben, wie wir Partitionen in unseren Topics besitzen. Oft ist der Flaschenhals bei der Datenverarbeitung nicht der Broker oder die Producer, sondern die Consumer, die die Daten nicht nur lesen, sondern auch weiterverarbeiten müssen.

Allgemein gilt: je mehr Partitionen, desto

• höher ist unser Datendurchsatz: Sowohl die Broker als auch die Producer können unterschiedliche Partitionen vollkommen unabhängig – und damit parallel – verarbeiten. So können diese Systeme die vorhandenen Ressourcen besser auslasten und mehr Nachrichten verarbeiten. Wichtig: Die Anzahl der Partitionen kann auch deutlich höher sein als die Anzahl der Broker. Das ist kein Problem.
• mehr Consumer können wir in unseren Consumer Groups haben: Dadurch erhöht sich potenziell auch der Datendurchsatz, da wir die Arbeit auf mehr Schultern verteilen können. Aber Achtung: Je mehr einzelne Systeme wir haben, desto mehr Teile können ausfallen und zu Problemen führen.
• mehr offene File Handles haben wir auf den Brokern: Kafka öffnet für jedes Segment einer Partition zwei Dateien: das Log und den Index. Das hat zwar kaum Einfluss auf die Performance, aber wir sollten unbedingt die erlaubte Anzahl der offenen Dateien auf Betriebssystemseite erhöhen.
• längere Ausfallzeiten entstehen: Wird ein Kafka Broker sauber heruntergefahren, dann meldet sich dieser beim Controller ab und der Controller kann die Partition-Leader auf die anderen Broker ohne Ausfallzeiten verschieben. Fällt aber ein Broker unkontrolliert aus, gibt es unter Umständen längere Ausfallzeiten, da es für eine große Anzahl an Partitionen keinen Leader gibt. Aufgrund von Einschränkungen in Zookeeper kann der Consumer nur einen Leader zu einem Zeitpunkt verschieben. Dies dauert etwa 10 ms. Bei tausenden von Leadern, die verschoben werden müssen, kann dies unter Umständen Minuten dauern. Wenn der Controller ausfällt, dann muss dieser die Leader aller Partitionen einlesen. Wenn dies etwa 2 ms pro Leader dauert, dann dauert der Prozess noch länger. Mit KRaft wird dieses Problem viel kleiner werden.
• mehr RAM verbrauchen die Clients: Die Clients legen pro Partition Buffer an und wenn ein Client mit sehr vielen Partitionen, möglicherweise verteilt auf viele Topics, interagiert (insbesondere als Producer), dann summiert sich der RAM-Verbrauch stark auf.

Es gibt keine harten Limits für die Anzahl an Partitionen in Kafka-Clustern. Hier sind aber ein paar allgemeine Regeln:

• maximal 4000 Partitionen pro Broker (insgesamt; meistens verteilt auf viele Topics)
• maximal 200.000 Partitionen pro Kafka-Cluster (insgesamt; meistens verteilt auf viele Topics)
• daraus folgend: maximal 50 Broker pro Kafka-Cluster

Dadurch reduziert sich die Ausfallzeit, falls doch etwas schiefgeht. Aber Achtung: Es sollte nicht dein Ziel sein, diese Limits auszureizen. In vielen „Medium Data“-Anwendungen brauchst du nichts davon.

Wie bereits eingangs beschrieben, gibt es keine “richtige” Antwort auf die Frage nach der Anzahl der Partitionen. Über die Zeit haben sich jedoch folgende Daumenregeln (Faustregeln) etabliert:

• Keine Primzahlen: Auch wenn in vielen Beispielen im Internet (oder in Schulungen) drei Partitionen verwendet werden, so ist es oft eine schlechte Idee, Primzahlen zu verwenden, da sich Primzahlen schwierig auf unterschiedliche Anzahlen an Brokern und Consumern aufteilen lassen.
• Gut teilbare Zahlen: Deshalb sollten stets Zahlen benutzt werden, die sich durch viele andere Zahlen teilen lassen.
• Vielfaches der Consumer: So können die Partitionen gleichmäßig auf die Consumer einer Consumer Group verteilt werden.
• Vielfaches der Broker: Wenn wir nicht gerade sehr viele Broker haben, können wir so die Partitionen (und Leader!) gleichmäßig auf alle Broker verteilen
• Konsistenz im Kafka Cluster: Spätestens wenn wir Kafka Streams einsetzen möchten, stellen wir fest, dass es sinnvoll ist, keinen Wildwuchs bei den Partitionen zu haben. Wenn wir zum Beispiel einen Join über zwei Topics machen möchten und diese beiden Topics nicht die gleiche Anzahl an Partitionen haben, muss Kafka Streams ein Topic vorher repartitionieren. Dies ist eine kostspielige Angelegenheit, die wir möglichst vermeiden möchten.
• Abhängig von den Performance-Messungen: Wenn wir unseren Ziel-Datendurchsatz kennen und auch den gemessenen Datendurchsatz unserer Consumer und Producer pro Partition wissen, können wir daraus berechnen, wie viele Partitionen wir benötigen. Wenn wir zum Beispiel wissen, dass wir 100 MB/s an Daten bewegen möchten und im Producer pro Partition 10 MB/s und im Consumer 20 MB/s erreichen können, brauchen wir mindestens 10 Partitionen (und mindestens 5 Consumer in der Consumer Group).
• Nicht übertreiben: Dies ist kein Wettbewerb, bei dem die größtmögliche Anzahl an Partitionen eingerichtet werden soll. Wenn ihr nur wenige zehntausend Nachrichten pro Tag verarbeitet, benötigt ihr keine hunderte von Partitionen.

In meiner Beratungspraxis hat sich die 12 als guter Richtwert für die Anzahl der Partitionen durchgesetzt. Bei Kunden, die sehr wenige Daten mit Kafka verarbeiten (oder pro Partition bezahlen müssen) können sogar kleinere Zahlen sinnvoll sein (z.B. 2,4,6). Wenn ihr große Datenmengen verarbeitet, dann hilft Peres Excel-Tabelle, die er auf GitHub zur Verfügung gestellt hat: kafka-cluster-size-calculator

Weiterführende Informationen:

• Confluent Blog: How to choose the number of topics/partitions in a Kafka cluster?
• Kafka Buch Seite 60–61: “Wie viele Partitionen sollten wir haben”

Immer noch nicht sicher? Dann schreib mir oder buche gleich einen Immer noch nicht sicher? Dann Kennenlerntermin mit mir und wir finden gemeinsam die richtige Antwort.