Data Warehouse & Lakehouse

Executive summary

Le aziende che raccolgono grandi volumi di dati, transazioni, ordini, dati di produzione, interazioni, hanno bisogno di un luogo dove conservarli in modo strutturato e poterli analizzare velocemente. Negli ultimi anni, le opzioni disponibili si sono moltiplicate: dai sistemi specializzati offerti dai grandi fornitori di servizi cloud, ai motori analitici leggeri che funzionano su un singolo computer, fino a formati di archiviazione aperti che permettono di interrogare gli stessi dati con strumenti diversi senza doverli copiare. Questo articolo analizza le principali architetture di archiviazione e analisi dei dati, confrontandone i meccanismi interni, i costi, i vincoli, e la recente convergenza verso sistemi ibridi che combinano i vantaggi di approcci precedentemente separati, mostrando che la scelta dell'architettura ha implicazioni dirette e durature sulla flessibilità, sui costi e sulla capacità di evoluzione dell'infrastruttura dati aziendale.

Background

L'evoluzione delle architetture di storage analitico negli ultimi due decenni riflette un cambiamento fondamentale nel rapporto tra costo dello storage, costo del compute e volume dei dati. I data warehouse tradizionali (Teradata, Netezza, Oracle Exadata) adottavano architetture in cui storage e compute risiedevano sullo stesso hardware dedicato, con scalabilità ottenuta aggiungendo nodi fisici a un cluster proprietario. Questo modello offriva performance prevedibili ma a un costo elevato e con scalabilità limitata dalla capacità dell'hardware proprietario.

La transizione al cloud ha introdotto il principio architetturale della separazione tra storage e compute: i dati risiedono su object storage distribuito (Amazon S3, Google Cloud Storage, Azure Blob Storage) a costo marginale per terabyte, mentre il compute viene allocato on-demand e rilasciato al termine della query [2]. Questa separazione, formalizzata da Snowflake nel paper "The Snowflake Elastic Data Warehouse" presentato a SIGMOD 2016, ha trasformato l'economia del data warehousing: il costo di conservazione dei dati storici è diventato trascurabile, mentre il costo si concentra sul compute effettivamente utilizzato per le query [2].

In parallelo, il formato colonnare è diventato lo standard per lo storage analitico. A differenza dei formati row-based (dove ogni riga è memorizzata contiguamente), i formati colonnari (Apache Parquet, ORC) memorizzano i valori di ciascuna colonna in modo contiguo, consentendo: (a) la lettura selettiva delle sole colonne necessarie per la query (column pruning), (b) una compressione significativamente più efficiente grazie all'omogeneità dei valori nella stessa colonna, e (c) l'applicazione di encoding specifici per tipo di dato (dictionary encoding, run-length encoding, delta encoding) [3]. Su workload analitici tipici (aggregazioni su subset di colonne), lo storage colonnare produce miglioramenti di performance significativi rispetto al row-based, tipicamente di uno o due ordini di grandezza su workload con alta selettività colonnare e ripetizione dei valori, con rapporti di compressione variabili in base alla distribuzione dei dati (5-10x è un range frequentemente osservato ma non universale) [3].

La convergenza più recente è l'emergere del data lakehouse: un'architettura che combina lo storage economico e flessibile del data lake (file su object storage) con le garanzie transazionali e le performance di query del data warehouse, mediate da open table format (Apache Iceberg, Delta Lake, Apache Hudi) che aggiungono transazioni ACID, time travel, schema evolution e metadata management a file Parquet su object storage [4, 5].

Architetture cloud: analisi comparativa

Snowflake

Snowflake implementa un'architettura multi-cluster shared-data: i dati risiedono su un layer di storage proprietario (basato su micro-partition immutabili e compresse), mentre il compute è fornito da virtual warehouse, cluster elastici che vengono avviati on-demand e sospesi automaticamente quando inattivi [2]. Ogni virtual warehouse opera indipendentemente sullo stesso storage, consentendo workload concorrenti (ETL, query analitiche, data science) senza contesa.

Il modello di costo è basato su credit consumati dal compute (il costo per credit varia per edizione e regione, si consulti il listino ufficiale per i valori correnti). Il costo di storage è separato e dipende dalla regione e dalla compressione effettiva. L'auto-suspend, la sospensione automatica del warehouse dopo un periodo di inattività, è il meccanismo chiave per controllare i costi, ma richiede configurazione consapevole: un warehouse che resta attivo 24/7 senza auto-suspend consuma 720 credit/mese anche senza query [6].

Dal 2024, Snowflake supporta la lettura e scrittura di tabelle in formato Apache Iceberg, Iceberg Tables, consentendo a engine esterni (Spark, Flink, Trino) di accedere agli stessi dati senza passare per Snowflake, riducendo il vendor lock-in sullo storage [6]. Questa apertura verso formati open è una risposta strategica alla pressione competitiva del paradigma lakehouse.

BigQuery

BigQuery adotta un'architettura serverless: non esistono cluster da configurare o warehouse da dimensionare. Il compute viene allocato automaticamente in base alla complessità della query, con due modelli di pricing: on-demand ($5/TB scansionato, con 1 TB/mese gratuito) e capacity-based (slot riservati, $0.04/slot/ora) [7]. Il modello on-demand è particolarmente attraente per PMI con workload irregolari, il costo è proporzionale all'uso effettivo, ma richiede ottimizzazione: una query non ottimizzata che scansiona un'intera tabella da 1 TB costa $5 ogni volta.

Il motore di query di BigQuery, Dremel, descritto nel paper originale pubblicato su VLDB nel 2010, utilizza un'architettura ad albero multi-livello per la distribuzione delle query su migliaia di nodi in parallelo [8]. Lo storage nativo è colonnare e compresso, con supporto per nested e repeated field (strutture JSON-like nativamente interrogabili). BigQuery supporta tabelle in formato Apache Iceberg (BigLake Managed Tables) e Delta Lake (via BigLake), consentendo workload cross-engine sugli stessi dati [7].

Le ottimizzazioni chiave per il controllo dei costi includono: partitioning (organizzazione fisica per colonna temporale, le partizioni non scansionate non vengono fatturate), clustering (ordinamento fisico all'interno delle partizioni per le colonne filtrate più frequentemente), e materialized view (risultati pre-calcolati aggiornati automaticamente) [7].

DuckDB

DuckDB è un motore analitico SQL embeddabile, progettato per l'esecuzione in-process, all'interno dell'applicazione che lo utilizza, senza un server separato [9]. L'architettura opera su un singolo nodo (laptop, server, container), utilizza una rappresentazione colonnare in memoria e su disco, e sfrutta il parallelismo delle CPU multi-core per le query analitiche.

DuckDB è distribuito sotto licenza MIT a costo zero di licenza. Le performance su dataset che entrano in memoria (tipicamente fino a decine di GB, estendibili a centinaia di GB con spill-to-disk) sono competitive con i warehouse cloud per query ad hoc, con latenza nell'ordine dei millisecondi anziché dei secondi [9]. L'integrazione nativa con Apache Parquet e Apache Iceberg consente a DuckDB di interrogare direttamente file su disco locale o su object storage (S3, GCS) senza importazione.

MotherDuck, la versione cloud-managed di DuckDB, estende il modello con un'architettura ibrida: il processing avviene sia localmente (DuckDB nel client) sia nel cloud, con il query planner che decide automaticamente dove eseguire ciascuna operazione in base alla località dei dati [10]. Per le PMI, DuckDB rappresenta un punto di ingresso a costo zero: un singolo data engineer può costruire una pipeline dbt + DuckDB su un server esistente, senza infrastruttura cloud. Il limite emerge quando i volumi crescono oltre la capacità di un singolo nodo o quando la concorrenza multi-utente diventa un requisito.

PostgreSQL con estensioni analitiche

PostgreSQL non è nativamente ottimizzato per workload analitici (storage row-based, query analitiche con full table scan). Tuttavia, un ecosistema di estensioni ne amplia le capacità: pg_duckdb integra il motore DuckDB direttamente nel processo PostgreSQL per query analitiche colonnari [9]; Citus distribuisce le tabelle su un cluster di nodi per query parallele su grandi dataset [11]; TimescaleDB ottimizza PostgreSQL per serie temporali con chunking e compressione colonnare [12]. Questo approccio è rilevante per le PMI che già utilizzano PostgreSQL come database applicativo: l'aggiunta di un'estensione evita un sistema separato e la duplicazione dei dati, al costo di un compromesso sulle performance rispetto a un warehouse dedicato.

Open table format: Iceberg, Delta Lake e interoperabilità

Gli open table format aggiungono un layer di metadati sopra file Parquet su object storage, fornendo: transazioni ACID, time travel (accesso a snapshot storici), schema evolution (modifica di colonne senza riscrittura), e partition evolution [4, 5].

Apache Iceberg, progetto della Apache Software Foundation nato da un'iniziativa Netflix, è il formato con il supporto multi-engine più ampio: Snowflake, BigQuery, Databricks, Spark, Flink, Trino, Presto, Dremio, DuckDB [4]. La specifica definisce un modello di metadati a tre livelli, catalog (puntatore al metadata corrente), metadata file (schema, partitioning, snapshot), manifest file (lista dei file dati con statistiche per il pruning), che consente al query engine di determinare quali file leggere prima di scansionare i dati, abilitando pruning efficiente su tabelle con milioni di file [4].

Delta Lake, sviluppato da Databricks, adotta un approccio basato su transaction log sequenziale [5]. L'integrazione più stretta è con l'ecosistema Spark/Databricks, ma il supporto per engine esterni si è ampliato con la specifica Delta UniForm (2024), che genera automaticamente metadati compatibili con Iceberg, riducendo la barriera di interoperabilità [5].

La convergenza verso Iceberg come formato di interscambio è il trend dominante nel 2025-2026: tutti i principali warehouse cloud e engine analitici supportano la lettura di tabelle Iceberg, rendendo possibile un'architettura in cui i dati vengono scritti una volta su object storage e letti da qualsiasi engine compatibile, riducendo strutturalmente il vendor lock-in [4].

Criteri di selezione per contesti PMI

In tutti i casi, l'adozione di Apache Iceberg come formato di storage preserva la portabilità dei dati indipendentemente dal warehouse scelto, una decisione architetturale che protegge l'investimento nella modellazione e nella pipeline da futuri cambi di piattaforma [4].

Limiti e problemi aperti

Costi nascosti. I modelli pay-per-query e pay-per-credit possono produrre costi inattesi con query non ottimizzate su grandi dataset. Senza partitioning, clustering e query governance, i costi mensili possono eccedere significativamente le previsioni.

Interoperabilità incompleta. Nonostante la convergenza verso Iceberg, le implementazioni vendor-specific introducono estensioni proprietarie che limitano la portabilità effettiva. L'interoperabilità è reale ma non ancora trasparente, richiede validazione caso per caso.

DuckDB: limiti di scala. DuckDB è un motore single-node senza supporto nativo per distribuzione su cluster, multi-tenancy, né concorrenza da molti utenti. Il modello di scaling è verticale (più RAM, più CPU) [9]. Per workload oltre le centinaia di GB con decine di utenti, la migrazione a un warehouse cloud diventa necessaria.

Governance e sicurezza. I warehouse cloud offrono governance integrata (row-level security, column masking, audit trail) che i motori open-source (DuckDB, PostgreSQL) non forniscono nativamente. Per contesti con requisiti GDPR o dati sensibili, questa differenza è architetturalmente significativa.

Riferimenti

[1] M. Kleppmann, Designing Data-Intensive Applications, O'Reilly Media, 2017.

[2] T. Dageville et al., "The Snowflake Elastic Data Warehouse," in Proc. ACM SIGMOD, 2016. https://doi.org/10.1145/2882903.2903741

[3] D. Abadi et al., "The Design and Implementation of Modern Column-Oriented Database Systems," in Foundations and Trends in Databases, vol. 5, no. 3, 2013.

[4] Apache Software Foundation, "Apache Iceberg Documentation," 2025. https://iceberg.apache.org/docs/latest/

[5] Linux Foundation / Databricks, "Delta Lake Documentation," 2025. https://docs.delta.io/latest/index.html

[6] Snowflake, "Snowflake Documentation," 2026. https://docs.snowflake.com/

[7] Google Cloud, "BigQuery Documentation," 2026. https://cloud.google.com/bigquery/docs

[8] S. Melnik et al., "Dremel: Interactive Analysis of Web-Scale Datasets," in Proc. VLDB Endowment, vol. 3, 2010. https://research.google/pubs/pub36632/

[9] M. Raasveldt, H. Mühleisen, "DuckDB: an Embeddable Analytical Database," in Proc. ACM SIGMOD, 2019. https://doi.org/10.1145/3299869.3320212

[10] MotherDuck, "MotherDuck Documentation," 2026. https://motherduck.com/docs/

[11] Citus Data / Microsoft, "Citus Documentation," 2025. https://docs.citusdata.com/

[12] Timescale, "TimescaleDB Documentation," 2025. https://docs.timescale.com/