Lo sviluppo di un impianto di stoccaggio è un'impresa lunga e seria.
Molto nella vita di un progetto dipende da quanto bene sono pensati il modello a oggetti e la struttura di base all'inizio.
L'approccio generalmente accettato è stato e rimane varie opzioni per combinare lo schema a stella con la terza forma normale. Di norma, secondo il principio: dati iniziali - 3NF, vetrine - stella. Questo approccio, testato nel tempo e supportato da una grande quantità di ricerche, è la prima (e talvolta l'unica) cosa che viene in mente a uno specialista DWH esperto quando pensa a come dovrebbe apparire un repository analitico.
D’altro canto, il business in generale e le esigenze dei clienti in particolare tendono a cambiare rapidamente, e i dati tendono a crescere sia “in profondità” che “in ampiezza”. Ed è qui che appare il principale svantaggio di una stella: limitato flessibilità.
E se nella tua vita tranquilla e accogliente di sviluppatore DWH all'improvviso:
- è sorto il compito di “fare almeno qualcosa in fretta, e poi vedremo”;
- è apparso un progetto in rapido sviluppo, con il collegamento di nuove fonti e la rielaborazione del modello di business almeno una volta alla settimana;
- è apparso un cliente che non ha idea di come dovrebbe essere il sistema e di quali funzioni dovrebbe svolgere alla fine, ma è pronto a sperimentare e perfezionare costantemente il risultato desiderato avvicinandosi costantemente ad esso;
- Il project manager è intervenuto con la buona notizia: “E ora abbiamo Agile!”
Oppure, se sei semplicemente interessato a scoprire in quale altro modo puoi costruire strutture di stoccaggio, benvenuto nel taglio!
Cosa significa "flessibilità"?
Innanzitutto definiamo quali proprietà deve avere un sistema per potersi definire “flessibile”.
Separatamente, vale la pena ricordare che le proprietà descritte dovrebbero riguardare specificamente sistema, non a processi il suo sviluppo. Pertanto, se desideri leggere sull'Agile come metodologia di sviluppo, è meglio leggere altri articoli. Ad esempio, proprio lì, su Habré, ci sono molti materiali interessanti (come и E ).
Ciò non significa che il processo di sviluppo e la struttura del data warehouse siano completamente indipendenti. Nel complesso, dovrebbe essere molto più semplice sviluppare un repository Agile per un'architettura agile. Tuttavia, in pratica, più spesso ci sono opzioni con lo sviluppo Agile del classico DWH secondo Kimbal e DataVault - secondo Waterfall, che felici coincidenze di flessibilità nelle sue due forme su un unico progetto.
Quindi, quali funzionalità dovrebbe avere lo storage flessibile? Ci sono tre punti qui:
- Consegna anticipata e tempi rapidi - ciò significa che idealmente il primo risultato aziendale (ad esempio i primi rapporti di lavoro) dovrebbe essere ottenuto il prima possibile, cioè anche prima che l'intero sistema sia completamente progettato e implementato. Inoltre, anche ogni revisione successiva dovrebbe richiedere il minor tempo possibile.
- Affinamento iterativo - ciò significa che ogni miglioramento successivo idealmente non dovrebbe influenzare la funzionalità già funzionante. È questo momento che spesso diventa l'incubo più grande nei progetti di grandi dimensioni: prima o poi i singoli oggetti iniziano ad acquisire così tante connessioni che diventa più facile ripetere completamente la logica in una copia vicina piuttosto che aggiungere un campo a una tabella esistente. E se sei sorpreso dal fatto che l'analisi dell'impatto dei miglioramenti sugli oggetti esistenti possa richiedere più tempo dei miglioramenti stessi, molto probabilmente non hai ancora lavorato con data warehouse di grandi dimensioni nel settore bancario o delle telecomunicazioni.
- Adattarsi costantemente alle mutevoli esigenze aziendali - la struttura complessiva dell'oggetto dovrebbe essere progettata non solo tenendo conto di una possibile espansione, ma con l'aspettativa che la direzione di questa prossima espansione non possa essere nemmeno sognata in fase di progettazione.
E sì, soddisfare tutti questi requisiti in un unico sistema è possibile (ovviamente, in alcuni casi e con alcune riserve).
Di seguito prenderò in considerazione due delle metodologie di progettazione agile più popolari per i data warehouse: Modello di ancoraggio и Archivio dati. Tra parentesi vengono lasciate fuori dalle parentesi tecniche eccellenti come, ad esempio, EAV, 6NF (nella sua forma pura) e tutto ciò che riguarda le soluzioni NoSQL - non perché siano in qualche modo peggiori, e nemmeno perché in questo caso l'articolo minaccerebbe di acquisire il volume del disser medio. È solo che tutto ciò si riferisce a soluzioni di una classe leggermente diversa: o a tecniche che puoi utilizzare in casi specifici, indipendentemente dall'architettura generale del tuo progetto (come EAV), o ad altri paradigmi di archiviazione delle informazioni a livello globale (come i database a grafo e altre opzioni NoSQL).
Problemi dell'approccio “classico” e loro soluzioni in metodologie flessibili
Per approccio “classico” intendo la buona vecchia stella (indipendentemente dall'implementazione specifica degli strati sottostanti, possano perdonarmi i seguaci di Kimball, Inmon e CDM).
1. Cardinalità rigida delle connessioni
Questo modello si basa su una chiara divisione dei dati in Dimensione и fatti. E questo, dannazione, è logico: dopotutto, l'analisi dei dati nella stragrande maggioranza dei casi si riduce all'analisi di determinati indicatori numerici (fatti) in determinate sezioni (dimensioni).
In questo caso, le connessioni tra oggetti vengono stabilite sotto forma di relazioni tra tabelle utilizzando una chiave esterna. Ciò sembra abbastanza naturale, ma porta immediatamente alla prima limitazione della flessibilità: definizione rigorosa della cardinalità delle connessioni.
Ciò significa che in fase di progettazione della tabella è necessario determinare con precisione per ciascuna coppia di oggetti correlati se possono essere correlati come molti a molti o solo 1 a molti e "in quale direzione". Ciò determina direttamente quale tabella avrà la chiave primaria e quale avrà la chiave esterna. Cambiare questo atteggiamento quando si ricevono nuovi requisiti porterà molto probabilmente a una rielaborazione della base.
Ad esempio, durante la progettazione dell'oggetto "scontrino in contanti", tu, affidandoti ai giuramenti del reparto vendite, hai stabilito la possibilità di azione una promozione per diverse posizioni di controllo (ma non viceversa):
E dopo qualche tempo, i colleghi hanno introdotto una nuova strategia di marketing in cui possono agire nella stessa posizione più promozioni contemporaneamente. E ora devi modificare le tabelle separando la relazione in un oggetto separato.
(Anche tutti gli oggetti derivati a cui è unito il controllo di promozione ora devono essere migliorati).
Relazioni nel Data Vault e nel modello di ancoraggio
Evitare questa situazione si è rivelato abbastanza semplice: non devi fidarti del reparto vendite per farlo. tutte le connessioni vengono inizialmente archiviate in tabelle separate ed elaborarlo come molti-a-molti.
Questo approccio è stato proposto Dan Linstedt come parte del paradigma Archivio dati e pienamente supportato Lars Rönnback в Modello di ancoraggio.
Di conseguenza, otteniamo la prima caratteristica distintiva delle metodologie flessibili:
Le relazioni tra gli oggetti non vengono archiviate negli attributi delle entità principali, ma sono un tipo di oggetto separato.
В Archivio dati vengono chiamate tali tabelle di collegamento Link, mentre in Modello di ancoraggio - Tie. A prima vista sono molto simili, anche se le differenze non finiscono con il nome (di cui parleremo più avanti). In entrambe le architetture, le tabelle di collegamento possono collegarsi qualsiasi numero di entità (non necessariamente 2).
Questa ridondanza, a prima vista, offre una notevole flessibilità per le modifiche. Una tale struttura diventa tollerante non solo ai cambiamenti nella cardinalità dei collegamenti esistenti, ma anche all'aggiunta di nuovi - se ora una posizione di assegno ha anche un collegamento al cassiere che l'ha sfondato, l'apparizione di un tale collegamento semplicemente diventare un componente aggiuntivo sulle tabelle esistenti senza influenzare gli oggetti e i processi esistenti.
2. Duplicazione dei dati
Il secondo problema risolto dalle architetture flessibili è meno evidente ed è inerente al primo. Misure di tipo SCD2 (dimensioni che cambiano lentamente del secondo tipo), anche se non solo loro.
In un magazzino classico, una dimensione è in genere una tabella che contiene una chiave surrogata (come PK) e un insieme di chiavi e attributi aziendali in colonne separate.
Se una dimensione supporta il controllo delle versioni, i limiti di validità della versione vengono aggiunti all'insieme standard di campi e diverse versioni vengono visualizzate nel repository per una riga nell'origine (una per ogni modifica negli attributi con versione).
Se una dimensione contiene almeno un attributo con versione che cambia frequentemente, il numero di versioni di tale dimensione sarà impressionante (anche se gli attributi rimanenti non hanno versione o non cambiano mai) e se ci sono diversi attributi di questo tipo, il numero di versioni può crescere esponenzialmente dal loro numero. Questa dimensione può occupare una notevole quantità di spazio su disco, sebbene gran parte dei dati archiviati siano semplicemente duplicati di valori di attributi immutabili di altre righe.
Allo stesso tempo, viene anche utilizzato molto spesso denormalizzazione — alcuni attributi vengono memorizzati intenzionalmente come valore e non come collegamento a un libro di consultazione o a un'altra dimensione. Questo approccio accelera l'accesso ai dati, riducendo il numero di join quando si accede a una dimensione.
In genere questo porta a le stesse informazioni vengono archiviate contemporaneamente in più luoghi. Ad esempio, le informazioni sulla regione di residenza e sulla categoria del cliente possono essere memorizzate contemporaneamente nelle dimensioni “Cliente” e nei fatti “Acquisto”, “Consegna” e “Chiamate al Call Center”, nonché nella dimensione “Cliente - Gestore clienti "tabella dei collegamenti.
In generale, quanto sopra descritto si applica alle dimensioni regolari (senza versione), ma in quelle con versione possono avere una scala diversa: la comparsa di una nuova versione di un oggetto (soprattutto in retrospettiva) porta non solo all'aggiornamento di tutti i relativi tabelle, ma alla comparsa a cascata di nuove versioni di oggetti correlati: quando la Tabella 1 viene utilizzata per creare la Tabella 2 e la Tabella 2 viene utilizzata per creare la Tabella 3, ecc. Anche se non un singolo attributo della Tabella 1 è coinvolto nella costruzione della Tabella 3 (e sono coinvolti altri attributi della Tabella 2 ottenuti da altre fonti), il controllo delle versioni di questa costruzione comporterà come minimo un sovraccarico aggiuntivo e come massimo un extra versioni nella Tabella 3. che non ha nulla a che fare con esso, e più in basso nella catena.
3. Complessità non lineare della rilavorazione
Allo stesso tempo, ogni nuovo negozio costruito sulla base di un altro aumenta il numero di luoghi in cui i dati possono “divergere” quando vengono apportate modifiche all’ETL. Ciò, a sua volta, porta ad un aumento della complessità (e della durata) di ogni successiva revisione.
Se quanto sopra descrive sistemi con processi ETL modificati raramente, puoi vivere in un tale paradigma: devi solo assicurarti che le nuove modifiche vengano apportate correttamente a tutti gli oggetti correlati. Se le revisioni si verificano frequentemente, la probabilità di “perdere” accidentalmente diverse connessioni aumenta notevolmente.
Se, inoltre, teniamo conto del fatto che l’ETL “con versione” è significativamente più complicato di quello “senza versione”, diventa piuttosto difficile evitare errori quando si aggiorna frequentemente l’intera struttura.
Memorizzazione di oggetti e attributi in Data Vault e Anchor Model
L’approccio proposto dagli autori delle architetture flessibili può essere formulato come segue:
È necessario separare ciò che cambia da ciò che rimane uguale. Cioè, memorizza le chiavi separatamente dagli attributi.
Tuttavia, non bisogna confondere non versione attribuire con invariato: il primo non memorizza la cronologia delle sue modifiche, ma può cambiare (ad esempio quando si corregge un errore di input o si ricevono nuovi dati); il secondo non cambia mai.
I punti di vista differiscono su cosa esattamente può essere considerato immutabile nel Data Vault e nell'Anchor Model.
Dal punto di vista architettonico Archivio dati, può ritenersi invariato intero mazzo di chiavi - naturali (TIN dell'organizzazione, codice prodotto nel sistema sorgente, ecc.) e surrogati. In questo caso, gli attributi rimanenti possono essere suddivisi in gruppi in base alla fonte e/o alla frequenza delle modifiche e Mantenere un tavolo separato per ciascun gruppo con un insieme indipendente di versioni.
Nel paradigma Modello di ancoraggio considerato invariato solo chiave surrogata essenza. Tutto il resto (comprese le chiavi naturali) è solo un caso speciale dei suoi attributi. In cui tutti gli attributi sono indipendenti l'uno dall'altro per impostazione predefinita, quindi per ogni attributo a tavolo separato.
В Archivio dati vengono chiamate le tabelle contenenti le chiavi di entità Hubami. Gli hub contengono sempre un insieme fisso di campi:
- Chiavi di entità naturale
- Chiave surrogata
- Collegamento alla fonte
- Registra il tempo aggiunto
Post negli hub non cambiare mai e non avere versioni. Esternamente, gli hub sono molto simili alle tabelle di tipo ID-map utilizzate in alcuni sistemi per generare surrogati, tuttavia, si consiglia di utilizzare un hash da un set di chiavi aziendali come surrogati in Data Vault. Questo approccio semplifica il caricamento di relazioni e attributi dalle sorgenti (non è necessario unirsi all'hub per ottenere un surrogato, basta calcolare l'hash di una chiave naturale), ma può causare altri problemi (legati, ad esempio, a collisioni, maiuscole e minuscole e non stampabili caratteri nelle chiavi di stringa, ecc. .p.), quindi non è generalmente accettato.
Tutti gli altri attributi dell'entità sono memorizzati in tabelle speciali chiamate Satelliti. Un hub può avere diversi satelliti che memorizzano diversi set di attributi.
La distribuzione degli attributi tra i satelliti avviene secondo il principio cambiamento congiunto — in un satellite è possibile memorizzare attributi senza versione (ad esempio, data di nascita e SNILS per un individuo), in un altro - quelli con versione che cambiano raramente (ad esempio, cognome e numero di passaporto), nel terzo - quelli che cambiano frequentemente (ad esempio, indirizzo di consegna, categoria, data dell'ultimo ordine, ecc.). In questo caso, il controllo delle versioni viene effettuato a livello dei singoli satelliti e non dell'entità nel suo insieme, quindi è consigliabile distribuire gli attributi in modo che l'intersezione delle versioni all'interno di un satellite sia minima (il che riduce il numero totale di versioni archiviate ).
Inoltre, per ottimizzare il processo di caricamento dei dati, gli attributi ottenuti da varie fonti vengono spesso inclusi nei singoli satelliti.
I satelliti comunicano con l'Hub tramite chiave esterna (che corrisponde alla cardinalità 1-a-molti). Ciò significa che più valori di attributo (ad esempio, più numeri di telefono di contatto per un cliente) sono supportati da questa architettura "predefinita".
В Modello di ancoraggio vengono chiamate le tabelle che memorizzano le chiavi Ancore. E continuano:
- Solo chiavi surrogate
- Collegamento alla fonte
- Registra il tempo aggiunto
Vengono considerate le chiavi naturali dal punto di vista dell'Anchor Model attributi ordinari. Questa opzione può sembrare più difficile da comprendere, ma offre molto più spazio per identificare l'oggetto.
Ad esempio, se i dati sulla stessa entità possono provenire da sistemi diversi, ognuno dei quali utilizza la propria chiave naturale. In Data Vault, ciò può portare a strutture piuttosto ingombranti di diversi hub (uno per sorgente + una versione master unificante), mentre nel modello Anchor, la chiave naturale di ciascuna sorgente rientra nel proprio attributo e può essere utilizzata durante il caricamento indipendentemente da tutti gli altri.
Ma qui c'è anche un punto insidioso: se si combinano attributi di sistemi diversi in un'unica entità, molto probabilmente ce ne sono alcuni regole dell’“incollare”, in base al quale il sistema deve comprendere che i record provenienti da fonti diverse corrispondono a un'istanza dell'entità.
В Archivio dati queste regole molto probabilmente determineranno la formazione “hub surrogato” dell’entità master e non influenzare in alcun modo gli Hub che memorizzano le chiavi sorgente naturali e i loro attributi originali. Se ad un certo punto le regole di fusione cambiano (o gli attributi con cui viene eseguita vengono aggiornati), sarà sufficiente riformattare gli hub surrogati.
В Modello di ancoraggio molto probabilmente tale entità verrà archiviata l'unica ancora. Ciò significa che tutti gli attributi, indipendentemente dalla fonte da cui provengono, saranno legati allo stesso surrogato. Separare record erroneamente uniti e, in generale, monitorare la rilevanza della fusione in un tale sistema può essere molto più difficile, soprattutto se le regole sono piuttosto complesse e cambiano frequentemente, e lo stesso attributo può essere ottenuto da fonti diverse (anche se è certamente possibile, poiché ciascuna versione dell'attributo conserva un collegamento alla propria fonte).
In ogni caso, se si suppone che il tuo sistema implementi la funzionalità deduplicazione, unione di record e altri elementi MDM, vale la pena prestare particolare attenzione agli aspetti relativi alla memorizzazione delle chiavi naturali nelle metodologie agili. È probabile che il design più ingombrante di Data Vault diventi improvvisamente più sicuro in termini di errori di unione.
Modello di ancoraggio fornisce anche un tipo di oggetto aggiuntivo chiamato Nodo è essenzialmente speciale tipo di ancoraggio degenerato, che può contenere un solo attributo. I nodi dovrebbero essere utilizzati per archiviare directory flat (ad esempio sesso, stato civile, categoria del servizio clienti, ecc.). A differenza dell'Ancora, il Nodo non ha tabelle di attributi associatee il suo unico attributo (nome) è sempre archiviato nella stessa tabella con la chiave. I Nodi sono collegati alle Ancore tramite tabelle di collegamento (Tie) nello stesso modo in cui le Ancore sono collegate tra loro.
Non esiste un'opinione chiara sull'uso dei Nodes. Per esempio, , che promuove attivamente l'uso del modello di ancoraggio in Russia, ritiene (non irragionevolmente) che per nessun libro di consultazione si possa affermare con certezza che esso sempre sarà statico e a livello singolo, quindi è meglio utilizzare immediatamente un'ancora a tutti gli effetti per tutti gli oggetti.
Un'altra importante differenza tra Data Vault e il modello Anchor è la disponibilità attributi delle connessioni:
В Archivio dati I collegamenti sono gli stessi oggetti a tutti gli effetti degli hub e possono avere propri attributi. In Modello di ancoraggio I collegamenti vengono utilizzati solo per collegare ancore e non possono avere attributi propri. Questa differenza si traduce in approcci di modellazione significativamente diversi di fatti, di cui si parlerà più avanti.
Archiviazione dei fatti
Prima di questo abbiamo parlato principalmente di modelli di misurazione. I fatti sono un po’ meno chiari.
В Archivio dati un oggetto tipico per archiviare i fatti è Collegamento, nei cui satelliti vengono aggiunti indicatori reali.
Questo approccio sembra intuitivo. Fornisce un facile accesso agli indicatori analizzati ed è generalmente simile a una tabella dei fatti tradizionale (solo gli indicatori non sono memorizzati nella tabella stessa, ma nella tabella “vicina”). Ma ci sono anche delle insidie: è necessaria una delle modifiche tipiche del modello, l'ampliamento della chiave di fatto aggiungendo una nuova chiave esterna a Link. E questo, a sua volta, “rompe” la modularità e potenzialmente comporta la necessità di modifiche ad altri oggetti.
В Modello di ancoraggio Una connessione non può avere i propri attributi, quindi questo approccio non funzionerà: assolutamente tutti gli attributi e gli indicatori devono essere collegati a un'ancora specifica. La conclusione da ciò è semplice: Ogni fatto ha bisogno anche della propria ancora. Per alcuni di ciò che siamo abituati a percepire come fatti, ciò può sembrare naturale: ad esempio, il fatto di un acquisto può essere perfettamente ridotto all'oggetto "ordine" o "ricevuta", la visita di un sito a una sessione, ecc. Ma ci sono anche fatti per i quali non è così facile trovare un "oggetto vettore" così naturale, ad esempio i resti di merci nei magazzini all'inizio di ogni giornata.
Di conseguenza, non sorgono problemi di modularità quando si espande una chiave di fatto nel modello di Ancoraggio (è sufficiente aggiungere semplicemente una nuova Relazione all'Ancora corrispondente), ma progettare un modello per visualizzare i fatti è meno univoco; possono apparire Ancore "artificiali" che visualizzano il modello a oggetti di business in modo poco chiaro.
Come si ottiene la flessibilità
La costruzione risultante in entrambi i casi contiene molti più tavolirispetto alla misurazione tradizionale. Ma potrebbe essere necessario molto meno spazio su disco con lo stesso insieme di attributi con versione della dimensione tradizionale. Naturalmente, qui non c’è magia: è tutta una questione di normalizzazione. Distribuendo gli attributi sui satelliti (nel Data Vault) o sulle singole tabelle (modello di ancoraggio), riduciamo (o eliminiamo completamente) duplicazione dei valori di alcuni attributi quando si modificano altri.
per Archivio dati le vincite dipenderanno dalla distribuzione degli attributi tra i Satelliti, e per Modello di ancoraggio — è quasi direttamente proporzionale al numero medio di versioni per oggetto di misurazione.
Tuttavia, il risparmio di spazio è un vantaggio importante, ma non il principale, derivante dall'archiviazione separata degli attributi. Insieme all'archiviazione separata delle relazioni, questo approccio crea il negozio design modulare. Ciò significa che l'aggiunta sia di attributi individuali che di intere nuove aree tematiche in un modello di questo tipo assomiglia sovrastruttura su un insieme esistente di oggetti senza modificarli. Ed è proprio questo che rende flessibili le metodologie descritte.
Ciò ricorda anche il passaggio dalla produzione su pezzo alla produzione di massa: se nell'approccio tradizionale ogni tabella del modello è unica e richiede un'attenzione speciale, nelle metodologie flessibili è già un insieme di “parti” standard. Da un lato ci sono più tabelle e i processi di caricamento e recupero dei dati dovrebbero sembrare più complicati. D'altra parte, lo diventano tipico. Il che significa che potrebbe esserci automatizzato e basato sui metadati. La domanda “come la porremo?”, la cui risposta potrebbe richiedere una parte significativa del lavoro sulla progettazione dei miglioramenti, ora semplicemente non vale la pena (così come la domanda sull’impatto del cambiamento del modello sui processi di lavoro ).
Ciò non significa che gli analisti non siano affatto necessari in un sistema del genere: qualcuno deve ancora lavorare sull'insieme di oggetti con attributi e capire dove e come caricarli tutti. Ma la quantità di lavoro, così come la probabilità e il costo di un errore, vengono notevolmente ridotti. Sia in fase di analisi che durante lo sviluppo di ETL, che in gran parte può ridursi alla modifica dei metadati.
Lato oscuro
Tutto ciò rende entrambi gli approcci veramente flessibili, tecnologicamente avanzati e adatti al miglioramento iterativo. Naturalmente, c'è anche un "barile nell'unguento", che penso tu possa già intuire.
La scomposizione dei dati, che è alla base della modularità delle architetture flessibili, porta ad un aumento del numero di tabelle e, di conseguenza, sopraelevato ai join durante il campionamento. Per ottenere semplicemente tutti gli attributi di una dimensione, in un negozio classico è sufficiente una selezione, ma un'architettura flessibile richiederà tutta una serie di unioni. Inoltre, se tutti questi join per i report possono essere scritti in anticipo, gli analisti abituati a scrivere SQL manualmente ne soffriranno doppiamente.
Ci sono diversi fatti che facilitano questa situazione:
Quando si lavora con grandi dimensioni, tutti i suoi attributi non vengono quasi mai utilizzati contemporaneamente. Ciò significa che potrebbero esserci meno join di quanto sembri a prima vista nel modello. Data Vault può anche tenere conto della frequenza prevista di condivisione durante l'assegnazione degli attributi ai satelliti. Allo stesso tempo, gli stessi Hub o Ancore sono necessari principalmente per generare e mappare surrogati nella fase di caricamento e sono usati raramente nelle query (questo è particolarmente vero per le Ancore).
Tutti i join sono tramite chiave. Inoltre, un modo più “compresso” di archiviare i dati riduce il sovraccarico della scansione delle tabelle laddove necessario (ad esempio, quando si filtra in base al valore dell'attributo). Ciò può portare al fatto che il campionamento da un database normalizzato con una serie di join sarà ancora più veloce della scansione di una dimensione pesante con molte versioni per riga.
Ad esempio, qui dentro L'articolo contiene un test comparativo dettagliato delle prestazioni del modello Anchor con un campione tratto da una tabella.
Molto dipende dal motore. Molte piattaforme moderne dispongono di meccanismi di ottimizzazione dei join interni. Ad esempio, MS SQL e Oracle possono "saltare" i join alle tabelle se i loro dati non vengono utilizzati ovunque tranne che per altri join e non influiscono sulla selezione finale (eliminazione di tabelle/join) e MPP Vertica , si è rivelato un motore eccellente per il modello di ancoraggio, data l'ottimizzazione manuale del piano di query. D’altro canto, memorizzare l’Anchor Model, ad esempio, su Click House, che ha un supporto limitato per i join, non sembra ancora una buona idea.
Inoltre, per entrambe le architetture esistono mosse speciali, semplificando l'accesso ai dati (sia dal punto di vista delle prestazioni delle query che per gli utenti finali). Per esempio, Tabelle point-in-time nell'archivio dati o funzioni speciali della tabella nel modello dell'ancora.
In totale
L'essenza principale delle architetture flessibili considerate è la modularità del loro “design”.
È questa proprietà che permette:
- Dopo una preparazione iniziale relativa alla distribuzione dei metadati e alla scrittura di algoritmi ETL di base, fornire rapidamente al cliente il primo risultato sotto forma di una coppia di report contenenti dati provenienti da pochi oggetti sorgente. Non è necessario riflettere completamente (anche al livello più alto) sull'intero modello a oggetti.
- Un modello di dati può iniziare a funzionare (ed essere utile) con solo 2-3 oggetti, e poi crescere gradualmente (riguardo al modello Anchor Nikolai bel paragone con il micelio).
- La maggior parte dei miglioramenti, inclusa l'espansione dell'area tematica e l'aggiunta di nuove fonti non influisce sulle funzionalità esistenti e non comporta il rischio di rompere qualcosa che già funziona.
- Grazie alla scomposizione in elementi standard, i processi ETL in tali sistemi sembrano uguali, la loro scrittura si presta all'algoritmo e, in definitiva, automazione.
Il prezzo di questa flessibilità è производительность. Ciò non significa che sia impossibile ottenere prestazioni accettabili su tali modelli. Nella maggior parte dei casi, potresti semplicemente aver bisogno di più impegno e attenzione ai dettagli per raggiungere le metriche desiderate.
Apps
Tipi di entità Archivio dati
Ulteriori informazioni su Data Vault:
Tipi di entità Modello di ancoraggio
Maggiori dettagli sul modello di ancoraggio:
Tabella riassuntiva con caratteristiche comuni e differenze degli approcci considerati:
Fonte: habr.com