Im Gespräch: Gunnar Morling über Debezium und CDC

Es gibt viele interessante Menschen in der Java-Community, die mit ihrem Engagement in Java Specification Requests (JSRs) und Open-Source-Projekten die Entwicklung vorantreiben. Einige von ihnen möchte ich hier nach und nach vorstellen und mit ihnen über ihre Projekte sprechen. Dieses mal habe ich mit Gunnar Morling über Change Data Capture und das Open-Source-Projekt Debezium gesprochen.

Thorben Janssen: Vielen Dank, dass du wieder für ein Gespräch bereitstehst. Der eine oder andere hat vielleicht das frühere Interview mit dir über die Bean-Validation-2.0-Spezifikation verpasst. Kannst du dich bitte noch mal kurz vorstellen?

Gunnar Morling: Ich bin als Open-Source-Softwareentwickler für Red Hat tätig. Zunächst habe ich als Teil des Hibernate-Teams unter anderem an Projekten wie Hibernate Validator und Hibernate Search gearbeitet und die Entwicklung von Bean Validation 2.0 (JSR 380) geleitet. Als ein Bestandteil der Java-EE-Plattform wird aktuell übrigens auch die Bean-Validation-Spezifikation nach Jakarta EE überführt und künftig unter dem Dach der Eclipse Foundation weiterentwickelt werden.

Seit nunmehr reichlich zwei Jahren arbeite ich an Debezium, einer Open-Source-Plattform für Change Data Capture. Vielleicht kennt mich der eine oder andere Leser auch schon von Konferenzen wie dem JavaLand oder meiner Arbeit an anderen Projekten wie MapStruct und Deptective.

Janssen: Seitdem Microservices zunehmend an Popularität gewonnen haben, wird auch wieder mehr über Patterns zum Datenaustausch zwischen verschiedenen Datenquellen gesprochen. Eines davon ist Change Data Capture (CDC). Was genau hat es damit auf sich und was ist die grundlegende Idee dahinter?

Morling: Die Idee von Change Data Capture ist schnell erklärt: Wenn immer sich in einer Datenbank etwas ändert, also zum Beispiel ein Kunde angelegt, ein Auftrag aktualisiert oder eine Lieferung gelöscht wird, wird diese Änderung erfasst und als Event an interessierte Consumer verteilt. Diese Events beschreiben alten und neuen Zustand des betroffenen Datensatzes sowie Metadaten wie den Zeitstempel der Änderung, Transaktions-ID und einiges andere mehr. Im Sinne einer losen Kopplung werden die Change Events dabei typischerweise asynchron über Message Broker wie Apache Kafka an die Konsumenten übertragen.

Janssen: Und wie sieht ein ideales Anwendungsszenario für CDC aus?

Morling: Die Anwendungsfälle für CDC sind ausgesprochen vielfältig:

Zum einen kann man direkt auf die Events reagieren und zum Beispiel korrespondierende Einträge eines Caches invalidieren. Auch Streaming Queries fallen in diese Kategorie: Dabei werden vordefinierte Abfragen (z.B. "Wie hoch ist der akkumulierte Auftragswert der Produktkategorie Möbel innerhalb der letzten 60 Minuten?") automatisch ausgeführt, wann immer ein relevantes Change Event eintrifft, also etwa "Purchase order created". Die kontinuierlich aktualisierten Ergebnisse einer solchen Streaming Query können dann wiederum genutzt werden, um etwa ein Dashboard live zu aktualisieren oder zum Beispiel ein Alerting zu implementieren, wenn der Bestand eines Produkts unter einen bestimmten Schwellwert fällt.

Zum anderen können die Daten der Change Events auch genutzt werden, um andere Datenspeicher zu aktualisieren und konsistent mit der Quelldatenbank zu halten. Dies könnte etwa ein Volltextsuchindex in Elasticsearch sein, ein Data Warehouse oder andere Datenbanken für Analysezwecke. Aber auch Audit Logs oder optimierte Lesedatenmodelle in einer CQRS-Architektur (Command Query Responsibility Segregration) können per CDC erzeugt werden.

Im Kontext von Microservices kann Change Data Capture genutzt werden, um Datenänderungen zwischen verschiedenen Services zu propagieren. Services können dann beispielsweise eine Kopie der Daten anderer Services in ihrer eigenen lokalen Datenbank anlegen, wodurch synchrone Aufrufe zwischen den Services vermieden werden können.

Janssen: Mit dem Debezium-Projekt bietet ihr eine Implementierung der CDC-Patterns. Wie funktioniert das genau und mit welchen Datenquellen kann ich es verwenden?

Morling: Debezium implementiert das sogenannte Log-basierte CDC, das heißt, die Quelle der Change Events sind die Transaktionslogs der Datenbank. Dies bietet große Vorteile gegenüber alternativen Ansätzen wie dem Polling (also der wiederholten Ausführung von Queries, um neue oder geänderte Datensätze zu identifizieren):

• Es ist garantiert, dass alle Änderungen erfasst werden, inklusive kurz aufeinanderfolgender Updates des gleichen Datensatzes sowie Löschungen.
• Change Events werden auf sehr effiziente Weise aus dem Log ermittelt, ohne einen negativen Performance-Einfluss auf andere Queries zu haben.
  
• Es sind keine Änderungen am Datenschema erforderlich wie eine "Last Updated"-Spalte.
  
• Je nach Konfiguration und Datenbank können der vorherige Zustand eines geänderten Datensatzes sowie Metadaten wie ein Änderungszeitstempel, die verursachende Query usw. erfasst werden.

Debezium basiert auf Kafka Connect, einem Framework zur Implementierung und Ausführung von Kafka-Konnektoren, welches unter anderem das Management von Konnektoren (Konfiguration, Start, Stopp etc.), Monitoring und Hochverfügbarkeit mittels Clustering von Kafka-Connect-Instanzen ermöglicht. Auch die Fehlertoleranz ist dabei berücksichtigt: Stürzt etwa ein Konnektor ab oder muss einfach aufgrund eines Updates neu gestartet werden, gehen keine Change-Events verloren, sondern das Log wird einfach ab der zuletzt verarbeiten Position weitergelesen. Im Kontext von Kafka Connect gibt es eine Vielzahl sogenannter Sink-Konnektoren, die mit Debezium genutzt werden können, um Datenänderungen zum Beispiel an andere Datenbanken, Elasticsearch, Hadoop-Cluster usw. zu übertragen.

Neben dem Deployment per Kafka Connect kann Debezium auch als Bibliothek in beliebigen Java-Applikationen genutzt werden, wovon Nutzer Gebrauch machen, um etwa Change-Events nach Amazon Kinesis zu streamen.

Debezium unterstützt diverse Datenbanken wie MySQL, PostgreSQL, SQL Server und MongoDB. Auch arbeitet die Community aktuell an einem Konnektor für Apache Cassandra.

Janssen: Was muss ich tun, wenn ich Debezium einsetzen möchte?

Morling: Ein Startpunkt könnte die Lektüre des Debezium-Tutorials sein, das die erforderlichen Komponenten (eine Datenbank wie MySQL, Apache Kafka, Kafka Connect, Debezium) als Container-Images bereitstellt und die Schritte von der Konfiguration eines Konnektors bis zur Anzeige der Change-Events in Kafka aufzeigt.

Für den produktiven Einsatz basierend auf Kubernetes/OpenShift empfiehlt sich das Strimzi-Projekt, welches einen Kubernetes-Operator zum Betrieb von Kafka und Kafka Connect bereitstellt. Hierfür gibt es bei Bedarf kommerziellen Support durch Red Hat; dies gilt auch für Debezium selbst (aktuell als Developer Preview verfügbar).

Janssen: Aktuell liegt Debezium in der Version 0.9 vor. Ist es bereits für den produktiven Einsatz geeignet? Was fehlt noch zur Version 1.0?

Morling: Die Community setzt die diversen Debezium-Konnektoren bereits im großen Stil in Produktion ein. User berichten von Deployments mit zum Teil Hunderten von Datenbanken. Wir als Entwicklungsteam sind daher sehr darauf bedacht, in neuen Releases die Kompatibilität mit früheren Versionen zu gewährleisten und ein möglichst reibungsloses Upgrade zu ermöglichen. Aktuell arbeiten wir an Version 0.10, welche unter anderem einige Vereinheitlichungen der Event-Formate der diversen Konnektoren und eine erste Version des Cassandra-Konnektors umfasst.

Debezium 1.0 sollte als Nächstes folgen, hier wird der Fokus im Wesentlichen auf Vereinheitlichungen bezüglich der Konfigurationsoptionen der Konnektoren und dem Ausbau der automatisierten Test-Suite liegen, um die Stabilität der Konnektoren noch weiter zu verbessern.

Einige Schlagworte für mögliche künftige Weiterentwicklungen sind die Integration mit dem CloudEvents-Standard, Integration mit weiteren Message-Brokern, Unterstützung für die Erstellung denormalisierter Datensichten und einiges andere mehr. Wir richten uns dabei sehr nach den Bedürfnissen der Community und passen die Roadmap stetig an.

Janssen: Wo kann ich mehr über das Projekt erfahren?

Morling: Zentraler Anlaufpunkt ist unsere Website. Dort können die Konnektoren heruntergeladen werden; es gibt die Referenzdokumentation und das oben genannte Tutorial für einen schnellen Einstieg. Im Blog informieren wir über neue Releases und weiterführende Themen wie Demos zu spezifischen CDC-Use-Cases.

Für Fragen steht die Community bei Bedarf mittels einer Mailing-Liste und einem Chat-Room zur Verfügung, und natürlich findet man @debezium auf Twitter.

Janssen: Und wo kann man dich finden?

Morling: Ich bin über die diese Kanäle und auch auf Twitter unter @gunnarmorling erreichbar.

Janssen: Vielen Dank für das Interview und weiterhin viel Erfolg mit Debezium. ()