Von Andrew Tan
Change Data Capture ist die unsichtbare Schicht, die Echtzeitanalysen und ereignisgesteuerte Systeme ermöglicht — aber die meisten Teams beschäftigen sich erst nach ihrem ersten Produktionsvorfall damit.
Die unsichtbare Schicht, von der alles abhängt
Echtzeit-Dashboards. Ereignisgesteuerte Microservices. Immer aktuelle Data Lakes. Hinter jeder dieser modernen Datenarchitekturen steckt eine Komponente, über die die meisten Teams nicht lange nachdenken: Change Data Capture.
Die Aufgabe von CDC ist einfach genug — die Transaktionslogs der Datenbank überwachen und bei jeder Datenänderung ein Ereignis auslösen. Neue Bestellung? Ereignis. Statusänderung? Ereignis. Kundenlöschung? Ereignis. Das Konzept ist elegant, und wenn es funktioniert, funktioniert es einfach.
Aber es gibt ein Problem. CDC ist die Infrastruktur moderner Datenarchitekturen: unsichtbar, solange sie funktioniert, katastrophal, wenn sie ausfällt, und irgendwie immer ein Nachgedanke in Architektur-Reviews. Teams verbringen Wochen damit, Kafka-Topologien und Spark-Konfigurationen zu diskutieren, und setzen dann einen CDC-Connector mit den Standardeinstellungen ein.
Sechs Monate später klingelt das Telefon. Das Dashboard ist sechs Stunden im Rückstand. Die Bestandssynchronisation zeigt die Daten von gestern. Der CEO fragt, warum Kunden Produkte kaufen können, die es gar nicht gibt. Und niemand kann herausfinden warum — denn laut Monitoring-Dashboard ist der CDC-Connector "gesund".
Dieses Muster spielt sich in der Branche mit bemerkenswerter Konsequenz ab. Das Problem ist nicht, dass CDC grundsätzlich unzuverlässig wäre. Es liegt darin, dass die Lücke zwischen dem, was Teams annehmen, dass es tut, und dem, was es tatsächlich tut, groß genug ist, um Produktionsvorfälle zu verbergen, bis sie zu Geschäftsproblemen werden.
Was CDC tatsächlich tut (und was Teams annehmen, dass es tut)
Im Kern überwacht Change Data Capture das Transaktionslog Ihrer Datenbank und löst bei jeder Datenänderung ein Ereignis aus. Eine Zeile einfügen? Ereignis. Ein Feld aktualisieren? Ereignis. Einen Datensatz löschen? Ereignis. Das Konzept ist wunderschön einfach.
Aber diese Einfachheit ist trügerisch. Hier ist, was CDC tatsächlich erfasst im Vergleich zu dem, was Teams annehmen, dass es erfasst:
| Was Teams annehmen | Was tatsächlich passiert |
|---|---|
| "Jede Änderung wird sofort erfasst" | Es gibt Latenz. Manchmal Millisekunden, manchmal Sekunden, manchmal länger, wenn der Connector im Rückstand ist. |
| "Die Ereignisse liegen in derselben Reihenfolge wie die Transaktionen vor" | Nicht unbedingt. Parallele Replikation, Commit-Reihenfolge und eventuelle Konsistenz können die Sequenzen durcheinanderbringen. |
| "Schemaänderungen werden elegant gehandhabt" | Eine Spalte hinzufügen? Kein Problem. Eine Spalte umbenennen? Eine Spalte löschen? Einen Typ ändern? Ihre CDC-Pipeline erfordert möglicherweise manuellen Eingriff. |
| "Es ist nur ein Log-Tail, was kann schon schiefgehen?" | Connector-Abstürze, Erschöpfung der Replikationsslot-Ressourcen, Speicherplatzprobleme auf der Quelldatenbank, Netzwerkpartitionen... |
Die Lücke zwischen Annahme und Realität ist der Nährboden für Vorfälle.
Die drei Ausfallmodi, über die niemand spricht
Nachdem ich ein Dutzend CDC-Implementierungen scheitern sah, habe ich drei Fehlermuster bemerkt, die in Tutorials und Vendor-Demos nicht genug Aufmerksamkeit bekommen.
1. Die Schema-Drift-Falle
Ihr Anwendungsteam fügt der orders-Tabelle eine neue Spalte hinzu. Es ist eine harmlose Änderung — ein nullable delivery_notes-Feld. Sie deployen am Dienstag. Bis Donnerstag hat Ihr Data Warehouse unvollständige Datensätze, weil der CDC-Connector immer noch das alte Schema verwendet und das neue Feld stillschweigend verwirft.
Das Schlimmste? Der Connector schlägt nicht fehl. Er produziert einfach Ereignisse, die technisch gültig, aber praktisch falsch sind. Ihre Datenqualitätsmonitore entdecken es nicht, weil der Schema-Validator glaubt, dass alles in Ordnung ist. Sie entdecken die Lücke erst, wenn jemand fragt, warum der Lieferscheinbericht für die halbe Woche leer ist.
2. Die Replikationsslot-Bombe
PostgreSQL-Nutzer, dies ist für Sie. CDC-Connectors verwenden "Replikationsslots", um zu verfolgen, welche WAL (Write-Ahead Log)-Einträge sie bereits verarbeitet haben. Wenn Ihr Connector ausfällt — oder sogar nur deutlich langsamer wird — halten diese Slots die Log-Einträge fest. Die Datenbank kann diesen Speicherplatz nicht freigeben.
Ich habe Teams erlebt, die zu Produktionsdatenbanken mit 95 % Speicherkapazität aufwachten, weil ein wackeliger CDC-Connector die Replikationsslots als Geisel hielt. Die Lösung ist ein manueller Bereinigungsjob, der um 2 Uhr nachts furchteinflößend auszuführen ist. Die Prävention? Monitoring und Alerting, die die meisten Teams erst nach dem ersten Vorfall einrichten.
3. Das Consumer-Coupling-Problem
CDC erzeugt eine Flut von Ereignissen. Jeder Microservice, jeder Analyse-Job und jede Data-Warehouse-Synchronisation, die sich für Datenbankänderungen interessiert, zapft diesen Stream an. Es ist elegant und entkoppelt — bis es das nicht mehr ist.
Was passiert, wenn ein langsamer Consumer nicht mithalten kann? Backpressure breitet sich aus. Der CDC-Connector puffert, verwirft dann Ereignisse und stürzt ab. Oder schlimmer: Er läuft weiter, fällt aber zurück, und Ihre "Echtzeit"-Pipeline hat eine 20-minütige Verzögerung, die niemand bemerkt, weil das Metrics-Dashboard "Connector gesund" anzeigt.
Die Lösung ist meist eine Form der Pufferung (Kafka, Kinesis, eine Message Queue) zwischen der CDC-Quelle und den Consumern. Aber damit haben Sie Latenz hinzugefügt und ein weiteres Infrastrukturstück zu verwalten. Die einfache Infrastruktur ist zu einem komplexen Subsystem geworden.
Dimensionierung für die Realität, nicht für die Hoffnung
Hier ist ein fiktives Gespräch:
Ich: "Wie viele Transaktionen pro Sekunde muss Ihr CDC verarbeiten können?"
Sie: "Oh, vielleicht ein paar Hundert zu Spitzenzeiten."
Ich: "Und wie groß ist Ihre größte Tabelle?"
Sie: "Etwa fünfzig Millionen Zeilen."
Ich: "Was passiert, wenn Sie auf dieser Tabelle ein Bulk-Update ausführen?"
Sie: "... Das machen wir manchmal."
CDC-Connectors werden nicht für Ihr durchschnittliches Transaktionsvolumen dimensioniert. Sie werden für Ihr worst-case-Transaktionsvolumen dimensioniert. Dieser vierteljährliche Datenbereinigungsjob, der zehn Millionen Zeilen berührt? Der generiert zehn Millionen CDC-Ereignisse in einem Stoß. Wenn Ihr Connector diesen Spitzenwert nicht verkraften kann, erhalten Sie Verzögerungen, Backpressure oder verworfene Ereignisse.
Die Teams, die das gut machen, planen von Tag eins an Stoßbelastungen ein. Sie richten Monitoring für Replikationsverzögerungen ein, nicht nur für die Connector-Gesundheit. Sie testen ihre Ausfallmodi: Was passiert, wenn der Connector mitten in einem Bulk-Update neu startet? Was passiert, wenn das Ziel eine Stunde lang nicht erreichbar ist?
Design-Entscheidungen, die CDC beherrschbar machen
CDC muss keine tickende Zeitbombe sein. Hier sind die Muster, die ich in Produktion erfolgreich gesehen habe:
CDC-Infrastruktur von Analyse-Infrastruktur trennen
Führen Sie Ihren CDC-Connector nicht im selben Cluster wie Ihre Spark-Jobs oder BI-Queries aus. Wenn das Analyseteam einen schweren Join ausführt, der das Netzwerk auslastet, sollten Ihre CDC-Ereignisse nicht darunter leiden. Geben Sie CDC eine eigene Spur.
Idempotente Consumer sind nicht verhandelbar
CDC-Ereignisse können dupliziert werden. Connectors starten neu, Netzwerkpartitionen passieren, At-least-once-Delivery ist der Standard. Wenn Ihr Downstream-Consumer nicht mit "diese Bestellaktualisierung zweimal verarbeiten" umgehen kann, werden Sie Datenkorruption erleben. Bauen Sie Idempotenz von Anfang an ein.
Schema-Register bewahren den Verstand
Verwenden Sie ein Schema-Register (Confluent Schema Registry, AWS Glue oder ähnliches), um Änderungen an Ihren Event-Schemas zu verfolgen. Wenn das Anwendungsteam eine Tabelle ändert, fließt die Schemaänderung durch das Register, und Ihre Consumer können sich programmatisch anpassen, anstatt stillschweigend zu brechen.
Überwachen Sie das, was zählt
"Connector läuft" ist die falsche Metrik. Überwachen Sie:
- Replikationsverzögerung (wie weit hinkt CDC hinter der Datenbank her?)
- Ereignisverarbeitungsrate (halten wir mit der Produktion mit?)
- Schemaänderungsereignisse (hat sich etwas an der Quelle geändert, das wir wissen müssen?)
- Dead-Letter-Queue-Tiefe (was konnte nicht verarbeitet werden und warum?)
Wo layline.io passt: CDC ohne die Fallstricke
Bei layline.io haben wir genug gesehen, wie Teams mit CDC kämpfen, dass wir ein dediziertes Debezium Source Asset direkt in die Plattform gebaut haben. Das Ziel ist nicht, CDC neu zu erfinden — Debezium ist hervorragend —, sondern es in die Zuverlässigkeit und Beobachtbarkeit zu verpacken, die Produktionssysteme brauchen.
Anstatt einen eigenständigen Connector zu betreiben, den Sie ständig beaufsichtigen müssen, bietet Ihnen layline.io:
Visuelles Pipeline-Design, bei dem CDC-Quellen erstklassige Bürger sind. Sie sehen den Datenfluss von der Datenbank bis zum Ziel auf einer einzigen Arbeitsfläche. Wenn etwas bricht, wissen Sie genau, wo.
Integriertes Backpressure-Handling durch das Actor-Model-Streaming von Apache Pekko. Wenn Downstream-Systeme langsamer werden, drosselt layline.io elegant, anstatt Ereignisse zu verwerfen oder Connectors abstürzen zu lassen.
Einheitliches Retry- und Fehlerhandling über die gesamte Pipeline. CDC-Ereignisse, die nicht verarbeitet werden können, verschwinden nicht in einer Log-Datei — sie durchlaufen dieselben Retry-Mechanismen wie jede andere Datenquelle.
Schema-bewusste Transformation, die sich an Änderungen in der Quelldatenbank ohne manuellen Eingriff anpassen kann. Spalte hinzufügen, Feld umbenennen, Typ ändern — die Pipeline passt sich an, anstatt zu brechen.
Der größere Punkt: CDC ist zu wichtig, um ein Nachgedanke zu sein. Es verdient denselben technischen Anspruch wie der Rest Ihrer Dateninfrastruktur. Ob Sie layline.io nutzen oder Ihren eigenen Stack bauen — behandeln Sie CDC wie die kritische Komponente, die es ist, und nicht wie Infrastruktur, die Sie ignorieren können, bis der Keller überflutet.
Andrew Tan ist Serienunternehmer und Gründer von layline.io. Er baut unternehmensweite Datenverarbeitungsinfrastruktur, die Batch- und Echtzeit-Workloads im großen Maßstab verarbeitet.
