Amazon DEA-C01: Catalogazione dei dati e gestione dei metadati — 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 il livello di metadati che rende i dati individuabili, interrogabili e governabili su una piattaforma dati AWS. Una catalogazione e una gestione dei metadati efficaci riducono gli ostacoli per l’analisi e garantiscono che i consumatori a valle possano trovare schemi, partizioni, policy di accesso e lineage. I servizi AWS in quest’area — Glue Data Catalog, Glue Schema Registry, Lake Formation, l’integrazione con Athena e DataBrew — forniscono strumenti complementari per l’individuazione, l’evoluzione dello schema, la governance e il profiling. Comprendere come questi servizi interagiscono, i dettagli della loro configurazione e le tipiche modalità di fallimento è essenziale per l’affidabilità operativa e la sicurezza.

Struttura e operazioni di AWS Glue Data Catalog

Il Glue Data Catalog è il repository di metadati centralizzato e regionale per database, tabelle, partizioni, connessioni e classificatori definiti dall’utente. Le primitive principali sono:

• Database: un contenitore logico (usare la CLI aws:

undefined

).

• Table: descrive un set di dati (serde, formati di input/output, colonne, tableType

undefined

). È possibile crearla/aggiornarla tramite console, API di Glue o CloudFormation; es.,

undefined

.

• Partition: mappatura tra i valori delle chiavi di partizione e i prefissi S3; le partizioni possono essere gestite dai crawler di Glue (

undefined

) o aggiunte esplicitamente (

undefined

).

Pattern operativi:

• Crawler per l’individuazione: pianificare i crawler per layout S3 in evoluzione, scegliere l’ordine dei classificatori (CSV/JSON/Parquet) e impostare la policy del crawler per aggiornamenti incrementali.
• Controllo programmatico: preferire le API di Glue o Lambda per aggiungere partizioni in caso di arrivi di dati su S3 guidati da eventi, piuttosto che affidarsi esclusivamente ai crawler.
• Replica del catalogo: il Glue Data Catalog è regionale. Per letture multi-regione, considerare l’esecuzione di crawler in ogni regione, la creazione di automazioni per replicare i metadati o l’uso di pattern di resource-linking; le decisioni progettuali dipendono dai costi, dalle esigenze di coerenza e dai pattern di query cross-regione.

Criteri decisionali:

• Usare i crawler quando è richiesto il rilevamento dello schema e i formati dei dati sono eterogenei; usare la creazione esplicita delle tabelle per schemi rigidi e per set di dati prevedibili e ad alto volume.
• Usare batch-create-partition o la gestione delle partizioni basata su Lambda per arrivi di file di piccole dimensioni ad alta frequenza, per evitare ritardi del crawler e ridurre i costi delle API di Glue.

Individuazione ed evoluzione dello schema

Lo Schema Registry e gli schemi di Glue supportano Avro, JSON e Protobuf per lo streaming e per contratti producer/consumer di lunga durata. Funzionalità chiave:

• Registrare gli schemi tramite console o CLI (

undefined

).

• Modalità di compatibilità: BACKWARD (i consumer possono leggere i nuovi dati), FORWARD (i nuovi consumer possono leggere i vecchi dati) e FULL (entrambe). La scelta dipende dai pattern di deployment dei consumer.
• Applicazione dello schema: per lo streaming, integrare il registry con Kinesis Data Streams, MSK o client Kafka e gli SDK AWS per serializzare/deserializzare con versioni dello schema e validazione incorporate.

Pattern pratici di configurazione ed evoluzione:

• Per Avro con molti consumer, usare la compatibilità BACKWARD per consentire l’aggiunta di nuovi campi con valori di default; evitare rimozioni che causano rotture di compatibilità.
• Per un’evoluzione rigorosa del contratto tra team diversi, richiedere la compatibilità FULL e controllare le modifiche allo schema tramite uno step di CI che esegue la validazione dello schema.
• Per JSON, dove i campi sono opzionali e lo schema è fluido, usare l’evoluzione dello schema con default permissivi ma versionando i metadati nel catalogo per prevenire rotture silenziose dei consumer.

Criteri decisionali:

• Usare lo Schema Registry per eventi di streaming e quando più consumer necessitano di uno schema canonico. Usare gli schemi delle tabelle Glue per set di dati batch dove il formato (Parquet/ORC) fornisce lo schema on read.
• Scegliere la modalità di compatibilità valutando se si ha il controllo di tutti i consumer (si può coordinare FORWARD) o se si necessita di modifiche aggiuntive sicure (scegliere BACKWARD).

Data lineage e governance con Lake Formation

Lake Formation si basa sul Glue Data Catalog per fornire controllo degli accessi a grana fine, auditing e controlli di lineage. Funzionalità principali:

• LF-Tags: controlli di accesso basati su tag applicati a database, tabelle e colonne. Creare gli LF-Tags in Lake Formation, assegnare coppie chiave:valore e quindi concedere le autorizzazioni ai principal IAM tramite grant basati su tag anziché grant basati su risorse.
• Controlli a livello di colonna: usare gli LF-Tags per mascherare o limitare le colonne; configurare le autorizzazioni a livello di colonna nella console di Lake Formation o con

undefined

.

• Lineage e auditing: abilitare CloudTrail e le metriche dei job di Glue per catturare il lineage dei job ETL; usare i bookmark dei job di Glue e i metadati dei bookmark nel catalogo per tracciare i dati elaborati.

Pattern di configurazione:

• Definire un set piccolo e coerente di chiavi per gli LF-Tag (es. sensitivity:public/private/PII) e automatizzare il tagging alla creazione della tabella o tramite i crawler di Glue, usando la configurazione del crawler o codice di post-elaborazione.
• Delegare l’amministrazione tramite i ruoli di Delegated Admin di Lake Formation e concedere le autorizzazioni di Lake Formation ai team di analisi, limitando al contempo l’accesso a S3 a livello di IAM.

Criteri decisionali:

• Usare Lake Formation quando si necessita di controlli centralizzati, a livello di colonna e basati su tag per molti consumer e quando la governance/auditabilità è obbligatoria.
• Se le esigenze di controllo degli accessi sono semplici (a livello di bucket), le policy IAM+S3 potrebbero essere sufficienti; usare Lake Formation per controlli a grana fine integrati con il catalogo.

Integrazione tra Athena e il catalogo Glue

Athena si basa sul Glue Data Catalog per i metadati. Punti di integrazione comuni e controlli operativi:

• Gestione delle partizioni: Athena legge le partizioni dal catalogo di Glue. Quando vengono aggiunte nuove partizioni S3, è necessario aggiornare il catalogo. Opzioni:
  • Eseguire MSCK REPAIR TABLE db.table; da Athena o usare aws athena start-query-execution con quella query SQL per aggiornare le partizioni scoperte nella posizione della tabella.
  • Usare aws glue batch-create-partition per aggiungere partizioni programmaticamente in risposta a eventi S3 PUT (consigliato per flussi event-driven).
  • Usare la proiezione delle partizioni (partition projection) impostando proprietà della tabella come projection.enabled=true, projection.year.type=integer, projection.month.range=1 e projection.year.range=2018,2026 — questo evita completamente le ricerche su Glue ed è essenziale per un numero molto elevato di partizioni.
• Compromessi tra performance delle query e costi:
  • La proiezione delle partizioni rimuove le chiamate API a Glue e riduce drasticamente la latenza in presenza di molte piccole partizioni, ma richiede una denominazione deterministica delle partizioni.
  • MSCK REPAIR TABLE è semplice per arrivi ad-hoc occasionali ma può essere lento per dataset di grandi dimensioni.

Complemento con Glue DataBrew:

• Usare DataBrew per profilazione e trasformazioni no-code; puntare DataBrew a tabelle del Glue Catalog o a percorsi S3, eseguire job di profilazione, creare “recipe” e pubblicare l’output nuovamente su S3 o come nuove tabelle Glue.
• Usare DataBrew per controlli di qualità esplorativi e per generare trasformazioni da mettere in produzione successivamente in Glue ETL quando è richiesta una logica Spark complessa.

Criteri decisionali:

• Usare la proiezione delle partizioni quando le partizioni sono numerose e seguono uno schema prevedibile (basato su date / numerico).
• Usare aggiornamenti programmatici delle partizioni Glue per l’ingestion event-driven e near-real-time.
• Eseguire MSCK REPAIR TABLE solo per backfill occasionali o quando l’automazione non è disponibile.

Errori Comuni e Criteri Decisionali

• Le query Athena falliscono perché le partizioni di Glue non vengono aggiornate dopo l’arrivo di dati su S3: evitare di fare affidamento esclusivamente sui crawler; eseguire MSCK REPAIR TABLE per aggiornamenti occasionali, invocare aws glue batch-create-partition su eventi S3, o implementare la proiezione delle partizioni per set di partizioni ampi e prevedibili.
• La scelta della modalità di compatibilità errata nello schema registry può rompere i consumer: selezionare BACKWARD per modifiche additive e per la stabilità dei consumer, FORWARD quando i producer devono rimanere compatibili con consumer più vecchi, e FULL quando entrambe le direzioni devono essere sicure; validare le modifiche in CI rispetto agli schemi dei consumer.
• Presumere che il Glue Data Catalog sia globale: il catalogo è regionale. Per l’accesso cross-region, progettare la replica o eseguire cataloghi nelle region di destinazione; non dare per scontato che i metadati di Glue siano automaticamente disponibili tra le region.
• Concedere l’accesso IAM a S3 ma non i permessi di Lake Formation: Athena e Lake Formation applicano permessi a livello di catalogo; concedere sempre i permessi di Lake Formation (e gli LF-Tags dove usati) in aggiunta a qualsiasi policy IAM.
• Granularità eccessiva delle partizioni: usare troppe partizioni minuscole danneggia la pianificazione delle query e aumenta l’overhead dei metadati; preferire partizioni più grossolane (giornaliere vs. al minuto) o usare la proiezione delle partizioni.
• Trascurare i permessi del ruolo di DataBrew: i job di DataBrew richiedono un ruolo di servizio con permessi per Glue e S3; assicurarsi che il ruolo abbia Glue:GetTable, permessi di lettura/scrittura su S3 e kms:Decrypt se i dataset sono crittografati.

Problema Pratico: Scenario d’Uso

Acme Retail riceve file di vendita orari su S3 con partizioni per data/ora e gli analisti interrogano i dati in Athena; dopo il caricamento, gli utenti riscontrano errori nelle query e risultati non aggiornati perché le partizioni non sono visibili nel Glue Data Catalog.

1. Implementare una notifica di evento S3 PUT per invocare una funzione Lambda che chiami aws glue batch-create-partition per registrare immediatamente la nuova partizione.
2. Per dati più vecchi o per backfill, pianificare una query Athena che esegua MSCK REPAIR TABLE db.sales_hourly; o eseguire un aws glue batch-create-partition mirato per intervalli noti.
3. Se le partizioni seguono una convenzione di denominazione rigorosa per data/ora, abilitare la proiezione delle partizioni sulla tabella Glue (impostare projection.enabled=true e definire le proprietà per anno/mese/giorno/ora) per eliminare i costi di aggiornamento del catalogo.
4. Aggiungere LF-Tags per la sensibilità dei dati alla tabella e concedere agli analisti i permessi di Lake Formation in modo che le query Athena siano consentite e governate.
5. Usare Glue DataBrew per profilare i nuovi file orari in un ambiente di staging per individuare deviazioni dello schema (schema drift); se vengono trovate modifiche allo schema, registrare nuove versioni dello schema nel Glue Schema Registry e validare la compatibilità prima del rollout in produzione.

Logica: la registrazione automatica delle partizioni o la proiezione rimuove il ritardo dei metadati che causa il fallimento delle query Athena; abbinare questo alla governance di Lake Formation assicura un accesso sicuro, e la profilazione guidata da DataBrew rileva precocemente lo schema drift, mentre il Glue Schema Registry protegge i consumer di streaming e batch da modifiche di schema incompatibili.

← Archiviazione dei dati e architettura del Lake · Tutti i domini · Trasformazione ed elaborazione dei dati →

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

Sfoglia Amazon →