Data Vault – Una panoramica

L’approccio di cui sopra fa a meno dell’EDW per fornire rapidamente risultati agli utenti finali. Ho usato questa tecnica nel 2008 in una banca d’investimento di primo livello a Londra per fornire valutazioni del rischio di credito agli utenti aziendali entro poche settimane dall’inizio del progetto. Se avessimo aspettato di costruire un data warehouse tradizionale, saremmo andati in bancarotta prima di aver consegnato qualcosa di utile.

Inizialmente, gli utenti di business erano entusiasti della velocità di consegna; tuttavia, col tempo, abbiamo trovato molte sfide che sono diventate sempre più dolorose da affrontare. Queste includevano:

1. Complessità crescente del codice: Il codice ETL (Extract, Transform, and Load) stava diventando così complicato che non era più gestibile. Sostituire lo strumento ETL (Informatica) con gli script Oracle ci ha aiutato, (poiché abbiamo semplificato la soluzione man mano), ma non era la radice del problema. Stavamo cercando di ristrutturare i dati in entrata, deduplicare, pulire e conformare i dati, e applicare regole di business che cambiano nel tempo. Fare tutti questi passi in una singola base di codice era davvero molto difficile.

2. Mancanza di dati grezzi: Poiché l’area di atterraggio era puramente transitoria (cancellata e ricaricata ogni volta), non avevamo alcun record storico di dati grezzi. Questo rendeva difficile per gli analisti scoprire nuove preziose relazioni tra i dati, e la crescente importanza della Data Science, che (soprattutto) ha bisogno di dati grezzi, veniva semplicemente ignorata.

3. Gestione della storia: Poiché non avevamo uno storico dei dati grezzi e caricavamo solo gli attributi necessari per l’analisi, diventava difficile ripopolare ulteriori feed di dati.

4. Il lineage era difficile: Poiché sia la logica tecnica che quella di business erano implementate in strati sempre più sedimentati di codice sorgente, era quasi impossibile tracciare la discendenza di un elemento di dati dal report al sistema di origine.

L’azienda amava la velocità iniziale di consegna. Tuttavia, con il passare del tempo, è diventato sempre più difficile mantenere il ritmo man mano che la soluzione diventava sempre più complessa e le regole aziendali cambiavano nel tempo.

Architettura Data Vault

Il diagramma seguente mostra una potenziale architettura di dati utilizzata dalla metodologia Data Vault.

Mentre a prima vista sembra molto simile all’architettura dell’Enterprise Data Warehouse di cui sopra, ha alcune differenze e similitudini significative, che includono:

• Caricamento dei dati: Quando i dati vengono caricati dalla Landing Area nel Raw Data Vault, il processo è puramente di ristrutturazione del formato (piuttosto che del contenuto) dei dati. I dati di origine non sono né puliti né modificati, e potrebbero essere interamente ricostruiti senza problemi.
• Separazione di responsabilità: Il Raw Vault contiene i dati grezzi non modificati, e l’unica elaborazione è interamente tecnica, per ristrutturare fisicamente i dati. Le regole di business forniscono tabelle e righe aggiuntive per estendere il Raw Vault con un Business Vault. Questo significa che le regole di business sono sia derivate che memorizzate separatamente dai dati grezzi. Questa separazione di responsabilità rende più facile gestire i cambiamenti delle regole di business nel tempo e riduce la complessità complessiva del sistema.
• Regole di business: I risultati delle regole di business, compresa la deduplicazione, i risultati conformi e persino i calcoli sono memorizzati centralmente nel Business Vault. Questo aiuta ad evitare calcoli duplicati e potenziali incoerenze quando i risultati sono calcolati per due o più data mart.
• Data Marts: A differenza del metodo Kimball in cui i risultati calcolati sono memorizzati in tabelle di fatti e dimensioni nei Data Mart, usando l’approccio Data Vault, i Data Mart sono spesso effimeri, e possono essere implementati come viste direttamente sul Business e sul Raw Vault. Questo significa che sono entrambi più facili da modificare nel tempo ed evita il rischio di risultati incoerenti. Se le viste non forniscono il livello di performance necessario, allora esiste l’opzione di memorizzare i risultati in una tabella.

I vantaggi di Data Vault

Data Vault affronta le difficoltà inerenti sia al 3° Data Warehouse Aziendale in forma normale che all’approccio di progettazione dimensionale, combinando i migliori aspetti di entrambi in un singolo approccio ibrido. I vantaggi includono:

1. Consegna incrementale: Mentre è ragionevole costruire qualsiasi Data Warehouse nel contesto di un modello aziendale complessivo, Data Vault supporta una consegna interamente incrementale. Proprio come l’approccio Dimensional Design di Kimball, è possibile iniziare in piccolo e aggiungere incrementalmente fonti aggiuntive nel tempo.

2. Flessibilità: A differenza dell’approccio di modellazione della terza forma normale, che può essere poco flessibile, Data Vault non richiede alcuna rielaborazione quando si aggiungono fonti aggiuntive. Poiché Data Vault memorizza i dati grezzi e i dati derivati dal business separatamente, supporta facilmente le modifiche alle regole di business.

3. Complessità ridotta: Poiché Data Vault è costruito con un approccio in due fasi, separa la ristrutturazione tecnica dei dati dall’applicazione delle regole di business, il che aiuta a isolare queste fasi potenzialmente complesse. Allo stesso modo, la pulizia dei dati è considerata una regola di business e può essere gestita indipendentemente dallo sforzo iniziale di caricamento dei dati.

4. Dati grezzi inclusi: Registrare i dati grezzi in Data Vault significa che è possibile ripopolare l’area di presentazione con attributi storici che non sono stati inizialmente resi disponibili. Se i Data Mart sono implementati come viste, questo può essere semplice come aggiungere una colonna aggiuntiva a una vista esistente.

5. Supporta elegantemente il cambiamento nel tempo: Simile alla dimensione che cambia lentamente nell’approccio Kimball, Data Vault supporta elegantemente i cambiamenti nel tempo. A differenza del puro design dimensionale, tuttavia, Data Vault separa i dati grezzi e quelli derivati dal business e supporta i cambiamenti derivanti sia dal sistema sorgente che dalle regole di business.

6. Lineage e audit: Poiché Data Vault include metadati che identificano i sistemi di origine, rende più facile supportare il lineage dei dati. A differenza dell’approccio Dimensional Design in cui i dati vengono puliti prima del caricamento, le modifiche di Data Vault sono sempre incrementali e i risultati non vengono mai persi, il che fornisce un audit trail automatico.

7. Carichi paralleli ad alte prestazioni: Con l’introduzione di Hash Keys in Data Vault 2.0, le dipendenze del carico di dati sono state eliminate, il che significa che è possibile caricare i dati quasi in tempo reale, oltre a caricare in parallelo da terabyte a petabyte di dati.

8. Possibilità di automatizzare: Mentre sia l’Entity Relationship Modelling che il Dimensional Design richiedono tempo ed esperienza per costruire le competenze, Data Vault tende ad essere più facile da automatizzare, e ci sono diversi strumenti (elencati sotto) per aiutare a fornire la soluzione.

Gli svantaggi di Data Vault

Data Vault non è la perfetta soluzione unica per tutti i data warehouse, e ha alcuni svantaggi che devono essere considerati. Questi includono:

1. La curva di apprendimento: Proprio come la terza forma normale, la modellazione delle relazioni tra entità e la progettazione dimensionale sono competenze specifiche che richiedono tempo per essere padroneggiate, c’è una curva di apprendimento con Data Vault. Imbarcarsi in un progetto di trasformazione del Data Warehouse comporta rischi significativi, e l’aggiunta di Data Vault può aumentare il rischio, specialmente se il team non ha esperienza di Data Vault. Assicuratevi di avere la consulenza e il supporto di esperti, oltre alla formazione delle persone chiave.

2. Molteplici join: Un progetto di Data Vault mal progettato produrrà un numero enorme di tabelle derivate dal sistema sorgente, ma anche una soluzione ben progettata moltiplica il numero di tabelle sorgente per un fattore di 2 o 3. Il numero di tabelle e quindi di join può apparire ingombrante e portare a complesse condizioni di join. Questo può, tuttavia, essere affrontato con l’uso corretto di tabelle ponte nel Business Vault, e come con qualsiasi soluzione, è un compromesso tra complessità apparente e flessibilità.

Dove usare Data Vault?

Data Vault richiede un certo rigore nel fornire un buon design e attenersi ai principi del Data Vault 2.0. Come l’Enterprise Data Warehouse, è progettato per integrare dati provenienti da diverse fonti di dati e può, quindi, essere eccessivo in alcune situazioni.

In sintesi, se avete un’esigenza di analisi di piccole o medie dimensioni, con un piccolo (meno di 10) team di architetti, designer e ingegneri che fornisce una soluzione con dati provenienti da pochi sistemi, allora Data Vault potrebbe essere inappropriato per le vostre esigenze.

Se, tuttavia, avete un grande progetto con 30 o più sistemi sorgente che portano a un’enorme sfida di integrazione dei dati e siete pronti ad assumere le competenze e il rigore di una nuova metodologia, allora Data Vault può potenzialmente aggiungere un enorme valore al progetto.

Altre risorse e strumenti

Le seguenti risorse possono aiutare a valutare e comprendere il metodo Data Vault:

• Kent Graziano (Data Vault Master certificato) ha un riassunto di Data Vault che vale la pena leggere.
• La Genesee Academy (Formazione) fornisce una buona introduzione ai principi principali di Data Vault.
• La società di consulenza britannica Data Vault fornisce un riassunto informativo delle domande frequenti che affrontano molte delle preoccupazioni immediate.
• Dan Linstedt ha un enorme numero di articoli approfonditi sui dettagli di Data Vault.
• Costruire un Data Warehouse scalabile con Data Vault 2.0 – è il libro di riferimento di Dan Linstedt.
• The Elephant in the Fridge – è una accessibile introduzione a Data Vault.

Anche se questi non devono essere considerati in alcun modo una raccomandazione, ecco una breve lista di strumenti che possono aiutare ad automatizzare la fornitura di Data Vault.

• dbtvault
• Wherescape
• VaultSpeed
• Data Vault Builder
• Joyn – A lightweight open source automation framework

Conclusion

Come i progetti di data warehouse on-premise vengono trasferiti nel cloud, un numero crescente di imprese sta ripensando l’architettura del data warehouse. Il passaggio da più silos di dati indipendenti on-premise a una moderna soluzione basata sul cloud è un’opportunità unica per integrare i dati di tutta l’azienda in un unico repository coerente.

Se questa è la sfida che dovete affrontare, allora Data Vault potrebbe aiutarvi a fornire la soluzione.

Se avete trovato utile questo articolo, potreste essere interessati al mio blog personale (assolutamente privo di pubblicità), all’indirizzo www.Analytics.Today.

Disclaimer: Le opinioni espresse nei miei articoli sono mie e non riflettono necessariamente quelle del mio datore di lavoro (passato o presente) o di qualsiasi cliente con cui ho lavorato.