Scegliere lo strumento di trasformazione
Il primo criterio d’esame è abbinare il workload al servizio giusto, non scegliere “il più potente”.
- Dataproc: cluster gestiti Spark/Hadoop. È la scelta quando esiste già codice Spark, Hive o Pig, oppure competenze nell’ecosistema Hadoop da migrare con un approccio lift-and-shift. Puoi usare cluster effimeri creati per il singolo job e distrutti alla fine, per contenere i costi.
- Dataflow: servizio serverless per pipeline Apache Beam, con un unico modello di programmazione per batch e streaming e autoscaling automatico. Da preferire per pipeline nuove, soprattutto in streaming, quando non vuoi gestire cluster.
- Cloud Data Fusion: ETL visuale drag-and-drop, per team che preferiscono un’interfaccia grafica invece di scrivere codice.
- Dataform: gestisce l’ELT in SQL dentro BigQuery, con grafo delle dipendenze fra le trasformazioni, versionamento e assertion per la data quality. Non esegue Spark: opera esclusivamente su BigQuery.
ETL vs ELT
L’esame chiede spesso di distinguere i due pattern.
- ETL: trasformi i dati prima del load, in uno staging esterno. Utile quando servono pulizia, deduplica o masking prima che i dati entrino nel warehouse.
- ELT: carichi i dati grezzi e li trasformi dopo, direttamente in BigQuery, sfruttando la potenza di calcolo del warehouse serverless. È il pattern nativo di Dataform ed è generalmente preferito su Google Cloud quando la destinazione è BigQuery.
Orchestrazione e scheduling
La domanda tipica è “quale soluzione di orchestrazione”, ed è quasi sempre una questione di complessità.
- Scheduled query: schedulazione nativa di una query SQL ricorrente in BigQuery. Perfetta per un singolo step SQL periodico (es. aggiornare una tabella aggregata ogni notte).
- Cloud Scheduler: cron gestito che innesca un target HTTP o un topic Pub/Sub. È un trigger temporale generico, non un motore di pipeline.
- Dataproc Workflow Templates: definiscono una sequenza di job su un cluster Dataproc (spesso effimero), utili per orchestrare più step Spark/Hadoop.
- Workflows: orchestrazione serverless leggera di chiamate ad API e servizi, con logica condizionale e retry, senza infrastruttura da gestire. Adatta a coordinare pochi servizi.
- Cloud Composer: Apache Airflow gestito, per DAG complessi con molte dipendenze cross-service e tra sistemi eterogenei. È la scelta giusta per pipeline articolate, ma è sovradimensionato per un singolo step.
Monitoraggio delle pipeline
Per Dataflow, il job graph mostra ogni fase; le metriche (throughput, system lag, data freshness) confluiscono in Cloud Monitoring, mentre i log di worker e job stanno in Cloud Logging. Da qui puoi impostare alert su lag crescente o errori. Ricorda che il monitoraggio è centralizzato in Cloud Monitoring/Logging per tutti i servizi, non specifico di un singolo prodotto.
Ingestione event-driven
- Pub/Sub è il bus di messaggi per l’ingestione streaming e il disaccoppiamento fra produttori e consumatori.
- Per portare messaggi in BigQuery senza scrivere codice si usa la BigQuery subscription di Pub/Sub, che scrive direttamente in una tabella; una pipeline Dataflow custom serve solo se occorrono trasformazioni non banali durante il transito.
- Eventarc instrada eventi (per esempio l’arrivo di un nuovo file in Cloud Storage) verso target come Workflows o Cloud Run, abilitando pipeline che partono quando accade un evento, invece di eseguire polling a intervalli.
Trappole tipiche d’esame
- Codice Spark/Hadoop esistente da migrare → Dataproc: non riscriverlo in Beam; Dataproc esegue nativamente l’ecosistema Hadoop.
- Pipeline unica batch e streaming → Dataflow: il modello Beam è unificato e serverless; Dataproc è la trappola per chi confonde “gestito” con “Spark”.
- Trasformazioni SQL con dipendenze dentro BigQuery → Dataform (ELT): non serve Composer né Dataflow per orchestrare pura logica SQL.
- Una sola query ricorrente giornaliera → scheduled query: Cloud Composer qui è over-engineering; l’esame premia la soluzione più semplice adeguata.
- Da Pub/Sub a BigQuery senza trasformazioni → BigQuery subscription: evita la pipeline Dataflow custom quando non c’è logica da applicare.
- Avvio pipeline all’arrivo di un file in Cloud Storage → Eventarc: trigger event-driven, non Cloud Scheduler con polling a intervalli fissi.