Wer zum ersten Mal mit Apache Kafka arbeitet, stößt schnell auf einen zentralen Begriff: das Topic. Ein Topic fungiert wie ein Ordner, in dem zusammengehörige Events gesammelt werden – und ist das Rückgrat des gesamten Systems.

Diese Beitrage nicht verpassen

4 verwandte Artikel

Fundamentale Einheit: Organisation von Events in Kafka · Ähnlichkeit: Ordner in Dateisystem · Eigenschaft: Unveränderliche Logs · Namen: Einzigartig im Cluster · Zweck: Kategorisierung von Nachrichten

Kurzüberblick

1Bestätigte Fakten
  • Topics sind die grundlegende Organisationseinheit für Nachrichten (Soutier.de)
  • Jede Partition ist eine append-only Log-Sequenz mit Offsets (Confluent Developer)
  • Reihenfolge wird nur pro Partition garantiert, nicht global (Confluent Developer)
2Was unklar ist
  • Performance-Metriken bei spezifischen Partitionzahlen
  • Cloud-spezifische Limits bei AWS MSK
3Zeitleisten-Signal
4Wie es weitergeht
  • Partitionierung bleibt zentral für horizontale Skalierung
  • Compacted Topics gewinnen für Event-Sourcing an Bedeutung

Die folgende Tabelle fasst die wichtigsten Attribute und Grenzwerte von Kafka-Topics zusammen.

Attribut Wert Quelle
Definition Logische Gruppe von Nachrichten Soutier.de
Quelle Apache Kafka offiziell Confluent Developer
Ähnlichkeit Dateisystem-Ordner DataCamp
Eigenschaft Unveränderlich (append-only) Tirsus
Nutzung Event-Streaming DataCamp
Max Partitionen pro Broker 4.000 Dataflow Academy
Max Partitionen pro Cluster 200.000 Dataflow Academy
Max Broker pro Cluster 50 Dataflow Academy
Topic-Typen 2 (regulär, compacted) DataCamp
Reihenfolgegarantie Nur innerhalb Partition Confluent Developer
Partition Assignment Key Hash Modulo Confluent Developer
Consumer Group Max Consumer = Partitionenanzahl Dataflow Academy

Was ist ein Kafka-Topic?

Ein Kafka-Topic ist die zentrale Datenstruktur in Apache Kafka. Laut Soutier.de versteht man darunter eine Sammlung von Nachrichten mit einem eindeutigen Namen, die als Container für Daten beliebiger Art dient – ohne Vorgabe der Datenart. Jedes Topic erhält einen eindeutigen Namen innerhalb des Clusters und fungiert als logische Gruppierung von Events.

Definition aus offiziellen Quellen

Confluent Developer beschreibt Topics als verteilte, partitionierte Log-Dateien. Jede Nachricht wird dabei an das Ende des Logs angehängt – ein sogenanntes Append-Only-Verhalten. Das bedeutet: Nachrichten können gelesen, aber nicht nachträglich verändert oder gelöscht werden. Diese Unveränderlichkeit ist ein Kernprinzip von Kafka.

Vergleich mit Dateisystem

Die anschaulichste Metapher stammt von DataCamp: Ein Topic verhält sich wie ein Ordner in einem Dateisystem. Einzelne Dateien im Ordner entsprechen den Nachrichten (Events), und der Ordnername ist der Topic-Name. Der entscheidende Unterschied: Statt Dateien von Hand zu verwalten, kümmert sich Kafka automatisch um Speicherung, Replikation und Weiterverteilung.

Der Unterschied

Im Gegensatz zu einem Dateisystem-Ordner speichert Kafka Nachrichten mit einem Offset – einer laufenden Nummer, die jede Nachricht eindeutig innerhalb ihrer Partition positioniert. Das ermöglicht präzises Replay: Consumer können an einen bestimmten Offset zurücksetzen.

Die Offset-Mechanik hebt Kafka fundamental von einfachen Dateisystemen ab: Weil jede Nachricht eine fortlaufende Nummer trägt, können Consumer gezielt an jede Stelle des Logs zurückspringen – ein mächtiges Werkzeug für Event-Driven Architekturen.

Was ist der Zweck eines Kafka-Topics?

Der Zweck eines Topics geht über die einfache Speicherung hinaus. entwickler.de beschreibt Apache Kafka als verteilte, partitionierende Plattform für Datenströme. Topics dienen dabei als Grundbaustein für drei zentrale Funktionen:

Organisation von Events

Producer schreiben Nachrichten seriell ans Ende eines Topics, Consumer lesen sie im Stream – so beschreibt es Soutier.de. Diese Asymmetrie – viele Producer, viele Consumer – ist ein Grundmerkmal von Kafka. Ein Topic ermöglicht es, dass verschiedene Anwendungen unabhängig voneinander dieselben Events verarbeiten können, ohne sich zu blockieren.

Historischer Kontext und Replay

Anders als klassische Message Queues behält Kafka Events standardmäßig für einen konfigurierbaren Zeitraum. Laut Tirsus steuern die Parameter retention.ms und retention.bytes die Löschung alter Events. Diese Retention-Policy ist entscheidend für Anwendungsfälle wie Event-Sourcing oder das Debugging historischer Zustände.

Warum das relevant ist

Wer Events für 7 Tage aufbewahrt, kann neue Consumer starten, die vom Anfang des Streams lesen – ein mächtiges Werkzeug für Event-Driven Architekturen, das bei synchronen Message Queues nicht möglich wäre.

Die Retention-Policy macht Kafka zu einem dauerhaften Datenspeicher: Events bleiben replayfähig, solange die Retention-Zeit nicht abläuft – das unterscheidet Kafka fundamental von transienten Message Queues.

Was ist ein Kafka-Topic-Beispiel?

Um das Konzept greifbar zu machen, helfen konkrete Beispiele. Die folgenden Szenarien zeigen, wie Topics in der Praxis eingesetzt werden.

Einfaches Beispiel

Ein einfaches Topic könnte den Namen events tragen. DataCamp zeigt die Erstellung mit folgendem Befehl:

bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 3 --topic events

Dieser Befehl erstellt ein Topic mit 3 Partitionen. Die Anzahl der Partitionen bestimmt die Parallelität: Mehr Partitionen bedeuten mehr Möglichkeiten für parallele Consumer.

Reales Anwendungsbeispiel

In einem E-Commerce-System könnten separate Topics für verschiedene Event-Typen existieren: orders, shipments und payments. Jedes Topic sammelt Events eines bestimmten Geschäftsbereichs. IT-Schulungen.com erklärt, dass jede Partition einen Leader und Follower für Replikation besitzt – das sichert Hochverfügbarkeit.

“Partitionen sind der elementare Mechanismus, über den sowohl Skalierung als auch Replikation funktionieren.”

— Soutier.de

“Jede Topic Partition ist eine Queue, also eine Warteschlange, die nach dem FIFO-Prinzip funktioniert.”

— Tirsus

Was ist Kafka in einfachen Worten?

Apache Kafka ist ein verteilter, partitionierender Service für Datenströme – so definiert es entwickler.de. Das klingt technisch, ist aber im Kern simpel: Kafka ist eine Plattform, die es Anwendungen ermöglicht, Events in Echtzeit zu publizieren und zu konsumieren.

Grundlagen von Apache Kafka

Die Architektur besteht aus Brokern, die Topics speichern, Producer, die Daten schreiben, und Consumer, die sie lesen. Confluent Developer erklärt, dass Partitionierung das zentrale Konzept ist: Sie teilt das Topic-Log in kleinere Logs auf, die auf verschiedene Nodes verteilt werden können. Das ermöglicht horizontale Skalierung.

Rolle der Topics

Ohne Topics gäbe es keine logische Trennung von Datenströmen. The Cattle Crew beschreibt, wie Consumer Groups Partitionen einem Consumer zuweisen – für parallele Verarbeitung. Das Topic fungiert als Namensraum, der Producers und Consumers entkoppelt.

Der Vorteil der Entkopplung

Producer müssen nicht wissen, wer ihre Daten konsumiert. Solange sie an das richtige Topic senden, findet die Verarbeitung unabhängig statt – ideal für Microservices-Architekturen.

Producer und Consumer bleiben entkoppelt, weil das Topic als gemeinsame Schnittstelle dient: Änderungen an der Produzenten- oder Konsumenten-Seite beeinflussen einander nicht, solange das Topic gleich bleibt.

Was ist eine Kafka-Partition?

Die Partition ist die untere Einheit eines Topics. Soutier.de bestätigt: Topics werden in Partitionen unterteilt, wobei die Anzahl bei der Erstellung festgelegt wird und die Skalierbarkeit direkt beeinflusst.

Beziehung zu Topics

Jede Partition ist eine geordnete, append-only Log-Sequenz von Nachrichten, identifiziert durch Offsets. Das erklärt Tirsus: Jede Partition folgt dem FIFO-Prinzip (First In, First Out). Die Reihenfolgegarantie gilt jedoch nur pro Partition – nicht über das gesamte Topic hinweg.

Skalierbarkeit

DataCamp bestätigt, dass Partitionen horizontale Skalierung durch Verteilung auf mehrere Broker ermöglichen. Je mehr Partitionen ein Topic hat, desto mehr Consumer können parallel arbeiten – bis die Anzahl der Partitionen als Obergrenze erreicht ist.

Die Obergrenze

Laut Dataflow Academy liegt das Limit bei 4.000 Partitionen pro Broker und 200.000 pro Cluster. Wer mehr braucht, muss die Architektur ändern – Partitionen lassen sich nachträglich nur erhöhen, nicht senken.

Die Partitionenanzahl ist eine kritische Architekturentscheidung: Zu wenige begrenzen die Parallelität, zu viele erhöhen den Verwaltungsaufwand und können die Broker-Limits überschreiten.

Verwandte Beiträge: “Was kostet ein Bitcoin” · “Https://microsoft.com/link Erklärung”

Die zentrale Rolle von Partitionen und Replikation in einem Kafka-Topic wird im englischen Architektur-Guide praxisnah mit Beispielen aus der Event-Streaming-Welt erläutert.

Häufig gestellte Fragen

Wie viele Partitionen hat ein Kafka-Topic?

Die Anzahl der Partitionen wird bei der Erstellung festgelegt und kann nachträglich erhöht werden. Laut Dataflow Academy sind maximal 4.000 Partitionen pro Broker und 200.000 pro Cluster möglich. Die Anzahl bestimmt die maximale Parallelität für Consumer.

Was ist der Unterschied zwischen Topic und Partition?

Ein Topic ist die logische Gruppierung von Nachrichten; Partitionen sind die physikalischen Untereinheiten. Soutier.de erklärt, dass Partitionen das Topic-Log aufteilen und über mehrere Broker verteilen. Ohne Partitionen gäbe es keine horizontale Skalierung.

Kann ein Kafka-Topic gelöscht werden?

Ja, Topics können gelöscht werden. Standardmäßig löscht Kafka Events basierend auf retention.ms oder retention.bytes automatisch. Tirsus beschreibt diese Retention-Policy, die auch für reguläre Topics gilt.

Wie erstellt man ein Kafka-Topic?

Mit dem kafka-topics.sh-Skript. DataCamp zeigt den Befehl:

bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 3 --topic mein_topic

Auf Windows lautet der Befehl .\bin\windows\kafka-topics.bat --create --topic MyFirstTopic --bootstrap-server localhost:9092 (laut DataCamp).

Was ist ein Kafka-Connector für Topics?

Kafka Connectors sind vorgefertigte Integrationen, die Daten zwischen Kafka und externen Systemen bewegen. Sie schreiben in Topics oder lesen daraus – ohne benutzerdefinierten Code. Die Connector-Konfiguration gibt das Ziel-Topic an.

Was ist der Unterschied zwischen Key-basiertem und Round-Robin-Partitioning?

Dataflow Academy erklärt: Mit Key wird per Hash der Key modulo Partitionenanzahl die Partition bestimmt – gleiche Keys landen in derselben Partition. Ohne Key wählt der Producer Round-Robin oder zufällig.

Was passiert bei Broker-Ausfall mit Partitionen?

Under-replicated Partitionen entstehen. Soutier.de beschreibt, dass der Replikationsfaktor angibt, auf wie viele Broker jede Partition repliziert wird. Fällt ein Broker aus, übernehmen Follower-Partitionen – vorausgesetzt der Replikationsfaktor ist größer als 1.

Für Entwickler, die mit Event-Streaming starten, ist das Verständnis von Topics der Ausgangspunkt. Das Topic-Konzept entkoppelt Producer von Consumern und ermöglicht gleichzeitig horizontale Skalierung durch Partitionen. Wer die Grundlagen beherrscht – Unveränderlichkeit, Offset-basiertes Lesen, FIFO pro Partition – hat die Basis für komplexere Kafka-Patterns gelegt. Die Wahl der Partitionenanzahl, die Konfiguration des Replikationsfaktors und das Design der Topic-Namenskonvention sind Entscheidungen, die spätere Architekturen maßgeblich beeinflussen.