Change Data Capture (CDC)

Wat is Change Data Capture?

Change Data Capture, meestal afgekort tot CDC, is een techniek om elke wijziging in een bronsysteem (insert, update, delete) te detecteren en naar andere systemen door te sturen. In plaats van elke nacht de volledige tabel opnieuw te laden, stuur je alleen wat er sinds de vorige run veranderd is. Dat schaalt beter, belast de bron minder en maakt bijna-realtime synchronisatie mogelijk.

CDC zit tegenwoordig in zowat elke datastack: replicatie tussen operationele systemen, voeden van een lakehouse of data warehouse, synchroniseren van microservices, realtime analyses op transactiedata.

Je kan CDC vergelijken met een logboek van een boekhouder: in plaats van elke avond het hele grootboek opnieuw door te schrijven, noteer je enkel de bewegingen van de dag. Wie de stand van zaken wil weten, begint van de laatst bekende versie en speelt de bewegingen af.

Waarom CDC in plaats van een volledige load?

Full-load ETL werkt prima zolang je tabellen klein blijven. Vanaf enkele honderden miljoenen rijen beginnen drie problemen te knellen.

Belasting van de bron
Een nachtelijke full-load legt een OLTP-database tien minuten lang plat. Bij 24/7-operaties is dat geen optie.

Doorlooptijd
Full-loads worden steeds langer terwijl het refresh-venster niet meekrijkt. Business vraagt vaak verse data, terwijl IT uur na uur bijbakt.

Kosten
Op cloud-platformen betaal je voor rekenkracht per minuut. Incrementeel laden is altijd goedkoper dan volledig laden.

CDC lost dit alles op door enkel deltas over te brengen.

Methodes van CDC

Log-based CDC
De database schrijft elke wijziging naar een intern transactielog (WAL in PostgreSQL, binlog in MySQL, CDC-tabellen in SQL Server). CDC-tools lezen dat log en publiceren elke wijziging als gebeurtenis. Grote voordeel: minimale impact op de bron en geen aanpassingen aan applicaties nodig. Tools zoals Debezium, SQL Server CDC en Fabric Mirroring werken zo.

Trigger-based CDC
Je plaatst database-triggers die bij elke insert, update of delete een kopie in een changelog-tabel schrijven. Werkt in elke database, maar vertraagt schrijfacties en vergt onderhoud op elke betrokken tabel.

Timestamp-based CDC
Elke tabel heeft een last_modified-kolom. Je pipeline vraagt telkens de rijen op die na de vorige run veranderd zijn. Simpel en goedkoop, maar detecteert geen deletes en faalt zodra iemand de kolom vergeet bij te werken.

Snapshot differencing
Je vergelijkt een verse kopie met de vorige en leidt zelf de deltas af. Werkt altijd, maar is traag en zwaar. Soms de laatste uitweg als de bron niets anders toelaat.

Hoe past CDC in een moderne datastack?

1. Capture
   Een CDC-tool leest de wijzigingen uit de bron. Voor SQL Server, Oracle, PostgreSQL en MySQL bestaan volwassen connectoren.

2. Transport
   De wijzigingen gaan naar een streaming-laag zoals Apache Kafka, Azure Event Hubs of Pulsar. Dat maakt meerdere consumers op dezelfde stroom mogelijk.

3. Sink
   Downstream-systemen abonneren zich: een lakehouse schrijft de wijzigingen weg als Delta-tabellen, een zoekindex update zijn records, een microservice bouwt een cache.

4. Apply
   In de doeltabel worden inserts toegevoegd, updates overschreven en deletes weggevlagd (of echt verwijderd). Delta's MERGE INTO-statement is hier een werkpaard.

CDC in Microsoft Fabric

Microsoft Fabric heeft een aparte feature genaamd Mirroring die CDC out of the box verzorgt voor Azure SQL Database, Cosmos DB en Snowflake. Wijzigingen in de bron verschijnen binnen seconden als Delta-tabellen in OneLake, zonder eigen pipeline. Voor andere bronnen kan je de traditionele Data Factory-connectoren met incremental load-patroon gebruiken, of Debezium via Event Streams.

Wanneer gebruik je CDC?

• Data warehouse of lakehouse voeden met operationele data zonder de brondatabase te belasten.

• Realtime dashboards op transactiedata, bijvoorbeeld verkoop per minuut.

• Microservice-synchronisatie, waarbij een service de eigen cache up-to-date houdt op basis van wijzigingen bij een andere service.

• Fraudedetectie waar seconden tellen: een verdachte transactie vraagt direct een reactie.

• Migratie naar een nieuw systeem zonder downtime, door eerst een bulkload te doen en dan met CDC de deltas bij te werken tot je kan omschakelen.

Valkuilen

Schema-wijzigingen breken pipelines
Een kolom toevoegen in de bron gaat niet automatisch mee in je CDC-stroom tenzij je tool schema-evolutie aankan. Plan data lineage-checks in.

Deletes vergeten
Sommige CDC-methoden (vooral timestamp-based) registreren geen deletes. Je doeltabel krijgt dan rijen die al lang niet meer in de bron staan.

Exactly-once versus at-least-once
Streaming-systemen leveren berichten soms meer dan eens. Zorg dat je apply-logica idempotent is, bijvoorbeeld via een unieke change-key.

Replicatie-lag bewaken
Zonder monitoring ontdek je pas te laat dat de stream achterloopt. Zet een alert op de vertraging tussen bron-commit en sink-applicatie.