Chi progetta un data stack oggi convive con un’incertezza scomoda: non sappiamo quali workload chiederà l’AI il prossimo anno. La proposta della Open Data Infrastructure (ODI) è di smettere di indovinare il futuro e progettare invece per il cambiamento, tenendo i dati portabili e governati. In pratica, ODI scompone in cinque layer separabili quello che le piattaforme tradizionali tenevano accoppiato.
I cinque layer
Il primo è lo storage. La separazione tra storage e compute nasce con l’object storage: S3 è del 2006 e ha reso pratico tenere i dati fuori dal motore che li interroga. Se lo storage è tuo (S3, ADLS, GCS), il compute torna a essere una scelta reversibile.
Il secondo è il file format. Un formato colonnare aperto come Apache Parquet permette a molti motori — Spark, Trino, DuckDB, i warehouse — di leggere gli stessi dati senza conversioni. Si passa da “questo motore possiede i miei dati” a “molti motori li capiscono”.
Il terzo è il table format con il relativo catalog. È il layer che mancava ai data lake grezzi: Apache Iceberg e Delta Lake portano transazioni ACID, snapshot, schema evolution e time travel, coordinando letture e scritture concorrenti. Ma anche il catalog e i metadata devono restare accessibili via standard aperti, altrimenti il lock-in si sposta solo di un livello.
Il quarto è il compute, che a questo punto diventa una decisione di workload: Spark per il batch, Trino per la produzione, un runtime distribuito per il training, DuckDB in locale. L’architettura non deve rendere irreversibile questa scelta.
Il quinto è il layer di trust e semantics. Qui entrano freschezza, gestione dello schema, observability, access control e definizioni di business coerenti. È il territorio di dbt: model contract che fanno fallire la build se il modello non rispetta la forma attesa, e un semantic layer che definisce le metriche una volta sola. La fusione tra Fivetran e dbt Labs, annunciata il 1° giugno 2026, va esattamente in questa direzione.
Un avvertimento onesto dalla fonte: il Fivetran Managed Data Lake Service ha limiti dichiarati, come l’assenza di position delete su Iceberg, nessun supporto Delta Change Data Feed per le tabelle Delta create da Fivetran e nessuna trasformazione interna al servizio. Conoscere questi confini fa parte del progettare bene.
In sintesi
- ODI separa cinque layer: storage, file format, table format e catalog, compute, trust e semantics.
- Standard aperti come Parquet e Iceberg tengono i dati leggibili da più motori e rendono il compute una scelta reversibile.
- Meglio iniziare con un audit dei layer esistenti che con una migrazione “big bang”.
Hai qualcosa da aggiungere? Unisciti alla discussione.