I database sono generalmente classificati come relazionali (SQL) o NoSQL e transazionali (OLTP), analitici (OLAP) o ibridi (HTAP). I database dipartimentali e per scopi speciali sono stati inizialmente considerati enormi miglioramenti per le pratiche commerciali, ma in seguito sono stati denotati negativamente come “isole”.

I tentativi di creare database unificati per tutti i dati in un’azienda sono classificati come data lake se i dati vengono lasciati nel loro formato nativo, e data warehouse se i dati vengono portati in un formato e uno schema comuni. I sottoinsiemi di un data warehouse sono chiamati data mart.

Definizione di data warehouse

In sostanza, un data warehouse è un database analitico, solitamente relazionale, creato da due o più origini dati, in genere per archiviare dati storici, che possono avere una scala di petabyte. I data warehouse spesso dispongono di risorse di memoria e di calcolo significative per l’esecuzione di query complesse e la generazione di report. Sono spesso le origini dati per i sistemi di business intelligence (BI) e machine learning.

Perché utilizzare un data warehouse?

Una delle principali motivazioni per l’utilizzo di un data warehouse aziendale, o EDW, è che il database operativo (OLTP) limita il numero e il tipo di indici che è possibile creare e quindi rallenta le query analitiche. Dopo aver copiato i dati nel data warehouse, potete indicizzare al suo interno tutto ciò che vi interessa per buone prestazioni delle query analitiche, senza influire sulle prestazioni di scrittura del database OLTP.

Un altro motivo per avere un data warehouse aziendale è consentire l’unione di dati da più origini per l’analisi. Ad esempio, la vostra applicazione OLTP per le vendite probabilmente non ha bisogno di conoscere il tempo atmosferico nei vostri punti vendita, ma le vostre previsioni di vendita potrebbero trarre vantaggio da tali dati. Se aggiungete dati meteorologici storici al vostro data warehouse, sarebbe facile includerli nei vostri modelli di dati storici di vendita.

Data warehouse vs. data lake

I data lake, che archiviano file di dati nel loro formato nativo, sono essenzialmente “schema in lettura”, il che significa che qualsiasi applicazione che legge i dati dal “lago” dovrà imporre i propri tipi e relazioni sui dati. I data warehouse, d’altra parte, sono “schema in scrittura”, il che significa che i tipi di dati, gli indici e le relazioni vengono imposti ai dati mentre vengono archiviati nell’EDW.

“Schema in lettura” è utile per i dati che possono essere utilizzati in diversi contesti e presenta un rischio minimo di perdita di dati, sebbene il pericolo sia che i dati non vengano mai utilizzati; Qubole, un fornitore di strumenti di cloud data warehouse per data lake, stima che il 90% dei dati nella maggior parte dei data lake sia inattivo.

“Schema in scrittura” è ideale invece per i dati che hanno uno scopo specifico e per i dati che devono correlano adeguatamente i dati provenienti da altre fonti. Il pericolo è che i dati formattati in modo errato possano essere eliminati durante l’importazione perché non vengono convertiti correttamente nel tipo di dati desiderato.

Data warehouse vs data mart

I data warehouse contengono dati a livello aziendale, mentre i data mart contengono dati orientati a una specifica linea di business. I motivi per creare un data mart includono l’utilizzo di meno spazio, la restituzione dei risultati delle query più rapidamente e il costo di esecuzione inferiore rispetto a un data warehouse completo. Spesso un data mart contiene dati riepilogati e selezionati, anziché o in aggiunta ai dati dettagliati trovati nel data warehouse.

Architetture di data warehouse

In generale, i data warehouse hanno un’architettura a strati: dati di origine, un database di staging, strumenti ETL (estrazione, trasformazione e caricamento) o ELT (estrazione, caricamento e trasformazione), l’archiviazione dei dati propriamente detta e strumenti di presentazione dei dati. Ogni strato ha uno scopo diverso.

database-blue

I dati di origine spesso includono database operativi di vendite, marketing e altre parti dell’attività. Possono anche includere social media e dati esterni, come sondaggi e dati demografici.

Il livello di staging archivia i dati recuperati dalle origini dati; se una fonte non è strutturata, come il testo dei social media, è qui che viene imposto uno schema. Questo è anche il luogo in cui vengono applicati i controlli di qualità per rimuovere dati di scarsa qualità e correggere errori comuni. Gli strumenti ETL prelevano i dati, eseguono le mappature e le trasformazioni desiderate e caricano i dati nel livello di archiviazione dei dati.

Gli strumenti ELT memorizzano prima i dati e poi li trasformano. Quando utilizzate gli strumenti ELT, potete anche utilizzare un data lake e saltare il livello di staging tradizionale.

Il livello di archiviazione dei dati di un data warehouse contiene dati puliti e trasformati pronti per l’analisi. I data warehouse hanno spesso molti più indici rispetto agli archivi dati operativi, in modo da velocizzare le query analitiche.

La presentazione dei dati da un data warehouse viene spesso eseguita eseguendo query SQL, che possono essere costruite con l’aiuto di uno strumento GUI. L’output delle query SQL viene utilizzato per creare tabelle di visualizzazione, grafici, dashboard, report e previsioni, spesso con l’ausilio di strumenti di BI (business intelligence).

Di recente, i data warehouse hanno iniziato a supportare il machine learning per migliorare la qualità dei modelli e delle previsioni. Google BigQuery, ad esempio, ha aggiunto istruzioni SQL per supportare modelli di regressione lineare per la previsione e modelli di regressione logistica binaria per la classificazione. Alcuni data warehouse si sono persino integrati con librerie di deep learning e strumenti di machine learning automatizzato (AutoML).

Data warehouse cloud rispetto a on-premise

Un data warehouse può essere implementato in locale, nel cloud o come ibrido. Storicamente, i data warehouse sono sempre stati on-premise, ma a volte il costo del capitale e la mancanza di scalabilità dei server on-premise nei data center erano un problema.

Le installazioni EDW sono cresciute quando i fornitori hanno iniziato a offrire dispositivi di data warehouse. Ora, tuttavia, la tendenza è spostare tutto o parte del proprio data warehouse nel cloud per sfruttare la scalabilità intrinseca del cloud EDW e la facilità di connessione ad altri servizi cloud.

Lo svantaggio di inserire petabyte di dati nel cloud è il costo operativo, sia per l’archiviazione dei dati nel cloud, sia per le risorse di calcolo e memoria del data warehouse nel cloud. Si potrebbe pensare che il tempo per caricare petabyte di dati nel cloud sia un’enorme barriera, ma i fornitori di cloud iperscalabili ora offrono servizi di trasferimento dati basati su disco ad alta capacità.

Progettazione di data warehouse top-down e bottom-up

Esistono due principali scuole di pensiero su come progettare un data warehouse. La differenza tra i due ha a che fare con la direzione del flusso di dati tra il data warehouse e i data mart.

La progettazione top-down (nota come approccio Inmon) tratta il data warehouse come un repository di dati centralizzato per l’intera azienda. I data mart sono derivati dal data warehouse.

La progettazione bottom-up (nota come approccio Kimball) considera i data mart come primari e li combina nel data warehouse. Nella definizione di Kimball, il data warehouse è “una copia dei dati delle transazioni specificamente strutturata per query e analisi”.

Le applicazioni assicurative e di produzione dell’EDW tendono a favorire la metodologia di progettazione top-down di Inman. Il marketing tende a favorire l’approccio Kimball.

Data lake, data mart o data warehouse?

In definitiva, tutte le decisioni associate ai data warehouse aziendali si riducono agli obiettivi, alle risorse e al budget della vostra azienda. La prima domanda è se avete bisogno di un data warehouse. Il prossimo compito è identificare le vostre origini dati, la loro dimensione, il loro tasso di crescita attuale e cosa state facendo attualmente per utilizzarle e analizzarle. Successivamente, potete iniziare a sperimentare con data lake, data mart e data warehouse per vedere cosa funziona per la vostra organizzazione.

Il suggerimento è di fare la vostra proof of concept con un piccolo sottoinsieme di dati, ospitato su hardware locale esistente o su una piccola installazione cloud. Dopo aver convalidato i vostri progetti e dimostrato i vantaggi per l’organizzazione, potete scalare fino a un’installazione completa con supporto completo per la gestione.