I sistemi EDW (Enterprise Data Warehouse) mirano a fornire una vera Business Intelligence (BI) per l’impresa guidata dai dati. Le aziende devono occuparsi di metriche critiche radicate in questi dati vitali e vibranti. Fornire un processo essenziale di integrazione dei dati che alla fine supporti una varietà di requisiti di reporting è un obiettivo chiave per questi sistemi di Enterprise Data Warehouse. Costruirli comporta uno sforzo significativo di progettazione, sviluppo, amministrazione e funzionamento. Quando i sistemi di business a monte, le strutture o le regole cambiano, non riescono a fornire dati coerenti o richiedono nuove soluzioni di integrazione dei sistemi, i requisiti minimi di reingegnerizzazione ci presentano il problema #1: l’unica costante è il cambiamento; quanto bene può adattarsi una soluzione EDW/BI?
“Non è il più forte della specie a sopravvivere, né il più intelligente a sopravvivere. È quella che è più adattabile al cambiamento”. Charles Darwin
Il consumo e l’analisi dei dati aziendali da parte di diverse comunità di utenti è diventata una realtà critica per mantenere un vantaggio competitivo, ma le realtà tecnologiche di oggi richiedono spesso utenti finali altamente qualificati. La cattura, l’elaborazione, la trasformazione, la pulizia e il reporting di questi dati possono essere comprensibili, ma nella maggior parte dei casi il volume dei dati può essere schiacciante; Sì, il problema #2: Davvero Big Data; spesso caratterizzato come: Volume, Velocità, Varietà, Variabilità, Veracità, Visualizzazione, & Valore!
Costruire sistemi EDW/BI efficaci ed efficienti, semplificati per l’usabilità e il reporting su questi dati, diventa rapidamente una prova tecnica scoraggiante e spesso difficile anche per team di ingegneri veterani. Sono necessarie diverse tecnologie integrate, da sistemi di database, strumenti di elaborazione dei dati (ETL) come Talend, vari linguaggi di programmazione, software di amministrazione, reporting e grafica interattiva a reti ad alte prestazioni e computer potenti con capacità di archiviazione molto grandi. La progettazione, la creazione, la consegna e il supporto di sistemi EDW/BI robusti e senza sforzo per un uso semplificato e intelligente sono, avete indovinato; problema #3: Complessità!
Spesso vediamo soluzioni complete ed eleganti consegnate all’utente aziendale che non riesce a capire le vere esigenze del business. Ci viene detto che è così e basta, a causa di requisiti tecnici (limitazioni; wink, wink) e/o parametri di progettazione (mancanza di caratteristiche; nudge, nudge). Quindi; problema #4: il dominio del business; adattare i dati per soddisfare le esigenze del business, non il contrario!
Inoltre, mentre i sistemi a monte cambiano (e lo faranno), mentre la tecnologia EDW/BI va avanti (e deve), mentre le complessità dinamiche coinvolte prevalgono (inesorabilmente), ogni tanto nuove fonti di dati devono essere aggiunte al mix. Queste sono di solito impreviste e non pianificate. L’impatto dell’integrazione può essere enorme e spesso richiede una rigenerazione completa dei dati aggregati; da qui il problema #5: Flessibilità; o la mancanza di questa!
Come possiamo risolvere questi problemi? Bene …
Bill Inmon, ampiamente considerato come il padre del data warehousing, definisce un data warehouse come:
“Una raccolta di dati orientata al soggetto, non volatile e variabile nel tempo a sostegno delle decisioni della direzione”
(http://en.wikipedia.org/wiki/Bill_Inmon)
Ralph Kimball (http://en.wikipedia.org/wiki/Ralph_Kimball), un architetto pioniere del data warehousing, ha sviluppato la metodologia di “modellazione dimensionale” ora considerata come lo standard de-facto nell’area del supporto alle decisioni. Il modello dimensionale (chiamato “schema a stella”) è diverso dalla metodologia di “modellazione normalizzata” di Inman (talvolta chiamata “schema a fiocco di neve”). Nello Star Schema di Kimball, i dati transazionali sono partizionati in “fatti” aggregati con “dimensioni” referenziali che circondano e forniscono descrittori che definiscono i fatti. Il modello normalizzato (3NF o “terza forma normale”) memorizza i dati in “tabelle” correlate seguendo le regole di progettazione dei database relazionali stabilite da E. F. Codd e Raymond F. Boyce nei primi anni ’70 che eliminano la ridondanza dei dati. Promuovendo un vigoroso dibattito tra gli architetti EDW/BI su quale metodologia sia la migliore, entrambe hanno un punto debole quando si tratta di affrontare gli inevitabili cambiamenti nei sistemi che alimentano il magazzino di dati e nella pulizia dei dati per conformarsi ai severi requisiti della metodologia.
Inoltre, il cubo OLAP (per “elaborazione analitica online”) è una struttura di dati che permette una rapida analisi dei dati da prospettive multiple. La struttura del cubo viene creata da uno schema a stella o a fiocco di neve memorizzato come metadati da cui si possono visualizzare o “ruotare” i dati in vari modi. Generalmente i cubi hanno una dimensione basata sul tempo che supporta una rappresentazione storica dei dati. La creazione di cubi OLAP può essere molto costosa e spesso crea una quantità significativa di dati di scarsa o nessuna utilità. La regola 80/20 sembra in molti casi essere vera (dove solo il 20% dei dati del cubo OLAP si rivela utile), il che porta alla domanda: Costruito su un’architettura tradizionale, un cubo OLAP offre davvero un ROI sufficiente? Spesso la risposta è un clamoroso NO! I sistemi EDW/BI durevoli devono fornire un valore reale.
Scopri come Talend ha aiutato Tipico a trasformare oceani di dati in una business intelligence all’avanguardia.
Un approccio fresco
Il Data Vault è una metodologia ibrida di modellazione dei dati che fornisce una rappresentazione storica dei dati da più fonti, progettata per essere resiliente ai cambiamenti ambientali. Originariamente concepito nel 1990 e rilasciato nel 2000 come metodologia di modellazione di pubblico dominio, Dan Linstedt, il suo creatore, descrive un database Data Vault risultante come:
“Un dettaglio orientato, tracciamento storico e un insieme univocamente collegato di tabelle normalizzate che supportano una o più aree funzionali di business. È un approccio ibrido che comprende il meglio della razza tra 3NF e Star Schemas. Il design è flessibile, scalabile, coerente e adattabile ai bisogni dell’impresa.”
(http://en.wikipedia.org/wiki/Data_Vault_Modeling)
Focalizzato sul processo di business, il Data Vault come architettura di integrazione dei dati, ha standard robusti e metodi di definizione che uniscono le informazioni per dargli un senso. Il modello Data Vault è composto da tre tipi di tabelle di base:
HUB (blu): contenente una lista di chiavi di business uniche con una propria chiave surrogata. I metadati che descrivono l’origine della chiave aziendale, o la “fonte” del record, sono anche memorizzati per tracciare dove e quando i dati hanno avuto origine.
LNK (rosso): che stabilisce relazioni tra chiavi aziendali (tipicamente hub, ma i collegamenti possono collegarsi ad altri collegamenti); essenzialmente descrivono una relazione molti-a-molti. I collegamenti sono spesso usati per gestire i cambiamenti nella granularità dei dati, riducendo l’impatto dell’aggiunta di una nuova chiave aziendale a un hub collegato.
SAT (giallo): tenere attributi descrittivi che possono cambiare nel tempo (simile a una dimensione Kimball di tipo II che cambia lentamente). Dove gli Hub e i Link formano la struttura del modello di dati, i Satelliti contengono attributi temporali e descrittivi, compresi i metadati che li collegano alle loro tabelle Hub o Link. Gli attributi di metadati all’interno di una tabella Satellite che contengono una data di validità del record e una data di scadenza forniscono potenti capacità storiche che permettono di effettuare query che possono andare “indietro nel tempo”.
Ci sono diversi vantaggi chiave nell’approccio Data Vault:
– Semplifica il processo di ingestione dei dati
– Rimuove il requisito di pulizia di uno schema a stella
– Fornisce immediatamente la verificabilità per HIPPA e altri regolamenti
– Mette l’attenzione sul problema reale invece di programmare intorno ad esso
– Permette facilmente l’aggiunta di nuove fonti di dati senza interrompere lo schema esistente
In poche parole, il Data Vault è sia una tecnica di modellazione dei dati che una metodologia che accoglie i dati storici, l’auditing e il monitoraggio dei dati.
“Il Data Vault è la scelta ottimale per modellare l’EDW nel quadro del DW 2.0”
Bill Inmon
Adattabile
Per mezzo della separazione delle chiavi di business (che sono generalmente statiche) e delle associazioni tra di esse dai loro attributi descrittivi, un Data Vault affronta il problema del cambiamento dell’ambiente. Usando queste chiavi come spina dorsale strutturale di un data warehouse, tutti i dati correlati possono essere organizzati intorno ad esse. Questi hub (chiavi aziendali), link (associazioni) e SAT (attributi descrittivi) supportano una struttura di dati altamente adattabile mantenendo un alto grado di integrità dei dati. Dan Linstedt mette spesso in relazione il Data Vault con una visione semplicistica del cervello, dove i neuroni sono associati a Hub e Satelliti e dove i dendriti sono Link (vettori di informazioni). Alcuni Link sono come sinapsi (vettori in direzione opposta). Possono essere creati o eliminati al volo man mano che le relazioni di business cambiano, mortificando automaticamente il modello di dati come necessario senza impatto sulle strutture di dati esistenti. Problema #1 risolto!
Big Data
Data Vault v2.0 è entrato in scena nel 2013 e incorpora una perfetta integrazione delle tecnologie Big Data insieme a metodologia, architettura e best practice di implementazione. Grazie a questa adozione, quantità molto grandi di dati possono essere facilmente incorporate in un Data Vault progettato per memorizzare utilizzando prodotti come Hadoop, Infobright, MongoDB e molte altre opzioni NoSQL. Eliminando i requisiti di pulizia di un design Star Schema, il Data Vault eccelle quando si tratta di enormi insiemi di dati, diminuendo i tempi di ingestione e consentendo inserzioni parallele che sfruttano la potenza dei sistemi Big Data. Problema #2 Risolto!
Semplificazione
Costruire un modello di Data Vault efficace ed efficiente può essere fatto velocemente una volta che hai capito le basi dei 3 tipi di tabella: Hub, Satellite e Link! Identificare le chiavi di business per primo e definire gli Hub è sempre il miglior punto di partenza. Da lì gli Hub-Satelliti rappresentano le colonne della tabella sorgente che possono cambiare, e infine i Link legano tutto insieme. Ricorda che è anche possibile avere tabelle Link-Satellite. Una volta che hai questi concetti, è facile. Dopo aver completato il modello di Data Vault, la prossima cosa comune da fare è costruire il processo di integrazione dati ETL per popolarlo. Mentre un modello di dati Data Vault non è limitato alle soluzioni EDW/BI, ogni volta che è necessario far uscire i dati da una fonte di dati e portarli in una destinazione, è generalmente richiesto un processo di integrazione dei dati. La missione di Talend è quella di collegare l’impresa guidata dai dati.
Con la sua suite di software di integrazione, Talend semplifica il processo di sviluppo, riduce la curva di apprendimento e diminuisce il costo totale di proprietà con una piattaforma ETL unificata, aperta e prevedibile. Una tecnologia ETL collaudata, Talend può certamente essere usata per popolare e mantenere un robusto sistema EDW/BI costruito su un modello di dati Data Vault. Problema #3 Risolto!
Il tuo business
Il Data Vault definisce essenzialmente l’ontologia di un’impresa in quanto descrive il dominio del business e le relazioni al suo interno. L’elaborazione delle regole di business deve avvenire prima di popolare uno Star Schema. Con un Data Vault è possibile spingerle a valle, dopo l’ingestione dell’EDW. Un’ulteriore filosofia di Data Vault è che tutti i dati sono rilevanti, anche se sono sbagliati. Dan Linstedt suggerisce che i dati sbagliati sono un problema di business, non un problema tecnico. Sono d’accordo! Un EDW non è davvero il posto giusto per correggere (pulire) i dati sbagliati. La semplice premessa del Data Vault è di ingerire il 100% dei dati sorgente il 100% delle volte; buoni, cattivi o brutti. Rilevante nel mondo di oggi, l’audit e la tracciabilità di tutti i dati nel data warehouse diventano così un requisito standard. Questo modello di dati è progettato specificamente per soddisfare le esigenze dei sistemi EDW/BI di oggi. Problema #4 Risolto!
“Capire il Data Vault è capire il business”
(http://danlinstedt.com)
Flessibile
La metodologia Data Vault è basata sulle migliori pratiche SEI/CMMI Livello 5 e include molti dei suoi componenti combinandoli con le migliori pratiche di Six Sigma, TQM e SDLC (Agile). I progetti Data Vault hanno cicli di rilascio brevi e controllati e possono consistere in un rilascio di produzione ogni 2 o 3 settimane, adottando automaticamente i progetti ripetibili, coerenti e misurabili previsti al livello 5 di CMMI. Quando è necessario aggiungere nuove fonti di dati, sono probabili chiavi di business simili, nuovi Hub-Satelliti-Link possono essere aggiunti e poi ulteriormente collegati alle strutture esistenti di Data Vault senza alcuna modifica al modello di dati esistente. Problema #5 risolto!
Conclusione
In conclusione, la modellazione e la metodologia Data Vault affronta gli elementi dei problemi che abbiamo identificato sopra:
– Si adatta ad un ambiente di business che cambia
– Supporta insiemi di dati molto grandi
– Semplifica le complessità di progettazione EDW/BI
– Aumenta l’usabilità da parte degli utenti di business perché è modellato sul dominio del business
– permette l’aggiunta di nuove fonti di dati senza impatto sul design esistente
Questo progresso tecnologico sta già dimostrando di essere molto efficace ed efficiente. Facile da progettare, costruire, popolare e cambiare, il Data Vault è un chiaro vincitore. Molto cool! Ne vuoi uno?
Visita http://learndatavault.com o http://www.keyldv.com/lms per saperne di più sulla modellazione e la metodologia di Data Vault.
Già che ci sei, scarica una prova gratuita di Talend Cloud Integration Platform per vedere cosa i tuoi dati possono davvero fare.