Amazon DEA-C01: Orchestrazione dei dati e gestione del workflow — Guida allo studio

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

Fa parte della Amazon Data Engineer Associate DEA-C01 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

L’orchestrazione e la gestione dei flussi di lavoro (workflow) sono centrali per la creazione di piattaforme dati affidabili e manutenibili: coordinano i processi di estrazione, trasformazione e caricamento (ETL), gestiscono le dipendenze, gestiscono i fallimenti e integrano processi basati su eventi (event-driven). Questo dominio copre le opzioni gestite di AWS per l’ETL batch, i DAG complessi, le macchine a stati serverless e la pianificazione di eventi — ognuna con diverse semantiche di esecuzione, durabilità e compromessi di scalabilità. Comprendere quando utilizzare AWS Glue Workflows, MWAA, Step Functions o EventBridge Scheduler — e come configurare la gestione degli errori e l’osservabilità — è fondamentale per avere pipeline prevedibili e per il controllo dei costi operativi.

AWS Glue Workflows e trigger

AWS Glue Workflows raggruppa job, crawler e trigger di Glue in un grafo di dipendenze e consente di eseguire ETL coordinati. Crea i workflow tramite la console o la CLI (aws glue create-workflow –name MyWorkflow). I trigger si collegano ai workflow e sono di tre tipi: pianificati (scheduled), su richiesta (on-demand) e condizionali (conditional). Esempio di creazione tramite CLI per un trigger pianificato:

aws glue create-trigger –name hourly-trigger –workflow-name MyWorkflow –type SCHEDULED –schedule “cron(0 * * * ? *)” –actions ‘[{“JobName”:“etl-job”}]’

I trigger condizionali utilizzano un Predicate che fa riferimento al nome e allo stato del job (SUCCEEDED, FAILED). Esempio di JSON per un predicato: {“Logical”:“AND”,“Conditions”:[{“JobName”:“prev-job”,“State”:“SUCCEEDED”}]}. Di default, i trigger condizionali di Glue si attivano in caso di successo; per gestire i fallimenti, configura le condizioni con State=FAILED o crea un trigger esplicito di tipo FAILED per instradare gli errori verso job di ripristino o alert SNS.

Pattern operativi e criteri decisionali:

Usa Glue Workflows quando hai bisogno di orchestrazione nativa di job/crawler di Glue e della loro discendenza (lineage); scegli i trigger per la pianificazione cron o per concatenare i job al loro completamento.
Per l’invocazione ad-hoc, usa aws glue start-workflow-run –name MyWorkflow o start-trigger per i trigger on-demand.
Per ramificazioni complesse o task non legati a Glue, preferisci Step Functions o MWAA; i workflow di Glue sono ideali quando la pipeline è incentrata su Glue.

Gestione degli errori: aggiungi trigger di tipo FAILED, emetti metriche CloudWatch per il successo/fallimento dei job e invia i fallimenti a una coda dead-letter (DLQ) SQS/SNS tramite Lambda per tentativi automatici e indagini.

Amazon MWAA (Managed Airflow) per DAG complessi

MWAA fornisce un ambiente gestito Apache Airflow per esprimere DAG complessi, dipendenze tra task, sensori e operatori personalizzati. Crea gli ambienti con aws mwaa create-environment –name MyEnv –airflow-configuration-options Key=core.executor,Value=CeleryExecutor fornendo un percorso S3 per i DAG e un ruolo di esecuzione. Dettagli importanti su dimensionamento e networking:

MWAA richiede un VPC con sottoreti private e un NAT gateway per l’accesso a Internet; le configurazioni con solo sottoreti pubbliche non sono supportate.
Il comportamento dei worker e dello scheduler è controllato tramite le opzioni di configurazione di Airflow (AirflowConfigurationOptions) fornite alla creazione dell’ambiente. Ottimizza celery.worker_concurrency, celery.worker_autoscale e le impostazioni dello scheduler per farli corrispondere alla concorrenza dei task e alla complessità dei DAG.
Monitora le metriche CloudWatch (SchedulerHeartbeat, TasksFailed, TasksRunning, QueuedTasks) e scala gli autoscaler dei worker o aumenta il numero massimo di worker quando osservi una crescita della coda.

Criteri decisionali:

Usa MWAA quando hai bisogno delle funzionalità di Airflow: DAG complessi, operatori avanzati, dipendenze tra DAG diversi, sensori per SLA/task mancati e logica Python personalizzata.
Se i task sono di breve durata e con un throughput estremamente elevato, preferisci le opzioni serverless come Step Functions Express o Glue per operazioni ETL gestite.
Mantieni i task pesanti e di lunga durata su servizi di calcolo gestiti (Glue/EMR/EKS) e usa i task di MWAA solo per l’orchestrazione — evita di eseguire trasformazioni di dati massive direttamente sui worker di MWAA.

Gestione degli errori in Airflow: utilizza i tentativi (retries) e il retry_delay nelle definizioni dei DAG, imposta on_failure_callback per notificare o inviare a una coda dead-letter SQS e configura la gestione degli SLA a livello di task per attivare DAG di ripristino.

AWS Step Functions per l’orchestrazione serverless

Step Functions fornisce un’orchestrazione stateful con un linguaggio basato su JSON chiamato Amazon States Language e si integra ampiamente con i servizi AWS. Scegli tra workflow Standard ed Express:

Workflow Standard: progettati per macchine a stati durature e di lunga esecuzione (da mesi ad anni), con semantica di esecuzione exactly-once (univoca), cronologia di esecuzione integrata e tracciamento/logging per singola esecuzione. Avvia con aws stepfunctions start-execution –state-machine-arn arn:… –input ‘{“key”:“value”}’.
Workflow Express: ottimizzati per elaborazioni ad alto throughput, bassa latenza e breve durata, e sono convenienti su larga scala; utilizzano una semantica di esecuzione at-least-once, quindi i task devono essere idempotenti o utilizzare pattern di deduplicazione.

Casi d’uso e criteri decisionali:

Usa gli Standard quando hai bisogno di workflow duraturi e verificabili che possono durare a lungo e richiedono una semantica once-only.
Usa gli Express per micro-orchestrazioni basate su eventi con migliaia di esecuzioni al secondo, dove la breve durata e l’efficienza dei costi sono importanti, e puoi progettare task idempotenti o deduplicare a valle.

Pattern di gestione degli errori e di integrazione:

Usa i blocchi Retry in ASL per definire i tentativi con ErrorEquals, IntervalSeconds, BackoffRate e MaxAttempts.
Usa i blocchi Catch per reindirizzare i fallimenti a rami alternativi o a uno stato di Fail/Success e per popolare ResultPath con i dettagli dell’errore per la diagnostica.
Per il dead-lettering asincrono, invia i messaggi falliti a SQS/SNS o progetta un pattern di Step Functions che invia i payload degli errori a una DLQ SQS per l’elaborazione offline. Abilita i log di CloudWatch e il tracciamento X-Ray tramite LoggingConfiguration e TracingConfiguration per l’osservabilità.

EventBridge Scheduler e pipeline basate su eventi

EventBridge offre un routing degli eventi avanzato e una funzionalità Scheduler per attività cron e una tantum. È possibile creare regole basate su pianificazione con

undefined

e collegare destinazioni (target) tramite

undefined

. Per il routing basato su eventi (pattern), si usa put-rule con

undefined

per instradare eventi S3 verso Lambda, Step Functions o SQS.

Punti operativi chiave:

EventBridge supporta espressioni di pianificazione (cron e rate). Bisogna tenere presente l’intervallo minimo di 5 minuti per le regole EventBridge quando si usano espressioni rate; per una granularità più fine, considerare Step Functions o un livello di polling.
Usare EventBridge Scheduler per invocazioni future una tantum e ad hoc, e per pianificazioni ricorrenti; lo Scheduler supporta fusi orari e impostazioni di tentativi (retry) flessibili per ogni target e può configurare una coda SQS di messaggi non recapitabili (dead-letter queue) per le invocazioni non andate a buon fine.
Per pipeline ad alta affidabilità, collegare target come Step Functions, Lambda o SQS e configurare policy di retry e DLQ per ogni target. Ad esempio, put-targets accetta una DeadLetterConfig con l’ARN di una coda SQS.

Gestione degli errori: configurare tentativi di retry e backoff specifici per il target, usare una DLQ per le consegne fallite e combinare EventBridge con Step Functions per la gestione di errori complessi e transazioni di compensazione.

Errori Comuni e Criteri Decisionali

Errore: Usare Express Workflows per attività non idempotenti. Approccio corretto: progettare l’idempotenza (chiavi di deduplicazione, Lambda idempotenti) o usare Standard Workflows per una semantica “exactly-once”.
Errore: Presumere che i trigger condizionali di Glue si attivino in caso di fallimento. Approccio corretto: creare esplicitamente trigger per lo stato FAILED o includere State=FAILED nel Predicate del trigger per instradare gli errori.
Errore: Distribuire MWAA in subnet pubbliche o senza NAT. Approccio corretto: posizionare MWAA in subnet private e fornire un NAT gateway o VPC endpoint per l’accesso ai servizi richiesti.
Errore: Aspettarsi pianificazioni su EventBridge inferiori al minuto. Approccio corretto: ricordare che le regole di EventBridge hanno un intervallo minimo di 5 minuti; usare Step Functions o timer Lambda per esigenze inferiori ai 5 minuti.
Errore: Mancanza di una strategia centralizzata di retry/catch tra i servizi. Approccio corretto: standardizzare i tentativi e il backoff (Retry ASL, configurazione di retry di EventBridge, retry di Airflow) e usare le DLQ per conservare gli eventi falliti per una risoluzione manuale o automatizzata.
Errore: Sovraccaricare i worker di MWAA con elaborazioni di dati pesanti. Approccio corretto: usare MWAA solo per l’orchestrazione, eseguire le trasformazioni pesanti su Glue/EMR/EKS e passare puntatori (percorsi S3) tra le attività.

Problema Pratico: ETL orario con picchi di Acme Retail

Acme Retail necessita di un ETL orario che esegua job Glue per l’ingestion di dati grezzi, un DAG di arricchimento complesso con operatori Python e un’aggregazione di SKU di breve durata che deve rispondere a eventi di inventario ad alta frequenza. Richiedono meccanismi robusti di retry e di cattura dei fallimenti.

Usare EventBridge per attivare una regola pianificata oraria che invochi uno Standard Workflow di Step Functions per coordinare la pipeline complessiva.
In Step Functions, orchestrare i job Glue a lunga esecuzione (StartJobRun) con gestori Retry e Catch; in caso di fallimento, instradare verso una DLQ SQS e una Lambda di remediation tramite un blocco Catch.
Distribuire i DAG di arricchimento complessi in MWAA e invocarli da Step Functions usando la REST API di Airflow o inserendo messaggi di avvio del DAG in SQS; dimensionare i worker di MWAA tramite le impostazioni celery.worker_autoscale in base alla concorrenza prevista e monitorare le metriche di CloudWatch per eventuali aggiustamenti.
Per gli eventi di inventario ad alta frequenza, usare regole event-pattern di EventBridge per inviare gli eventi a un Express Step Function o a una Lambda con chiavi di idempotenza e una DLQ basata su SQS per assorbire i picchi.
Implementare un monitoraggio centralizzato (CloudWatch Logs/Metrics, X-Ray per Step Functions) e impostare allarmi sulla crescita della DLQ e sull’esaurimento dei tentativi delle attività.

Motivazione: Questo design utilizza lo strumento giusto per ogni requisito — Step Functions per l’orchestrazione durevole tra servizi e la gestione degli errori, MWAA per la logica complessa dei DAG, Glue per l’ETL gestito, ed EventBridge per la pianificazione e gli eventi reattivi. Impone l’idempotenza e l’uso di DLQ per pipeline resilienti e osservabili, in linea con le best practice di AWS.

← Trasformazione ed elaborazione dei dati · Tutti i domini · Query e analytics dei dati →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →