Il post è del maggio 2023 ed è firmato da Charles Wang di Fivetran: contenuto di vendor, quindi con la conclusione già scritta. La lista di proprietà che propone, però, è indipendente dal prodotto e regge come griglia di valutazione per qualsiasi strumento di ingestion, compresi quelli che ci si costruisce in casa.
Il punto di partenza è la definizione: data movement significa spostare dati da qualsiasi sorgente a qualsiasi destinazione, su cloud, on-premise o hybrid, in modo potenzialmente multidirezionale. Le sorgenti includono applicazioni, file, event stream e database, ma anche warehouse e data lake. Le cinque proprietà da verificare sono automazione, incremental updates, idempotenza, gestione dello schema drift e performance di pipeline e rete.
Incremental updates e idempotenza
Sui full sync l’argomento è concreto: servono per il caricamento iniziale e per riparare record corrotti, ma sono sbagliati come modalità ordinaria perché lenti, perché saturano sia sorgente sia destinazione e perché consumano banda e compute in eccesso. La pratica dello snapshot giornaliero viene citata come sintomo: “giornaliero” descrive già la lentezza. L’alternativa è il change data capture, con due metodi prevalenti — log e timestamp di ultima modifica — che a batch sufficientemente piccoli si avvicinano allo streaming.
L’idempotenza è la proprietà che rende il resto praticabile: f(f(x)) = f(x), come la funzione valore assoluto o come il pulsante di un ascensore, che porta allo stesso piano indipendentemente da quante volte lo si prema. Applicata a una pipeline significa che riapplicare gli stessi dati alla destinazione non cambia il risultato. Senza, il recovery da un sync fallito diventa un’indagine manuale su quali record siano passati e quali no; con l’idempotenza si rigioca il batch e basta.
Schema drift e performance
Lo schema drift — colonne, tabelle e tipi che cambiano nella sorgente — è indicato come una delle principali cause di failure dell’ETL tradizionale. L’approccio del live updating propaga alla destinazione aggiunte, rinomine e rimozioni di colonne e tabelle, comprese le cancellazioni di righe. È una scelta con conseguenze: allinea perfettamente il modello dati, ma significa anche che una rimozione a monte cancella dati a valle.
Sulla performance l’ordine suggerito è sensato: prima ottimizzazione algoritmica e del codice, poi cambiamenti architetturali per parallelizzare processi indipendenti, infine il pipelining vero e proprio, cioè la separazione del processo in stadi sequenziali che lavorano in contemporanea come una catena di montaggio. Parallelizzazione e pipelining hanno un costo, in codice e in hardware, e vanno affrontati solo quando l’ottimizzazione più economica è esaurita. Come bonus l’articolo aggiunge le transformations: modelli versionati con CI/CD, data model già pronti, scheduling integrato e lineage osservabile.
In sintesi
- Full sync solo per load iniziale e riparazioni; per il resto CDC via log o timestamp di ultima modifica.
- Senza idempotenza il recovery da un sync fallito diventa lavoro manuale caso per caso.
- Il live updating sullo schema drift allinea sorgente e destinazione, ma propaga anche le rimozioni: va valutato, non dato per scontato.
Hai qualcosa da aggiungere? Unisciti alla discussione.