Change Data Capture (CDC) pattern

Il binario di questa lezione è ml-tabellare, ma la materia arriva da un posto inatteso: il log di scrittura di un database transazionale. Il CDC trasforma ogni modifica di quel database in un evento ordinato, pronto per l’analitica in tempo reale.

Il concetto in breve

Il Change Data Capture legge il log transazionale e pubblica ogni inserimento, aggiornamento e cancellazione come evento ordinato verso Kafka e ClickHouse. È il ponte discreto tra il mondo OLTP e il mondo analitico.

Come si mette in opera

Ecco la sequenza che porta dal database operativo alla vista analitica.

1. Abilita il log logico su Postgres o MySQL e verifica che ogni modifica sia ordinata e replayabile.
2. Collega Debezium come replica e pubblica gli eventi su topic dedicati per tabella.
3. Applica deduplicazione e gestione di update fuori ordine e delete con motori versionati.
4. Carica in ClickHouse con ReplacingMergeTree e verifica con letture di controllo.
5. Dichiara owner, monitoraggio del lag e procedura di replay prima della go-live.

Come funziona CDC

Il CDC legge il transaction log del database (il binlog di MySQL, il WAL di PostgreSQL) e produce un evento per ogni modifica:

INSERT → evento {op: "c", after: {id: 123, name: "Mario", ...}}
UPDATE → evento {op: "u", before: {...}, after: {id: 123, name: "Maria", ...}}
DELETE → evento {op: "d", before: {id: 123, ...}}

Debezium è lo standard de-facto open source per il CDC. Si connette al database come replica, legge il log e scrive i cambiamenti su Kafka.

L’architettura tipica

PostgreSQL ──► Debezium ──► Kafka ──► Kafka Connect Sink ──► ClickHouse
                                    ──► Stream processor (ksqlDB/Flink) ──► Alerting

In ClickHouse si usa il motore ReplacingMergeTree con version per gestire gli UPDATE senza deduplicazione istantanea:

CREATE TABLE customers (
    id UInt64,
    name String,
    email String,
    updated_at DateTime,
    _version UInt64
) ENGINE = ReplacingMergeTree(_version)
ORDER BY id;

ReplacingMergeTree mantiene l’ultima versione di ogni riga in base all’ORDER BY. La deduplicazione avviene durante i merge in background, quindi non è istantanea. Per query accurate aggiungi FINAL: SELECT * FROM customers FINAL WHERE id = 123.

Quando serve CDC, e quando no

Il CDC ha senso quando hai un database operativo, per esempio ordini o utenti, e vuoi dati near-real-time nel warehouse senza ETL pesanti. Non serve invece quando i dati sono già eventi nativi come clickstream o log, perché vanno direttamente in Kafka senza passare dal transaction log. Allo stesso modo, quando una latenza di ore è accettabile, il batch ETL resta più semplice e meno costoso.

Verdetto: usa CDC quando il database operativo deve alimentare l’analitica in near real-time, resta sul batch quando ore di ritardo sono accettabili e vai diretto su Kafka per eventi nativi.

Gli errori comuni

Il primo errore è fidarsi di export periodici senza gestione di update e delete, con dashboard che mostrano ore vecchie senza dichiararlo. Il secondo è ignorare fuori ordine, replay e cambi di schema, che trasformano la pipeline in fonte di incoerenza. Il terzo è non distinguere creazione da aggiornamento a valle, con conteggi gonfiati e rimborsi trattati come nuovi ordini.

Riferimenti: Debezium Documentation (2024), Architettura Debezium su debezium.io; Zalando Engineering Blog (2021), From Nightly ETL to Real-Time CDC.

Il caso Zalando: da ETL notturno a CDC

Zalando descrive nel 2021 la migrazione da export notturni a CDC con Debezium e Kafka per ordini, pagamenti e rimborsi. Il log transazionale diventa la sorgente ordinata che alimenta warehouse e viste operative senza ETL pesanti. La disciplina che rende il caso utile è esplicita: eventi idempotenti, gestione di update e delete e consumatori che distinguono creazione da aggiornamento. Il guadagno non è solo latenza ma coerenza tra operativo e analitico sotto replay e cambi di schema.

Domande per ripassare

1. Quale log abiliti per catturare insert, update e delete senza perdere ordine?
2. Come gestisci update fuori ordine e delete in ClickHouse?
3. Quando CDC batte il batch ETL e quando resta più costoso?
4. Quale controllo fai prima di fidarti di una vista alimentata da CDC?