Amazon DEA-C01: Query e analytics 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 la progettazione, l’ottimizzazione e la gestione dei servizi AWS che supportano query analitiche e di BI su grandi set di dati. Si concentra su pattern di query efficienti in termini di costi e ad alte prestazioni su Athena, Redshift, OpenSearch e QuickSight, e su come questi interagiscono con S3, Glue e archivi transazionali. La padronanza richiede di bilanciare il formato di archiviazione, il partizionamento, il tipo di calcolo e il posizionamento dei dati per minimizzare i byte scansionati e lo sbilanciamento di rete (network skew), fornendo al contempo insight a bassa latenza.

Ottimizzazione delle query di Amazon Athena

Il prezzo di Athena si basa sui byte scansionati, quindi la disposizione fisica dei dati e i metadati sono le leve principali. Utilizzare formati colonnari (Parquet o ORC) con compressione (Snappy per Parquet, opzioni Zlib/ORC) per ridurre le dimensioni e l’uso della CPU. Partizionare i dati per colonne ad alta cardinalità e filtrate nelle query (data, regione) e registrare le partizioni nel Glue Data Catalog. Pattern tipici:

Scrivere i dati su S3 in percorsi come s3://bucket/events/date=2026-08-02/ e usare i crawler di Glue o

undefined

per popolare le partizioni.

Usare

undefined

per imporre la compressione colonnare.

Usare la proiezione e il partition pruning tramite clausole

undefined

che fanno riferimento a chiavi di partizione per evitare di scansionare partizioni non necessarie.

Quando le query richiedono join con archivi transazionali, usare Athena Federated Query (connettori Lambda) per eseguire join tra diverse fonti con RDS, DynamoDB o Redshift. I connettori vengono distribuiti come funzioni Lambda e registrati come fonti di dati in Athena; flusso di esempio nella console: Athena > Data sources > Connectors > New. Criteri decisionali:

Usare Federated Query quando i volumi di dati in RDS/DynamoDB sono modesti o quando si unisce una piccola tabella dimensionale a un grande set di dati S3.
Per join pesanti e ripetuti, estrarre e materializzare i dati operativi in S3 (Parquet) per spostare il costo del join su un singolo ETL e usare Athena per le letture ripetute.

Ottimizzazione delle query e distribuzione in Amazon Redshift

Le prestazioni di Redshift dipendono dallo stile di distribuzione (distribution style) e dalle chiavi di ordinamento (sort key) per minimizzare lo spostamento dei dati e abilitare le zone map. Scegliere gli stili

undefined

usando questi punti decisionali:

undefined

(KEY): utile quando si uniscono tabelle di grandi dimensioni su una chiave di join ad alta cardinalità; evita la ridistribuzione se entrambe le tabelle condividono la stessa

undefined

.

undefined: replicare una piccola tabella dimensionale su tutti i nodi per evitare scambi di dati in rete (network shuffle) per i join.

undefined: impostazione predefinita per carichi di lavoro imprevedibili o quando non esiste una chiave adatta; evita gli hotspot.

undefined: lasciare che Redshift scelga in base alle dimensioni della tabella e al carico di lavoro se mancano indicazioni chiare.

Definire le

undefined

sulle colonne usate nei filtri di intervallo (range filter) o in

undefined

per abilitare le zone map e ridurre le letture da disco. Comandi operativi comuni:

undefined

;

Usare periodicamente

undefined

; monitorare

undefined

per metriche di sbilanciamento (skew) e distribuzione. Redshift Spectrum permette di interrogare tabelle esterne su S3 attraverso il Glue Data Catalog. Creare lo schema esterno con:

undefined

; Criteri decisionali per Spectrum rispetto a Redshift nativo:

Usare Spectrum per dati freddi (cold data) di grandi dimensioni interrogati di rado e archiviati in S3 o per architetture di dati a più livelli (tiered).
Mantenere i set di dati caldi (hot) e uniti di frequente all’interno di Redshift per le prestazioni; quando si eseguono join con Spectrum, scegliere le

undefined

per collocare le chiavi di join o usare la ridistribuzione per minimizzare l’I/O di rete.

Amazon OpenSearch Service per l’analisi dei log

OpenSearch è ottimizzato per l’ingestione e l’analisi rapida e ad-hoc dei log; la configurazione dei suoi indici e del cluster determina il throughput e il costo. Progettazione e ciclo di vita degli indici:

Usare pattern di indice come logs-AAAA.MM.GG e un template di indice per impostare

undefined

(indici piccoli: 1 shard; grandi: più shard di dimensioni ~10–50 GB) e

undefined

per la disponibilità.

Configurare le policy del ciclo di vita degli indici (ILM) per far transitare gli indici attraverso i livelli hot, warm, cold e UltraWarm per il controllo dei costi; UltraWarm riduce i costi di storage dei nodi hot per i dati storici. Sharding e repliche influenzano le prestazioni di query e indicizzazione:
Più shard aumentano il parallelismo ma aggiungono overhead; ottimizzare gli shard per nodo in base a heap e CPU.
Le repliche migliorano il throughput di lettura e la tolleranza ai guasti; impostare le repliche in base alla concorrenza delle query e agli SLA. Comandi operativi e pattern della console:
Usare gli OpenSearch Dev Tools (o

undefined

) per applicare (

undefined

) i template di indice e le policy ILM, e monitorare con le API di stato del cluster. Allocare attributi ai nodi e usare la shard allocation awareness per prevenire l’hot-spotting. Criteri decisionali:

Scegliere UltraWarm quando i requisiti di latenza delle query sui log storici possono tollerare una latenza di lettura più alta in cambio di un costo di storage inferiore.
Mantenere gli indici recenti sui nodi hot per supportare aggregazioni e dashboard veloci.

QuickSight per BI e visualizzazione

QuickSight fornisce dashboard veloci con due modalità principali di ingestione:

undefined

(in-memory) e query diretta.

undefined

offre prestazioni inferiori al secondo per le dashboard ed è adatto a letture ripetute; le query SQL dirette (verso Athena, Redshift, RDS) sono preferibili per set di dati molto grandi o dati che cambiano frequentemente. Configurazioni chiave e best practice:

Creare set di dati nella console: New dataset > Choose source (Athena/Redshift/RDS/OpenSearch) > Importa in SPICE o Usa query diretta.
Usare aggiornamenti pianificati di

undefined

per esigenze giornaliere o quasi in tempo reale; configurare l’aggiornamento incrementale tramite partizionamento per timestamp per limitare lo spostamento dei dati. Sicurezza e governance:

Implementare la sicurezza a livello di riga (row-level security) tramite mappature utente/gruppo di QuickSight e regole sul set di dati.
Per l’accesso ai dati tra account diversi, distribuire un ruolo IAM e permessi basati su risorse che QuickSight possa assumere. Criteri decisionali:
Usare

undefined

per dashboard con molti utenti simultanei e finestre di aggiornamento prevedibili.

Usare la query diretta quando la freschezza dei dati è critica o la capacità di

undefined

è limitata; combinandola con campi calcolati e parametri per un’esperienza utente interattiva.

Errori Comuni e Criteri Decisionali

Athena addebita i costi in base ai dati scansionati: partizionare sempre in base ai predicati delle query e archiviare in formati colonnari (Parquet/ORC) con compressione (Snappy/Zlib) per ridurre i byte scansionati.
L’uso di DISTKEY in Redshift su una colonna a bassa cardinalità causa data skew (asimmetria dei dati): scegliere chiavi di join ad alta cardinalità per DISTKEY o usare DISTSTYLE ALL per le tabelle dimensionali di piccole dimensioni.
Le tabelle esterne di Redshift Spectrum richiedono il Glue Data Catalog: assicurarsi che Glue sia abilitato nella regione di destinazione e che i ruoli IAM consentano a Redshift di accedere al catalogo.
Errori nel conteggio e nel dimensionamento degli shard di OpenSearch: evitare un numero eccessivo di shard di piccole dimensioni; dimensionare gli shard a decine di GB e usare ILM per spostare gli indici più vecchi su UltraWarm per risparmiare sui costi.
Dimenticare di eseguire RUN ANALYZE/VACUUM su Redshift dopo caricamenti massivi: pianificare l’esecuzione di ANALYZE e VACUUM per aggiornare le statistiche e recuperare spazio su disco per ottenere piani di query ottimali.
Overflow di SPICE in QuickSight e dati non aggiornati: pianificare la capacità di SPICE, utilizzare aggiornamenti incrementali o passare alla modalità direct query per esigenze in tempo reale.

Problema Pratico: Scenario d’Uso

Acme Retail necessita di report di BI giornalieri che combinino gli ordini transazionali presenti in Amazon RDS, gli eventi di clickstream in S3 e i profili utente di DynamoDB, rispettando limiti di costo e garantendo aggiornamenti delle dashboard inferiori al minuto per i dati recenti.

Convertire i dati di clickstream in S3 in formato Parquet partizionato (su base data), comprimerli con Snappy e registrare i metadati in AWS Glue tramite un crawler.
Utilizzare Athena per query ad-hoc sui dati in S3 e implementare connettori Federated Query per RDS e DynamoDB per eseguire join con tabelle dimensionali di piccole dimensioni; materializzare i risultati dei join frequenti come file Parquet se le query vengono ripetute.
Effettuare il provisioning di Redshift per join analitici complessi: caricare snapshot aggregati in Redshift, impostare DISTKEY su una colonna ad alta cardinalità come customer_id e definire SORTKEY su order_date; utilizzare Spectrum per i dati storici “freddi” (cold) su S3.
Inserire i log applicativi in OpenSearch utilizzando pattern di indice giornalieri; applicare una policy ILM per mantenere gli indici recenti sui nodi “hot” e spostare gli indici più vecchi su UltraWarm per risparmiare sui costi.
Creare dashboard in QuickSight: importare gli aggregati recenti in SPICE con aggiornamenti incrementali pianificati per una reattività percepita inferiore al minuto, e utilizzare le direct query per le metriche che devono essere sempre aggiornate.

Motivazione: Questo approccio minimizza i costi di scansione di Athena tramite la partizione e i formati colonnari, riduce il network shuffle di Redshift con chiavi di distribuzione e di ordinamento appropriate, utilizza Spectrum per evitare di archiviare dati “freddi” in Redshift, applica ILM in OpenSearch per ottimizzare i costi di storage e sfrutta SPICE per dashboard reattive, mantenendo al contempo l’aggiornamento critico dei dati tramite le direct query.

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

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