Data Warehouse: cos’è e come funziona la fonte della Business Intelligence

Data Warehouse: cos'è e come funziona la fonte della Business Intelligence

I Data Warehouse aziendali sono archivi di Dati strutturati completi progettati per l’analisi.

Spesso fungono da fonti di Dati per i sistemi di BI ed il Machine Learning.

Le tipologie più comuni di Database

I Database sono generalmente classificati come relazionali (SQL) o non relazionali (NoSQL), oppure transazionali (OLTP), analitici (OLAP) o ibridi (HTAP).

I Database dipartimentali e quelli utilizzati per scopi speciali vennero inizialmente considerati un enorme miglioramento per le pratiche di business, ma in seguito vennero invece declassati a strumenti troppo “isolati”.

I tentativi di creare Database unificati per tutti i Dati in un’Azienda sono classificati come Data Lake – se i Dati vengono lasciati nel 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.

Potrebbe anche interessarti: Come scegliere la tua prossima piattaforma di Analytics

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) ed il Machine Learning.

Perché utilizzare un Data Warehouse?

Una delle principali motivazioni per l’utilizzo di un Data Warehouse Aziendale, o EDW (Enterprise Data Warehouse), è che il Database operativo (OLTP) limita il numero ed il tipo di indici che è possibile creare e quindi rallenta le query analitiche.

Dopo aver copiato i Dati nel Data Warehouse, sarà possibile indicizzare tutto ciò che ci interessa verso quest’ultimo per garantire buone prestazioni delle query analitiche, senza influire sulle prestazioni di scrittura del Database OLTP.

Un altro motivo per disporre di un Data Warehouse Aziendale è consentire l’unione di Dati da più origini per l’analisi.

Ad esempio, un’applicazione OLTP per le vendite probabilmente non avrà bisogno di conoscere il meteo nelle zone dei nostri Punti Vendita, ma le nostre previsioni di vendita potrebbero trarre vantaggio da tali Dati.

Se aggiungiamo Dati meteorologici storici al nostro Data Warehouse, sarà facile includerli nei nostri modelli di Dati storici di vendita.

Potrebbe anche interessarti: Data Management: cos’è e quali vantaggi può portare in Azienda

Data Warehouse vs. Data Lake

I Data Lake, che archiviano file di Dati nel loro formato nativo, sono essenzialmente “schema on read”, il che significa che qualsiasi applicazione che legge i Dati dal Data Lake dovrà imporre i propri tipi e relazioni su di essi.

I Data Warehouse, d’altra parte, sono “schema on write”, il che significa che i tipi di Dati, gli indici e le relazioni tra di essi vengono imposti mentre vengono archiviati nell’EDW.

Il modello “schema on read” è utile per i Dati che possono essere utilizzati in diversi contesti e presenta un rischio minimo di perdita, sebbene il pericolo sia che questi ultimi non vengano mai utilizzati.

Si stima infatti che il 90% dei Dati nella maggior parte dei Data Lake sia inattivo.

Lo “Schema on write” va bene invece per i Dati che hanno uno scopo specifico e che si riferiscono correttamente a 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 desiderato.

Data Warehouse vs. Data Mart

I Data Warehouse contengono Dati a livello aziendale, mentre i Data Mart contengono Dati orientati verso una specifica linea di business.

I Data Mart possono dipendere dal Data Warehouse o esserne indipendenti – cioè estratti da un Database operativo o da una fonte esterna – o presentarsi come un ibrido dei due.

I motivi per creare un Data Mart includono l’utilizzo di meno spazio, la restituzione più rapida dei risultati delle query ed il costo di esecuzione inferiore rispetto ad un Data Warehouse completo.

Spesso un Data Mart contiene Dati riepilogati e selezionati, anziché o in aggiunta ai Dati dettagliati trovati nel Data Warehouse.

Potrebbe anche interessarti: Come diventare un’Azienda Data-Driven

Architettura del Data Warehouse

In generale, i Data Warehouse hanno un’architettura a strati:

  • Dati di origine (o source data)
  • un Database di staging
  • strumenti di ETL (Estract Transform Load – Estrazione, Trasformazione e Caricamento) o ELT (Estract Load Transform – Estrazione, Caricamento e Trasformazione)
  • l’archiviazione dei Dati – o Data Storage – propriamente detta
  • strumenti di presentazione dei dati – o Data Presentation.

Ogni strato ha uno scopo diverso.

I source data spesso includono Database operativi di vendite, marketing ed altre parti del Business. Possono anche includere Dati provenienti dai social media o 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 di ETL prelevano i Dati, ne eseguono le mappature e le trasformazioni desiderate e li caricano nel Data Storage.

Gli strumenti ELT memorizzano prima i Dati e poi li trasformano. Quando si utilizzano questi strumenti, è anche possibile utilizzare un Data Lake e saltare il livello di staging tradizionale.

Il livello di archiviazione dei Dati – o Data Storage – di un Data Warehouse contiene Dati puliti e trasformati pronti per l’analisi.

Sarà spesso un archivio relazionale row-oriented, ma può anche essere column-oriented o avere indici di elenchi invertiti per la ricerca full-text.

I Data Warehouse hanno spesso molti più indici rispetto ai Data Store operativi, per velocizzare le query analitiche.

La presentazione dei dati – o Data Presentation – da un Data Warehouse viene spesso eseguita attraverso 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 in Cloud vs On-Premise

Un Data Warehouse può essere implementato in locale (On-Premise), nel Cloud o come ibrido.

Storicamente, i Data Warehouse erano sempre 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 vendor hanno iniziato ad 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 il Data Storage nel Cloud che per le risorse di calcolo e di memoria del Data Warehouse sempre su Cloud.

Si potrebbe pensare che il tempo per caricare Petabyte di Dati nel Cloud sia un’enorme barriera, ma i fornitori di cloud iper-scalabili ora offrono servizi di Data Transfer su disco ad alta capacità.

Progettazione di un Data Warehouse: Top-Down vs Bottom-Up

Esistono due principali scuole di pensiero su come progettare un Data Warehouse.

La differenza tra le 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 Inman) 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 ed al budget della propria Azienda.

La prima domanda è: abbiamo davvero bisogno di un Data Warehouse?

Il compito successivo – supponendo che si voglia procedere con l’integrazione – è identificare le proprie fonti Dati, la loro dimensione, il loro tasso di crescita attuale e cosa si sta facendo attualmente per utilizzarle ed analizzarle.

Successivamente, è possibile iniziare a sperimentare con Data Lake, Data Mart e Data Warehouse per vedere quale soluzione funziona meglio per la propria organizzazione.

Il nostro suggerimento è quello di fare la propria prova di fattibilità con un piccolo sottoinsieme di Dati, ospitato su hardware locale esistente o su una piccola installazione Cloud.

Dopo aver convalidato i progetti e dimostrato i vantaggi per l’Azienda, si potrà dunque scalare fino ad un’installazione completa con supporto per la sua gestione.

Cerchi una Consulenza Informatica di qualità? Contattaci!

 

Leave a Reply

Il tuo indirizzo email non sarà pubblicato.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>