Progetto: data lake completo su S3

Questo è il lavoro finale del binario ml-tabellare, e va svolto come una vera consegna architetturale. Il progetto porta un lake S3 da cartelle sparse a sistema leggibile e governato: zone raw, curated e analytics, formati colonnari, catalogo, policy di accesso, lifecycle e query engine. Ogni scelta deve spiegare quale rischio riduce tra costi, sicurezza, query lente, dati non tracciabili, schema instabile o recovery mai verificato.

L’obiettivo del progetto

Questo progetto consegna un data lake su S3 con zone, formato colonnare, catalogo, accessi governati e query veloci dimostrate da una prova misurabile. Il peso non sta nelle singole configurazioni, ma nel fatto che tutte insieme funzionino davvero.

Come procedere, passo dopo passo

1. Disegna il layout dei bucket con zone raw, curated e analytics e partizioni per data.
2. Carica i dati in formato Parquet con compressione Snappy e partizioni tra 200 e 500 MB.
3. Crea almeno una tabella Iceberg registrata nel Glue Catalog con time travel funzionante.
4. Configura in Lake Formation le policy che mostrano a ogni ruolo solo dati e colonne consentiti.
5. Esegui la query Athena di controllo e misura scansione e latenza su un volume noto.
6. Verifica la consegna con la checklist e ripeti la query dopo ogni modifica al layout.

Fase 1: architettura S3 e partizionamento

La struttura del bucket separa i dati transazionali da quelli dimensionali e partiziona i primi per data, così le query temporali leggono solo le partizioni rilevanti. Ecco come deve apparire il layout, con la zona transactional scandita da anno, mese e giorno:

s3://globalretail-datalake/
  transactional/
    sales/year=YYYY/month=MM/day=DD/
    inventory/year=YYYY/month=MM/
  dimensional/
    products/
    stores/
    customers/

Il formato è Parquet con compressione Snappy. Le partizioni ottimali stanno tra 200 e 500 MB ciascuna: troppo piccole moltiplicano i file e rallentano le scansioni, troppo grandi riducono il parallelismo.

Fase 2: Apache Iceberg

Iceberg trasforma i file in tabelle versionate con time travel, così puoi interrogare lo stato di una tabella a una data passata senza ricostruirla a mano. La creazione della tabella sulle vendite usa la format-version 2 e un layout per anno e mese:

CREATE TABLE sales_iceberg (
    order_id STRING, store_id INT, product_id INT,
    quantity INT, amount DECIMAL(10,2), margin DECIMAL(10,2)
) PARTITIONED BY (year INT, month INT)
LOCATION 's3://globalretail-datalake/transactional/sales'
TBLPROPERTIES ('format-version'='2');

-- Time travel: stato tabella a gennaio
SELECT * FROM sales_iceberg FOR TIMESTAMP AS OF TIMESTAMP '2024-01-15 00:00:00';

Fase 3: Glue Catalog e governance

Tutte le tabelle Iceberg vanno registrate nel Glue Catalog, che diventa il punto unico da cui i motori scoprono schema e posizione dei dati. Su questo si appoggia Lake Formation per il controllo granulare: il marketing vede solo metriche aggregate, la finanza vede i dati transazionali ma senza PII. Così la stessa tabella espone viste diverse a ruoli diversi senza duplicare i dati.

Fase 4: query ottimizzate Athena

Con partizioni e catalogo in piedi, Athena sfrutta il partition pruning per scansionare solo i dati necessari. La query seguente calcola la revenue per paese e trimestre leggendo solo i mesi richiesti, e dovrebbe diventare la tua prova di performance:

-- Revenue per paese e trimestre (usa partition pruning)
SELECT c.country, year, quarter, SUM(amount) AS revenue
FROM sales_iceberg s JOIN dim_customers c ON s.customer_id = c.id
WHERE year=2024 AND month BETWEEN 1 AND 3
GROUP BY c.country, year, quarter;

La consegna e la sua checklist

Il progetto è completo quando puoi spuntare tutti i punti seguenti, dove l’ultimo è il vero test di affidabilità: una query su 100 GB deve restare sotto i cinque secondi grazie a partizionamento e formato colonnare.

• Data lake su S3 con partizionamento ottimale
• Iceberg abilitato su almeno una tabella
• Glue Catalog popolato
• Lake Formation policy per accesso granulare
• Query Athena sotto i cinque secondi su 100 GB

Il verdetto si ripete in ogni iterazione del progetto: Parquet partizionato più Iceberg più Glue più Lake Formation più Athena è lo stack che chiude il cerchio senza duplicare i dati.

Perché il progetto funziona: la storia di Netflix

Netflix gestisce tabelle enormi su S3 lette da più motori e incontra i limiti dei file semplici quando schema e partizioni cambiano. Nel 2018 il team rende pubblico Iceberg, un formato tabellare con metadata transazionali ed evoluzione di schema e partizioni. Il progetto passa poi alla Apache Software Foundation e viene adottato da altri operatori su larga scala. La lezione per questo progetto è diretta: il lake regge quando file, catalogo e motori dialogano attraverso un formato versionato e non attraverso convenzioni sui nomi delle cartelle.

Verdetto: Parquet partizionato più Iceberg più Glue più Lake Formation più Athena è lo stack che chiude il cerchio senza duplicare i dati: il progetto è completo solo quando la query di controllo su 100 GB resta sotto i cinque secondi e ogni scelta spiega quale rischio riduce.

Domande di riepilogo

1. Quale partizionamento applica la zona transactional per rendere economica la query del trimestre?
2. Quando il time travel di Iceberg evita di ricostruire a mano lo stato passato di una tabella?
3. Quale policy di Lake Formation impedisce al marketing di leggere le colonne con dati personali?
4. Quale misura sulla query Athena dimostra che partizionamento e formato colonnare funzionano?