Google PDE: Orchestrazione dei Flussi di Lavoro e Automazione delle Pipeline — Guida allo studio

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

Fa parte della Google Professional Data Engineer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

L’orchestrazione dei workflow e l’automazione delle pipeline coordinano i task di dati tra i vari servizi in modo che l’ingestion, la trasformazione, i controlli di qualità e la pubblicazione avvengano in modo affidabile, sicuro ed economico. In Google Cloud, l’orchestrazione deve allinearsi con il modello di esecuzione di ogni carico di lavoro: batch pianificati, stream guidati dagli eventi, ad-hoc o job a lunga esecuzione. Gli obiettivi di progettazione sono la ripetibilità, l’idempotenza, l’osservabilità, il principio del privilegio minimo e la promozione sicura tra gli ambienti.

Scelte chiave:

Orchestrazione batch incentrata sul codice con Cloud Composer (Apache Airflow) per DAG, dipendenze tra task e pianificazione avanzata.
Coreografia di API serverless con Cloud Workflows per sequenze leggere, guidate dagli eventi e cross-service.
Endpoint di esecuzione come i job di Cloud Run o Dataproc, attivati da Cloud Scheduler per esecuzioni cron o da Eventarc per eventi.
Orchestrazione nativa SQL con Dataform per trasformazioni, asserzioni e gestione delle release in BigQuery.

Il modello operativo enfatizza i tentativi con backoff esponenziale limitato, i timeout, gli SLA, le procedure di catchup e backfill, la progettazione di task idempotenti per riesecuzioni sicure e una gestione robusta dei fallimenti con cattura in una dead-letter queue. La sicurezza è garantita tramite account di servizio per-pipeline, isolamento dei secret, parametrizzazione e IAM basato sul principio del privilegio minimo. CI/CD, infrastructure as code e una telemetria completa definiscono un approccio pronto per la produzione.

Orchestrazione su Google Cloud: Strumenti e Pattern

Cloud Composer (Airflow)

I DAG definiscono grafi di esecuzione aciclici diretti con dipendenze esplicite. Utilizzare la TaskFlow API o gli operator (es. BigQuery, Dataflow, Dataproc, Cloud Run) per esprimere i task. I Sensor e gli operator differibili riducono il carico sullo scheduler per le condizioni di attesa (es. la finalizzazione di un oggetto in Cloud Storage o la comparsa di una partizione in BigQuery).
Pianificazione: espressioni cron, start_date, end_date e catchup controllano le esecuzioni storiche. Usare il catchup per i backfill; disabilitarlo per destinazioni adiacenti allo streaming o non idempotenti. Limitare la concorrenza con max_active_runs e le pool per proteggere i sistemi downstream.
Dipendenze: set_upstream/set_downstream o dipendenze taskflow. Per l’orchestrazione guidata dai metadati, generare dinamicamente i task da una tabella di controllo in BigQuery (es. lista di clienti/partizioni) usando la mappatura dinamica dei task, mantenendo stabile il tempo di parsing del DAG e rendendo i task guidati dai dati.
Esempio (sintetico) di un frammento di DAG:

undefined

Cloud Workflows, Cloud Scheduler, job di Cloud Run ed esecuzione guidata dagli eventi

Cloud Workflows orchestra le API di Google e gli endpoint HTTP con tentativi integrati, cicli, rami paralleli e logica di compensazione. È ideale per un flusso di controllo leggero tra servizi come BigQuery, Dataflow, Batch e i job di Cloud Run.
Cloud Scheduler attiva Workflows, topic Pub/Sub o servizi HTTP per un’automazione in stile cron. Per un batch giornaliero alle 02:00, pianificare un Workflow che avvia un job di Dataflow o Dataproc.
I job di Cloud Run eseguono passaggi batch containerizzati con tentativi automatici e operazioni minime. Si abbinano bene con Workflows per task di dati multi-step o per la pre/post-elaborazione attorno a Dataflow o BigQuery.
Guidato dagli eventi: usare Eventarc per instradare la finalizzazione di un oggetto in Cloud Storage, i messaggi Pub/Sub o gli Audit Logs verso Cloud Run o Workflows. Per le notifiche di job di inserimento in una singola tabella BigQuery, creare un sink di Cloud Logging con un filtro avanzato verso Pub/Sub, quindi attivare il consumer da quel topic.

Dataform: workflow SQL per BigQuery

Modellare i grafi di dipendenze con ref(), definire tabelle/viste/tabelle incrementali e orchestrare le build tramite tag o pianificazioni. Dataform compila SQLX in piani di esecuzione ordinati, abilitando un’orchestrazione guidata dai metadati a partire da definizioni dichiarative.
Le asserzioni garantiscono la qualità dei dati. Un’asserzione è una query che deve restituire zero righe per avere successo. Esempio di asserzione:

undefined

Release e controlli del repository: archiviare il codice in un repository, usare branch e revisioni, e promuovere le release taggate verso gli ambienti (es. dev, test, prod) con variabili specifiche per l’ambiente. Controllare i deploy tramite verifiche CI/CD e i risultati delle asserzioni.

Pattern per Dataproc, Dataflow e storage

Per il riutilizzo di Hadoop/Spark con operazioni minime, usare Dataproc con il connettore GCS per rendere persistenti i dati oltre la vita del cluster e minimizzare il costo dei dischi persistenti. Creare cluster effimeri per job per l’isolamento e il controllo dei costi; orchestrare con Composer o Workflows.
Per l’ingestion batch con righe malformate, eseguire Dataflow per scrivere i record validi in BigQuery e instradare gli errori di parsing/validazione verso una tabella dead-letter in BigQuery per ispezione.

Affidabilità, gestione dei guasti e idempotenza

Tentativi, timeout e backoff

Utilizzare il backoff esponenziale limitato (bounded exponential backoff) per i guasti transitori e limitare le finestre di tentativi totali all’SLA del job. Ad esempio, un frontend o un task che interroga un database ogni 15 minuti dovrebbe ritentare con un backoff esponenziale fino a 15 minuti, per poi presentare un errore controllato.
Configurare execution_timeout per-task e SLA globali per i DAG in Airflow; in Workflows, impostare timeout per-step e policy di tentativi con max_doublings e max_retry_duration. Per i job di Cloud Run, impostare il conteggio dei tentativi e il backoff.

Backfill, catchup e gestione dei guasti

Abilitare il catchup per il ricalcolo storico quando i task sono idempotenti e le fonti sono partizionate per data. Per output non deterministici o effetti collaterali esterni, considerare l’uso di DAG di solo backfill o tabelle di write-audit per tracciare ciò che è stato prodotto.
Utilizzare topic/tabelle dead-letter per i fallimenti a livello di record nelle trasformazioni streaming/batch. Per Dataflow in modalità batch, catturare le righe errate con tag di errore e aggregare le metriche di errore; per lo streaming, usare le DLQ di Pub/Sub.

Progettazione di task idempotenti e riesecuzioni

BigQuery: preferire MERGE o INSERT con chiavi di de-duplicazione; usare insertId per deduplicare gli inserimenti in streaming. Per il batch, scrivere in una tabella di staging e poi eseguire il MERGE nella destinazione all’interno di un passo transazionalmente sicuro per consentire riesecuzioni complete.
Cloud Storage: utilizzare precondizioni di generazione e nomi di oggetti deterministici (ad es. prefisso/data/hash) in modo che le riesecuzioni sovrascrivano in sicurezza solo quando previsto.
Pub/Sub e Dataflow: progettare per una consegna at-least-once (almeno una volta). Includere identificatori di messaggio (ad es. ID del pacchetto, timestamp logico dell’evento) in modo che i sistemi a valle (downstream) possano deduplicare e gestire la latenza. Se le regole di business accettano la semantica “il primo evento elaborato vince”, documentare tale compromesso e monitorare lo skew (disallineamento); altrimenti, risolvere i vincitori in base all’event time con dei tie-breaker (criteri di spareggio).
Ripristino da un fallimento parziale: partizionare gli output per run_id o data, scrivere marcatori di completamento (completion markers) e rendere i task a valle dipendenti da tali marcatori. Rielaborare solo le partizioni contrassegnate come incomplete.

Risoluzione dei problemi e scalabilità

Quando una dashboard di streaming non mostra degli eventi ma Pub/Sub indica che sono presenti, eseguire un set di dati fisso e noto attraverso la pipeline Dataflow per isolare i difetti di trasformazione. Validare il windowing (finestre temporali), i trigger e la latenza consentita (allowed lateness).
Modalità di fallimento comune: creare una pipeline di streaming senza windowing/trigger appropriati per sorgenti illimitate (unbounded) o usare una finestra partizionata (sharded window) in modo errato può causare il fallimento della creazione della pipeline o un’esplosione dello stato (state blowup).
Scalare Dataflow tramite max workers e l’algoritmo di autoscaling; per i picchi (ad es. 50.000 installazioni), aumentare il numero massimo di worker per consentire la scalabilità orizzontale durante i picchi.

Sicurezza, parametrizzazione, ambienti e CI/CD

Parametrizzazione e gestione della configurazione

Esternalizzare la configurazione per ambiente. In Composer, usare Variables, Connections e variabili d’ambiente; parametrizzare i parametri dei DAG tramite template in base alla data di esecuzione o alla partizione. In Workflows, usare argomenti di runtime e workflow separati per ambiente, oppure leggere la configurazione da Secret Manager.
Utilizzare l’orchestrazione basata su metadati (metadata-driven) leggendo una tabella di controllo (ad es. un dataset di configurazione in BigQuery) che elenca client, sorgenti o partizioni. Generare i task dinamicamente in modo che le modifiche al codice siano disaccoppiate dalle modifiche guidate dai dati.

Segreti, service account e principio del privilegio minimo

Archiviare le credenziali in Secret Manager e farvi riferimento a runtime. Evitare di incorporare segreti nel codice o nelle Variables di Airflow.
Assegnare un service account distinto per ogni pipeline con i ruoli IAM minimi necessari. Per l’accesso regolamentato a BigQuery, isolare i dati dei clienti in dataset separati, concedere ruoli specifici per dataset solo agli utenti approvati e limitare l’accesso all’API di BigQuery solo ai principal approvati. Per la multitenancy, creare un dataset per cliente e associare (bind) solo i ruoli appropriati.

CI/CD e infrastruttura come codice (IaC)

Gestire l’infrastruttura (ambienti Composer, Workflows, job di Scheduler, topic di Pub/Sub, log sink) con Terraform. Usare i moduli per standardizzare progetti/ambienti, segreti e service account.
Compilare e testare il codice della pipeline con Cloud Build o GitHub Actions. Automatizzare test unitari, linting SQL, dry-run di Dataform e validazione dei DAG di Airflow. Promuovere gli artefatti tramite tag; per Composer, impacchettare i DAG come bundle distribuibili; per Dataform, usare branch di rilascio che promuovono il codice dopo il superamento delle asserzioni.
Promozione del deployment: dev → test → prod tramite progetti separati e configurazioni parametrizzate. Utilizzare la continuous delivery con gate di approvazione manuale e finestre di modifica (change windows) per le promozioni ad alto rischio.

Osservabilità, Alerting e Runbook

Telemetria e alerting

Indirizzare tutti i log di orchestrazione a Cloud Logging con campi strutturati (pipeline, dag_id, run_id, task_id, partition). Esportare i log di errore in Monitoring tramite metriche basate su log. Impostare alert per:
- Mancate esecuzioni pianificate o violazioni degli SLA
- Fallimenti consecutivi dei task
- Crescita del backlog (es. messaggi non confermati (unacked) in Pub/Sub, ritardo di sistema (system lag) in Dataflow)
- Fallimenti delle asserzioni sulla qualità dei dati
Cloud Composer: monitorare la durata di DAG/task, il tasso di successo, la profondità della coda e lo stato di salute dello scheduler. Configurare on_failure_callback per il paging e i runbook di remediation.
Cloud Workflows: ispezionare i log di esecuzione e le latenze dei passaggi; aggiungere tentativi di riesecuzione (retry) espliciti e gestori di errori; emettere log personalizzati con ID di correlazione.
Notifiche di modifica delle tabelle BigQuery: creare un sink di Logging a livello di progetto con un filtro avanzato per i job di inserimento che hanno come target una tabella specifica ed esportare su Pub/Sub; lo strumento di monitoraggio si sottoscrive al topic per ricevere alert istantanei senza il rumore generato da altre tabelle.

Progettazione dei runbook

Per ogni pipeline, documentare trigger, dipendenze, SLA, procedure di rollback/retry e passaggi sicuri per il backfill. Includere il “replay di un dataset fisso” per Dataflow, come eseguire il drain di un job di streaming, come riprocessare le partizioni fallite e come effettuare la remediation dei messaggi nella DLQ.
Acquisire le signature di fallimento comuni (es. permission denied, quota exceeded, schema mismatch) con alberi decisionali e percorsi di escalation.

Scenario di un Problema Pratico

Acme Retail Analytics ha la necessità di ingerire quotidianamente file CSV forniti da partner, che occasionalmente contengono righe malformate. Deve trasformare e caricare i dati validi in BigQuery e far emergere le righe errate per l’analisi. Vuole anche un arricchimento event-driven per aggiornamenti dei prezzi quasi in tempo reale e una promozione sicura dall’ambiente di sviluppo (dev) a quello di produzione (prod).

Approccio:

Storage e trigger basati su eventi
- Creare un bucket Cloud Storage dedicato con versioning degli oggetti e accesso uniforme a livello di bucket. Abilitare le notifiche di finalizzazione dell’oggetto verso Pub/Sub tramite Eventarc.
- Motivazione: La finalizzazione di un oggetto è un evento affidabile per avviare l’ingestion a valle; il versioning supporta le riesecuzioni e gli audit.
Ingestion batch con gestione dei messaggi non recapitabili (dead-letter)
- Usare Cloud Composer per pianificare un DAG Airflow giornaliero alle 02:00 con catchup abilitato. Il DAG avvia un job batch di Dataflow che effettua il parsing dei CSV, valida lo schema e scrive i record validi in BigQuery usando tabelle di staging deterministiche, per poi eseguire un’operazione di MERGE nelle tabelle di destinazione partizionate. Indirizzare i record malformati/falliti a una tabella dead-letter in BigQuery.
- Motivazione: Dataflow scala il parsing/validazione; l’operazione MERGE garantisce l’idempotenza; l’acquisizione in una tabella dead-letter supporta l’ispezione senza bloccare la pipeline, in linea con il pattern raccomandato per le righe malformate.
Arricchimento event-driven
- Eseguire il deploy di un job Cloud Run per effettuare un arricchimento leggero (lightweight) per gli aggiornamenti incrementali dei prezzi. Attivarlo tramite Cloud Workflows in ascolto dei messaggi Pub/Sub da Eventarc quando arrivano piccoli file di aggiornamento durante il giorno.
- Motivazione: I container serverless con Workflows forniscono un’orchestrazione a bassa latenza e con basso carico operativo (low-ops) per piccoli eventi, mantenendo le trasformazioni pesanti in modalità batch.
Controlli di affidabilità
- Configurare retry con backoff esponenziale per i fallimenti transitori nei job Dataflow e Cloud Run, limitando il tempo totale di retry in base allo SLA del DAG. Impostare timeout di esecuzione per singolo task e callback on_failure in Airflow; in Workflows, impostare max_doublings e max_retry_duration.
- Motivazione: Il backoff limitato preserva gli SLA e previene retry incontrollati.
Sicurezza e principio del privilegio minimo (least privilege)
- Eseguire ogni componente con un service account dedicato: SA dell’orchestratore Composer, SA del worker Dataflow, SA del job Cloud Run. Concedere solo i ruoli necessari: GCS read sul bucket di ingest a Dataflow, BigQuery dataEditor sui dataset di destinazione e Viewer sui log. Archiviare i secret in Secret Manager e farvi riferimento a runtime.
- Motivazione: Applica il principio del privilegio minimo e isola il raggio d’impatto (blast radius).
Orchestrazione guidata da metadati
- Mantenere una tabella di controllo in BigQuery che elenchi le fonti dei partner, i pattern dei file e i dataset di destinazione. A runtime del DAG, Airflow interroga questa tabella e utilizza la mappatura dinamica dei task per generare task specifici per partner.
- Motivazione: L’aggiunta di un partner diventa una modifica ai dati, non una modifica al codice, riducendo il rischio di deployment.
Osservabilità e alerting
- Emettere log strutturati con run_id e partner_id. Creare policy di alerting per le violazioni degli SLA dei DAG, il system lag di Dataflow e i conteggi non nulli nella tabella dead-letter. Per gli inserimenti in BigQuery nella tabella di destinazione, configurare un sink di Cloud Logging con un filtro avanzato per quella tabella verso un topic Pub/Sub utilizzato dallo strumento di monitoraggio di Acme.
- Motivazione: Alert granulari consentono un triage rapido e senza rumore di fondo.
CI/CD e promozione
- Gestire l’infrastruttura (bucket, Pub/Sub, Eventarc, Composer, Workflows, dataset BigQuery) con Terraform. Usare Cloud Build per validare la sintassi dei DAG di Airflow, eseguire gli unit test ed effettuare il deploy in un ambiente Composer di sviluppo. Promuovere agli ambienti di test e produzione con configurazioni parametrizzate e gate di approvazione manuale dopo il superamento delle asserzioni di Dataform e dei test di integrazione.
- Motivazione: Deployment dichiarativi e ripetibili e promozione sicura tra gli ambienti.
Runbook e ripristino
- Documentare i passaggi per rieseguire (replay) i dati di una data specifica: ripristinare il CSV dal versioning degli oggetti, rieseguire il job Dataflow per quella partizione, eseguire il MERGE dei risultati e rivedere i record della DLQ. Includere una procedura di “replay di un dataset fisso” per isolare i bug di trasformazione in caso di discrepanze.
- Motivazione: Un design idempotente e un ripristino documentato semplificano la remediation di fallimenti parziali.