Dataflow: il modello unificato batch + streaming

Dataflow è il servizio serverless per l’esecuzione di pipeline Apache Beam. Il valore centrale, e quello che l’esame verifica di più, è il modello unificato: lo stesso codice Beam descrive sia il batch (bounded data) sia lo streaming (unbounded data), cambiando solo la sorgente e i parametri di windowing. Non gestisci VM, non dimensioni un cluster: Dataflow provisiona i worker e applica l’autoscaling in base al backlog e al parallelismo, oltre al Dynamic Work Rebalancing che ridistribuisce le task tra worker lenti e veloci.

Nello streaming, i concetti chiave sono windowing e watermark. Il windowing suddivide un flusso infinito in finestre finite su cui calcolare aggregazioni: fixed (tumbling) non sovrapposte, sliding sovrapposte, e session basate su gap di inattività. Il watermark è la stima di Beam di “fino a che event time abbiamo ricevuto tutti i dati”: quando il watermark supera la fine di una finestra, questa si chiude e produce il risultato. I dati che arrivano dopo (late data) si governano con triggers e allowed lateness. Distinguere sempre event time (quando l’evento è accaduto) da processing time (quando lo elabori) è tipico banco di prova: le aggregazioni corrette in streaming sono quasi sempre su event time.

Dataflow è la scelta naturale per lo streaming near-real-time, tipicamente alimentato da Pub/Sub (che di default è at-least-once, con exactly-once opzionale), e per trasformazioni ETL/ELT senza gestione di infrastruttura.

Dataproc: Spark/Hadoop gestito

Dataproc è il cluster Spark/Hadoop/Hive/Presto gestito. È il servizio giusto quando esiste già un workload OSS — job Spark/Hadoop, script PySpark, query Hive — che vuoi portare sul cloud con modifiche minime (lift-and-shift). Il pattern professionale è il cluster effimero: crei il cluster per il singolo job, leggi/scrivi i dati su Cloud Storage (usato come data lake al posto di HDFS locale), e distruggi il cluster a fine job. Così paghi solo il tempo di calcolo e disaccoppi storage e compute; le Preemptible/Spot VM abbattono ulteriormente il costo per i worker.

Il criterio di scelta che l’esame ripete: Dataflow per pipeline nuove, serverless, batch+streaming unificato; Dataproc per riusare codice Spark/Hadoop esistente o competenze OSS del team. “Nuova pipeline streaming senza vincoli OSS” → Dataflow. “Migrare job Spark on-prem con il minimo refactoring” → Dataproc.

Per la preparazione dati visuale e no-code (profiling, pulizia, deduplica esplorativa da parte di analisti), lo strumento è Cloud Dataprep, che genera ed esegue trasformazioni sottostanti; utile quando il requisito parla di preparazione interattiva senza scrivere codice.

Cloud Composer: orchestrazione con Airflow

Quando devi coordinare più step eterogenei — un job Dataflow, poi un load in BigQuery, poi un cluster Dataproc effimero, con dipendenze, retry e schedulazione — usi Cloud Composer, cioè Apache Airflow gestito. Definisci il workflow come DAG (grafo diretto aciclico) in Python: ogni task è un nodo, gli archi sono le dipendenze. Composer offre scheduling, gestione dei retry/backfill, monitoraggio e integrazione con gli altri servizi via operator.

Distinzione da non sbagliare: Composer orchestra pipeline (chi parte, quando, dopo cosa), non elabora i dati riga per riga; l’elaborazione la fanno Dataflow/Dataproc/BigQuery. Per un semplice trigger event-driven (un file arriva su Cloud Storage → avvia una funzione) bastano soluzioni più leggere; Composer è la risposta quando serve un workflow multi-step con dipendenze complesse.

Trappole tipiche d’esame

  • Riusare job Spark/Hadoop esistenti con minimo refactoring → Dataproc: Dataflow richiederebbe di riscrivere in Beam; per il lift-and-shift OSS la risposta è Dataproc, meglio se con cluster effimero e dati su Cloud Storage.
  • Pipeline streaming nuova, serverless, senza gestire cluster → Dataflow: se lo scenario non impone codice OSS preesistente e vuole autoscaling senza ops, la scelta è Dataflow, non Dataproc.
  • Aggregazioni streaming corrette su dati in ritardo → windowing su event time + watermark/triggers/allowed lateness: rispondere “processing time” o “finestra fissa senza gestione del late data” è la trappola.
  • Coordinare più step con dipendenze e retry → Cloud Composer (Airflow/DAG): Composer orchestra, non trasforma; scegliere Composer per “elaborare i dati” è errato, così come usare Dataflow per orchestrare altri servizi.
  • Ridurre i costi Dataproc → cluster effimeri + Preemptible/Spot + storage su Cloud Storage: cluster long-running “sempre acceso” con HDFS locale è l’anti-pattern di costo.
  • Preparazione dati visuale/no-code per analisti → Cloud Dataprep: se il requisito è pulizia interattiva senza scrivere codice, non forzare una pipeline Dataflow scritta a mano.