import pandas as pd

Apache Iceberg e table formats per data lake

Quando una tabella di un lakehouse cresce, non basta più sapere dove sono i file. Servono metadata affidabili, schema evolution, partition evolution e time travel. I table format sono il contratto tra lo storage a oggetti e i query engine moderni, ed è questo passaggio da file a tabelle gestite che rende Iceberg interessante: ti lascia evolvere schema e partizioni senza rompere query, cataloghi e processi a valle.

Il problema concreto

Il problema non è conoscere Iceberg in astratto, ma decidere cosa fare quando il team lavora con dati incompleti, metriche ambigue e vincoli tecnici. Una lezione utile separa il segnale dal rumore, dice rispetto a quale baseline interpretare un risultato e indica quale azione diventa difendibile dopo l’analisi.

Un caso tipico: una tabella di eventi cambia schema, aggiunge una partizione logica e deve restare interrogabile da più motori. Qui Iceberg mostra il suo valore, con metadata transazionali, schema evolution e partition evolution che non costringono a riscrivere manualmente il lake.

Come ragionare sulla decisione

Conviene tenere a mente una sequenza, dalla decisione all’azione misurabile.

Passaggio	Domanda da fare	Output atteso
Decisione	Che cosa cambia se capiamo meglio i table format?	Scelta esplicita
Segnale	Quale dato osservabile riduce l’incertezza?	Metrica o evento
Baseline	Rispetto a cosa interpretiamo il risultato?	Confronto credibile
Vincolo	Che cosa puo falsare la lettura?	Assunzione da dichiarare
Azione	Quale passo operativo segue?	Raccomandazione controllabile

La sequenza evita che una nozione tecnica diventi un rituale vuoto. La prima domanda non è “quale metrica calcolo?”, ma quale decisione dovrà essere presa grazie a questa analisi. Se il risultato non aiuta a scegliere tra due azioni alternative, l’analisi è incompleta.

Formalizzare evidenza e rischio

Leggi la lezione come una relazione tra decisione, evidenza e rischio. La tabella rende esplicite le assunzioni, così uno stakeholder può discutere il criterio invece di fidarsi del risultato per autorità.

Elemento	Definizione operativa	Controllo minimo
Unita di analisi	Oggetto su cui misuri il fenomeno	Utente, account, evento, ordine o periodo
Variabile osservata	Segnale che rappresenta il comportamento	Definizione stabile e tracciabile
Baseline	Stato contro cui confronti il segnale	Periodo, segmento, controllo o benchmark
Soglia decisionale	Punto in cui cambia l’azione	Criterio scritto prima della lettura
Rischio residuo	Errore che puo restare anche dopo l’analisi	Sensitivity check o revisione qualitativa

La formalizzazione è solida quando un altro analista può riprodurre la logica, criticare le assunzioni e arrivare alla stessa decisione partendo dagli stessi dati. L’unità di lavoro è il bucket, la partizione, il file, la tabella, il formato o la policy. La metrica osservabile è il costo di scansione, la latenza, l’affidabilità, la freshness o il rischio di accesso. La decisione attesa riguarda il layout dei dati, il table format, il controllo accessi o le lifecycle rule.

Cosa fa Iceberg

Iceberg porta sul lake quattro proprietà che prima richiedevano un warehouse. Le transazioni ACID rendono atomici INSERT, UPDATE e DELETE su file Parquet via snapshot isolation, così non corrompi mai i dati. Il time travel ti lascia leggere la tabella com’era in un istante passato, per esempio SELECT * FROM orders FOR TIMESTAMP AS OF '2024-01-15'. La schema evolution permette di aggiungere, rinominare o riordinare colonne senza riscrivere i dati. L’hidden partitioning evita di specificare WHERE year=2024, perché Iceberg sa come sono partizionati i dati e applica il filtro da solo. Infine, compaction e garbage collection compattano i file piccoli in background e cancellano gli snapshot obsoleti.

Iceberg, Delta Lake e Hudi a confronto

	Iceberg	Delta Lake	Hudi
Creatore	Netflix → Apache	Databricks	Uber → Apache
Ecosistema	Multi-engine (Spark, Trino, Flink, Presto)	Forte su Spark/Databricks	Forte su Spark
Time travel	Sì	Sì	Sì
Maturità	Alta, adottato da Netflix, Apple, Airbnb	Altissima, adottato da Databricks clients	Alta, adottato da Uber, Amazon
Quando usarlo	Ambienti multi-tool, cloud-agnostici	Su Databricks	Pipeline con upsert frequenti

Per un’azienda che non è su Databricks, Iceberg è la scelta più flessibile, perché funziona con Athena, Trino, Spark, Flink e Snowflake.

Caso reale: Netflix e la disciplina delle metriche

Netflix è un esempio utile perché ha costruito molte decisioni di prodotto intorno a segnali comportamentali osservabili: completamento degli episodi, tempo di ricerca prima della riproduzione, abbandono dopo pochi minuti, ritorno nella settimana successiva, efficacia delle raccomandazioni. Il punto non è che ogni azienda debba copiare Netflix. È metodologico: il dato non viene trattato come ornamento, ma come infrastruttura decisionale. Non a caso Iceberg nasce proprio in Netflix.

Quando Netflix valuta una modifica all’esperienza, per esempio una nuova riga di raccomandazioni o un diverso algoritmo di ranking, non misura solo il click immediato. Controlla anche se l’utente guarda davvero il contenuto, se torna nei giorni successivi, se riduce il tempo speso a cercare. Questa disciplina impedisce di ottimizzare vanity metric che sembrano positive nel breve ma erodono valore nel lungo periodo.

Esempio SQL: una vista di controllo

Il pattern è generico ma eseguibile nella maggior parte dei warehouse moderni. Serve a creare una base analitica con metrica, segmento e finestra temporale, così da confrontare periodi e gruppi senza riscrivere la logica ogni volta.

WITH base_events AS (
  SELECT
    user_id,
    account_id,
    event_type,
    event_time,
    DATE_TRUNC('week', event_time) AS week,
    source,
    device_type
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '180 days'
    AND user_id IS NOT NULL
),
weekly_user_metrics AS (
  SELECT
    week,
    user_id,
    COALESCE(source, 'unknown') AS source,
    COALESCE(device_type, 'unknown') AS device_type,
    COUNT(*) AS total_events,
    COUNT(DISTINCT DATE(event_time)) AS active_days,
    COUNT(DISTINCT event_type) AS event_diversity,
    MAX(CASE WHEN event_type IN ('purchase', 'subscribe', 'activation') THEN 1 ELSE 0 END) AS reached_key_outcome
  FROM base_events
  GROUP BY week, user_id, source, device_type
)
SELECT
  week,
  source,
  device_type,
  COUNT(DISTINCT user_id) AS users,
  ROUND(AVG(active_days), 2) AS avg_active_days,
  ROUND(AVG(event_diversity), 2) AS avg_event_diversity,
  ROUND(AVG(reached_key_outcome) * 100, 2) AS key_outcome_rate
FROM weekly_user_metrics
GROUP BY week, source, device_type
ORDER BY week, source, device_type;

La query non è la risposta finale. Crea una superficie di osservazione fatta di trend, segmenti, differenze tra canali e variazioni nel tempo, da cui formulare ipotesi più precise.

Esempio Python: stabilità e anomalie

Una metrica deve essere stabile abbastanza da orientare le decisioni e sensibile abbastanza da segnalare cambiamenti reali. In Python puoi controllare le variazioni anomale settimana su settimana.

# df contiene: week, segment, users, key_outcome_rate
# key_outcome_rate espresso in percentuale, es. 12.4

df = df.sort_values(['segment', 'week']).copy()
df['previous_rate'] = df.groupby('segment')['key_outcome_rate'].shift(1)
df['wow_change_pp'] = df['key_outcome_rate'] - df['previous_rate']
df['rolling_mean'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).mean()
)
df['rolling_std'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).std()
)
df['z_score'] = (df['key_outcome_rate'] - df['rolling_mean']) / df['rolling_std']

anomalies = df[df['z_score'].abs() >= 2].sort_values('z_score')
print(anomalies[['week', 'segment', 'key_outcome_rate', 'wow_change_pp', 'z_score']])

Il controllo evita di reagire a ogni oscillazione casuale e segnala quando una variazione merita un’indagine. In azienda alimenta alert, review settimanali e retrospettive di prodotto.

Lab in tre livelli

Al livello base, scrivi in cinque righe quale decisione concreta dovrebbe migliorare scegliendo un table format. Indica metrica, unità di analisi, baseline e rischio principale. Se non riesci a nominare la decisione, la lezione è ancora troppo astratta.

Al livello intermedio, costruisci una tabella con quattro colonne: segnale osservato, interpretazione prudente, controllo necessario, azione consigliata. Inserisci almeno un caso in cui il segnale non basta per decidere.

Al livello research-grade, trasforma l’esercizio in un memo decisionale con assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e una proposta di monitoraggio dopo la decisione. Come materiale usa S3, Parquet, Iceberg, Delta, Athena, Glue e dataset lakehouse. Se non hai accesso a dati reali, crea un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione segmento e una metrica di outcome.

Errori da evitare

L’errore tipico è usare Iceberg come etichetta tecnica invece che come criterio di scelta. Succede quando il team presenta un numero senza dire quale decisione cambia, quale baseline lo rende interpretabile e quale rischio resta aperto.

Tre errori ricorrono spesso. Il primo è lavorare su dati aggregati troppo presto, perché una media globale può nascondere due segmenti che si muovono in direzioni opposte. Il secondo è non controllare la qualità del dato, dato che eventi duplicati, tracking incompleto e timezone incoerenti producono conclusioni false. Il terzo è confondere correlazione e causalità: se gli utenti che usano una feature convertono di più, potrebbero farlo perché sono già più motivati, non perché la feature causi la conversione.

Checkpoint

Prima di chiudere, prova a rispondere:

1. Quale decisione concreta dovrebbe migliorare questa lezione?
2. Quale unità di analisi rende il problema misurabile?
3. Quale baseline useresti per evitare una lettura isolata?
4. Quale assunzione, se falsa, cambierebbe la conclusione?
5. Quale output consegneresti a uno stakeholder non tecnico?

---

Riferimenti:

• Iceberg. (2024). “Apache Iceberg Documentation.” iceberg.apache.org.
• Netflix. (2021). “Iceberg at Netflix.” Netflix Tech Blog.

Riepilogo

Iceberg e i table format vanno trattati come uno strumento decisionale, non come un argomento da manuale. Il valore nasce dal collegare problema, dati, metrica, segmentazione e azione. Una buona analisi non termina con “il numero è salito” o “il numero è sceso”: termina con una frase operativa, cioè quale decisione prendiamo, con quale confidenza, e quale metrica useremo per sapere se avevamo ragione.