Tipologie di Data Warehouse: la guida completa ad architetture e casi d'uso

Un data warehouse è un repository centralizzato che raccoglie, organizza e memorizza dati strutturati provenienti da tutta l'organizzazione, consentendo ad analisti e data scientist di eseguire query complesse, generare report e supportare i carichi di lavoro di business intelligence (BI). A differenza dei database operativi progettati per l'elaborazione delle transazioni, un data warehouse è creato per i carichi di lavoro analitici: unisce dati provenienti da più fonti, conserva i dati storici nel corso degli anni e fornisce la base controllata e governata richiesta dal processo decisionale strategico.

Comprendere i diversi tipi di data warehouse è essenziale prima di impegnarsi in qualsiasi piattaforma o migrazione. Ciascun tipo riflette un preciso compromesso architetturale tra scalabilità, latenza, costi e ambito tematico. Questa guida copre tutti i principali tipi di data warehouse, dai tradizionali Enterprise Data Warehouse alle moderne architetture lakehouse, e fornisce indicazioni chiare su quando ciascuno rappresenta la scelta giusta.

I tre tipi principali di data warehouse

Il settore riconosce tre tipi principali di data warehouse che costituiscono la base della moderna architettura dei dati: l'Enterprise Data Warehouse (EDW), il Data Mart e l'Operational Data Store (ODS). Oltre a questi, le organizzazioni implementano anche data warehouse basati sul cloud, data warehouse virtuali, data warehouse ibridi e piattaforme lakehouse a seconda dei requisiti del carico di lavoro, del volume dei dati e della complessità della governance.

Ogni tipo si differenzia per il modo in cui memorizza i dati, per chi ne è il proprietario, per la latenza che supporta e per le query analitiche che gestisce al meglio. La scelta giusta dipende dalle fonti di dati, dalla struttura del team, dai requisiti di qualità dei dati e dai casi d'uso analitici da supportare.

Enterprise Data Warehouse (EDW)

Un enterprise data warehouse (EDW) è il tipo di data warehouse più completo, progettato per fungere da unica fonte di verità autorevole per un'intera organizzazione. Un EDW integra i dati di tutte le principali business unit (vendite, finanza, operazioni, risorse umane, sistemi di customer relationship management (CRM) e sistemi di gestione dell'inventario) in un unico data warehouse centralizzato, regolato da standard di qualità dei dati e controlli di accesso coerenti.

Architettura e ambito

La caratteristica distintiva di un enterprise data warehouse è il suo ambito interorganizzativo. I dati provenienti da più fonti passano attraverso processi di Extract, Transform, Load (ETL) prima di arrivare nel warehouse, dove regole di business, pulizia dei dati e validazione garantiscono la coerenza tra i vari team. Il risultato è un repository governato in cui ogni analista interroga la stessa versione dei dati aziendali, indipendentemente dal reparto di appartenenza.

Gli EDW implementano in genere un'architettura a tre livelli. Il livello inferiore gestisce le fonti di dati e i processi ETL che acquisiscono e trasformano i dati grezzi dai sistemi operativi. Il livello intermedio ospita un server OLAP che rende i dati accessibili per l'analisi multidimensionale. Il livello superiore fornisce strumenti front-end (dashboard e applicazioni BI) in cui gli utenti aziendali analizzano i dati. Questo design a livelli separa la complessità dell'acquisizione dalle prestazioni analitiche, consentendo di ottimizzare ciascun livello in modo indipendente.

Quando scegliere un EDW

Un EDW è la base ideale quando l'organizzazione ha bisogno di analisi a livello aziendale, reportistica di conformità normativa o di un'unica fonte di verità tra business unit che attualmente operano in silos di dati. Le organizzazioni con requisiti complessi di governance dei dati, come le società di servizi finanziari che gestiscono la reportistica normativa, le organizzazioni sanitarie che gestiscono i dati dei pazienti o i grandi produttori che integrano i dati della supply chain e della produzione, traggono il massimo vantaggio dalla governance centralizzata offerta da un EDW.

La sfida principale dei data warehouse tradizionali è la scalabilità. Con la crescita del volume dei dati, i formati di tabella proprietari e le configurazioni hardware fisse rendono costosa la scalabilità delle distribuzioni EDW on-premise. Molte organizzazioni che si trovano ad affrontare questo vincolo stanno migrando verso architetture basate sul cloud o lakehouse, che mantengono il modello di governance di un EDW eliminando al contempo i limiti dell'infrastruttura.

Data Mart

Un data mart è un sottoinsieme specifico per argomento di un data warehouse, limitato a un singolo reparto, funzione aziendale o dominio analitico. Mentre un EDW serve l'intera organizzazione, un data mart si rivolge a un pubblico mirato: il team di marketing, il reparto finanziario o una divisione vendite regionale. I data mart memorizzano i dati in formati ottimizzati per query e report specifici eseguiti da un determinato team, in genere utilizzando schemi a stella o a fiocco di neve denormalizzati che riducono al minimo la complessità dei join.

Data Mart dipendenti e indipendenti

I data mart si dividono in due modelli architetturali. Un data mart dipendente estrae i dati da un EDW esistente, ereditando gli standard di governance e qualità dei dati del repository centrale. Questo è l'approccio consigliato quando esiste già un EDW, perché evita definizioni metriche contrastanti tra i vari reparti.

Un data mart indipendente acquisisce i dati direttamente dai sistemi di origine senza passare attraverso un EDW. I mart indipendenti sono più rapidi da creare ma comportano dei rischi: ogni mart può applicare regole di business diverse, portando a una reportistica incoerente tra le business unit, proprio il tipo di silos di dati che l'architettura del data warehouse mira a eliminare.

Quando creare un Data Mart

Crea un data mart quando un team specifico ha requisiti analitici che non giustificano l'attesa di un'implementazione completa dell'EDW, quando le prestazioni delle query su un sottoinsieme di dati richiedono un'ottimizzazione indipendente o quando la proprietà dei dati da parte del reparto è un requisito di governance. I data mart funzionano particolarmente bene per l'analisi dei dati di vendita, l'attribuzione di marketing e la reportistica finanziaria, casi d'uso in cui il dominio dei dati è ben definito e il pubblico è concentrato.

Operational Data Store (ODS)

Un Operational Data Store (ODS) è un tipo di data warehouse progettato per la reportistica quasi in tempo reale e il processo decisionale operativo, posizionato tra i database transazionali e l'EDW analitico. Mentre un EDW memorizza dati storici accumulati nel corso degli anni, un ODS conserva dati operativi correnti e recenti, in genere aggiornati a intervalli che vanno da pochi minuti a ore, ottimizzati per query che riflettono lo stato attuale dell'azienda piuttosto che le tendenze a lungo termine.

Il ruolo dell'ODS nell'architettura dei dati

I sistemi operativi come le piattaforme CRM, i sistemi di gestione dell'inventario e le piattaforme di elaborazione degli ordini generano continuamente dati transazionali, ma non sono progettati per query analitiche. L'esecuzione di report complessi su un database transazionale di produzione rallenta le operazioni che supporta. L'ODS risolve questo problema replicando i dati operativi in un ambiente separato in cui gli analisti possono interrogarli senza influire sui sistemi di origine.

Un ODS integra i dati provenienti da più fonti operative, applica una leggera trasformazione per standardizzare i formati e rende disponibili i dati operativi integrati per la reportistica. Non sostituisce l'EDW: l'analisi dei trend storici e le query di pianificazione strategica appartengono ancora al data warehouse. L'ODS gestisce questioni operative sensibili al fattore tempo: livelli di inventario correnti, prestazioni di vendita in giornata, casi di assistenza clienti attivi.

Data Warehouse virtuale

Un data warehouse virtuale, talvolta chiamato data warehouse federato, non consolida fisicamente i dati in un'unica posizione di storage. Crea invece un livello di astrazione logica che interroga i dati direttamente nei vari sistemi di origine, presentando tali sistemi disparati come un ambiente analitico unificato.

I data warehouse virtuali si affidano alla tecnologia di federazione delle query per inviare le query ai sistemi di origine e aggregare i risultati a livello di presentazione. Questo approccio elimina i costi di storage e di infrastruttura ETL del consolidamento fisico e offre un time-to-value più rapido quando si analizzano dati già esistenti nei database operativi senza doverli spostare. La limitazione principale riguarda le prestazioni delle query: le query complesse che richiedono l'unione di grandi dataset su più sistemi introducono una latenza significativa, poiché ogni query deve recuperare dati da sistemi non progettati per carichi di lavoro analitici.

I data warehouse virtuali funzionano meglio per l'analisi esplorativa, la reportistica su piccola scala o in situazioni in cui i vincoli normativi impediscono lo spostamento dei dati. Raramente rappresentano l'architettura giusta per query analitiche ad alto volume o carichi di lavoro di AI che richiedono l'elaborazione di dati su larga scala.

Data Warehouse basati sul cloud

I data warehouse basati sul cloud sono ospitati su piattaforme cloud (AWS, Microsoft Azure, Google Cloud e altre) e offrono funzionalità di data warehouse come servizi completamente gestiti. Le organizzazioni che utilizzano data warehouse basati sul cloud non devono predisporre o mantenere l'hardware fisico; il cloud provider gestisce l'infrastruttura, mentre l'organizzazione si concentra sull'acquisizione, la modellazione e l'analisi dei dati.

Vantaggi della distribuzione nel cloud

Il vantaggio più significativo dei data warehouse basati sul cloud è la scalabilità elastica. I tradizionali data warehouse on-premise richiedono alle organizzazioni di dimensionare l'hardware per il carico di picco, con un conseguente sovradimensionamento durante le normali operazioni. I data warehouse nel cloud scalano automaticamente le risorse di calcolo e di storage in base alla domanda con un modello pay-as-you-go, in modo che le organizzazioni paghino solo per ciò che utilizzano. La distribuzione nel cloud accelera anche il time-to-value: mentre le distribuzioni on-premise possono richiedere mesi dall'approvvigionamento alla produzione, un data warehouse nel cloud può essere predisposto e caricare dati nel giro di poche ore.

Costi di egress e preparazione alla migrazione

I data warehouse basati sul cloud introducono compromessi che le organizzazioni devono valutare. I costi di egress dei dati — ovvero le tariffe per il trasferimento dei dati al di fuori della rete di un cloud provider — possono diventare significativi su larga scala. Le organizzazioni che operano su più cloud provider affrontano una maggiore complessità nella gestione dell'integrazione dei dati, delle policy di sicurezza e dei framework di governance tra diverse piattaforme.

Prima di migrare a un cloud data warehouse, valuta il volume di dati che uscirà dalla piattaforma, prendi in considerazione formati di dati aperti che riducono il vendor lock-in e verifica che le funzionalità di governance e sicurezza della piattaforma di destinazione soddisfino i tuoi requisiti di conformità.

Data warehouse ibridi e moderni

Un data warehouse ibrido combina funzionalità di archiviazione dei dati on-premises e cloud, consentendo alle organizzazioni di conservare i dati sensibili o regolamentati nei propri data center, sfruttando al contempo la scalabilità del cloud per l'elaborazione analitica con domanda variabile.

Caratteristiche di un data warehouse moderno

Un data warehouse moderno estende il modello di warehouse tradizionale in diversi modi significativi. Supporta non solo dati strutturati in schemi predefiniti, ma anche dati semistrutturati e non strutturati. Separa l'elaborazione (compute) dall'archiviazione (storage), consentendo a ciascuna componente di scalare in modo indipendente e riducendo i costi di elaborazione dei dati su larga scala. Si integra con pipeline di dati in streaming per ridurre la latenza, supporta formati di dati aperti per evitare il vendor lock-in e fornisce integrazioni native per carichi di lavoro di machine learning e AI, oltre alla BI e alla reportistica tradizionali.

I moderni data warehouse integrano anche solide funzionalità di data lineage, tracciando i dati dai sistemi di origine attraverso ogni fase di trasformazione fino al punto di consumo finale. Questo lineage è essenziale per la data governance e la garanzia della qualità dei dati: quando un analista mette in dubbio un numero in un report, la documentazione del lineage consente al team dei dati di tracciare esattamente come è stato calcolato quel numero.

Architettura Data Lake e Lakehouse

Un data lake archivia i dati grezzi nel loro formato originale senza schemi predefiniti, accettando dati strutturati, semistrutturati e non strutturati da qualsiasi sorgente. A differenza di un data warehouse, che richiede che i dati passino attraverso processi ETL e si conformino a uno schema definito prima di poter essere archiviati e interrogati, un data lake applica lo schema in lettura (schema-on-read) — lo schema viene applicato al momento della query, non dell'ingestione. Questa flessibilità rende i data lake ideali per archiviare grandi volumi di dati grezzi per il machine learning e l'esplorazione di data science.

Il compromesso è l'affidabilità. Senza l'applicazione della qualità dei dati fornita dai processi ETL, i data lake possono accumulare dati incoerenti, duplicati o scarsamente documentati di cui gli analisti non possono fidarsi per una reportistica BI controllata.

Il Lakehouse come soluzione unificata

Un data lakehouse unisce la flessibilità e l'efficienza dei costi di un data lake con le funzionalità di gestione dei dati di un data warehouse. Un lakehouse archivia i dati in formati aperti su object storage cloud, quindi aggiunge un livello di metadati transazionali e governance che impone transazioni ACID, evoluzione dello schema, vincoli di qualità dei dati e time travel — ovvero la capacità di interrogare i dati così come esistevano in qualsiasi momento storico.

Il risultato è un'unica piattaforma in cui i data engineer eseguono pipeline ETL, i data analyst eseguono query SQL su tabelle controllate e i data scientist accedono a dati grezzi e con feature engineering per l'addestramento dei modelli — il tutto senza spostare i dati tra i sistemi. La medallion architecture, comune nelle implementazioni lakehouse, organizza i dati in livelli bronze (grezzi), silver (validati e integrati) e gold (curati e pronti per il consumo), migliorando progressivamente la qualità dei dati in ogni fase. Il livello gold si mappa direttamente sui data mart e sui livelli di serving EDW già utilizzati dai warehouse tradizionali, rendendo la transizione familiare dal punto di vista dell'architettura.

Architettura e archiviazione del data warehouse

Indipendentemente dal modello di implementazione, l'architettura del data warehouse riflette lo stesso principio fondamentale: i dati devono essere separati dalle applicazioni che li generano, puliti e integrati attraverso un processo controllato, e archiviati in formati ottimizzati per le query analitiche piuttosto che per le scritture transazionali.

Archiviazione e progettazione dello schema

I moderni data warehouse separano l'elaborazione (compute) dall'archiviazione (storage), consentendo a ciascuna dimensione di scalare in modo indipendente. I sistemi di archiviazione conservano i dati in formati colonnari che riducono al minimo i dati scansionati durante le query analitiche — una query che interessa solo tre colonne su cinquanta legge solo i dati relativi a quelle tre colonne, anziché scansionare ogni riga nella sua interezza.

La progettazione dello schema influisce in modo significativo sulle prestazioni delle query. Lo schema a stella organizza i dati attorno a una tabella dei fatti centrale — contenente eventi misurabili come transazioni di vendita o sessioni web — circondata da tabelle delle dimensioni che descrivono le entità coinvolte (clienti, prodotti, periodi di tempo). I join in uno schema a stella sono semplici e veloci. Lo schema a fiocco di neve normalizza ulteriormente le tabelle delle dimensioni, riducendo la ridondanza di archiviazione a scapito di una maggiore complessità dei join. Uno schema a galassia condivide le tabelle delle dimensioni su più tabelle dei fatti, supportando query analitiche che spaziano su diversi processi aziendali.

Gli schemi a stella sono la scelta più comune per i data mart e per il livello gold di un lakehouse perché danno priorità alle prestazioni di lettura. Lo schema corretto dipende dal volume dei dati, dai pattern di aggiornamento e dalla complessità delle query analitiche che lo schema deve supportare.

Tipi di dati in un data warehouse

Storicamente, i data warehouse hanno archiviato dati strutturati — righe e colonne con tipi di dati e schemi predefiniti, provenienti da database relazionali, piattaforme CRM, sistemi finanziari e sistemi di gestione dell'inventario. I dati strutturati sono facili da interrogare con SQL standard e si integrano perfettamente nelle pipeline ETL.

Dati strutturati, semistrutturati e non strutturati

I dati semistrutturati non si conformano a un rigido schema relazionale ma contengono marcatori organizzativi che li rendono analizzabili — documenti JSON, file XML, record di log e dati di clickstream rientrano tutti in questa categoria. Molte moderne piattaforme di data warehouse supportano tipi di dati semistrutturati nativi, consentendo alle query SQL di navigare in strutture nidificate senza dover prima appiattire i dati.

I dati non strutturati — immagini, video, documenti di testo libero, registrazioni audio — non possono essere interrogati direttamente con SQL, ma sono sempre più importanti man mano che le organizzazioni sviluppano funzionalità di AI e machine learning. Le architetture lakehouse sfumano questo confine, consentendo di archiviare e gestire i dati non strutturati insieme a quelli strutturati all'interno della stessa piattaforma.

La scelta tra lo schema in scrittura (schema-on-write, che impone la struttura al momento dell'ingestione, come fanno i data warehouse tradizionali) e lo schema in lettura (schema-on-read, che rimanda la struttura al momento della query, come fanno i data lake) riflette un compromesso fondamentale tra la coerenza della qualità dei dati e la flessibilità dell'ingestione. La maggior parte delle piattaforme dati mature utilizza lo schema-on-write per le tabelle analitiche controllate e lo schema-on-read per le zone di dati esplorativi e grezzi.

Sorgenti di dati esterne e integrazione

Raramente i data warehouse attingono da un'unica sorgente. Le tipiche implementazioni aziendali integrano dati provenienti da database operativi, sistemi CRM, piattaforme ERP, strumenti di marketing automation, registri finanziari, fornitori di dati di terze parti e API esterne. Gestire la diversità di queste sorgenti di dati esterne — ciascuna con il proprio schema, frequenza di aggiornamento e caratteristiche di qualità dei dati — è una delle sfide principali dell'architettura del data warehouse.

Prima che i dati esterni entrino nel warehouse, dovrebbero essere convalidati rispetto agli schemi previsti e alle regole di qualità dei dati. La convalida rileva tempestivamente i problemi comuni: campi obbligatori mancanti, valori al di fuori degli intervalli previsti e violazioni dell'integrità referenziale. Rilevare questi problemi al momento dell'ingestione è molto meno costoso che scoprirli dopo che i dati si sono propagati in report e dashboard. L'arricchimento dei dati (data enrichment) — che integra i dati inseriti con il contesto proveniente da tabelle di riferimento o dataset esterni — trasforma i dati di origine grezzi nei dataset pronti per il business di cui gli analisti hanno bisogno.

ETL vs ELT e monitoraggio delle pipeline

Il processo di integrazione dei dati determina il modo in cui i dati si spostano dai sistemi di origine al warehouse e come vengono trasformati. L'ETL (Extract, Transform, Load) è l'approccio tradizionale: i dati vengono estratti dalle sorgenti, trasformati in un ambiente di elaborazione separato e caricati nella loro forma strutturata finale. L'ELT (Extract, Load, Transform) inverte l'ordine: i dati grezzi vengono caricati per primi, quindi trasformati all'interno del warehouse utilizzando la sua stessa potenza di calcolo. I moderni cloud data warehouse spesso preferiscono l'ELT perché la fase di trasformazione può sfruttare le capacità di elaborazione parallela del warehouse a un costo complessivo inferiore. Per un approfondimento sulle implicazioni architetturali, il confronto tra ELT ed ETL analizza i principali compromessi.

Il monitoraggio delle pipeline di dati garantisce che i processi di ingestione vengano completati nei tempi previsti, che i volumi di dati corrispondano alle aspettative e che i controlli di qualità vengano superati prima che i dati vengano promossi in produzione. Le pipeline che falliscono silenziosamente — completando il processo senza errori ma producendo risultati errati — rappresentano una delle modalità di guasto più pericolose nelle operazioni di data warehouse.

Sicurezza e governance dei dati

La governance e la sicurezza dei dati sono requisiti fondamentali per qualsiasi data warehouse, in particolare per le organizzazioni che gestiscono dati sensibili soggetti a conformità normativa. Un warehouse che non può dimostrare chi ha effettuato l'accesso a quali dati, quando e per quale scopo non può soddisfare i revisori o mantenere la fiducia dei clienti di cui conserva i dati.

Controllo degli accessi, crittografia e audit logging

Una sicurezza dei dati efficace inizia con il controllo dell'accesso basato sui ruoli (RBAC), che assegna le autorizzazioni di accesso ai dati ai ruoli anziché ai singoli individui, rendendo la gestione degli accessi scalabile all'interno delle grandi organizzazioni. I controlli di accesso dovrebbero operare a più livelli: a livello di catalogo, di tabella, di colonna (fondamentale per mascherare le informazioni personali identificabili) e di riga (in base all'affiliazione organizzativa o alla proprietà dei dati).

I dati devono essere crittografati sia a riposo (at rest) che in transito. La crittografia a riposo protegge dall'accesso non autorizzato ai supporti di memorizzazione; la crittografia in transito protegge dall'intercettazione attraverso le reti. L'audit logging registra ogni evento di accesso e modifica — chi ha interrogato una tabella, quando e quali dati sono stati restituiti — supportando le indagini di sicurezza e la dimostrazione della conformità normativa. Il tracciamento della lineage dei dati, che segue i dati dalla sorgente attraverso ogni trasformazione fino al punto di consumo, supporta sia la governance sia la garanzia della qualità dei dati.

Casi d'uso della data analytics per tipo di data warehouse

Diversi tipi di data warehouse si associano a diversi carichi di lavoro analitici; comprendere questa associazione aiuta le organizzazioni a evitare di distribuire un'architettura ottimizzata per un solo tipo di carico di lavoro aspettandosi che funzioni per tutti i casi d'uso.

Abbinare l'architettura al carico di lavoro

Gli enterprise data warehouse supportano l'analisi strategica — analisi dei trend anno su anno, reportistica interfunzionale, dashboard per l'executive management e reportistica di conformità che richiede l'unione di dati provenienti da più domini aziendali. I data mart supportano l'analisi dipartimentale — prestazioni di vendita, attribuzione di marketing, report di chiusura finanziaria e segmentazione dei clienti — dove l'ambito limitato dei dati rende il self-service più rapido. Gli operational data store supportano l'analisi operativa — monitorando le condizioni aziendali correnti e rispondendo agli eventi in tempo reale nei settori della vendita al dettaglio, della logistica e dei servizi finanziari.

Le architetture cloud e lakehouse supportano l'analisi avanzata e l'AI — l'addestramento di modelli di machine learning su larga scala, pipeline di elaborazione del linguaggio naturale e sistemi di raccomandazione. Questi carichi di lavoro richiedono non solo dati strutturati e governati, ma anche i dati grezzi e semistrutturati che solo un'architettura di archiviazione più flessibile può ospitare.

BI, reportistica e analisi avanzata

Gli strumenti di BI si connettono ai data warehouse per creare dashboard e report accessibili agli utenti aziendali che non scrivono codice SQL. L'integrazione del machine learning richiede che i data scientist accedano sia a dati puliti e governati per la feature engineering, sia a dati storici grezzi per l'addestramento dei modelli. Le architetture lakehouse supportano entrambi i casi d'uso in un'unica piattaforma, eliminando il sovraccarico di data engineering dovuto al mantenimento di copie separate dei dati per i carichi di lavoro di BI e ML.

Scegliere e migrare a una soluzione di data warehouse

La selezione della giusta soluzione di data warehouse comporta la valutazione delle opzioni gestite dal fornitore (vendor-managed) rispetto a quelle ospitate in proprio (self-hosted), la comprensione delle strutture dei costi e la convalida che una piattaforma possa supportare i carichi di lavoro analitici specifici su scala. I servizi gestiti dal fornitore si occupano della gestione dell'infrastruttura, della scalabilità, dell'applicazione delle patch e dell'elevata disponibilità, a scapito di un certo controllo operativo. Le opzioni self-hosted offrono alle organizzazioni una maggiore flessibilità per soddisfare requisiti rigorosi di residenza dei dati o policy di sicurezza complesse, ma richiedono che i team gestiscano i cluster, coordinino gli aggiornamenti e si occupino della pianificazione della capacità.

Valutazione dei fattori relativi a fornitori e costi

I costi del data warehouse rientrano in tre categorie: costi di archiviazione (storage), costi di calcolo (compute) e costi di trasferimento dei dati. I moderni data warehouse cloud tariffano lo storage e il compute separatamente, consentendo a ciascuno di scalare in modo indipendente. Prima di impegnarsi con una piattaforma per carichi di lavoro di produzione critici, esegui una proof of concept (PoC) con i tuoi dati reali e i tuoi pattern di query — i benchmark sintetici raramente riflettono le prestazioni reali con i volumi di dati con cui operi.

Migrazione graduale e ottimizzazione dei costi

La migrazione da un data warehouse legacy a una piattaforma moderna trae vantaggio da un approccio graduale organizzato per dominio aziendale. Inizia con un dominio che presenti requisiti di dati ben definiti e un business owner motivato. Convalida la migrazione rispetto ai benchmark di produzione prima di procedere al dominio successivo.

La separazione tra calcolo e archiviazione è una delle leve di ottimizzazione dei costi più significative nei moderni data warehouse. Nelle architetture tradizionali, il calcolo e l'archiviazione scalano insieme. Le moderne architetture cloud disaccoppiano queste dimensioni, consentendo alle organizzazioni di aggiungere storage senza allocare ulteriore compute e di scalare il compute verso l'alto per i periodi di picco delle query senza aumentare in modo permanente i costi di storage. L'autoscaling previene sia il sotto-dimensionamento durante i periodi di picco sia il sovra-dimensionamento durante i periodi di inattività.

Confronto tra i tipi di data warehouse

Domande frequenti

Quali sono i principali tipi di data warehouse?

I tre tipi principali di data warehouse sono l'Enterprise Data Warehouse (EDW), il Data Mart e l'Operational Data Store (ODS). Oltre a questi tipi fondamentali, le organizzazioni distribuiscono anche data warehouse basati sul cloud, data warehouse virtuali, data warehouse ibridi che combinano storage on-premises e cloud, e architetture lakehouse che uniscono la governance del data warehouse alla flessibilità del data lake. Ciascun tipo risponde a casi d'uso distinti in base all'ambito dei dati, ai requisiti di latenza e ai carichi di lavoro analitici.

Qual è la differenza tra un data warehouse e un data lake?

Un data warehouse archivia dati strutturati in schemi predefiniti e garantisce la qualità dei dati tramite processi ETL prima che i dati vengano caricati. Un data lake archivia i dati grezzi nel loro formato originale — strutturati, semistrutturati o non strutturati — senza richiedere uno schema predefinito al momento dell'acquisizione. I data warehouse sono ottimizzati per query SQL analitiche complesse e reportistica BI; i data lake sono ottimizzati per la flessibilità e per carichi di lavoro di data science e machine learning su larga scala. Un lakehouse combina entrambi: archivia i dati in formati aperti con la flessibilità del data lake, quindi aggiunge un livello di governance e transazionale con l'affidabilità di un data warehouse.

Quando un'organizzazione dovrebbe utilizzare un data mart anziché un EDW?

Un data mart è la scelta giusta quando un reparto specifico ha bisogno di funzionalità analitiche in tempi più rapidi rispetto a quanto consentito da un'implementazione EDW completa, quando le prestazioni delle query su un dominio di dati ristretto richiedono un'ottimizzazione indipendente o quando la proprietà dei dati di reparto è un requisito di governance. I data mart sono più efficaci come archivi dipendenti costruiti sopra un EDW esistente, attingendo dal repository centrale anziché acquisire direttamente dai sistemi sorgente. La creazione di data mart indipendenti senza un EDW centrale rischia di creare definizioni di metriche incoerenti e silos di dati tra i vari team.

Che cos'è un Operational Data Store e in cosa si differenzia da un data warehouse?

Un Operational Data Store (ODS) contiene dati operativi correnti e quasi correnti aggiornati a intervalli che vanno da minuti a ore, progettati per la reportistica operativa e il processo decisionale. Un data warehouse accumula dati storici nel corso degli anni ed è ottimizzato per l'analisi dei trend, la reportistica strategica e query multidimensionali complesse. L'ODS colma il divario di latenza tra i sistemi transazionali operativi e il data warehouse, che potrebbe essere aggiornato solo quotidianamente. Entrambi i sistemi vengono spesso distribuiti insieme: l'ODS supporta la visibilità operativa in giornata, mentre il data warehouse supporta l'analisi strategica a lungo termine.

In che modo i data warehouse cloud si differenziano dai data warehouse on-premises?

I data warehouse cloud sono ospitati su piattaforme cloud e offrono scalabilità elastica, prezzi basati sul consumo (pay-as-you-go) e un ridotto sovraccarico di gestione dell'infrastruttura rispetto alle distribuzioni on-premises. I tradizionali data warehouse on-premises devono essere dimensionati per la capacità di picco, il che spesso si traduce in un significativo sovra-dimensionamento durante le normali operazioni. I data warehouse cloud scalano automaticamente e possono essere predisposti in poche ore. I compromessi includono i costi di trasferimento dei dati in uscita (data egress) per volumi elevati, la dipendenza dalla disponibilità del cloud provider e la complessità della governance per le organizzazioni che operano su più piattaforme cloud.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale