Amazon DEA-C01: Qualità, convalida e osservabilità 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 le pratiche end-to-end e i servizi AWS utilizzati per garantire la correttezza dei dati, rilevare anomalie e mantenere l’affidabilità delle pipeline. Una solida validazione e osservabilità riducono i difetti a valle, consentendo di rispettare gli SLA e di eseguire riprocessamenti sicuri. I data engineer devono combinare Glue Data Quality, framework di validazione, il rilevamento di anomalie di CloudWatch, le DLQ e una progettazione idempotente per costruire pipeline robuste.

Regole e valutazione di AWS Glue Data Quality

Glue Data Quality utilizza set di regole (ruleset) in Data Quality Definition Language (DQDL) per definire asserzioni sui set di dati (conteggio delle righe, soglie di valori nulli, unicità, controlli SQL personalizzati). È possibile creare i ruleset nella console o con la CLI (esempio:

undefined

). I ruleset possono essere associati a job ETL di Glue o eseguiti in modo indipendente tramite le API

undefined

/

undefined

per valutare set di dati archiviati in S3, tabelle del catalogo o Glue DynamicFrames.

Dettagli chiave di configurazione e criteri decisionali:

• Struttura DQDL: le regole includono ruleName, expression (DQDL o SQL), severity (gravità) e action on failure (azione in caso di fallimento). Impostare esplicitamente l’azione in caso di fallimento su FAIL per il job quando i controlli critici non vanno a buon fine; altrimenti, Glue potrebbe registrare i risultati nei log senza far fallire l’esecuzione.
• Contesto di valutazione: fornire riferimenti a tabelle o percorsi S3 e opzioni di campionamento (scansione completa vs. campione) tramite i parametri del job o gli input dell’esecuzione di valutazione per bilanciare costi e copertura.
• Output: la valutazione delle regole scrive i risultati nelle metriche di Glue e su Amazon S3 in formato JSON; utilizzare questi artefatti per audit e remediation automatizzata.

Quando usare Glue Data Quality rispetto a framework esterni:

• Usare Glue DQDL per regole standard su schema, completezza e unicità semplice che si integrano nativamente nei job e nel lineage di Glue.
• Usare Great Expectations (vedi il prossimo sottodominio) quando si necessita di librerie di “expectation” più ricche, controlli più espressivi o suite di “expectation” condivise tra più sistemi.

Pattern di validazione dei dati nelle pipeline

La validazione va inserita in più punti di contatto: ingresso (ingress), trasformazione e destinazione (sink). Pattern comuni:

• Controlli leggeri pre-acquisizione (pre-ingest) in producer Lambda/Kinesis per lo schema e intervalli di valori di base, per rifiutare o instradare le righe errate prima che entrino nella pipeline.
• Validazione lato server in job ETL di Glue (Spark) utilizzando ruleset DQDL e validazioni esplicite nel codice. In Glue Studio, aggiungere una trasformazione Data Quality che fa riferimento a un ruleset; nella CLI, passare

undefined

o includere parametri del job per avviare le esecuzioni di valutazione.

• Validazione post-trasformazione con Great Expectations integrato in job Glue Python Shell o Glue Spark. Distribuire le “expectation” su S3 (directory

undefined

) e caricare il DataContext nel job:

undefined

dopo aver sincronizzato le “expectation” da S3 all’ambiente del job.

Confronto tra le opzioni di validazione:

• Glue DQDL
  • Pro: integrazione nativa, basso overhead operativo, scrive i risultati nel catalogo/metriche di Glue
  • Contro: meno espressivo per “expectation” logiche complesse
• Great Expectations
  • Pro: “expectation” ricche, data docs, checkpoint integrati, backend estensibili
  • Contro: richiede l’impacchettamento e la gestione degli artefatti delle “expectation” in S3 e l’orchestrazione nei job di Glue
• Controlli manuali nel codice (Spark/DataFrame)
  • Pro: piena flessibilità, alte prestazioni per logiche personalizzate
  • Contro: manutenzione più onerosa, nessun reporting standardizzato senza lavoro aggiuntivo

Per lo streaming, validare i record in transito (in-flight) e, in caso di fallimento, inviarli a una SQS DLQ (configurare la RedrivePolicy con

undefined

tramite la CLI AWS o la console) invece di scartarli. Per il batch, generare un artefatto con il report di validazione e far fallire o mettere in quarantena gli output in base alla policy.

Rilevamento di anomalie e monitoraggio del data drift

Utilizzare il rilevamento di anomalie di CloudWatch per le metriche operative (record elaborati, tasso di errore, durata del job). Creare un detector con la CLI:

undefined

e poi creare allarmi CloudWatch che fanno riferimento alla banda di rilevamento delle anomalie. Per il drift a livello di dati (spostamenti nella distribuzione, variazioni nel tasso di valori nulli), pianificare job di profilazione (profile job) di Glue DataBrew (

undefined

) per calcolare statistiche, istogrammi e quantili; archiviare i profili su S3 come baseline.

Criteri decisionali per allarmi basati su anomalie vs. soglie:

• Scegliere il rilevamento di anomalie di CloudWatch quando i pattern delle metriche sono stagionali o variabili; esso apprende il comportamento passato e riduce la necessità di regolare manualmente le soglie.
• Usare allarmi a soglia statica per condizioni binarie (es. job bloccato > X ore) dove la prevedibilità è alta.

Per il rilevamento automatico del drift:

• Pianificare job di profilazione DataBrew regolari (giornalieri/settimanali a seconda della velocità dei dati) per catturare le baseline delle metriche (% di valori nulli, cardinalità, percentili).
• Confrontare i nuovi output dei profili con le baseline utilizzando ruleset di Glue (controlli SQL personalizzati) o “expectation” personalizzate di Great Expectations che fanno riferimento alle statistiche della baseline.
• Inviare un alert tramite SNS / EventBridge quando il drift supera le soglie definite dalla policy o quando i detector di anomalie segnalano un comportamento insolito delle metriche.

Gestione degli SLA e affidabilità delle pipeline

La gestione degli SLA lega l’osservabilità alla remediation e all’ingegneria dell’affidabilità. Strumentare ogni pipeline con queste metriche di base: throughput (record/sec), latenza (dall’ingestione alla destinazione), tasso di errore, durata del processo/runtime e conteggi a valle. Utilizzare CloudWatch Metrics per i processi Glue (metriche di esecuzione del processo), il lag dei consumer Kinesis/Kafka e le metriche applicative personalizzate tramite PutMetricData.

Pattern di affidabilità e dettagli di configurazione:

• Code di messaggi non recapitabili (DLQ SQS): per i consumer di streaming (Lambda, consumer Kinesis), configurare una DLQ e impostare la RedrivePolicy(maxReceiveCount). Utilizzare la retention della DLQ e un processo di elaborazione separato per ispezionare e rielaborare i messaggi della DLQ.
• Progettazione idempotente: assicurarsi che le destinazioni (sink) supportino scritture idempotenti — esempi:
  • DynamoDB: usare PutItem con espressioni condizionali o una chiave composita per il token di idempotenza.
  • S3: scrivere con pattern di ridenominazione atomica o usare chiavi basate sul contenuto (hash del record) in modo che i replay sovrascrivano anziché duplicare.
  • Redshift/Glue ETL: usare staging + MERGE per chiave per deduplicare dopo la rielaborazione.
• Checkpointing: abilitare i checkpoint del connettore Kinesis/DynamoDB e gestire la frequenza dei checkpoint del consumer per bilanciare la finestra di rielaborazione e il rischio di duplicazione.

Criteri decisionali per retry vs fail-fast:

• Per i fallimenti transitori (throttling a valle), implementare nuovi tentativi (retry) con backoff esponenziale e una DLQ solo dopo il numero massimo di tentativi.
• Per i fallimenti di qualità dei dati (mancata corrispondenza dello schema), applicare il fail-fast (fallimento rapido) e scrivere i record problematici in un prefisso S3 di quarantena con metadati per la revisione manuale.

Errori Comuni e Criteri Decisionali

• Le regole di Glue Data Quality registrano i fallimenti ma non causano il fallimento del processo per impostazione predefinita — configurare l’azione della regola su FAIL per i controlli critici e allegare la valutazione del set di regole all’esecuzione del processo.
• Le pipeline di streaming senza DLQ scartano o perdono i record falliti — configurare sempre DLQ SQS (o uno staging persistente su S3) e una redrive policy per ispezionare e rielaborare.
• La rielaborazione senza idempotenza produce record duplicati — progettare chiavi deterministiche, usare semantiche di upsert/merge nella destinazione (sink) o applicare chiavi oggetto basate sul contenuto per S3.
• Il rilevamento del data drift senza baseline produce avvisi superflui — pianificare processi di profilazione di Glue DataBrew per creare e archiviare statistiche di baseline, quindi confrontare i nuovi profili con esse.
• L’eccessivo affidamento a soglie statiche di CloudWatch causa falsi positivi — usare il rilevamento delle anomalie di CloudWatch per metriche stagionali/variabili e riservare le soglie statiche per limiti non negoziabili.
• Impostare un maxReceiveCount troppo alto ritarda l’instradamento verso la DLQ e aumenta la latenza di elaborazione — scegliere un maxReceiveCount ragionevole in modo che le DLQ ricevano i messaggi che falliscono persistentemente in modo tempestivo.

Problema Pratico: Scenario d’Uso

Streamline Retail riscontra frequenti errori di reporting a valle dopo l’ETL notturno: picchi anomali occasionali nello schema, violazioni silenti delle regole e ordini duplicati durante la rielaborazione di esecuzioni fallite.

1. Implementare le regole di Glue Data Quality (DQDL) per lo schema, le soglie di valori null e l’unicità su order_id; impostare l’azione in caso di fallimento su FAIL per il processo e pubblicare gli artefatti di valutazione su S3.
2. Aggiungere Great Expectations in uno step Glue Python Shell per controlli di business complessi (coerenza degli ordini tra le tabelle); archiviare le ’expectations’ in S3 ed eseguire checkpoint nella pipeline.
3. Pianificare processi di profilazione di DataBrew per catturare baseline giornaliere (cardinalità, tasso di valori null, percentili) e usare confronti automatizzati per rilevare il drift.
4. Per gli eventi di ordine in streaming, configurare una DLQ SQS con una RedrivePolicy appropriata e creare un processo di replay per elaborare i messaggi della DLQ in modo idempotente (usando order_id come chiave di deduplica).
5. Strumentare i rilevatori di anomalie di CloudWatch per la durata del processo e il conteggio degli errori; collegare allarmi basati sulle anomalie a SNS per l’escalation al personale di reperibilità.

Logica della best practice AWS: combinare i controlli di qualità nativi di Glue per un’integrazione rapida, Great Expectations per l’espressività, DataBrew per le statistiche di baseline e i rilevatori di anomalie di CloudWatch per il monitoraggio adattivo. Le DLQ e le destinazioni (sink) idempotenti chiudono il cerchio per nuovi tentativi e rielaborazioni sicure, preservando al contempo gli SLA.

← Ottimizzazione dei costi per i carichi di lavoro dei dati · Tutti i domini

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

Sfoglia Amazon →