Apache Kafka — Real-Time Data Streaming in der Praxis

Ihr Batch-ETL läuft einmal täglich und Ihr Dashboard zeigt die Daten von gestern? Im Jahr 2020 ist das für viele Unternehmen zu langsam. Apache Kafka ermöglicht die Verarbeitung von Millionen Ereignissen pro Sekunde in Echtzeit. Schauen wir uns an, wie und wann man sie einsetzt.

Was ist Kafka und warum brauchen Sie sie¶

Apache Kafka ist eine verteilte Streaming-Plattform. Ursprünglich bei LinkedIn für die Verarbeitung von Activity Logs erstellt, ist sie heute der De-facto-Standard für Event-Driven-Architekturen. Kafka ist keine Message Queue (auch wenn sie oft so genutzt wird) — sie ist ein verteiltes Commit Log mit Ordering-Garantien, Persistenz und Replay-Fähigkeit.

Schlüsseleigenschaften, die sie von RabbitMQ oder ActiveMQ unterscheiden:

• Retention: Nachrichten bleiben im Topic auch nach dem Lesen — Consumer Groups können unabhängig lesen, jederzeit Replay
• Horizontale Skalierung: Partitioning ermöglicht parallele Verarbeitung — Broker hinzufügen, Throughput erhöhen
• Ordering-Garantie: Nachrichten innerhalb einer einzelnen Partition sind strikt geordnet
• Throughput: Millionen Nachrichten pro Sekunde auf Standard-Hardware — LinkedIn verarbeitet 7 Billionen Nachrichten pro Tag

Architektur: Broker, Topics und Partitions¶

Ein Kafka-Cluster besteht aus Brokern (Servern). Daten werden in Topics (logische Kanäle) organisiert und jedes Topic wird in Partitions (physische Logs) unterteilt. Der Replikationsfaktor bestimmt, wie viele Kopien jeder Partition existieren — typischerweise 3 für die Produktion.

Für unseren Einsatz im Bankensektor wählten wir 5 Broker, Replikationsfaktor 3 und Partitionierung nach Kunden-ID. Das garantiert, dass alle Ereignisse eines einzelnen Kunden in einer Partition liegen — striktes Ordering ohne Kompromisse.

Kafka Connect — Integration ohne Code¶

Kafka Connect ist ein Framework zum Streaming von Daten zwischen Kafka und externen Systemen. Source Connectors lesen Daten in Kafka, Sink Connectors schreiben sie heraus. Für die meisten Datenbanken gibt es fertige Connectors:

• Debezium: CDC (Change Data Capture) für PostgreSQL, MySQL, SQL Server, Oracle — erfasst jede Datenbankänderung als Event
• JDBC Source/Sink: Polling-basiert, einfacher aber ohne Echtzeit-Garantien
• Elasticsearch Sink: Automatische Indexierung in Elasticsearch für Volltextsuche
• S3 Sink: Archivierung in S3 für Langzeitspeicherung und Analytics

In einem Projekt für eine Versicherungsgesellschaft nutzten wir Debezium CDC, um Änderungen in einer Oracle-Datenbank von Versicherungspolicen zu erfassen und in einen Data Lake auf Azure Blob Storage zu streamen. Von täglichem Batch-ETL zu Echtzeit — Latenz unter 5 Sekunden.

Schema Registry — Evolution ohne Chaos¶

Ohne Schema-Management ist Kafka nur eine glorifizierte Byte-Pipe. Confluent Schema Registry speichert Avro/JSON/Protobuf-Schemas und erzwingt Kompatibilität. Eine abwärtskompatible Änderung (Hinzufügen eines optionalen Feldes) geht durch; eine Breaking Change (Entfernen eines Pflichtfeldes) wird abgelehnt.

In der Praxis bedeutet das, dass das Producer-Team ein neues Feld zu einem Event hinzufügen kann, ohne sich mit allen Consumer-Teams abzustimmen. Alte Consumer ignorieren es einfach, neue können es nutzen. Schema-Evolution statt Big-Bang-Migration.

Kafka Streams vs. Apache Flink¶

Für Stream Processing im Jahr 2020 haben Sie zwei Hauptoptionen:

• Kafka Streams: Eine Java-Bibliothek, kein zusätzlicher Cluster nötig, ideal für einfachere Transformationen, Filterung, Aggregationen. Läuft als reguläre Java-Anwendung
• Apache Flink: Eine vollwertige Streaming Engine, eigener Cluster, deutlich leistungsfähiger für komplexes Event Processing, Windowing, Pattern Detection

Unsere Empfehlung: Beginnen Sie mit Kafka Streams. Wenn Sie Complex Event Processing (CEP), Sliding Windows über Millionen Events oder Exactly-Once Processing über Systeme hinweg benötigen — wechseln Sie zu Flink.

Produktionsbetrieb — Lessons Learned¶

Nach zwei Jahren Betrieb von Kafka-Clustern in der Produktion haben wir einige Erkenntnisse:

• Monitoring ist kritisch: Kafka JMX-Metriken in Prometheus + Grafana. Consumer Lag, unter-replizierte Partitions, Request-Latenz überwachen
• Partition Count nicht zu hoch setzen: Mehr Partitions = mehr File Handles, langsamere Leader Election. 12 Partitions pro Topic ist ein guter Ausgangspunkt
• Retention vorausplanen: 7 Tage Standard-Retention × 100 MB/s = 60 TB Speicher. Entsprechend planen
• ZooKeeper ist ein Single Point of Failure: Dediziertes ZooKeeper-Ensemble, nicht auf denselben Nodes wie Broker (2020 brauchen Sie noch ZK; KRaft kommt später)
• Consumer Group Rebalancing: Deployment neuer Consumer kann einen Storm verursachen — Cooperative Rebalancing nutzen (Kafka 2.4+)

Managed vs. Self-Hosted¶

Confluent Cloud, AWS MSK, Azure Event Hubs (Kafka-kompatibel) — Managed Services reduzieren den Betriebsaufwand, aber zu einem Preis. Für einen Kunden mit 50 GB/Tag ist Confluent Cloud deutlich teurer als Self-Hosted. Für ein Startup mit einem DevOps-Ingenieur ist ein Managed Service die klare Wahl.

Kafka als Rückgrat der Event-Driven-Architektur¶

Apache Kafka ist 2020 keine experimentelle Technologie — sie ist ein produktionserprobtes Fundament für Real-Time-Datenplattformen. Der Schlüssel zum Erfolg ist nicht Kafka selbst, sondern durchdachtes Event-Design, Schema-Management und Monitoring. Ohne sie ist es nur schnelles Chaos.