Amazon DEA-C01: Ingestione e raccolta 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 pattern, i servizi AWS e i dettagli operativi utilizzati per portare i dati grezzi in una piattaforma dati in modo affidabile e su larga scala. I data engineer devono scegliere tra punti di ingresso batch e streaming, garantire la catalogazione e la reperibilità dei dati e progettare tenendo conto di throughput, rigiocabilità e modalità di fallimento. I componenti AWS fondamentali sono S3 e Glue per il batch, Kinesis e Firehose per lo streaming, DMS per la migrazione di database e il CDC, e componenti basati su API/eventi (API Gateway, Lambda, SNS, SQS, eventi S3) per l’ingestion ad-hoc e basata su push.

Ingestion batch con AWS Glue e S3

Glue è la principale soluzione gestita di ETL e metadati per l’ingestion batch in S3 e nel proprio catalogo dati. Il pattern tipico è: depositare i file grezzi in S3 (con prefissi separati per le zone raw), eseguire un crawler di Glue per inferire lo schema e popolare il Glue Data Catalog, quindi eseguire job ETL di Glue (Spark) per trasformare, partizionare, convertire in formati colonnari (Parquet/ORC) e riscrivere i dati ottimizzati su S3. Configurare i crawler con i classificatori appropriati (CSV/JSON/Parquet integrati o grok/regex personalizzati) e assegnare al crawler un ruolo IAM con le autorizzazioni s3:GetObject/s3:ListBucket e glue:catalog — la loro mancanza è un comune errore operativo.

Quando si configurano i job e i crawler di Glue, utilizzare questi pattern e opzioni da console/CLI:

Creare un crawler:

undefined

e avviarlo con

undefined

Job di Glue:

undefined

; abilitare i job bookmark per evitare la rielaborazione. Criteri decisionali per Glue rispetto alle alternative:

Usare Glue quando si desidera un ETL Spark gestito, l’individuazione dello schema e l’integrazione del catalogo con Athena/Redshift Spectrum.
Usare EMR quando si necessita di ottimizzazione specializzata del cluster, librerie personalizzate o cluster a lunga esecuzione.
Usare una semplice funzione Lambda o Glue on-demand per trasformazioni leggere su file di piccole dimensioni.

Ingestion streaming con Kinesis Data Streams e Firehose

Kinesis Data Streams (KDS) è per l’ingestion in tempo reale con possibilità di replay, controllo dei consumer e scalabilità granulare. Uno shard di Kinesis fornisce una capacità di scrittura di 1 MB/sec o 1.000 record/sec e una capacità di lettura di 2 MB/sec; usare

undefined

e inserire i dati con

undefined

. Le chiavi di partizione determinano l’assegnazione allo shard; una bassa cardinalità delle chiavi di partizione causa “hot shard” (shard sovraccarichi) — evitare il problema aumentando l’entropia della chiave o aggiungendo un suffisso con un hash. Scalare gli shard usando

undefined

o abilitare la modalità On-Demand per la scalabilità automatica.

Firehose è un servizio di delivery stream ottimizzato per la consegna quasi in tempo reale (near-real-time) a S3, Redshift, OpenSearch e Splunk, con buffering integrato, compressione e trasformazione opzionale tramite Lambda. Configurare il buffering con i BufferingHints: buffer_size (MB) e buffer_interval (secondi) per ottimizzare la latenza di consegna rispetto ai costi; abilitare la compressione (GZIP, Snappy) e impostare una Lambda di elaborazione per trasformazioni a livello di record. Differenze principali:

Kinesis Data Streams:
- Tempo reale, supporta più consumer, replay dei dati conservati, gestione esplicita degli shard
- Throughput per shard (1MB/1k scritture), richiede la progettazione delle chiavi di partizione
Kinesis Data Firehose:
- Consegna gestita verso le destinazioni, retry/backoff automatico, nessun replay dei record consegnati
- Supporta buffering (dimensione/tempo), compressione, trasformazione tramite Lambda, staging su S3 per i caricamenti su Redshift

Scegliere KDS quando si necessita di replay, forte controllo sui consumer o più consumer a valle; scegliere Firehose quando si necessita di una consegna e trasformazione semplice verso S3/Redshift/OpenSearch con un overhead operativo minimo.

Migrazione di database e CDC con DMS

AWS DMS viene utilizzato per migrazioni omogenee/eterogenee e per la replica continua (CDC - Change Data Capture). Distribuire un’istanza di replica (

undefined

) dimensionata per il throughput, con decisioni di dimensionamento guidate dal tasso di modifica (change rate), dal volume del caricamento completo (full-load) e dal parallelismo dei task. Tipi di task DMS:

full-load: copia solo i dati esistenti
cdc: esegue lo streaming delle modifiche correnti
full-load + cdc: caricamento iniziale seguito dallo streaming continuo delle modifiche Configurare gli endpoint con le impostazioni del motore appropriate (JDBC/connection-string), abilitare il supplemental logging o i plugin sull’origine e fornire una mappatura delle tabelle in formato JSON per filtrare/includere le tabelle. Per le origini basate su MySQL, il CDC di DMS richiede l’abilitazione del binary logging (binlog) e un binlog_format appropriato (si consiglia ROW) sull’origine; per PostgreSQL è necessario abilitare la replica logica e un plugin come wal2json o utilizzare gli slot di replica. Monitorare i task tramite i parametri di CloudWatch e i log dei task; ottimizzare batchApplyEnabled e maxFullLoadSubTasks per il throughput.

Criteri decisionali tra full-load e CDC: utilizzare full-load+CDC quando è necessaria una migrazione con tempi di inattività minimi; utilizzare solo CDC per la replica continua dopo che un caricamento iniziale è stato completato con un altro meccanismo. Validare sempre la mappatura dello schema ed eseguire migrazioni di prova su volumi di dati rappresentativi.

Pattern di ingestion basati su API e guidati da eventi

Le API e gli eventi sono utilizzati per l’ingestion e l’orchestrazione di tipo push. I pattern comuni includono:

API Gateway -> Lambda -> Firehose/Kinesis: adatto quando i client inviano eventi JSON in modalità push. Utilizzare il throttling di API Gateway e i controlli di concorrenza di Lambda per fornire backpressure e applicare header di idempotenza.
Notifiche di eventi S3: configurare le notifiche del bucket per inviare eventi di creazione di oggetti (object-created) a Lambda, SQS o SNS tramite la console o con il comando

undefined

; usare filtri su prefisso/suffisso per limitare gli attivatori (trigger). Per il fan-out, instradare S3 -> topic SNS -> più code SQS/sottoscrittori Lambda per consegnare lo stesso evento a più consumer senza accoppiamento.

SQS e SNS per un’ingestion durevole e disaccoppiata: SQS per l’elaborazione pull-based da parte di worker con visibility timeout, SNS per il fan-out di tipo push.

Considerazioni operative e pattern CLI:

Usare le DLQ per i fallimenti di Lambda/SQS; configurare una policy di tentativi (retry policy) sulle sottoscrizioni SNS.
Per lo streaming ad alta velocità (high-throughput) dalle API, preferire il raggruppamento in batch verso Kinesis o Firehose piuttosto che scritture sincrone a valle, per evitare di bloccare i client API.

Errori Comuni e Criteri Decisionali

Confondere Kinesis Data Streams (con capacità di replay, gestione degli shard) con Firehose (consegna gestita, senza replay): scegliere KDS quando è necessario il replay o si hanno più consumer; scegliere Firehose per pipeline di consegna dirette.
Dimenticare i permessi IAM per i crawler di Glue: associare sempre un ruolo IAM che conceda i permessi s3:GetObject/s3:ListBucket e glue:CreateTable/UpdateTable/DeleteTable affinché i crawler possano popolare il Data Catalog.
Mancata abilitazione del binary logging/replica logica per il CDC di DMS: abilitare il binlog su MySQL (formato ROW) o la replica logica e wal2json su PostgreSQL prima di avviare i task di CDC.
Bassa cardinalità della chiave di partizione che causa hot shard: aumentare la cardinalità della chiave di partizione tramite hashing, includere attributi ad alta cardinalità o aumentare il numero di shard; monitorare le metriche di throttling per Put/Get.
Overbuffering in Firehose o buffering mal configurato che porta a latenza elevata: ottimizzare buffer_size e buffer_interval in base alla latenza accettabile e al volume di richieste.
Affidarsi alle notifiche di eventi S3 senza DLQ o meccanismi di retry: usare il fan-out SNS/SQS o Lambda con una DLQ per evitare la perdita di eventi e garantire un fan-out durevole.

Problema Pratico: Scenario d’Uso

RetailCo raccoglie clickstream da dispositivi mobili (ad alto volume, in tempo reale) e file notturni del catalogo prodotti; necessita di dashboard in tempo reale e di un data lake consolidato per l’analisi.

Ingestire i clickstream in Kinesis Data Streams con chiavi di partizione derivate dalla sessione utente + un suffisso di shard sottoposto a hashing; creare consumer usando Kinesis Data Analytics o Lambda/Kinesis Client Library per l’elaborazione in tempo reale.
Usare Kinesis Data Firehose con una Lambda di trasformazione per persistere gli output dello streaming arricchiti su S3 (in formato Parquet), comprimerli con Snappy e, opzionalmente, caricarli su Redshift Spectrum per l’analisi.
Posizionare i file notturni del catalogo in S3 raw/ ed eseguire un crawler di Glue pianificato per aggiornare il Glue Data Catalog, quindi eseguire job ETL di Glue per convertirli in formato Parquet partizionato nella zona curata (curated zone).
Usare le notifiche di eventi S3 -> SNS -> Lambda per attivare aggiornamenti leggeri di metadati o invalidare le cache; instradare la consegna a SQS per un’elaborazione a valle durevole.
Monitorare le metriche degli shard di Kinesis (IncomingBytes, IncomingRecords, PutRecords.Success) e usare UpdateShardCount o gli stream On-Demand per gestire la crescita; abilitare gli allarmi di CloudWatch.

Razionale delle best practice AWS: separare i percorsi in tempo reale e batch, usare Kinesis Data Streams quando sono richiesti il replay e l’isolamento dei consumer, usare Firehose per la consegna gestita verso S3/destinazioni e mantenere un Glue Data Catalog per la discovery e l’integrazione delle query con Athena/Redshift.

Tutti i domini · Archiviazione dei dati e architettura del Lake →

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