Il Glue Data Catalog come metastore centrale

Il AWS Glue Data Catalog è il metastore Hive-compatibile che fa da registro centrale dei metadati del data lake. Non contiene i dati, ma li descrive: database, tabelle, schema (colonne e tipi), posizione dei file su S3, formato di serializzazione (SerDe) e definizioni di partizione. La forza sta nella condivisione: lo stesso catalogo alimenta Amazon Athena, Redshift Spectrum, Amazon EMR e AWS Glue ETL, così un’unica definizione di tabella serve più motori di query secondo il principio dello schema-on-read.

Per popolarlo hai tre strade: i Glue crawler, che scandiscono un prefisso S3 inferendo schema e partizioni e aggiornandole a ogni run; le istruzioni DDL da Athena; oppure gli ETL job che scrivono direttamente in tabella. Il crawler è comodo ma non infallibile: su file eterogenei può inferire tipi sbagliati o creare tabelle multiple, e uno schema errato si propaga a tutti i consumer. Per pipeline stabili spesso conviene un catalogo gestito esplicitamente invece di crawler ricorrenti.

Partizionamento dei dati su S3

Il partizionamento organizza i file in prefissi S3 secondo i valori di una o più colonne, tipicamente in stile Hive chiave=valore (es. s3://bucket/eventi/year=2026/month=07/day=30/). Il vantaggio chiave è il partition pruning: quando la query filtra su una colonna di partizione, il motore legge solo i prefissi rilevanti, riducendo drasticamente i dati scansionati e quindi costo e latenza in Athena e Redshift Spectrum, che fatturano sui byte letti.

I trade-off contano. Poche partizioni troppo grandi limitano il pruning; troppe partizioni piccole (over-partitioning) generano un eccesso di metadati e molti file minuscoli, penalizzando le performance. Scegli come chiave una colonna a cardinalità medio-bassa e usata di frequente nei filtri (spesso la data). Quando le partizioni diventano moltissime, in Athena conviene la partition projection, che calcola le partizioni da una configurazione invece di elencarle nel catalog, evitando MSCK REPAIR/crawler continui.

Formati colonnari e compressione

I formati row-based (CSV, JSON, Avro) memorizzano un record per riga: adatti a scritture riga-per-riga e a ingestione, ma inefficienti per analytics perché costringono a leggere tutte le colonne. I formati colonnari come Parquet e ORC memorizzano i valori per colonna e abilitano column pruning (leggi solo le colonne richieste) e predicate pushdown (salti interi row group grazie alle statistiche min/max nei metadati). Su carichi OLAP Parquet riduce byte scansionati e costo Athena/Spectrum di un ordine di grandezza rispetto a CSV/JSON. Nota: Avro resta row-based ma con schema evolutivo, utile per lo streaming e le tabelle di staging, non come formato finale di query.

La compressione si somma al guadagno. Snappy è il default pragmatico: veloce, buon rapporto, e all’interno di Parquet/ORC resta splittable a livello di row group, quindi parallelizzabile. Gzip comprime di più ma su file testuali non è splittable, limitando il parallelismo; Bzip2 è splittable ma lento; Zstd offre ottimo rapporto/velocità. La regola d’esame: preferisci Parquet+Snappy per le tabelle analitiche, e ricorda che la splittability determina quanti task possono leggere il file in parallelo.

Governance con AWS Lake Formation

AWS Lake Formation aggiunge uno strato di governance sopra il Glue Data Catalog e S3. Permette permessi fine-grained — a livello di database, tabella, colonna, riga e cella — gestiti centralmente, superando la granularità grezza delle bucket policy e delle policy IAM su S3. Con le LF-Tags (tag-based access control) assegni etichette a risorse e concedi accessi per tag, scalando meglio delle grant singole. Lake Formation offre inoltre blueprint di ingestione e la condivisione cross-account del catalogo, restando comunque integrato con IAM.

Trappole tipiche d’esame

  • Query Athena costose su tanti dati scansionati → converti in Parquet e partiziona: i costi si abbattono con formato colonnare + partition pruning, non aumentando la capacità di calcolo.
  • Migliaia di partizioni e crawler lenti in Athena → partition projection: evita di enumerare le partizioni nel catalog; ricorda che è specifica di Athena.
  • Serve mascherare alcune colonne a un gruppo → Lake Formation column-level, non bucket policy S3: le policy S3/IAM non danno granularità a colonna/riga/cella.
  • File Gzip enormi che non si parallelizzano → usa Snappy dentro Parquet o formati splittable: Gzip su testo non è splittable; Parquet+Snappy sì, a livello di row group.
  • Dati in streaming da salvare con schema evolutivo → Avro per lo staging, Parquet per le query: Avro è row-based, ottimo per ingestione, non per analytics finali.
  • Un solo schema per Athena, Redshift Spectrum ed EMR → definiscilo una volta nel Glue Data Catalog: è il metastore condiviso; non serve replicare le definizioni per ogni motore.