Apache Iceberg alimenta i lakehouse moderni e abilita workflow interoperabili e multi-engine, ma impararne le interne — manifest file, snapshot management, servizi di catalog, strategie di compaction — è complicato. Il punto dell’articolo di Fivetran è pragmatico: per la maggior parte dei team quella curva di apprendimento non porta valore di business, ed è possibile costruire uno storage layer interoperabile senza gestire Iceberg a mano.
Cosa significa interoperabile
Un data lake interoperabile non ti lega a un singolo engine o vendor. Gli stessi dati, in formato aperto su storage cloud standard, sono leggibili da più strumenti: DuckDB, Trino, Snowflake, BigQuery, Spark e Databricks. Si carica il dato una volta e lo si usa ovunque — analisti su Snowflake, data science da notebook Spark, ML engineer su Databricks — senza pipeline ridondanti né copie duplicate.
Perché molti team non dovrebbero gestire Iceberg
Iceberg aggiunge un layer di metadata sopra i Parquet che fa comportare una cartella di file come una tabella di database, con transazioni ACID, schema evolution e time travel. Il costo è operativo: serve un servizio di catalog (una dipendenza critica), l’ingestion deve passare dalle API di Iceberg per garantire l’ACID, e la manutenzione — compaction dei file piccoli, pulizia di snapshot e orphan file — resta a carico del team. Nulla di impossibile, ma è overhead che non tocca il problema di business.
L’approccio fully managed
Il Managed Data Lake Service gestisce ingestion, formato tabellare, catalog e ottimizzazione dello storage. I dati atterrano come Parquet nello storage che possiedi (S3, ADLS Gen2, GCS) tramite oltre 700 connettori, con un Fivetran Iceberg REST Catalog su Apache Polaris read-only per gli engine. La manutenzione è automatica: compaction durante l’ingestion, snapshot expiration giornaliera, pulizia orphan file ogni due settimane per file più vecchi di 7 giorni, metadata mantenuti alla versione corrente più 3 precedenti. Secondo una ricerca GigaOm citata da Fivetran, ingerire attraverso questo servizio porta un risparmio del 77-95% rispetto ai meccanismi di loading nativi di un warehouse.
Restano alcune trappole da evitare, tutte legate al non scavalcare il catalog: non interrogare i Parquet grezzi, non cancellare file manualmente, non fare ALTER TABLE diretti e tenere storage e compute nella stessa region.
In sintesi
- Uno storage layer interoperabile dà accesso multi-engine (Snowflake, Spark, Trino, DuckDB, BigQuery, Databricks) sugli stessi dati aperti.
- Gestire Iceberg in proprio significa catalog, ingestion via API e manutenzione continua: overhead che il servizio managed elimina.
- Compaction, snapshot expiration e pulizia orphan file sono automatiche; GigaOm stima un risparmio del 77-95% sull’ingestion.
Fonte: Get started with Iceberg without the brain freeze — https://www.fivetran.com/blog/get-started-with-iceberg-without-the-brain-freeze
Hai qualcosa da aggiungere? Unisciti alla discussione.