Data Lake vs Data Warehouse vs Lakehouse per PMI italiane 2022: scelta architettura dati

Quasi tutte le PMI italiane che hanno superato i 25-30 dipendenti vivono lo stesso problema: i dati sono ovunque ma da nessuna parte. Il CRM ha gli ordini, l’ERP la fatturazione e il magazzino, l’e-commerce sessioni utente e carrelli, Google Analytics il traffico, Meta Ads le campagne, lo strumento di email marketing le aperture. Ogni reparto guarda i propri dashboard senza mai parlarsi davvero.

Negli ultimi 5-6 anni si è formato il cosiddetto modern data stack: un ecosistema pensato per centralizzare, modellare e analizzare dati senza dover assumere un team da 15 ingegneri come negli anni 2000. Il problema è che oggi (luglio 2022) lo stesso ecosistema offre tre approcci architetturali diversi – Data Warehouse, Data Lake e Data Lakehouse – e la scelta sbagliata trasforma un budget da 800€/mese in una fattura da 8.000€/mese senza che nessuno se ne accorga finché non arriva il rinnovo annuale.

Questo articolo è una guida architetturale per CTO, Head of Data e CEO di PMI italiane che devono decidere quale strada prendere nel 2022, con costi reali, casi d’uso, stack consigliati per fascia di azienda e gli errori più frequenti negli assessment.

I tre paradigmi: una mappa per non perdersi

Prima di scendere nei dettagli serve un linguaggio comune. I tre paradigmi non sono “evoluzioni” lineari: rispondono a problemi diversi con trade-off precisi.

Il Data Warehouse è il più anziano: nasce coi lavori di Bill Inmon (1990) e Ralph Kimball (1996) come repository centralizzato di dati strutturati, ottimizzato per OLAP. Schema definito prima di scrivere i dati (schema-on-write), struttura dimensionale (fatti e dimensioni nel modello a stella o snowflake), caso d’uso primario business intelligence: report, dashboard, ad hoc query.

Il Data Lake è più giovane: termine coniato da James Dixon (CTO Pentaho) nel 2010. L’intuizione: invece di forzare i dati in uno schema predefinito, scrivi tutto su storage cheap (HDFS prima, poi object storage S3, ADLS Gen2, GCS) nel formato originale e definisci lo schema al momento della lettura (schema-on-read). Ottimo per ingestion alto volume di dati eterogenei (log, eventi, immagini, video, JSON, parquet). Pessimo senza governance: diventa “data swamp”, palude di file che nessuno sa più cosa contengano.

Il Data Lakehouse sintetizza i due. Termine formalizzato da Databricks nel paper “Lakehouse: A New Generation of Open Platforms…” (CIDR 2021). Object storage cheap come fondamenta + livello transazionale (Delta Lake, Iceberg, Hudi) che porta ACID, schema enforcement, time travel e performance da DWH direttamente sopra parquet. Un unico sistema gestisce BI, data engineering e ML senza copie multiple.

Data Warehouse: il workhorse della BI moderna

Un Data Warehouse cloud nel 2022 è un sistema columnar, distribuito, con compute e storage separati (o quasi). Le scelte principali sul mercato sono Snowflake, Google BigQuery, Amazon Redshift e Azure Synapse Analytics.

Snowflake è la scelta più popolare nelle scale-up europee del 2022. Dopo l’IPO del 2020 ha investito in features enterprise: multi-cluster warehouse con auto-scale, zero-copy cloning, time travel, data sharing. Il pricing separa storage (~23€/TB/mese compresso) e compute (warehouse XS = $2/h, scale by power of 2). Il vantaggio operativo è enorme: scali il warehouse XS a M solo durante la trasformazione notturna. Lo svantaggio: è facile mandare la bolletta alle stelle se qualcuno lascia un warehouse Large idle.

BigQuery è la scelta più semplice per chi è già su Google Cloud. È serverless: $20/TB di storage attivo, $5/TB di dati scansionati dalle query nel modello on-demand. Esiste anche il flat-rate con slot reservation a partire da $2.000/mese, sensato solo sopra una certa soglia. Usato in Italia da molte PMI digitali perché l’export GA4 nativo è gratuito.

Redshift di AWS resta solido ma meno “fluido” di Snowflake. Con i nodi RA3 ha introdotto storage separato, ma cluster management (resize, snapshot, pause/resume) è più operativo. Conviene se siete full AWS e usate Redshift Spectrum su S3.

Azure Synapse è la scelta default in ambienti Microsoft enterprise: dedicated SQL pool, serverless SQL pool e Spark pool. Comodo se l’azienda è già su Azure AD e Power BI Premium.

Il dimensional modeling Kimball-style resta lo standard: tabelle dei fatti con misure (fact_orders, fact_invoices), dimensioni (dim_customer, dim_product, dim_date), star schema per la maggior parte dei casi BI. L’approccio Inmon (3NF + data mart) resta valido ma più adatto a contesti enterprise.

Data Lake: storage cheap e flessibilità estrema

Un Data Lake nasce come “scrivi tutto, capisci dopo”. Il foundation layer è quasi sempre object storage cloud: Amazon S3, Azure Data Lake Storage Gen2, Google Cloud Storage. Costi ridicoli rispetto a un DWH: S3 Standard ~$23/TB/mese, Glacier Instant Retrieval ~$4/TB/mese, con lifecycle policies sotto il dollaro per TB sui dati freddi.

Sopra lo storage si appoggiano formati colonnari: Apache Parquet (Apache 2013) è lo standard de facto, Apache ORC più diffuso in Hive/Hadoop. Si compone un catalogo (Glue Catalog su AWS, Hive Metastore altrove) e si interroga con motori SQL serverless: Athena, BigQuery External Tables, Trino/Presto, Spark.

L’ingestion usa due pattern: batch (CSV/JSON/parquet via Airflow o Fivetran con destination S3) e stream (eventi via Kafka, Kinesis o Pub/Sub partizionati per data/ora). I dati possono essere strutturati (export CRM), semi-strutturati (JSON eventi, log) o non-strutturati (immagini, audio, PDF).

Vantaggio: flessibilità totale e costi storage minimi, raw per anni a poche centinaia di euro. Svantaggio: senza governance diventa palude. Senza schema enforcement il file di ieri non garantisce lo stesso layout di oggi. Senza ACID due job concorrenti corrompono dati. Senza catalogo, dopo un anno nessuno sa cosa c’è dentro.

Per le PMI italiane il Data Lake “puro” del 2022 è raramente la risposta giusta: si paga complessità senza beneficiare se i dati sono <5 TB e i casi d'uso sono BI tradizionale.

Lakehouse: la sintesi che convince Databricks (e non solo)

Il Lakehouse risolve la governance del Lake aggiungendo un layer transazionale ai parquet. Le tre implementazioni principali nel 2022:

Delta Lake (OSS dal 2019, Databricks): transaction log JSON accanto ai parquet, ACID, MERGE/UPDATE/DELETE, time travel, schema enforcement ed evolution. Default su Databricks ma funziona fuori (Delta 2.0 amplia la compatibilità). Usabile su S3, ADLS, GCS senza lock-in di compute.

Apache Iceberg (Netflix 2018, Apache TLP 2020): table format con snapshot, partition evolution, hidden partitioning, schema evolution sicura. Supportato da Snowflake (preview), Dremio, Trino, Spark, Flink. Sta diventando lo standard “vendor-neutral”.

Apache Hudi (Uber 2017, Apache TLP 2020): orientato a workload incrementali con upsert pesanti. Strong su streaming, copy-on-write e merge-on-read tables.

Sopra al table format si appoggia il compute. Databricks Lakehouse Platform è il prodotto più maturo: Spark con motore Photon (GA nel 2022, C++ vettorizzato), notebook collaborativi, SQL Warehouses per BI, MLflow per ML, Unity Catalog (preview a luglio 2022) per governance. Pricing su DBU: cluster Jobs medio ~$0.30/DBU oltre al cloud compute.

L’architettura interna segue il pattern medallion (bronze/silver/gold) proposto da Databricks:

• Bronze: ingestion raw da source system, schema il più vicino possibile alla sorgente, immutabile, append-only.
• Silver: dati puliti, deduplicati, conformati. Filtri di qualità, standardizzazione formati, join leggeri.
• Gold: aggregati pronti al consumo da parte di BI, ML feature store, API. Modelli dimensionali, KPI calcolati, snapshot consolidati.

Pricing reale: cosa pagate davvero a 1 TB di dati

Numeri concreti per una PMI italiana con 1 TB di dati attivi, ingestion incrementale 5-10 GB/giorno, dashboard interattive per ~20 utenti, 1-2 job di trasformazione notturni.

Snowflake small: storage $23/TB/mese (~21€), warehouse XS attivo 4-6 ore/giorno = ~120 ore × $2 = $240/mese. Totale ~250€/mese. Più Fivetran (300-800€/mese per 5-10 connettori) e dbt Core (free) o dbt Cloud Team ($100/seat/mese): siete tra 600 e 1.500€/mese full stack.

BigQuery on-demand: storage 1 TB = $20/mese, query scan ~5 TB/mese (con partition pruning e materialized views) = $25. Totale ~50€/mese sui costi BigQuery, ma sopra i 10 TB scan/mese conviene flat-rate ($2.000/mese minimo).

Redshift RA3: si parte da ra3.xlplus ~$1,086/h, ~780€/mese 24/7 più storage RMS a $24/TB/mese. Pause/resume aiuta ma meno fluido di Snowflake.

Databricks Lakehouse: cluster Jobs medio (4-8 worker m5.xlarge) per 4 ore/giorno = ~120 DBU × $0.30 = $36 + cloud compute ~$200/mese + storage ~$25/mese. Totale ~250-350€/mese lakehouse core. SQL Warehouse per BI: altre 50-150€/mese.

Regola pratica: per una PMI sotto i 5 TB di dati attivi il costo piattaforma non è il problema. Il problema vero sono i tool intorno e il personale per integrarli.

Ingestion moderna: Fivetran, Airbyte e l’era dell’ELT

Nessuna PMI nel 2022 dovrebbe scrivere connettori ETL custom per Salesforce, HubSpot, Shopify, Stripe o Google Ads. Il mercato managed è maturo:

Fivetran (Series E sep 2021, valutata $5.6B): leader di mercato, ~250 connettori pre-built, pricing su MAR (Monthly Active Rows). Per 5-10 sorgenti standard: 300-1.500€/mese. Setup in minuti, manutenzione zero. Padre del modello “ELT moderno”: estrai raw nel DWH, trasforma poi con SQL.

Airbyte (open source dal 2020, Series B 2021): alternativa OSS, self-hosted gratis o Cloud da $2.50/1.000 righe sincronizzate. ~350 connettori a luglio 2022, qualità variabile. Ottimo per chi ha team in grado di gestire l’infrastruttura.

Stitch (Talend dal 2018): connettori più limitati, pricing fisso a tier, ok per use case semplici. Orchestrazione: Airflow, Prefect, Dagster (la terza è la più giovane ma in rapida crescita con un modello asset-based).

I dati raw nel DWH/Lakehouse si trasformano con dbt: SQL + Jinja + test + documentazione. dbt è la tecnologia più impattante del modern data stack: ha sostituito quasi ovunque le stored procedure custom e gli script Python sparsi. Series D nov 2021 a $4.2B di valutazione racconta meglio di qualsiasi articolo l’adozione.

Sei segnali che vi basta un Data Warehouse

Nella maggior parte degli assessment che facciamo per PMI italiane, il Data Warehouse cloud è la risposta giusta. Ecco i segnali concreti:

1. Volume sotto i 5 TB di dati attivi. A questi volumi anche BigQuery serverless o Snowflake XS gestiscono tutto agilmente, senza bisogno di compute distribuito.
2. Caso d’uso primario è la BI: dashboard direzionali, report finanziari, analisi vendite, customer journey. Niente ML pesante in produzione.
3. Struttura dei dati prevedibile. CRM (record di vendita), ERP (fatture, ordini, magazzino), e-com (ordini, clienti, prodotti). Tutto modellabile in star schema.
4. Team data composto da 1-2 persone. Un analytics engineer che conosca dbt + un BI developer su Power BI/Looker. Senza un team data engineering dedicato, gestire un Lakehouse è un peso.
5. Cadenza di refresh oraria o giornaliera. Se vi serve real-time sotto i 5 minuti, allora il discorso cambia.
6. Budget piattaforma sotto i 3.000€/mese. A questa fascia un DWH ben configurato è il sweet spot operativo.

Sei segnali che vale la pena valutare un Lakehouse

Il Lakehouse ha senso quando uno o più di questi fattori entrano in gioco:

1. Volume oltre i 10 TB attivi con previsione di crescita ad alta velocità. A scale lo storage cheap del Lake diventa significativo rispetto ai costi DWH.
2. Casi d’uso ML in produzione: scoring predittivo, raccomandazioni, forecasting con modelli che hanno bisogno di feature store e training su dati raw.
3. Dati eterogenei: log applicativi, eventi prodotto JSON, immagini, audio, file PDF da OCR. Il DWH non li gestisce nativamente.
4. Team data engineering di 3+ persone. Serve maturità per gestire cluster Spark, lineage, deployment di pipeline streaming.
5. Bisogno di near real-time (1-5 minuti) con architetture stream-first (Kafka + Spark Streaming o Flink).
6. Requisiti di portabilità open: volete evitare lock-in proprietario e mantenere i dati in formato Iceberg/Delta su object storage standard.

Modern data stack pattern per PMI italiane

Stack tipico consigliato a PMI italiana 50-150 dipendenti nel 2022:

• Ingestion: Fivetran (5-10 sorgenti standard) + Airbyte self-hosted per fonti custom.
• Storage/compute: Snowflake (XS-M) o BigQuery on-demand, in base all’ecosistema cloud preesistente.
• Trasformazione: dbt Core o dbt Cloud per CI/CD managed.
• Orchestrazione: Airflow su Cloud Composer/MWAA, o Prefect Cloud per team piccoli.
• Semantic layer: Looker (LookML) o Cube.js. dbt metrics è promettente ma giovane a luglio 2022.
• BI: Power BI Premium o Looker. Metabase OSS per quick wins.
• Data quality: Great Expectations o Soda Core.
• Catalog/lineage: Amundsen o DataHub se serve governance formale.

Budget realistico per PMI ~3 TB attivi: 2.500-6.000€/mese tooling + personale (1 analytics engineer + 1 BI developer = 80-130K€/anno).

Semantic layer e feature store: i pezzi che spesso si dimenticano

Due componenti che molte PMI non implementano e poi pagano caro.

Il semantic layer centralizza le definizioni di metriche e dimensioni. Senza, ogni dashboard riscrive “fatturato netto” o “margine lordo” a modo suo e dopo un anno avete tre numeri diversi sulla stessa metrica. Looker (LookML) è lo storico. Cube.js l’alternativa OSS in crescita. MetricFlow (acquisito da Transform nel 2022) il newcomer. dbt metrics è la promessa per il 2023.

Il feature store serve con ML in produzione: separa il calcolo delle feature da training e serving. Feast è lo standard OSS, Tecton il prodotto managed. Per PMI con <5 modelli ML è over-engineering: bastano tabelle gold ben fatte nel DWH.

Data mesh: perché probabilmente NON serve alle PMI

Il data mesh è stato proposto da Zhamak Dehghani (ThoughtWorks) nel 2019 come paradigma decentralizzato in cui ogni dominio aziendale è proprietario dei propri data product. È un’architettura organizzativa più che tecnica.

Per una PMI sotto i 500 dipendenti il data mesh è quasi sempre la risposta sbagliata: richiede una maturità organizzativa che si forma su scala enterprise. Se avete 50 persone, il team data centralizzato che fa da fornitore interno è più efficiente di 8 mini-team di dominio che reinventano la ruota ognuno a modo suo. Tenetelo come orizzonte per quando supererete i 300-500 dipendenti.

Governance, lineage, access control

Anche su scala PMI tre cose vanno fatte dal giorno uno.

Data catalog: dovete sapere cosa avete. DataHub, Amundsen o il catalog nativo della piattaforma (Snowflake Tagging, BigQuery Data Catalog).

Lineage: chi ha generato questo numero, da quale sorgente, attraverso quali trasformazioni. dbt genera lineage automatico sui propri modelli; per end-to-end serve uno strumento dedicato (OpenLineage è lo standard emergente).

Access control: non tutti devono vedere tutto. Row-level security in Snowflake/BigQuery, masking di colonne PII, ruoli per dominio. Per i dati personali la GDPR non lascia margine: serve audit trail.

Errori comuni che vediamo negli assessment

Negli ultimi 18 mesi ci è capitato di entrare in PMI italiane già “modernizzate” con problemi cronici. I pattern ricorrenti:

1. Over-engineering del Lake quando bastava un DWH. Cluster Spark accesi 24/7 a 4.000€/mese per servire 6 dashboard Power BI su volumi da 800 GB.
2. Niente semantic layer. Tre versioni di “MRR” in tre dashboard diverse. Il CFO torna a Excel.
3. Niente naming convention né documentazione. Tabelle `temp_test_v2_final_giuliano` in produzione. Nessuno sa cosa siano dopo 6 mesi.
4. Refresh notturni che falliscono in silenzio. Niente monitoring né alert. Il management lavora su dati di 4 giorni fa senza saperlo.
5. Cost monitoring assente. Bolletta Snowflake che passa da 800 a 6.000$ per un join scritto male, scoperta al consuntivo.
6. Stack troppo ampio. 14 tool diversi per un team di 2 persone. Manutenzione impossibile.
7. PII sparse senza masking. Email clienti in chiaro a tutti gli analisti. Rischio GDPR elevato.

Roadmap pilota in 90 giorni

Roadmap realistica per una PMI che parte da zero (Excel ovunque) e arriva a MVP affidabile in 90 giorni.

Settimane 1-2: Discovery e architecture decision. Mappa 6-8 sorgenti prioritarie, volumi attivi, 5 dashboard chiave. Decidi DWH vs Lakehouse coi segnali visti sopra. Per quasi tutte le PMI sarà DWH.

Settimane 3-4: Setup. Provisioning DWH cloud, account Fivetran/Airbyte, repo Git per dbt, ambiente staging/production, connettori sulle 6-8 sorgenti.

Settimane 5-8: Modeling con dbt. Staging (1:1 con sorgenti, pulizia base), intermediate (join e business logic), mart (star schema BI). Test dbt sui modelli chiave (uniqueness, not_null, accepted_values, relationships).

Settimane 9-10: BI layer. 5 dashboard chiave su Power BI o Metabase, semantic layer definito. Pubblicazione interna con onboarding stakeholder.

Settimane 11-12: Hardening e handover. Monitoring pipeline (Slack alert), cost dashboard, documentazione dbt auto-generata, training team interno.

Output atteso: 5 dashboard live, pipeline automatizzate, modello dati documentato, costi piattaforma 1.500-3.500€/mese.

Come scegliere: la decision matrix in 5 step

Domande frequenti

Conclusione: pragmatismo prima di tutto

Nel 2022 una PMI italiana ha tre paradigmi tra cui scegliere ma per quasi tutte la risposta giusta è la più semplice: un Data Warehouse cloud ben modellato, con ingestion managed, trasformazioni dbt e BI moderna. Il Data Lake e il Lakehouse sono strumenti potenti ma vanno usati quando i segnali architetturali lo giustificano: volumi reali sopra i 10 TB, ML in produzione, dati eterogenei, team data engineering forte.

L’errore peggiore non è “scegliere lo strumento sbagliato”: è perdere 12 mesi a litigare sulla scelta di architettura mentre il business continua a lavorare su Excel. Partite con un pilota di 90 giorni su DWH cloud, validate i casi d’uso e fate evolvere lo stack solo quando i numeri reali (volumi, casi d’uso, team) lo richiedono.