Orchestrazione con Cloud Composer

Cloud Composer è Apache Airflow gestito: definisci le pipeline come DAG (Directed Acyclic Graph) in Python, dove ogni task è un operatore con dipendenze esplicite. È la scelta quando devi coordinare più servizi eterogenei in un flusso con dipendenze, scheduling ricorrente e backfill: ad esempio attendere file su Cloud Storage, lanciare un job Dataflow, eseguire una query BigQuery e poi un job Dataproc, con ordine, retry e SLA gestiti centralmente. Tieni distinta l’orchestrazione (Composer decide “chi parte quando”) dall’elaborazione (Dataflow, Dataproc, BigQuery fanno il lavoro): Composer non processa i dati, li dirige. Per flussi event-driven semplici un trigger Pub/Sub più una Cloud Function può bastare; Composer si giustifica quando servono dipendenze articolate, orchestrazione multi-step e visibilità sui DAG.

Monitoring e logging delle pipeline

Cloud Monitoring raccoglie le metriche e permette di definire alerting policy su soglie; Cloud Logging centralizza i log applicativi e di sistema. Per una pipeline streaming su Dataflow le metriche chiave sono il system lag e il data watermark: un lag crescente segnala che il throughput non regge il volume in ingresso. Su Pub/Sub monitora il numero di messaggi non-acknowledged e l’oldest unacked message age (età del messaggio più vecchio non confermato), che indica un accumulo lato consumer. Usa le log-based metrics per contare pattern di errore nei log e trasformarli in alert. Ricorda la distinzione: per l’audit “chi ha fatto cosa, quando” servono i Cloud Audit Logs, non i log applicativi della pipeline.

Ottimizzazione dei costi

BigQuery offre due modelli di pricing: on-demand (paghi i byte scansionati) e capacity, basato su slot acquistati con reservation e commitment. Per carichi prevedibili e continui le reservation con slot dedicati stabilizzano la spesa; per query sporadiche l’on-demand resta più conveniente. Riduci i byte scansionati con il partitioning (limita le partizioni lette filtrando su data o intero) e il clustering (ordina fisicamente per le colonne più filtrate), evitando i SELECT *. Sul lato storage, applica lifecycle policy su Cloud Storage per far transitare i dati da Standard a Nearline, Coldline o Archive in base alla frequenza di accesso. Su Dataproc, i cluster effimeri (creati per il singolo job e distrutti al termine) affiancati da VM Spot abbattono il costo rispetto a un cluster long-running sempre acceso: separa lo storage (su Cloud Storage) dal compute.

Gestione errori, CI/CD e governance con Dataplex

Pub/Sub è at-least-once di default: i consumer devono essere idempotenti, perché lo stesso messaggio può essere consegnato più volte. Per i messaggi che falliscono ripetutamente configura un dead-letter topic dopo N tentativi di consegna, così i messaggi “avvelenati” non bloccano la pipeline e restano ispezionabili. Progetta retry con backoff e job idempotenti (riscrivi la stessa partizione invece di appendere) affinché un rerun dopo un errore non duplichi i dati. Per il CI/CD, versiona DAG e logica delle pipeline in un repository e deploya via Cloud Build verso il bucket dei DAG di Composer, testando in un ambiente separato prima di promuovere in produzione. Dataplex fornisce governance e cataloging: organizza dati distribuiti su più bucket e dataset in lake e zone, con discovery automatico, un metadata catalog per la ricerca, e controlli centralizzati di data quality e lineage, senza spostare fisicamente i dati.

Trappole tipiche d’esame

  • Pipeline con molte dipendenze e scheduling ricorrente → Cloud Composer: se lo scenario descrive un semplice trigger su evento singolo, una Cloud Function via Pub/Sub è più snella; Composer serve per DAG complessi.
  • Lag streaming crescente in Dataflow → monitora system lag e watermark: il backlog di messaggi Pub/Sub non basta a diagnosticare; il segnale primario è il system lag del job.
  • Costo del cluster Dataproc troppo alto → cluster effimeri + VM Spot: la trappola è “aggiungere nodi permanenti”; la risposta corretta separa compute da storage ed elimina il cluster sempre acceso.
  • Messaggi duplicati o dati raddoppiati dopo un retry → idempotenza: Pub/Sub è at-least-once, quindi la soluzione è rendere idempotente il consumer, non “attivare exactly-once” come prima scelta.
  • Messaggi che falliscono di continuo → dead-letter topic: aumentare solo i retry non risolve; serve isolare i messaggi problematici in un DLQ.
  • Ridurre il costo delle query BigQuery → partitioning e clustering: la risposta sbagliata è “comprare più slot”; prima si riducono i byte scansionati sul design della tabella.