Apache Kafka für Data Engineers: Streaming-Architektur, Partitionen und Interviewfragen

Apache Kafka hat sich als zentrale Infrastrukturkomponente moderner Datenarchitekturen etabliert. Von Echtzeit-Pipelines bei Netflix und Uber bis hin zu Change Data Capture in mittelständischen Unternehmen -- die verteilte Streaming-Plattform verarbeitet täglich Billionen von Events weltweit. Mit der Veröffentlichung von Kafka 4.x und dem vollständigen Wegfall von ZooKeeper zugunsten des KRaft-Modus hat sich die operative Komplexität erheblich reduziert. Für Data Engineers ist fundiertes Kafka-Wissen längst kein optionaler Pluspunkt mehr, sondern eine Grundvoraussetzung für das Design zuverlässiger Streaming-Pipelines. Dieser Artikel behandelt die Kernkonzepte -- Partitionsstrategien, Consumer Groups, Exactly-Once-Semantik, CDC mit Debezium und die neuen Share Groups -- ergänzt durch produktionsnahe Codebeispiele und häufig gestellte Data Engineering Interview-Fragen.

Kafka 4.x KRaft-Cluster aufsetzen

Der erste Schritt in der Arbeit mit Kafka besteht im Aufsetzen eines lokalen Clusters. Seit Version 4.0 entfällt ZooKeeper komplett. Der KRaft-Modus integriert die Konsensbildung direkt in die Kafka-Broker, wodurch ein separater ZooKeeper-Cluster überflüssig wird. Das vereinfacht sowohl Entwicklungs- als auch Produktionsumgebungen erheblich.

Die folgende Docker-Compose-Konfiguration erstellt einen Kafka-4.2-Cluster mit drei Knoten im KRaft-Modus. Jeder Knoten übernimmt gleichzeitig die Rollen Broker und Controller -- ideal für Entwicklungs- und Testumgebungen:

# docker-compose.yml — Kafka 4.x KRaft cluster (no ZooKeeper)
services:
  kafka-1:
    image: apache/kafka:4.2.0
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: broker,controller
      KAFKA_CONTROLLER_QUORUM_VOTERS: 1@kafka-1:9093,2@kafka-2:9093,3@kafka-3:9093
      KAFKA_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093
      KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
      KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER
      KAFKA_LOG_DIRS: /var/lib/kafka/data
      KAFKA_NUM_PARTITIONS: 6
      KAFKA_DEFAULT_REPLICATION_FACTOR: 3
      KAFKA_MIN_INSYNC_REPLICAS: 2
    ports:
      - "9092:9092"

Die Variable KAFKA_CONTROLLER_QUORUM_VOTERS definiert die am Raft-Quorum teilnehmenden Knoten. Mit einem Replikationsfaktor von 3 und mindestens 2 synchronen Replicas (MIN_INSYNC_REPLICAS) toleriert der Cluster den Ausfall eines Knotens ohne Datenverlust und ohne Unterbrechung des Betriebs. In Produktionsumgebungen empfiehlt es sich, die Controller- und Broker-Rollen auf dedizierte Knoten aufzuteilen, um die Metadatenverwaltung von der Nachrichtenverarbeitung zu entkoppeln.

Partitionsstrategien: Das Fundament der Kafka-Parallelität

Partitionen bilden den grundlegenden Parallelitätsmechanismus in Kafka. Jedes Topic wird in eine oder mehrere Partitionen unterteilt, wobei jede Partition ein geordnetes, unveränderliches Log darstellt. Nachrichten innerhalb einer Partition behalten eine streng sequentielle Reihenfolge bei -- zwischen verschiedenen Partitionen existiert jedoch keine globale Ordnungsgarantie.

Die Wahl des Partition Keys bestimmt, welche Nachrichten in welcher Partition landen. Diese Entscheidung beeinflusst unmittelbar drei kritische Aspekte: die Verarbeitungsreihenfolge, die Lastverteilung und die Skalierbarkeit der Consumer.

# partition_strategy.py — Choosing the right partition key
from confluent_kafka import Producer
import json

def create_producer():
    return Producer({
        'bootstrap.servers': 'kafka-1:9092',
        'acks': 'all',
        'enable.idempotence': True,
        'max.in.flight.requests.per.connection': 5
    })

def publish_order_event(producer, event):
    # Key by customer_id: all events for one customer stay ordered
    key = str(event['customer_id']).encode('utf-8')
    value = json.dumps(event).encode('utf-8')
    producer.produce(
        topic='order-events',
        key=key,
        value=value,
        headers=[('source', b'order-service'), ('version', b'2')]
    )
    producer.flush()

def publish_clickstream(producer, event):
    # Key by session_id: ordering within a session matters
    # NOT by user_id — one user may have multiple sessions
    key = str(event['session_id']).encode('utf-8')
    value = json.dumps(event).encode('utf-8')
    producer.produce(
        topic='clickstream',
        key=key,
        value=value
    )

Im Beispiel werden Bestellereignisse nach customer_id partitioniert. Sämtliche Events eines Kunden landen in derselben Partition und werden dadurch in chronologischer Reihenfolge verarbeitet. Für Clickstream-Daten erfolgt die Partitionierung nach session_id statt nach user_id, da ein Nutzer mehrere gleichzeitige Sessions haben kann. So bleibt die Reihenfolge innerhalb einer Session erhalten, während die Last auf mehrere Partitionen verteilt wird.

Die Konfiguration enable.idempotence: True in Kombination mit acks: all aktiviert die idempotente Produktion. Damit werden Duplikate bei Netzwerk-Retries zuverlässig verhindert. Der Parameter max.in.flight.requests.per.connection: 5 erlaubt bis zu fünf parallele Anfragen und bewahrt gleichzeitig die Nachrichtenreihenfolge -- eine Verbesserung, die seit Kafka 2.0 verfügbar ist.

Wie viele Partitionen konfigurieren?

Die Partitionsanzahl eines Topics bestimmt den maximalen Consumer-Parallelitätsgrad. Bei einem Topic mit 12 Partitionen können maximal 12 Consumer einer Consumer Group gleichzeitig verarbeiten. Ein 13. Consumer bliebe untätig. Als Ausgangspunkt dient die Formel: Zieldurchsatz (in MB/s) geteilt durch den maximalen Durchsatz eines einzelnen Consumers. Zu beachten ist, dass eine nachträgliche Erhöhung der Partitionsanzahl die Key-Zuordnung neu verteilt und temporär die Ordnungsgarantien bricht.

Consumer Groups und Offset-Management

Consumer Groups ermöglichen die parallele Verarbeitung eines Topics durch mehrere Instanzen eines Services. Kafka weist jede Partition exklusiv einem einzigen Consumer innerhalb der Gruppe zu, sodass keine Nachricht doppelt verarbeitet wird.

Das Offset-Management -- die Leseposition innerhalb jeder Partition -- ist der technisch kritischste Aspekt der Consumer-Konfiguration. Im Standardmodus (enable.auto.commit = True) werden Offsets periodisch committed, was bei Abstürzen zu Duplikaten oder Nachrichtenverlusten führen kann. Für zuverlässige Datenpipelines ist manuelles Offset-Commit nach erfolgreicher Verarbeitung unverzichtbar.

# consumer_pipeline.py — Consumer group with manual offset management
from confluent_kafka import Consumer, KafkaError
import json

def create_consumer(group_id: str):
    return Consumer({
        'bootstrap.servers': 'kafka-1:9092',
        'group.id': group_id,
        'auto.offset.reset': 'earliest',
        'enable.auto.commit': False,  # Manual commit for at-least-once
        'max.poll.interval.ms': 300000,
        'session.timeout.ms': 45000,
        'isolation.level': 'read_committed'  # Only read committed transactions
    })

def process_batch(consumer: Consumer, batch_size: int = 500):
    """Process records in micro-batches for throughput."""
    consumer.subscribe(['order-events'])
    buffer = []

    while True:
        msg = consumer.poll(timeout=1.0)
        if msg is None:
            continue
        if msg.error():
            if msg.error().code() == KafkaError._PARTITION_EOF:
                continue
            raise Exception(msg.error())

        record = json.loads(msg.value().decode('utf-8'))
        buffer.append(record)

        if len(buffer) >= batch_size:
            # Process the full batch (write to warehouse, etc.)
            write_to_warehouse(buffer)
            # Commit AFTER successful processing
            consumer.commit(asynchronous=False)
            buffer.clear()

def write_to_warehouse(records: list):
    # Insert batch into data warehouse (BigQuery, Snowflake, etc.)
    pass

Der Parameter isolation.level: read_committed verhindert, dass der Consumer Nachrichten aus abgebrochenen Transaktionen liest. In Kombination mit synchronem manuellen Commit ergibt sich eine At-Least-Once-Semantik: Jede Nachricht wird mindestens einmal verarbeitet, auch bei einem Neustart des Consumers. Die Micro-Batch-Größe (hier 500) stellt einen Kompromiss zwischen Latenz und Durchsatz dar -- größere Batches erhöhen den Throughput, verlängern aber die Verarbeitungszeit pro Batch.

Die Konfiguration max.poll.interval.ms: 300000 (5 Minuten) definiert die maximale Zeitspanne zwischen zwei poll()-Aufrufen. Dauert die Verarbeitung eines Batches länger, betrachtet Kafka den Consumer als ausgefallen und löst ein Rebalancing aus. Bei langsamen Warehouse-Schreiboperationen muss dieser Wert entsprechend angepasst werden.

Change Data Capture mit Debezium und Kafka Connect

Change Data Capture (CDC) gehört zu den wirkungsvollsten Kafka-Anwendungsfällen im Data Engineering. Anstatt die Quelldatenbank periodisch abzufragen (Polling), liest Debezium das Transaktionslog (WAL bei PostgreSQL, Binlog bei MySQL) und publiziert jede Änderung als Event in einem Kafka Topic. Dieser Ansatz bietet grundlegende Vorteile gegenüber herkömmlichem ETL/ELT Pipeline Patterns: nahezu keine Latenz, keine zusätzliche Last auf der Quelldatenbank und die vollständige Erfassung aller Operationen einschließlich Löschungen.

{
  "name": "postgres-cdc-source",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    "database.hostname": "postgres-primary",
    "database.port": "5432",
    "database.user": "replication_user",
    "database.dbname": "production",
    "topic.prefix": "cdc",
    "table.include.list": "public.orders,public.customers,public.products",
    "slot.name": "debezium_slot",
    "plugin.name": "pgoutput",
    "publication.name": "dbz_publication",
    "snapshot.mode": "initial",
    "transforms": "route",
    "transforms.route.type": "org.apache.kafka.connect.transforms.RegexRouter",
    "transforms.route.regex": "cdc\\.public\\.(.*)",
    "transforms.route.replacement": "warehouse.$1"
  }
}

Diese Debezium-Konfiguration erfasst Änderungen an den Tabellen orders, customers und products einer PostgreSQL-Produktionsdatenbank. Der snapshot.mode: initial führt zunächst eine vollständige Momentaufnahme des aktuellen Tabellenbestands durch, bevor in den Streaming-Modus für inkrementelle Änderungen gewechselt wird. Die RegexRouter-Transformation benennt die Ausgabe-Topics um (z. B. wird cdc.public.orders zu warehouse.orders), was das Routing zum Data Warehouse vereinfacht.

Der Replication Slot (debezium_slot) stellt sicher, dass PostgreSQL keine WAL-Segmente entfernt, die noch nicht konsumiert wurden. Die Überwachung der Slot-Größe ist kritisch: Wenn der Connector für Stunden gestoppt wird, kann der Slot Gigabytes an WAL ansammeln und den Speicherplatz des Datenbankservers gefährden.

Exactly-Once-Semantik: Transaktionale Kafka-Pipelines

Die Exactly-Once-Semantik stellt das anspruchsvollste Zustellungsmodell in Streaming-Pipelines dar. Ohne sie riskiert eine Pipeline entweder Duplikate (At-Least-Once) oder Nachrichtenverluste (At-Most-Once). Kafka implementiert Exactly-Once durch transaktionale Producer in Kombination mit der read_committed-Isolation auf Consumer-Seite.

Das Consume-Transform-Produce-Pattern veranschaulicht diesen Mechanismus: Der Consumer liest eine Nachricht, transformiert sie, produziert das Ergebnis in ein Ausgabe-Topic und committed den Offset der Quellnachricht -- alles innerhalb einer einzigen atomaren Transaktion.

# exactly_once_pipeline.py — Transactional consume-transform-produce
from confluent_kafka import Consumer, Producer
import json

def transactional_pipeline():
    consumer = Consumer({
        'bootstrap.servers': 'kafka-1:9092',
        'group.id': 'etl-transformer',
        'enable.auto.commit': False,
        'isolation.level': 'read_committed'
    })

    producer = Producer({
        'bootstrap.servers': 'kafka-1:9092',
        'transactional.id': 'etl-transformer-001',
        'acks': 'all',
        'enable.idempotence': True
    })

    producer.init_transactions()
    consumer.subscribe(['raw-events'])

    while True:
        msg = consumer.poll(1.0)
        if msg is None or msg.error():
            continue

        # Begin atomic transaction
        producer.begin_transaction()
        try:
            raw = json.loads(msg.value())
            enriched = transform(raw)

            # Write transformed record to output topic
            producer.produce(
                'enriched-events',
                key=msg.key(),
                value=json.dumps(enriched).encode('utf-8')
            )

            # Commit consumer offset within the same transaction
            producer.send_offsets_to_transaction(
                consumer.position(consumer.assignment()),
                consumer.consumer_group_metadata()
            )
            producer.commit_transaction()
        except Exception:
            producer.abort_transaction()

def transform(record: dict) -> dict:
    # Apply business logic transformations
    record['processed_at'] = '2026-04-20T00:00:00Z'
    record['pipeline_version'] = '2.1'
    return record

Die transactional.id identifiziert diese Pipeline-Instanz eindeutig. Bei einem Neustart nutzt Kafka diese ID, um alle unvollständigen Transaktionen der vorherigen Instanz abzubrechen und so Duplikate zu verhindern. Der Aufruf von send_offsets_to_transaction verknüpft den Consumer-Offset-Commit mit derselben Transaktion wie die Produktion der angereicherten Nachricht: Entweder werden beide Operationen gemeinsam committed oder keine von beiden.

Share Groups: Das neue Konsummodell in Kafka 4.x (KIP-932)

Kafka 4.0 führt mit den Share Groups eine grundlegende Erweiterung des Konsummodells ein. Im Gegensatz zu klassischen Consumer Groups, bei denen jede Partition exklusiv einem einzigen Consumer zugewiesen wird, erlauben Share Groups mehreren Consumern das gleichzeitige Lesen derselben Partition mit einem Acknowledgement-Mechanismus pro Nachricht.

Dieses Modell orientiert sich an traditionellen Message Queues (RabbitMQ, SQS) und bewahrt gleichzeitig die Vorteile der Kafka-Infrastruktur. Es eignet sich besonders für Workloads, bei denen die Verarbeitungsreihenfolge unkritisch ist, die gleichmäßige Lastverteilung zwischen Consumern jedoch essenziell.

| Feature | Consumer Groups | Share Groups | |---|---|---| | Partition assignment | Exclusive (one consumer per partition) | Shared (multiple consumers per partition) | | Ordering guarantee | Per-partition ordering preserved | No ordering guarantee | | Use case | Ordered event streams | Task distribution, work queues | | Acknowledgement | Offset-based (commit position) | Per-record (acknowledge individually) | | Max parallelism | Limited by partition count | Limited by consumer count |

Share Groups ersetzen die klassischen Consumer Groups nicht. Beide Modelle koexistieren und adressieren unterschiedliche Anforderungen. Für ETL-Pipelines, bei denen die Reihenfolge der Events entscheidend ist, bleiben Consumer Groups die richtige Wahl. Für die Verteilung von Berechnungsaufgaben (Reportgenerierung, Benachrichtigungsversand, ML-Inference) bieten Share Groups eine überlegene Skalierbarkeit ohne die Beschränkung durch die Partitionsanzahl.

Interviewfragen zu Apache Kafka für Data Engineers

Technische Vorstellungsgespräche für Data-Engineering-Positionen enthalten regelmäßig vertiefte Fragen zu Kafka. Die folgenden Fragen decken die am häufigsten geprüften Themengebiete ab. Weitere Übungsfragen finden sich in der Sammlung zu Data Engineering Interview-Fragen.

Wie garantiert Kafka die Nachrichtenreihenfolge? Die Reihenfolge ist ausschließlich innerhalb einer Partition garantiert. Alle Nachrichten mit demselben Partition Key landen in derselben Partition und werden in Produktionsreihenfolge verarbeitet. Zwischen verschiedenen Partitionen existiert keine Ordnungsgarantie. Für eine streng globale Reihenfolge wäre ein Topic mit nur einer Partition erforderlich, was jedoch jegliche Parallelität eliminiert.

Was unterscheidet At-Least-Once, At-Most-Once und Exactly-Once? At-Most-Once: Der Consumer committed den Offset vor der Verarbeitung. Bei einem Fehler geht die Nachricht verloren. At-Least-Once: Der Consumer committed nach der Verarbeitung. Bei einem Fehler und Neustart wird die Nachricht erneut verarbeitet. Exactly-Once: Die Kombination aus transaktionalen Producern, Idempotenz und read_committed-Isolation stellt sicher, dass jede Nachricht exakt einmal verarbeitet wird -- auch bei Ausfällen.

Wie funktioniert das Rebalancing in einer Consumer Group? Wenn ein Consumer einer Gruppe beitritt oder sie verlässt, löst Kafka ein Rebalancing aus. Dabei werden alle Partitionen temporär freigegeben und neu zugewiesen. Das Rebalancing unterbricht die Verarbeitung kurzzeitig. Der Cooperative Sticky Assignor minimiert die Auswirkungen, indem nur die tatsächlich betroffenen Partitionen neu zugewiesen werden.

Was passiert beim Ausfall eines Brokers? Wenn der ausgefallene Broker Partition-Leader hostet, wählt Kafka neue Leader aus den synchronen Replicas (ISR). Producer und Consumer werden automatisch zu den neuen Leadern umgeleitet. Falls min.insync.replicas nach dem Ausfall nicht mehr erfüllt ist, schlagen Produktionen mit acks=all fehl, bis genügend Replicas wieder synchronisiert sind.

Wann ist Kafka Streams gegenüber Apache Flink vorzuziehen? Kafka Streams ist eine in die Anwendung eingebettete Bibliothek ohne separaten Verarbeitungscluster. Sie eignet sich für Transformationen mittlerer Komplexität mit Durchsätzen bis zu einigen hunderttausend Nachrichten pro Sekunde. Flink ist eine eigenständige, verteilte Verarbeitungsengine für komplexe Operationen (erweitertes Windowing, Complex Event Processing, Multi-Stream-Joins) und extreme Volumina. Die Entscheidung hängt von der Verarbeitungskomplexität und der Bereitschaft ab, einen zusätzlichen Cluster zu betreiben.

Wie wird die Schema-Evolution in Kafka gehandhabt? Die Schema Registry (Confluent oder Apicurio) speichert und versioniert Avro-, Protobuf- oder JSON-Schema-Definitionen. Producer registrieren das Schema vor der Produktion, Consumer validieren die Kompatibilität beim Konsum. Kompatibilitätsrichtlinien (BACKWARD, FORWARD, FULL) verhindern, dass destruktive Schema-Änderungen bestehende Consumer beeinträchtigen. Vertiefende Informationen zur Datenstrukturierung bietet der Artikel zur Datenmodellierung.

Monitoring und Observability eines Kafka-Clusters

Ein Kafka-Cluster in Produktion erfordert die aktive Überwachung mehrerer Schlüsselmetriken. Ohne adäquates Monitoring entstehen schleichende Probleme: wachsender Consumer Lag, unterreplizierte Partitionen oder sich füllende Festplatten ohne rechtzeitige Warnung.

Die wichtigsten zu überwachenden Metriken umfassen:

• Consumer Lag: Die Differenz zwischen dem zuletzt produzierten und dem zuletzt committeten Offset. Ein stetig wachsender Lag zeigt an, dass der Consumer nicht mit dem Produktionstempo Schritt hält.
• Under-Replicated Partitions: Die Anzahl der Partitionen, deren Replicas nicht mit dem Leader synchronisiert sind. Ein Wert größer als null über mehrere Minuten signalisiert Netzwerk- oder Broker-Probleme.
• Request Latency (Produce/Fetch): Die Antwortzeit für Produktions- und Konsumationsanfragen. Ein plötzlicher Anstieg deutet auf Festplatten- oder Netzwerksättigung hin.
• Disk Usage: Kafka speichert Nachrichten auf der Festplatte. Die Aufbewahrungsrichtlinie (nach Dauer oder Größe) muss kalibriert werden, um eine Sättigung zu vermeiden.

Burrow, entwickelt von LinkedIn, bleibt das Referenztool für Consumer-Lag-Monitoring. Für eine umfassendere Sicht bietet die Kombination aus Prometheus und Grafana mit Kafka-JMX-Metriken konfigurierbare Dashboards und Alerting.

Fazit

Apache Kafka bildet das Rückgrat moderner Streaming-Architekturen im Data Engineering. Die zentralen Erkenntnisse im Überblick:

• Der KRaft-Modus (Kafka 4.x) eliminiert ZooKeeper und vereinfacht Deployment sowie Administration erheblich
• Die Wahl des Partition Keys bestimmt Verarbeitungsreihenfolge, Lastverteilung und Skalierbarkeit -- ein schlecht gewählter Key führt zu Hot Partitions, die die Gesamtperformance degradieren
• Manuelles Offset-Commit mit enable.auto.commit: False und read_committed-Isolation bildet das Fundament zuverlässiger At-Least-Once-Pipelines
• CDC über Debezium erfasst Änderungen in Echtzeit aus dem WAL der Quelldatenbank, ohne deren Performance zu beeinträchtigen
• Kafka-Transaktionen (Exactly-Once) gewährleisten die Atomarität des Consume-Transform-Produce-Patterns, wobei der Overhead durch Batch-Größen kalibriert werden sollte
• Share Groups (KIP-932), eingeführt in Kafka 4.0, eröffnen ein neues Konsummodell für Workloads ohne Ordnungsanforderung
• Das Monitoring von Consumer Lag, unterreplizierten Partitionen und Request-Latenz ist unverzichtbar, um schleichende Produktionsprobleme frühzeitig zu erkennen
• Die Konvergenz von Kafka mit offenen Tabellenformaten (Iceberg, Delta Lake) definiert die Referenzarchitektur moderner Datenplattformen