{"id":2268,"date":"2022-07-21T16:18:00","date_gmt":"2022-07-21T14:18:00","guid":{"rendered":"https:\/\/brentasoft.com\/blog\/data-lake-vs-warehouse-vs-lakehouse-pmi-italiane-2022\/"},"modified":"2022-07-21T16:18:00","modified_gmt":"2022-07-21T14:18:00","slug":"data-lake-vs-warehouse-vs-lakehouse-pmi-italiane-2022","status":"publish","type":"post","link":"https:\/\/brentasoft.com\/blog\/data-lake-vs-warehouse-vs-lakehouse-pmi-italiane-2022\/","title":{"rendered":"Data Lake vs Data Warehouse vs Lakehouse per PMI italiane 2022: scelta architettura dati"},"content":{"rendered":"

Quasi tutte le PMI italiane che hanno superato i 25-30 dipendenti vivono lo stesso problema: i dati sono ovunque ma da nessuna parte<\/strong>. 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.<\/p>\n

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

Questo articolo \u00e8 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\u00f9 frequenti negli assessment.<\/p>\n

\n

TL;DR – Verdetto per persona<\/h3>\n

PMI 25 dipendenti, 1-5M ricavi:<\/strong> Data Warehouse cloud (BigQuery o Snowflake small), ELT con Fivetran o Airbyte, dbt per le trasformazioni, Power BI o Looker Studio per la BI. Budget: 800-2.500\u20ac\/mese. Niente Data Lake, niente Lakehouse.<\/p>\n

Scale-up 100 dipendenti, 10M+ ricavi:<\/strong> Cloud Data Warehouse o Lakehouse leggero. Se hai casi ML o ingestion semi-strutturata (log, eventi prodotto) il Lakehouse Databricks o Snowflake con stage esterni S3 \u00e8 ragionevole. Budget: 3.000-8.000\u20ac\/mese.<\/p>\n

Enterprise 500+ dipendenti:<\/strong> Lakehouse pieno (Databricks o Snowflake + Iceberg), team data engineering dedicato (3-5 persone), governance formale con data catalog. Budget: 15-50K\u20ac\/mese.<\/p>\n<\/div>\n

I tre paradigmi: una mappa per non perdersi<\/h2>\n

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

Il Data Warehouse<\/strong> \u00e8 il pi\u00f9 anziano: nasce coi lavori di Bill Inmon (1990) e Ralph Kimball (1996) come repository centralizzato di dati strutturati, ottimizzato per OLAP. Schema definito prima<\/em> 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.<\/p>\n

Il Data Lake<\/strong> \u00e8 pi\u00f9 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\u00f9 cosa contengano.<\/p>\n

Il Data Lakehouse<\/strong> sintetizza i due. Termine formalizzato da Databricks nel paper “Lakehouse: A New Generation of Open Platforms…”<\/em> (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.<\/p>\n

Data Warehouse: il workhorse della BI moderna<\/h2>\n

Un Data Warehouse cloud nel 2022 \u00e8 un sistema columnar, distribuito, con compute e storage separati (o quasi). Le scelte principali sul mercato sono Snowflake<\/strong>, Google BigQuery<\/strong>, Amazon Redshift<\/strong> e Azure Synapse Analytics<\/strong>.<\/p>\n

Snowflake<\/strong> \u00e8 la scelta pi\u00f9 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\u20ac\/TB\/mese compresso) e compute (warehouse XS = $2\/h, scale by power of 2). Il vantaggio operativo \u00e8 enorme: scali il warehouse XS a M solo durante la trasformazione notturna. Lo svantaggio: \u00e8 facile mandare la bolletta alle stelle se qualcuno lascia un warehouse Large idle.<\/p>\n

BigQuery<\/strong> \u00e8 la scelta pi\u00f9 semplice per chi \u00e8 gi\u00e0 su Google Cloud. \u00c8 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\u00e9 l’export GA4 nativo \u00e8 gratuito.<\/p>\n

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

Azure Synapse<\/strong> \u00e8 la scelta default in ambienti Microsoft enterprise: dedicated SQL pool, serverless SQL pool e Spark pool. Comodo se l’azienda \u00e8 gi\u00e0 su Azure AD e Power BI Premium.<\/p>\n

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\u00f9 adatto a contesti enterprise.<\/p>\n

\"Server<\/p>\n

Data Lake: storage cheap e flessibilit\u00e0 estrema<\/h2>\n

Un Data Lake nasce come “scrivi tutto, capisci dopo”. Il foundation layer \u00e8 quasi sempre object storage cloud: Amazon S3<\/strong>, Azure Data Lake Storage Gen2<\/strong>, Google Cloud Storage<\/strong>. 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.<\/p>\n

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

L’ingestion usa due pattern: batch<\/strong> (CSV\/JSON\/parquet via Airflow o Fivetran con destination S3) e stream<\/strong> (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).<\/p>\n

Vantaggio: flessibilit\u00e0 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’\u00e8 dentro.<\/p>\n

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

Lakehouse: la sintesi che convince Databricks (e non solo)<\/h2>\n

Il Lakehouse risolve la governance del Lake aggiungendo un layer transazionale ai parquet. Le tre implementazioni principali nel 2022:<\/p>\n

Delta Lake<\/strong> (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\u00e0). Usabile su S3, ADLS, GCS senza lock-in di compute.<\/p>\n

Apache Iceberg<\/strong> (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”.<\/p>\n

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

Sopra al table format si appoggia il compute. Databricks Lakehouse Platform<\/strong> \u00e8 il prodotto pi\u00f9 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.<\/p>\n

L’architettura interna segue il pattern medallion<\/strong> (bronze\/silver\/gold) proposto da Databricks:<\/p>\n

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

    Pricing reale: cosa pagate davvero a 1 TB di dati<\/h2>\n

    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.<\/p>\n

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

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

    Redshift RA3<\/strong>: si parte da ra3.xlplus ~$1,086\/h, ~780\u20ac\/mese 24\/7 pi\u00f9 storage RMS a $24\/TB\/mese. Pause\/resume aiuta ma meno fluido di Snowflake.<\/p>\n

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

    Regola pratica: per una PMI sotto i 5 TB di dati attivi il costo piattaforma non \u00e8 il problema<\/strong>. Il problema vero sono i tool intorno e il personale per integrarli.<\/p>\n

    Ingestion moderna: Fivetran, Airbyte e l’era dell’ELT<\/h2>\n

    Nessuna PMI nel 2022 dovrebbe scrivere connettori ETL custom per Salesforce, HubSpot, Shopify, Stripe o Google Ads. Il mercato managed \u00e8 maturo:<\/p>\n

    Fivetran<\/strong> (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\u20ac\/mese. Setup in minuti, manutenzione zero. Padre del modello “ELT moderno”: estrai raw nel DWH, trasforma poi con SQL.<\/p>\n

    Airbyte<\/strong> (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\u00e0 variabile. Ottimo per chi ha team in grado di gestire l’infrastruttura.<\/p>\n

    Stitch<\/strong> (Talend dal 2018): connettori pi\u00f9 limitati, pricing fisso a tier, ok per use case semplici. Orchestrazione: Airflow<\/strong>, Prefect<\/strong>, Dagster<\/strong> (la terza \u00e8 la pi\u00f9 giovane ma in rapida crescita con un modello asset-based).<\/p>\n

    I dati raw nel DWH\/Lakehouse si trasformano con dbt<\/strong>: SQL + Jinja + test + documentazione. dbt \u00e8 la tecnologia pi\u00f9 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.<\/p>\n

    \"Team<\/p>\n

    Sei segnali che vi basta un Data Warehouse<\/h2>\n

    Nella maggior parte degli assessment che facciamo per PMI italiane, il Data Warehouse cloud \u00e8 la risposta giusta. Ecco i segnali concreti:<\/p>\n

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

      Sei segnali che vale la pena valutare un Lakehouse<\/h2>\n

      Il Lakehouse ha senso quando uno o pi\u00f9 di questi fattori entrano in gioco:<\/p>\n

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

        Modern data stack pattern per PMI italiane<\/h2>\n

        Stack tipico consigliato a PMI italiana 50-150 dipendenti nel 2022:<\/p>\n