Debezium

Wat is Debezium?

Debezium is een open source platform dat elke wijziging in je databank omzet in een stroom van events. Voegt iemand een record toe, past hij er een aan of verwijdert hij er een, dan pikt Debezium die wijziging op en stuurt ze bijna meteen door naar de systemen die ze nodig hebben.

Het doet dat via log-based Change Data Capture. Debezium leest niet je tabellen uit met steeds nieuwe queries, maar leest het transactielog dat de databank sowieso al bijhoudt: de binlog in MySQL, de write-ahead log (WAL) in PostgreSQL. Elke commit staat daar al in, en Debezium leest gewoon mee. De bron voelt daar amper iets van, want dat logboek wordt toch al geschreven.

Hoe werkt Debezium?

Voor elke ondersteunde databank bestaat een aparte connector. Die maakt verbinding met de bron, leest het transactielog vanaf een bepaalde positie en onthoudt waar hij gebleven is. Valt hij uit en herstart hij, dan pikt hij de draad weer op precies waar hij stopte, zonder wijzigingen te missen of dubbel te lezen.

Elke rij-wijziging wordt een gestructureerd event met vaste velden:

• before: de rij zoals ze was voor de wijziging. Bij een insert staat dit op null.

• after: de rij zoals ze na de wijziging is. Bij een delete staat dit op null.

• op: het soort operatie, met c voor een insert, u voor een update, d voor een delete en r voor een rij die uit een snapshot komt.

• source: metadata zoals de databanknaam, de tabelnaam en het tijdstip van de commit.

Wie zo'n update-event leest, ziet dus zowel de oude als de nieuwe waarde. Downstream weet daardoor exact wat er veranderd is, niet enkel wat de eindstand is.

Bij de eerste start maakt de connector meestal een snapshot van de bestaande tabellen, zodat je downstream met een volledig beeld begint. Daarna schakelt hij over op het log en stuurt hij enkel nog de nieuwe wijzigingen door.

Welke databanken ondersteunt Debezium?

Debezium heeft volwassen connectoren voor de courante operationele databanken:

• MySQL en MariaDB, via de binlog.

• PostgreSQL, via logische replicatie op de WAL.

• SQL Server, via de ingebouwde CDC-functie van SQL Server zelf.

• MongoDB, via de oplog of de change streams.

• Oracle, via LogMiner of XStream.

• Db2, via het transactielog.

De events uit al deze connectoren hebben dezelfde vorm, zodat je downstream niet per bron iets anders hoeft te bouwen.

Hoe draait Debezium?

Debezium is gebouwd bovenop Apache Kafka en kent drie manieren om te draaien.

Op Kafka Connect
De klassieke opzet. De connectoren draaien binnen Kafka Connect, het runtime-framework van Kafka, en schrijven hun events naar Kafka-topics, meestal één per tabel. Kafka bewaart die events, dus een afnemer die uitvalt leest nadien gewoon verder, en meerdere afnemers lezen dezelfde stroom elk op eigen tempo.

Als Debezium Server
Een aparte, standalone toepassing die de wijzigingen rechtstreeks naar een andere bestemming stuurt, bijvoorbeeld Google Pub/Sub, Amazon Kinesis of Apache Pulsar. Handig als je geen Kafka draait maar wel de connectoren van Debezium wil.

Ingebed in je eigen applicatie
Met de embedded engine draai je een connector als een bibliotheek binnen je eigen Java-applicatie, zonder Kafka of Kafka Connect. Je vangt de events dan zelf op in code.

Bij de Kafka-opzet werkt Debezium vaak samen met een Schema Registry. Die houdt het schema van je events centraal bij, zodat je ze compact als Avro kan doorsturen en zodat schema-evolutie onder controle blijft: een kolom bijkomen breekt je afnemers dan niet.

Wanneer gebruik je Debezium?

Debezium is op zijn plaats zodra je wijzigingen uit een operationele databank bijna live ergens anders nodig hebt.

• Een lakehouse of data warehouse voeden. In plaats van elke nacht alles opnieuw te laden, schrijf je enkel de wijzigingen weg. Een verwerkingsjob, bijvoorbeeld op Apache Spark, leest de stroom en houdt je tabellen bijna realtime synchroon met de bron.

• Een migratie zonder downtime. Je doet eerst een bulkload naar het nieuwe systeem en laat Debezium daarna de wijzigingen bijwerken tot je kan omschakelen.

Debezium is dus een manier om streaming data te winnen uit systemen die nooit voor streaming bedoeld waren. Het is de motor achter heel wat Change Data Capture-pijplijnen.

Debezium naast een ingebouwde CDC-feature

Veel databanken en platformen hebben zelf al een CDC-oplossing. De afweging draait om controle tegenover gemak.

Debezium versus SQL Server CDC

SQL Server CDC is de ingebouwde functie van SQL Server die wijzigingen wegschrijft naar aparte change-tabellen. Die data blijft wel binnen SQL Server; je moet ze er zelf nog uithalen. Debezium bouwt net op die functie voort: de SQL Server-connector leest die change-tabellen en zet de wijzigingen om in een stroom die je overal naartoe kan sturen.

Debezium versus Fabric Mirroring

Mirroring in Microsoft Fabric verzorgt CDC out of the box voor een reeks bronnen zoals Azure SQL Database. Wijzigingen landen binnen seconden als tabellen in OneLake, zonder dat je zelf iets moet draaien. Je koopt gemak, maar zit vast aan de bronnen en de bestemming die Fabric ondersteunt. Debezium beheer je zelf, wat meer werk vraagt, maar je bent vrij in welke bron je aftapt en waar de stroom naartoe gaat.

Waar moet je op letten bij het gebruik van Debezium

Je beheert de infrastructuur zelf
Kafka, Kafka Connect en de connectoren draaien niet vanzelf. Iemand moet ze opzetten, bewaken en updaten. Voor een klein team is dat een reële kost tegenover een kant-en-klare feature.

Schema-wijzigingen aan de bron
Een kolom bijkomen of van type veranderen loopt niet vanzelf mee. Een Schema Registry met een compatibiliteitsregel vangt veel op, maar zulke wijzigingen plan je best bewust in.

Berichten komen soms dubbel toe
Debezium levert events minstens één keer af, en dus af en toe twee keer, bijvoorbeeld na een herstart. Zorg dat je verwerking idempotent is: geef elk event een unieke sleutel zodat twee keer verwerken hetzelfde resultaat geeft als één keer.