Optimierung von Kafka-Partitionen für Skalierbarkeit und Durchsatz

Die Anzahl der Kafka-Partitionen ist eine dieser Einstellungen, die einfach erscheint, bis man mit ihr leben muss. Zu wenige Partitionen und Konsumenten können nicht skalieren. Zu viele und Broker verbringen mehr Zeit mit der Verwaltung von Metadaten, Rebalancings dauern länger und der operative Aufwand steigt.

Es gibt keine universelle beste Zahl. Ein Zahlungsthema, ein Clickstream-Thema und ein kompaktiertes Kundenzustands-Thema haben unterschiedliche Ordnungsanforderungen, Nachrichtengrößen, Aufbewahrungseinstellungen und Konsumentenverhalten. Die nützliche Frage ist nicht „Wie viele Partitionen sind am besten?" Es ist „Wie viele Partitionen benötigen wir für den Durchsatz, die Ordnung und das Wachstum dieses Themas, ohne unnötigen Broker-Overhead zu erzeugen?"

Grundlegendes zu Kafka-Partitionen

Im Kern ist ein Kafka-Thema in eine oder mehrere Partitionen unterteilt. Jede Partition ist ein geordnetes, nur-anhängbares Protokoll. Partitionen sind die Einheit der Parallelität in Kafka:

Produzenten schreiben in Partitionen: Ein Produzent kann eine Partition direkt auswählen, einen Schlüssel verwenden oder den Partitioner die Datensätze verteilen lassen.
Konsumenten lesen aus Partitionen: Jeder Konsument in einer Konsumentengruppe erhält eine oder mehrere Partitionen exklusiv zum Lesen zugewiesen. Dadurch wird sichergestellt, dass Nachrichten innerhalb einer Partition von einer einzelnen Konsumenteninstanz innerhalb dieser Gruppe der Reihe nach verarbeitet werden.
Broker hosten Partitionen: Kafka-Broker speichern Leader und Replicas. Ein Thema mit mehreren Partitionen kann Speicher und Datenverkehr auf mehrere Broker verteilen.

Wichtige Eigenschaften von Partitionen:

Innerhalb einer Partition geordnet: Nachrichten innerhalb einer einzelnen Partition sind immer geordnet. Konsumenten innerhalb einer Gruppe behalten diese Ordnung bei.
Über Partitionen hinweg ungeordnet: Es gibt keine garantierte Reihenfolge von Nachrichten über verschiedene Partitionen desselben Themas hinweg.
Parallelität: In einer Konsumentengruppe kann die nutzbare Anzahl aktiver Konsumenten für ein Thema die Anzahl der Partitionen nicht überschreiten. Zusätzliche Konsumenten bleiben für dieses Thema untätig.

Faktoren, die die Partitionsanzahl beeinflussen

Mehrere kritische Faktoren sollten bewertet werden, wenn Sie sich für die Anzahl der Partitionen für ein Kafka-Thema entscheiden:

1. Durchsatzanforderungen (Produzenten und Konsumenten)

Produzentendurchsatz: Mehr Partitionen können Schreibvorgänge auf Broker verteilen, aber nur, wenn die Leader ausgeglichen sind und die Produzenten die Datensätze gut verteilen. Ein thematisiertes Thema mit einem heißen Schlüssel kann immer noch eine Partition überlasten.
Konsumentendurchsatz: Wenn ein einzelner Konsument 2.000 Nachrichten pro Sekunde verarbeiten kann und das Thema Spitzen von 20.000 Nachrichten pro Sekunde erreicht, benötigen Sie genügend Partitionen, um genügend Konsumenten in der Gruppe auszuführen. Die genaue Anzahl hängt von der gemessenen Konsumentengeschwindigkeit ab, nicht von Schätzungen.

2. Skalierbarkeitsziele

Zukünftiges Wachstum: Kafka ermöglicht es Ihnen, Partitionen zu erhöhen, aber die Reduzierung der Partitionsanzahl ist kein normaler In-Place-Vorgang. Normalerweise erstellen Sie ein neues Thema und migrieren.
Rebalancing: Das Hinzufügen von Partitionen kann Rebalancings von Konsumentengruppen auslösen. Bei vielbeschäftigten Konsumenten kann dies die Verarbeitung vorübergehend verlangsamen oder anhalten.
Schlüsselverhalten: Das Erhöhen der Partitionen ändert die Schlüssel-zu-Partition-Zuordnung für viele Produzenten, die das Standard-Partitionierungsverhalten verwenden. Das kann Systeme überraschen, die davon ausgegangen sind, dass ein Schlüssel im Laufe der Zeit immer auf derselben Partition bleibt.

3. Broker-Ressourcen

Festplatte: Mehr Partitionen bedeuten mehr Log-Segmente und mehr zu verwaltende Dateien, insbesondere bei Replikation.
Netzwerk: Replikation und Konsumentenabrufe erhöhen den Datenverkehr. Das Problem ist nicht nur die Anzahl der Themen, sondern auch Replicas, Aufbewahrung, Nachrichtengröße und Konsumenten-Fan-Out.
CPU und Speicher: Broker, Controller und Clients zahlen alle einen gewissen Overhead für große Partitionsanzahlen. Moderne Kafka-Versionen verwalten große Cluster besser als ältere, aber die Partitionsanzahl ist immer noch Kapazitätsplanungsarbeit.

4. Anforderungen an die Nachrichtenordnung

Schlüsselbasierte Ordnung: Wenn die Ordnung kritisch ist und Sie einen Nachrichtenschlüssel verwenden, gehen Datensätze mit demselben Schlüssel normalerweise in dieselbe Partition. Das ergibt eine Ordnung pro Schlüssel, keine themenweite Ordnung. Ein heißer Schlüssel landet immer noch auf einer Partition und kann einen Konsumenten zum Engpass machen.
Keine strenge Ordnung: Wenn eine strenge Nachrichtenordnung keine Anforderung ist, können Sie Nachrichten freier über Partitionen verteilen und dabei Durchsatz und Parallelität priorisieren.

5. Skalierbarkeit der Konsumentengruppe

Wie bereits erwähnt, bestimmt die Anzahl der Partitionen die maximale Anzahl von Konsumenten, die gleichzeitig aus einem Thema innerhalb einer Konsumentengruppe lesen können. Wenn Sie Ihren Verbrauch durch Hinzufügen weiterer Konsumenteninstanzen skalieren müssen, müssen Sie mindestens so viele Partitionen haben wie die gewünschte Anzahl von Konsumenteninstanzen.

Ein praktischer Weg, eine Partitionsanzahl zu wählen

Hier sind praktische Strategien, die Ihnen helfen, eine optimale Partitionsanzahl zu ermitteln:

1. Beginnen Sie mit einer Basislinie und überwachen Sie

Eine nützliche Basislinie beginnt mit der Konsumentenparallelität. Wenn Sie vier Konsumenteninstanzen für dieses Thema erwarten, gibt der Start mit mehr als vier Partitionen Raum für Rebalancing und Wachstum.

Beispiel: Wenn Sie erwarten, vier Konsumenten auszuführen, könnten Sie mit acht Partitionen beginnen. Das ermöglicht jedem Konsumenten, zwei Partitionen zu besitzen, und Sie können ein paar weitere Konsumenten hinzufügen, bevor Sie eine Neupartitionierung vornehmen. Dies ist ein Ausgangspunkt, kein Gesetz.

Überwachen Sie kontinuierlich Ihren Kafka-Cluster und den Konsumenten-Rückstand. Wenn Sie einen hohen Konsumenten-Rückstand beobachten, der nicht durch Hinzufügen weiterer Konsumenteninstanzen behoben werden kann (weil Sie das Partitionslimit erreicht haben), ist dies ein klares Indiz dafür, dass Sie die Partitionsanzahl erhöhen müssen.

2. Berechnen Sie basierend auf dem erwarteten Durchsatz

Sie können die erforderlichen Partitionen aus dem gemessenen Durchsatz schätzen:

Formel: Anzahl der Partitionen = (Gesamterwarteter Durchsatz / Durchsatz pro Konsumenteninstanz) * Puffer
- Gesamterwarteter Durchsatz: Verwenden Sie die Spitzenproduktionsrate, nicht den Tagesdurchschnitt.
- Durchsatz pro Konsumenteninstanz: Messen Sie Ihren tatsächlichen Konsumenten mit tatsächlichen Nachrichtengrößen und nachgelagerten Aufrufen.
- Puffer: Fügen Sie Spielraum für Spitzen und Wachstum hinzu. Tun Sie nicht so, als ob die Berechnung exakt wäre.

Beispiel:

Erwarteter Spitzendurchsatz: 50.000 Nachrichten pro Sekunde
Durchsatz einer einzelnen Konsumenteninstanz: 5.000 Nachrichten pro Sekunde
Puffer: 1,5x
(50.000 / 5.000) * 1,5 = 15

In diesem Fall sind 16 Partitionen ein vernünftiger runder Ausgangspunkt. Wenn Ordnung, Broker-Kapazität oder Schlüsselverteilung gegen diese Zahl sprechen, passen Sie sie an.

3. Berücksichtigen Sie Broker-Fähigkeiten und -Grenzen

Beachten Sie die Gesamtzahl der Partitionen im gesamten Cluster. Es gibt keine einzelne sichere Anzahl von Partitionen pro Broker, die überall gilt. Hardware, Kafka-Version, Replikationsfaktor, Aufbewahrung, Nachrichtengröße, Controller-Last und Ziele der Fehlerbehebung sind alle wichtig.

Behandeln Sie „100 Partitionen pro Broker" oder „1.000 Partitionen pro Broker" nicht als universelle Wahrheit, sondern verfolgen Sie Broker-Metriken: Anforderungslatenz, Festplatten-I/O, Controller-Gesundheit, unter-replizierte Partitionen, Page-Cache-Druck und Rebalance-Dauer. Verwenden Sie die getesteten Grenzen Ihrer Plattform, wenn Ihre Organisation solche hat.

4. Schlüsselverteilung und heiße Partitionen

Wenn Sie Nachrichtenschlüssel verwenden, analysieren Sie die Schlüsselverteilung, bevor Sie entscheiden, dass „mehr Partitionen" den Durchsatz verbessern. Einige dominante Schlüssel können heiße Partitionen erzeugen. Der Broker, der den Leader hostet, arbeitet härter, und der dieser Partition zugewiesene Konsument fällt zurück.

Lösung: Wenn Sie heiße Partitionen vorhersehen, ziehen Sie Strategien in Betracht wie:
- Verwenden Sie einen weniger verzerrten Schlüssel, wenn es die geschäftliche Ordnung zulässt.
- Verwenden Sie einen zusammengesetzten Schlüssel, wie customer_id:event_type, wenn dies die von Ihnen benötigte Ordnung bewahrt.
- Teilen Sie einen heißen Workflow in ein separates Thema auf.
- Sharden Sie einen heißen Schlüssel absichtlich und handhaben Sie dann die Ordnung in einem engeren Bereich.

Das Erhöhen der Partitionen kann bei einer breiten Verteilung helfen. Es teilt einen Schlüssel nicht auf mehrere Konsumenten auf, wenn alle Datensätze für diesen Schlüssel geordnet bleiben müssen.

Erstellen und Ändern von Themen mit Partitionen

Beim Erstellen eines neuen Themas geben Sie die Partitionsanzahl an.

Erstellen eines Themas mit einer bestimmten Anzahl von Partitionen

Mit dem Skript kafka-topics.sh:

kafka-topics.sh --create --topic my-high-throughput-topic \
  --bootstrap-server kafka-broker-1:9092,kafka-broker-2:9092 \
  --partitions 16 \
  --replication-factor 3

--partitions 16: Setzt das Thema auf 16 Partitionen.
--replication-factor 3: Jede Partition hat 3 Replicas auf verschiedenen Brokern für Fehlertoleranz.

Erhöhen der Partitionen bei einem bestehenden Thema

Dies ist ein häufiger Vorgang, hat aber Auswirkungen. Kafka ermöglicht es Ihnen, die Anzahl der Partitionen für ein Thema zu erhöhen. Eine Verringerung erfordert eine Migration zu einem anderen Thema.

Mit dem Skript kafka-topics.sh:

kafka-topics.sh --alter --topic my-high-throughput-topic \
  --bootstrap-server kafka-broker-1:9092 \
  --partitions 24

--partitions 24: Erhöht die Partitionen für my-high-throughput-topic auf 24.

Wichtige Überlegungen beim Ändern von Partitionen:

Consumer-Rebalance: Das Erhöhen der Partitionen kann Rebalancings für abonnierte Konsumentengruppen auslösen. Dies kann den Konsum vorübergehend anhalten oder verlangsamen.
Neue Partitionen: Neue Partitionen werden an das Thema angehängt. Vorhandene Nachrichten werden nicht neu partitioniert.
Schlüsselzuordnung: Bei thematisierten Produzenten kann das Hinzufügen von Partitionen ändern, wohin zukünftige Datensätze für einen Schlüssel geschrieben werden.
Broker-Ressourcen: Stellen Sie sicher, dass die Broker Kapazität für die zusätzlichen Leader und Replicas haben.

Wenn die Schlüsselordnung über die gesamte Historie hinweg wichtig ist, seien Sie vorsichtig. Vorhandene Datensätze bleiben in alten Partitionen, während neue Datensätze nach der Änderung der Partitionsanzahl möglicherweise anders zugeordnet werden.

Metriken, die Ihnen sagen, dass die Partitionsanzahl falsch ist

Der Konsumenten-Rückstand ist das offensichtliche Signal, aber er allein reicht nicht aus. Rückstand kann von langsamen nachgelagerten Datenbanken, schlechtem Konsumenten-Code, kleinen Fetch-Einstellungen, Broker-Überlastung oder zu wenigen Partitionen herrühren.

Achten Sie auf diese Muster:

Konsumenten sind gesund, aber einige Instanzen sind untätig, weil es weniger Partitionen als Konsumenten gibt.
Eine Partition hat einen viel höheren Rückstand als andere.
Ein Broker trägt viele heiße Partitions-Leader.
Die Produzentenlatenz steigt während des Spitzenverkehrs, obwohl der Cluster freie Broker hat.
Rebalancings dauern lange genug, um Service-Level-Ziele zu beeinträchtigen.

Für Konsumentengruppen:

kafka-consumer-groups.sh --bootstrap-server kafka-broker-1:9092 \
  --describe --group my-consumer-group

Für das Themen-Layout:

kafka-topics.sh --bootstrap-server kafka-broker-1:9092 \
  --describe --topic my-high-throughput-topic

Wenn nur eine Partition zurückliegt, hilft das Hinzufügen von Konsumenten nicht, es sei denn, die Arbeit kann auf mehr Partitionen verteilt werden.

Best Practices und Fallstricke

Tun Sie:

Beginnen Sie mit gemessenen Anforderungen: Verwenden Sie erwartete Konsumentenanzahl, Durchsatztests und Broker-Kapazität.
Richten Sie sich nach der Konsumentenparallelität: Stellen Sie sicher, dass Sie genügend Partitionen haben, um Ihre Konsumenteninstanzen effektiv zu skalieren.
Lassen Sie Wachstumsspielraum: Das spätere Hinzufügen von Partitionen ist möglich, aber nicht folgenlos.
Verstehen Sie die Schlüsselverteilung: Wenn Sie Schlüssel verwenden, analysieren Sie deren Verteilung, um heiße Partitionen zu vermeiden.
Nutzen Sie Kafka-Überwachungstools: Verwenden Sie Tools, um Themen-/Partitionsmetriken, Konsumenten-Rückstand und Broker-Last zu verfolgen.

Tun Sie nicht:

Über-Partitionieren: Zu viele Partitionen erhöhen den Overhead, können Rebalancings verlangsamen und die Fehlerbehebung lauter machen.
Unter-Partitionieren: Schränkt Skalierbarkeit und Durchsatz ein und führt zu Konsumenten-Rückstand.
Blindlings willkürlichen Zahlen folgen: Verwenden Sie Faustregeln nur als Ausgangspunkte.
Broker-Kapazität vergessen: Stellen Sie sicher, dass Ihre Broker die Gesamtzahl der Partitionen über alle Themen hinweg bewältigen können.
Perfekte Ordnung über Partitionen hinweg erwarten: Denken Sie daran, dass die Ordnung nur innerhalb einer Partition garantiert ist.

Ein vernünftiger Entscheidungsprozess

Für ein neues Thema würde ich normalerweise in dieser Reihenfolge vorgehen:

Definieren Sie die Ordnungsanforderung. Pro Kunde? Pro Konto? Keine strenge Ordnung?
Messen oder schätzen Sie den Spitzenproduzentendurchsatz und die Nachrichtengröße.
Messen Sie eine Konsumenteninstanz mit realistischen nachgelagerten Abhängigkeiten.
Wählen Sie Partitionen basierend auf der benötigten Konsumentenparallelität plus Wachstumsspielraum.
Überprüfen Sie die gesamte Cluster-Auswirkung, nachdem der Replikationsfaktor einbezogen wurde.
Überwachen Sie den Rückstand pro Partition und die Broker-Last nach dem Start.

Die Partitionsanzahl ist kein Schönheitswettbewerb. Ein langweiliges Thema mit acht gut genutzten Partitionen ist besser als ein Thema mit 96 meist untätigen Partitionen, das jedes Rebalance verlangsamt. Wählen Sie die kleinste Anzahl, die Ihnen die Parallelität und den Wachstumsspielraum bietet, die Sie tatsächlich benötigen.