Data Warehouse & Centralized Storage
Dai ai tuoi dati un posto dove vivere: centralizzato, strutturato, pronto per l’analisi, senza rallentare i sistemi che fanno girare il business.
Il problema in breve
In quasi tutte le PMI italiane, i dati storici vivono dove non dovrebbero: dentro il gestionale. Anni di ordini, fatture, movimenti di magazzino e dati di produzione sono accumulati nello stesso database che gestisce le operazioni quotidiane. Il risultato è un sistema che rallenta progressivamente, le query di reportistica competono con quelle operative, e un’incapacità strutturale di fare analisi storiche (trend, stagionalità, confronti anno su anno). I dati più vecchi vengono cancellati o archiviati su file server e hard disk esterni per alleggerire il gestionale, diventando di fatto inaccessibili. Le normative impongono la conservazione delle fatture per dieci anni, ma conservare non significa poter utilizzare: dati archiviati su USB drive o cartelle di rete non sono interrogabili, non sono strutturati e non alimentano nessuna decisione.
La sfida
Il debito architetturale delle PMI italiane in ambito dati ha una radice precisa: l’assenza di separazione tra il sistema operazionale (OLTP, Online Transaction Processing) e il sistema analitico (OLAP, Online Analytical Processing). Il gestionale è progettato per scrivere e leggere singole transazioni con bassa latenza, inserire un ordine, aggiornare una giacenza, registrare un movimento contabile. Le query analitiche, aggregazioni su milioni di righe, join tra tabelle di grandi dimensioni, scansioni sequenziali su anni di dati, hanno requisiti diametralmente opposti: richiedono letture massive, compressione colonnare e parallelismo nel calcolo. Eseguire entrambi i carichi sullo stesso database è un compromesso che penalizza entrambi.
Le conseguenze sono concrete. Il gestionale rallenta durante le chiusure mensili, quando il controller esegue query di reportistica su dataset di dimensioni crescenti. Le query analitiche complesse vengono evitate perché “bloccano il sistema”. I report vengono estratti una volta e salvati in Excel, diventando immediatamente obsoleti. I dati storici vengono periodicamente eliminati dal gestionale per recuperare prestazioni, distruggendo la possibilità di analisi di trend a lungo termine. Le normative di conservazione (10 anni per la fatturazione elettronica, 5 anni per i dati contabili, requisiti GDPR sulla retention) vengono soddisfatte formalmente, i file esistono da qualche parte, ma non sostanzialmente: i dati non sono strutturati, non sono interrogabili, e in caso di audit la loro reperibilità è incerta.
Sul piano tecnico, la progettazione di un data warehouse per PMI presenta sfide specifiche di proporzionalità. Le soluzioni enterprise (Snowflake, BigQuery, Redshift) sono mature e potenti, ma il modello di costo, basato su compute consumato e dati scansionati, può generare costi inattesi per team senza esperienza di ottimizzazione. Un approccio naive (nessun partitioning, nessuna clusterizzazione, query full-scan su tabelle non ottimizzate) su un warehouse cloud può costare 5-10 volte più del necessario. Dall’altro lato, DuckDB, un motore analitico embeddabile a costo zero, ha raggiunto la maturità per workload fino a decine di gigabyte, coprendo la maggior parte dei casi d’uso delle PMI senza infrastruttura cloud. La scelta dell’architettura giusta dipende dal volume dei dati, dalla frequenza di query, dal numero di utenti concorrenti e dalla roadmap analitica dell’azienda.
La soluzione
Data Architecture Assessment
L’approccio parte da un data architecture assessment: analisi dei volumi di dati attuali e proiettati (a 3-5 anni), mappatura dei carichi di lavoro analitici (reportistica periodica, analytics ad hoc, dashboarding real-time, machine learning), valutazione del numero di utenti concorrenti, e definizione dei requisiti di latenza e freshness per ciascun caso d’uso. Questa fase determina la scelta architetturale: un warehouse cloud managed (BigQuery, Snowflake) per scenari con multi-utenza, query concorrenti e volumi in crescita rapida; PostgreSQL con estensioni analitiche (pg_duckdb, Citus) per scenari con volumi moderati e team tecnico esistente; DuckDB/MotherDuck per scenari con volumi fino a decine di GB e costi minimi.
Modellazione Dimensionale
La modellazione dimensionale segue la metodologia Kimball: identificazione dei processi di business da analizzare (vendite, produzione, acquisti, logistica), definizione del grain (il livello di dettaglio più granulare, la riga d’ordine, la singola lavorazione, il singolo movimento di magazzino), progettazione delle tabelle dei fatti (transazioni misurabili) e delle dimensioni (contesto, cliente, prodotto, tempo, stabilimento, canale di vendita). Lo star schema risultante ottimizza le query analitiche: join semplici tra fatti e dimensioni, aggregazioni performanti, e una struttura intuitiva che gli utenti business possono comprendere. Ogni dimensione include surrogate key per isolare il warehouse dai cambiamenti nei sistemi sorgente e Slowly Changing Dimensions (SCD Type 2) per tracciare l’evoluzione storica degli attributi (un cliente che cambia categoria, un prodotto che cambia prezzo di listino).
Strategie di Partitioning
Le strategie di partitioning allineano l’organizzazione fisica dei dati con i pattern di query effettivi. Il partitioning per data (mese, trimestre) sulle tabelle dei fatti consente al query engine di scansionare solo le partizioni rilevanti, una query sul Q1 2025 non tocca i dati del 2023, riducendo sia i tempi di esecuzione sia i costi (nei warehouse cloud, le partizioni escluse non vengono fatturate). La clusterizzazione aggiunge un secondo livello di ottimizzazione ordinando fisicamente i dati all’interno di ogni partizione per le colonne filtrate più frequentemente (codice cliente, codice prodotto, tipo di documento).
Ottimizzazione dei Costi
L’ottimizzazione dei costi è parte integrante del design. Le strategie includono: compressione colonnare nativa (riduzione 5-10x dello storage rispetto a formati row-based), tiering dello storage (dati recenti su storage veloce, dati storici su storage economico), scheduling dei workload di trasformazione (esecuzione notturna su slot a costo ridotto), e monitoring continuo dei costi per query per identificare e ottimizzare le query più costose prima che il conto diventi un problema. Per scenari ibridi, l’adozione di formati open table (Apache Iceberg) consente di scrivere i dati una volta su object storage (S3, GCS) e leggerli da qualsiasi engine compatibile, eliminando il vendor lock-in e rendendo possibili migrazioni future senza riscritture.
Pipeline ELT & Single Point of Truth
L’alimentazione del warehouse avviene tramite pipeline ELT (descritte nel dettaglio nella pagina dedicata alla Data Integration): i dati vengono estratti dai sistemi sorgente nella loro forma grezza, caricati nel warehouse, e trasformati con dbt in modelli analitici strutturati, testati e documentati. Il warehouse diventa il single point of truth, la fonte autoritativa per ogni numero, eliminando la proliferazione di fogli Excel e report discordanti.
Tecnologie chiave
Data Warehouse & Lakehouse
Architetture di storage analitico (Snowflake, BigQuery, DuckDB, PostgreSQL) con separazione compute/storage e supporto per formati open table.
ApprofondisciDimensional Modeling
Progettazione dello schema analitico (star schema, SCD, grain definition) secondo la metodologia Kimball per query performanti e struttura intuitiva.
Approfondiscidbt (Data Build Tool)
Trasformazione dei dati nel warehouse con version control, test automatici e documentazione integrata come standard di data engineering.
ApprofondisciOpen Table Formats (Apache Iceberg)
Formato di tabella aperto per storage su object storage con time travel, schema evolution e interoperabilità multi-engine.
ApprofondisciData Partitioning & Query Optimization
Strategie di organizzazione fisica dei dati (partitioning, clustering, materialized views) per ottimizzare performance e costi.
ApprofondisciRisultati e benefici
Separazione completa tra workload operativi e analitici: il gestionale non rallenta più durante la reportistica, e le query analitiche non sono più limitate dalle performance del database operazionale
-70-90% dei tempi di esecuzione delle query analitiche rispetto all’esecuzione diretta sul database operazionale, grazie alla compressione colonnare e al partitioning
Conservazione storica completa e interrogabile: tutti i dati transazionali degli ultimi 5-10 anni disponibili per analisi di trend, stagionalità e confronto anno su anno
Costo di storage ridotto del 60-80% rispetto al mantenimento dei dati nel database operazionale, grazie alla compressione colonnare (5-10x) e al tiering automatico
Single point of truth: ogni report, ogni dashboard, ogni modello ML attinge dalla stessa fonte, eliminando le discrepanze tra reparti
Conformità normativa sulla retention: dati conservati in formato strutturato, interrogabile e auditabile per la durata richiesta dalla legge
Fondamenta per tutte le iniziative data: il warehouse è il prerequisito tecnico per dashboard, self-service analytics, machine learning e qualsiasi altra applicazione data-driven
Use case
Manifatturiero: warehouse per analisi di produzione e qualità storica
Un’azienda di componenti meccanici (fatturato €40M, 100 dipendenti) accumula nel gestionale SAP Business One 8 anni di dati: 12 milioni di righe di ordini, 45 milioni di movimenti di magazzino, e 3 milioni di record di controllo qualità. Le query di reportistica mensile richiedono 15-30 minuti e rallentano visibilmente il gestionale. I dati anteriori al 2020 sono stati archiviati su un NAS e non sono più consultabili. Il warehouse progettato su BigQuery adotta uno star schema con fatti (ordini, lavorazioni, movimenti magazzino, controlli qualità) e dimensioni (cliente, prodotto, stabilimento, tempo, commessa). I dati storici dal NAS vengono migrati e integrati. Il partitioning per mese e la clusterizzazione per codice prodotto riducono i costi di query del 85%. Le query analitiche che richiedevano 20 minuti sul gestionale vengono eseguite in 3-5 secondi. Il costo cloud mensile è di €120-180 (pay-per-query BigQuery), inferiore al costo della manutenzione del NAS. Il controller produce il report mensile in 2 ore anziché 3 giorni, e per la prima volta può analizzare trend di qualità su 8 anni di dati per identificare correlazioni tra parametri di processo e difettosità.
Distribuzione: storico vendite per analisi stagionale e forecasting
Un distributore di prodotti alimentari (fatturato €55M, 80 dipendenti, 1.800 referenze attive) non ha capacità di analisi stagionale perché i dati storici nel gestionale vengono eliminati dopo 3 anni per motivi di performance. Le previsioni di vendita sono basate sull’esperienza del direttore commerciale, non su dati. Il warehouse su PostgreSQL con pg_duckdb centralizza 7 anni di transazioni (ordini, consegne, resi, crediti) con dimensioni cliente (canale, zona, fascia di fatturato), prodotto (categoria, fornitore, marca, stagionalità), e tempo (giorno, settimana, mese, stagione, festività). Lo schema dimensionale è alimentato da una pipeline dbt con run giornaliera che estrae i delta dal gestionale via CDC. Per la prima volta, il team commerciale può visualizzare la stagionalità per prodotto su 7 anni, confrontare le performance anno su anno per zona, e identificare i clienti con trend di acquisto in calo. Il costo infrastrutturale è quasi zero (PostgreSQL self-hosted su un server esistente, pg_duckdb come extension). Il warehouse diventa la base per un modello di demand forecasting (fase successiva) che riduce lo stock-out del 25% e le eccedenze del 18%.
E-commerce: data warehouse per marketing attribution e unit economics
Un e-commerce di arredamento (fatturato €14M, 22 dipendenti) spende €1,2M/anno in advertising digitale (Google Ads, Meta, TikTok) senza sapere quale canale produce il miglior ROI netto, perché i dati di advertising, transazioni, resi, costi di spedizione e costi di prodotto risiedono in sistemi diversi e non vengono mai riconciliati. Il warehouse su Snowflake (small warehouse, ~€200/mese) centralizza: dati di advertising (via connettori Airbyte da Google/Meta/TikTok), transazioni Shopify, dati di spedizione, costi di prodotto dal gestionale, e resi. Il modello dimensionale calcola la unit economics completa per ogni ordine: ricavo netto, COGS, costo di spedizione, commissioni marketplace, costo di reso, costo di advertising attribuito. L’aggregazione per canale, campagna, categoria di prodotto e periodo rivela che TikTok genera il CAC più basso ma il tasso di reso più alto (unit economics negativa su alcune categorie), mentre Google Shopping ha il CAC più alto ma il miglior margine netto. La riallocazione del budget basata sulla unit economics reale produce un aumento del margine netto del 15% a parità di spesa advertising nei primi 6 mesi.
Il tuo gestionale rallenta sotto il peso dei dati storici e i tuoi report partono da Excel?
Richiedi un data architecture assessment: analizziamo i volumi, i carichi di lavoro e gli obiettivi analitici per progettare un data warehouse su misura: dalla scelta della piattaforma alla modellazione dimensionale, con costi proporzionati alla scala del tuo business.