Amazon DEA-C01: Trasformazione ed elaborazione dei dati — 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.

Questo dominio copre i servizi e i pattern AWS utilizzati per pulire, trasformare e preparare i dati per l’analisi e il ML su larga scala. Si concentra sulla selezione del giusto strumento di calcolo (Glue, Lambda, EMR, DataBrew) in base al volume dei dati, ai requisiti di latenza e ai vincoli di costo. Comprendere i limiti dei servizi, i parametri di configurazione dei processi e come interagiscono i formati dei dati e i cataloghi è fondamentale per costruire pipeline affidabili e incrementali.

Processi ETL di AWS Glue (Spark e Python shell)

I processi Glue Spark sono la scelta principale per l’ETL distribuito su larga scala: vengono eseguiti su Apache Spark gestito da AWS Glue, utilizzano il GlueContext e operano sui tipi DynamicFrame e Spark DataFrame. Si configurano tramite la console o la CLI con il tipo di processo “glueetl”, workerType (G.1X, G.2X, G.4X) e NumberOfWorkers; si avviano con la CLI: aws glue start-job-run –job-name my-spark-job –arguments ‘–execution-class=STANDARD’. Utilizzare le API DynamicFrame (create_dynamic_frame.from_options, apply_mapping) quando si necessita di trasformazioni con schema flessibile, trasformazioni integrate (Relationalize, Unnest) e gestione automatica di dati semi-strutturati; convertire in Spark DataFrame con dyf.toDF() quando si necessita di Spark SQL, join ad alte prestazioni o UDF personalizzate.

I processi Glue Python shell utilizzano il tipo di processo “pythonshell” per attività di scripting leggero e di control-plane. Sono a singola DPU (1 DPU) con parallelismo limitato e sono ideali per piccole manipolazioni di file, aggiornamenti di metadati o orchestrazione. Si configurano tramite aws glue create-job –name my-pyjob –command ‘{“Name”:“pythonshell”,“PythonVersion”:“3”}’ e si avviano con aws glue start-job-run. Notare che i processi Python shell hanno un limite di 1 DPU — usare Spark per dataset di grandi dimensioni.

I bookmark dei processi Glue abilitano l’elaborazione incrementale tracciando gli oggetti S3 e le partizioni già elaborate in precedenza. Abilitare i bookmark nella configurazione del processo o all’avvio delle esecuzioni: aws glue start-job-run –job-name my-job –job-bookmark-option job-bookmark-enable. I bookmark funzionano per le origini dati basate su S3 che utilizzano i connettori integrati; le origini JDBC non supportano i bookmark di default e richiedono un watermarking personalizzato o un meccanismo di archiviazione dello stato.

Glue ora supporta ExecutionClass FLEX per processi non urgenti e ottimizzati per i costi. Avviare con aws glue start-job-run –job-name my-job –execution-class FLEX per consentire a Glue di pianificare il processo a un costo inferiore con SLA sui tempi di avvio più rilassati. Usare FLEX per i backfill in batch e per i carichi di lavoro non sensibili alla latenza; usare STANDARD per una latenza prevedibile.

Criteri decisionali — un rapido confronto:

DynamicFrame vs Spark DataFrame
- Usare DynamicFrame per l’ingestion di dati semi-strutturati JSON/Parquet con schema drift, sfruttando apply_mapping, relationalize e le trasformazioni di Glue.
- Usare Spark DataFrame quando si necessita delle prestazioni di Spark SQL, di join complessi, di window functions e di librerie Spark di terze parti.
- Convertire tra i due tipi tramite DynamicFrame.fromDF(df, glueContext, “name”) e dyf.toDF().
Glue Spark vs Python shell
- Scegliere Spark per ETL distribuito multi-nodo su dataset di grandi dimensioni e quando si utilizza l’integrazione con il Glue Catalog su larga scala.
- Scegliere Python shell per attività piccole e veloci o per passaggi di orchestrazione che rientrano nel limite di 1 DPU.

AWS Lambda per trasformazioni leggere

Lambda è ideale per trasformazioni leggere, a bassa latenza e guidate dagli eventi, attivate direttamente da S3, Kinesis o EventBridge. Gli usi tipici includono la validazione di file, l’estrazione di metadati, la conversione da JSON a CSV per file di piccole dimensioni o l’elaborazione in streaming di record. Configurare memoria e timeout con aws lambda update-function-configuration –function-name myFunc –memory-size 2048 –timeout 300. La Provisioned Concurrency può essere impostata con aws lambda put-provisioned-concurrency-config per mitigare i cold start per le pipeline di streaming sensibili alla latenza.

Tenere presenti i limiti di Lambda per l’elaborazione dei dati: 15 minuti di esecuzione massima, 10 GB di memoria (10.240 MB) e solo 512 MB di storage effimero in /tmp. Per l’elaborazione di file più grandi, concatenare l’elaborazione (suddividere i file), effettuare lo staging su S3 e invocare un processo Glue o EMR, oppure utilizzare l’elaborazione multi-part con AWS Step Functions. Usare le variabili d’ambiente per piccole configurazioni e policy di ruolo IAM che concedano rigorosamente il principio del privilegio minimo.

Criteri decisionali — quando scegliere Lambda:

Usare Lambda quando l’elaborazione per singola invocazione rientra nei vincoli di 15 minuti, 10 GB di memoria e 512 MB in /tmp e quando è richiesta una latenza da sub-secondo a secondo.
Evitare di usare Lambda per trasformazioni di grandi dimensioni, di lunga durata o con un elevato consumo di memoria; usare invece Glue Spark o EMR.

Amazon EMR per l’elaborazione su larga scala

EMR è la soluzione di riferimento per l’elaborazione personalizzabile di big data su larga scala (Spark, Hadoop, Presto, Flink) dove è richiesto un controllo a livello di cluster, azioni di bootstrap personalizzate o librerie specializzate. È possibile creare cluster tramite CLI con aws emr create-cluster e scegliere tra --instance-groups o --instance-fleets. Gli instance fleet offrono combinazioni flessibili di tipi di istanza e un mix di istanze spot/on-demand; gli instance group sono gruppi più semplici e a dimensione fissa.

Pattern di cluster EMR da considerare:

Cluster transitori: si avviano con --auto-terminate e inviano step in modo che il cluster si termini al completamento degli step. Ideale per il controllo dei costi, ma lo stato locale e l’HDFS effimero andranno persi alla terminazione.
Cluster a lunga esecuzione: non si terminano automaticamente; si usano per carichi di lavoro interattivi, HDFS persistente o quando molti piccoli job beneficiano del riscaldamento della JVM. Persistere i dati critici su S3 o su uno storage Hadoop basato su EBS se è prevista la terminazione del cluster.

Esempi di configurazione:

CLI con instance group: aws emr create-cluster --name Prod --release-label emr-6.6.0 --use-default-roles --instance-groups InstanceGroupType=MASTER,InstanceType=m5.xlarge,InstanceCount=1 InstanceGroupType=CORE,InstanceType=m5.xlarge,InstanceCount=4
La CLI per gli instance fleet utilizza --instance-fleets con allocazioni OnDemand/Spot e tipi di istanza multipli per resilienza e ottimizzazione dei costi.

Utilizzare EMR quando si necessita del pieno controllo sui componenti dell’ecosistema Hadoop, di script di bootstrap personalizzati o di un HDFS persistente per dati intermedi; altrimenti, Glue Spark è più semplice per ETL Spark gestiti che si integrano con il Glue Data Catalog.

Glue DataBrew e trasformazioni visuali

Glue DataBrew è uno strumento visuale, no-code/low-code, per il profiling, la pulizia e la trasformazione dei dati, rivolto a data analyst e ingegneri che lavorano in modo interattivo. Si crea un dataset da S3 o dal Glue Catalog, si costruisce una “recipe” di trasformazioni nella console, se ne visualizza l’anteprima su un campione e si eseguono job per applicare le recipe su larga scala. È possibile schedulare i job di DataBrew o eseguirli tramite CLI con aws databrew start-job-run --name my-databrew-job.

DataBrew è ottimizzato per attività di preparazione dei dati come standardizzazione, deduplicazione, conversione di tipo e trasformazioni a livello di colonna con funzioni integrate. Si integra con il Glue Catalog e scrive gli output su S3. Scegliere DataBrew quando gli utenti business necessitano di pulizia self-service e profiling rapido; per logiche di trasformazione pesanti, join complessi o set di dati molto grandi, preferire Glue Spark o EMR.

Confronto tra trasformazioni visuali e basate su codice:

Glue DataBrew
- Pro: profiling rapido, basato su recipe, creazione di pipeline senza codice, schedulazione integrata.
- Contro: non adatto per join distribuiti molto grandi o complessi e per librerie personalizzate.
Glue Spark / EMR
- Pro: controllo programmatico completo, gestisce set di dati massivi, supporta librerie di terze parti.
- Contro: richiede competenze da sviluppatore e una maggiore configurazione.

Errori Comuni e Criteri Decisionali

Presumere che i job bookmark di Glue funzionino per le sorgenti JDBC — i bookmark tracciano solo lo stato degli oggetti/partizioni S3; per caricamenti incrementali da JDBC, utilizzare colonne watermark, change-data-capture o memorizzare l’avanzamento in DynamoDB/S3.
Trattare i cluster EMR transitori come sistemi stateful — i cluster transitori terminano dopo gli step e perdono l’HDFS; persistere i dati intermedi su S3 o usare volumi EBS per uno storage durevole.
Ignorare i cold start di Lambda nelle pipeline di streaming — i cold start aumentano la latenza; mitigare con la provisioned concurrency per i percorsi critici o utilizzare risorse di calcolo a lunga esecuzione per requisiti di bassa latenza stringenti.
Eseguire grandi trasformazioni in una Glue Python shell — i job Python shell sono limitati a 1 DPU; per set di dati di grandi dimensioni, utilizzare job Glue Spark con workerType/NumberOfWorkers appropriati.
Configurare in modo errato i tipi di istanza EMR: scegliere gli instance fleet per costi e flessibilità con le istanze spot; usare gli instance group quando si necessita di una composizione di istanze prevedibile.
Utilizzare eccessivamente Glue Flex per carichi di lavoro urgenti — FLEX riduce i costi ma può ritardare i tempi di avvio; usare STANDARD per tempi di avvio ed esecuzione prevedibili.

Problema Pratico: Scenario d’Uso

AcmeRetail elabora file Parquet di clickstream notturni in una tabella unificata delle attività dei clienti e desidera un’elaborazione incrementale per evitare di rielaborare mesi di dati, mantenendo bassi i costi per i backfill non urgenti.

Utilizzare un layout partizionato su S3 (year=/month=/day=) e registrare il set di dati nel Glue Data Catalog.
Creare un job Glue Spark (glueetl) che legge da DynamicFrame.from_catalog per flessibilità dello schema, applica mappature, converte in DataFrame per join complessi e scrive nuovamente su S3 in formato Parquet partizionato.
Abilitare i job bookmark di Glue (job-bookmark-enable) per le esecuzioni notturne per elaborare solo le nuove partizioni; per le fonti di arricchimento JDBC, implementare colonne watermark persistite in DynamoDB per tracciare il timestamp massimo elaborato.
Per le esecuzioni notturne di routine, utilizzare ExecutionClass=STANDARD; per la rielaborazione storica non urgente, inviare le esecuzioni con --execution-class FLEX per risparmiare sui costi.
Monitorare con le metriche di CloudWatch e impostare allarmi per i fallimenti dei job; per scale molto grandi o librerie personalizzate, considerare cluster EMR transitori che scrivono i risultati intermedi su S3 e si auto-terminano.

Razionale: Questo approccio sfrutta lo Spark gestito di Glue per trasformazioni scalabili e i DynamicFrame per input semi-strutturati, utilizza i job bookmark per l’elaborazione incrementale da S3 e usa FLEX per ridurre i costi dei backfill, preservando costi, affidabilità e semplicità operativa.

← Catalogazione dei dati e gestione dei metadati · Tutti i domini · Orchestrazione dei dati e gestione del workflow →

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