Batch o streaming: il criterio della latenza
La prima domanda di design è sempre la stessa: quanto in fretta devono essere disponibili i dati? Se il requisito è la latenza bassa (dashboard quasi in tempo reale, alerting, personalizzazione, arricchimento evento per evento), la scelta è lo streaming: i record arrivano in modo continuo e vengono processati appena disponibili. Se invece i dati possono accumularsi e arrivare a intervalli (caricamenti notturni, sincronizzazioni schedulate, backfill storici), il batch offre throughput superiore e costo per record inferiore. L’esame ama gli scenari ibridi: sorgente batch da un data lake unita a un flusso di eventi live. Ricorda che Dataflow (Apache Beam serverless) gestisce sia batch sia streaming con lo stesso modello di programmazione, mentre l’ingestione è responsabilità di servizi dedicati a monte.
Pub/Sub: lo streaming di eventi
Pub/Sub è il servizio di messaggistica globale per l’ingestione di eventi in streaming: disaccoppia i producer dai consumer e assorbe i picchi di traffico. Punti chiave da memorizzare:
- La consegna è at-least-once di default: un messaggio può essere recapitato più di una volta, quindi i consumer devono essere idempotenti. Esiste la modalità exactly-once opzionale (su subscription pull) quando la deduplicazione a valle è troppo costosa.
- L’ordering key garantisce che i messaggi con la stessa chiave siano consegnati nell’ordine di pubblicazione. Va abilitato esplicitamente e riduce il parallelismo per quella chiave: si usa solo quando l’ordine per entità (es. per utente o per dispositivo) è un requisito reale.
- Il dead-letter topic raccoglie i messaggi che superano il numero massimo di tentativi di consegna, evitando che un messaggio “avvelenato” blocchi la subscription. È la risposta corretta quando lo scenario parla di messaggi che falliscono ripetutamente il processing.
Datastream: change data capture (CDC)
Quando lo scenario è “replicare le modifiche di un database operativo verso l’analytics con impatto minimo sulla sorgente”, la risposta è Datastream: un servizio serverless di change data capture che legge in modo continuo insert, update e delete da database relazionali (es. MySQL, PostgreSQL, Oracle) e li propaga a destinazioni come BigQuery o Cloud Storage. Il CDC è preferito ai dump periodici perché cattura solo le variazioni, mantiene bassa la latenza di replica e non richiede query pesanti sulla sorgente. Distinguilo da un semplice export batch: se la parola chiave è “modifiche near-real-time da un OLTP”, pensa a Datastream, spesso combinato con Dataflow per la trasformazione.
Data Fusion e i transfer service
Cloud Data Fusion è lo strumento di integrazione dati visuale (basato su CDAP): pipeline ETL/ELT costruite con connettori e trasformazioni senza scrivere codice, adatto a team che vogliono governance e riuso senza gestire cluster manualmente. Per i caricamenti massivi esistono due servizi mirati da non confondere:
- Storage Transfer Service: sposta grandi volumi di file/oggetti verso Cloud Storage, da altri cloud (S3, Azure), da sorgenti on-premise o tra bucket, con scheduling e ripresa.
- BigQuery Data Transfer Service: automatizza il caricamento schedulato in BigQuery da SaaS e sorgenti supportate. È la scelta quando lo scenario parla di ingestione ricorrente e gestita direttamente in BigQuery, non di trasformazioni custom.
Trappole tipiche d’esame
- Ordine dei messaggi per entità → ordering key su Pub/Sub: è la soluzione corretta; non affidarti al timestamp lato consumer né presumere che Pub/Sub ordini di default (non lo fa).
- Messaggi duplicati che rompono i conteggi → consumer idempotente o exactly-once: poiché il default è at-least-once, la deduplicazione va progettata; non dare per scontato “una sola consegna”.
- Replica near-real-time da un OLTP → Datastream (CDC), non export batch: un dump schedulato aumenta latenza e carico sulla sorgente; il CDC cattura solo le variazioni.
- Messaggi che falliscono ripetutamente → dead-letter topic: evita che un messaggio problematico blocchi la subscription; aumentare solo i retry non risolve.
- Caricamento ricorrente e gestito in BigQuery → BigQuery Data Transfer Service: non è Storage Transfer Service (che alimenta Cloud Storage) né una pipeline Data Fusion, se non servono trasformazioni.
- Trasferimento massivo di file da altro cloud/on-prem → Storage Transfer Service: distinguilo da Datastream (database CDC) e da Dataflow (elaborazione).