Nell'articolo precedente ho parlato delle basi del DATA VAULT, descrivendo i principali elementi del DATA VAULT e la loro funzione. Non si può considerare esaurito l'argomento del DATA VAULT, è necessario discutere dei seguenti stadi dell'evoluzione del DATA VAULT.
In questo articolo mi concentrerò sullo sviluppo del DATA VAULT e sulla transizione verso il BUSINESS DATA VAULT o semplicemente BUSINESS VAULT.
Le ragioni della nascita del BUSINESS DATA VAULT
È importante notare che, pur avendo determinate forze, il DATA VAULT non è privo di difetti. Uno di questi difetti è la complessità nella scrittura di query analitiche. Le query presentano un numero significativo di JOIN, il codice risulta lungo e pesante. Inoltre, i dati che entrano nel DATA VAULT non vengono sottoposti a nessuna trasformazione, dunque dal punto di vista commerciale il DATA VAULT in forma pura non ha un valore incondizionato.
È proprio per ovviare a questi difetti che la metodologia DATA VAULT è stata ampliata con elementi come:
- tabelle PIT (point in time);
- tabelle BRIDGE;
- DERIVAZIONI PREDEFINITE.
Analizziamo più nel dettaglio la funzione di questi elementi.
Tabelle PIT
Generalmente, un oggetto di business (HUB) può contenere dati con frequenze di aggiornamento diverse: ad esempio, se parliamo di dati che caratterizzano una persona, possiamo dire che le informazioni relative a un numero di telefono, a un indirizzo o all'email hanno una frequenza di aggiornamento più alta rispetto a nome, cognome, dati del passaporto, stato civile o sesso.
Pertanto, nella definizione dei satelliti, è importante considerare la loro frequenza di aggiornamento. Perché è importante?
Se in una tabella si conservano attributi con frecce di aggiornamento diverse, sarà necessario aggiungere una riga alla tabella ad ogni aggiornamento dell'attributo più frequentemente modificato. Di conseguenza, ci sarà un aumento del volume di spazio su disco e un incremento dei tempi di esecuzione delle query.
Ora che abbiamo suddiviso i satelliti in base alla frequenza di aggiornamento e possiamo caricare i dati in modo indipendente, è fondamentale garantire la possibilità di ottenere dati aggiornati. È meglio farlo senza l'uso eccessivo di JOIN.
Spiego, ad esempio, è necessario ottenere informazioni aggiornate (in base alla data dell'ultimo aggiornamento) dai satelliti che hanno diverse frequenze di aggiornamento. Per questo sarà necessario non solo eseguire un JOIN, ma anche creare diverse sottoquery (per ogni satellite contenente informazioni) con la selezione della data di aggiornamento massima MAX(Data di aggiornamento). Con ogni nuovo JOIN, questo codice diventa più complesso e rapidamente difficile da comprendere.
La tabella PIT è progettata per semplificare tali query, le tabelle PIT vengono compilate contemporaneamente all'inserimento di nuovi dati nel DATA VAULT. Tabella PIT:
In questo modo abbiamo informazioni sulla tempestività dei dati per tutti i satelliti in ogni momento. Utilizzando i JOIN alla tabella PIT, possiamo escludere completamente le sottoquery, naturalmente a condizione che la PIT venga riempita ogni giorno senza interruzioni. Anche se ci sono interruzioni nella PIT, è possibile ottenere dati aggiornati utilizzando solo una sottoquery direttamente sulla PIT. Una sottoquery funzionerà più velocemente rispetto alle sottoquery per ogni satellite.
BRIDGE
Le tabelle di tipo BRIDGE vengono utilizzate anche per semplificare le query analitiche. Tuttavia, a differenza della PIT, esse semplificano e accelerano le query tra diversi hub, link e i loro satelliti.
La tabella contiene tutte le chiavi necessarie per tutti i satelliti, che vengono spesso utilizzate nelle query. Inoltre, se necessario, le chiavi aziendali hashate possono essere integrate con chiavi in formato testuale, se i nomi delle chiavi sono necessari per l'analisi.
Il punto è che senza l'uso del BRIDGE, nel processo di estrazione dei dati dai satelliti appartenenti a hub diversi, sarà necessario eseguire il JOIN non solo dei satelliti stessi, ma anche dei link che collegano gli hub.
La presenza o l'assenza del BRIDGE è determinata dalla configurazione del deposito e dalla necessità di ottimizzare la velocità di esecuzione delle query. È difficile pensare a un esempio universale di BRIDGE.
DERIVAZIONI PREDEFINITE
Un altro tipo di oggetti che ci avvicina al BUSINESS DATA VAULT sono le tabelle contenenti indicatori calcolati in anticipo. Tali tabelle sono veramente importanti per il business, contengono informazioni aggregate in base a regole specifiche e permettono di accedervi in modo relativamente semplice.
Le derivazioni ARCHITETTURALI PREDEFINITE sono niente meno che un altro satellite di un determinato hub. Come un normale satellite, contiene una chiave aziendale e una data di creazione della registrazione nel satellite. Tuttavia, qui termina la similitudine. La composizione successiva degli attributi di questo «satellite specializzato» è definita dagli utenti aziendali sulla base degli indicatori più richiesti e pre-calcolati.
Ad esempio, un hub contenente informazioni su un dipendente può includere un satellite con indicatori come:
- Stipendio minimo;
- Stipendio massimo;
- Stipendio medio;
- Totale accumulato dello stipendio maturato, ecc.
È logico includere le DERIVAZIONI PREDEFINITE nella tabella PIT di questo stesso hub, in modo da poter ottenere facilmente estratti di dati per il dipendente in una data specifica.
CONCLUSIONI
Come dimostra la pratica, l'uso del DATA VAULT da parte degli utenti aziendali è piuttosto difficile per diverse ragioni:
- Il codice delle query è complesso e ingombrante;
- L'abbondanza di JOIN influisce sulle performance delle query;
- Per scrivere query analitiche è necessaria una conoscenza approfondita della struttura del data store.
Per semplificare l'accesso ai dati, il DATA VAULT viene ampliato con oggetti aggiuntivi:
- tabelle PIT (point in time);
- tabelle BRIDGE;
- DERIVAZIONI PREDEFINITE.
Nel prossimo Intendo illustrare, a mio avviso, gli aspetti più interessanti per coloro che lavorano con il BI. Presenterò i metodi di creazione di tabelle – fatti e tabelle – dimensioni basate su DATA VAULT.
I materiali dell'articolo sono basati su:
- A Kenta Graziano, che contiene, oltre a una descrizione dettagliata, anche schemi del modello;
- Libro: «Building a Scalable Data Warehouse with DATA VAULT 2.0»;
- su Lifehacker. .
Fonte: habr.com
