🥇Panoramica delle metodologie flessibili di progettazione DWH

Lo sviluppo di un data warehouse è un compito lungo e serio.

Molto nella vita del progetto dipende da quanto bene è stata pensata la modelizzazione degli oggetti e la struttura del database fin dall'inizio.

Un approccio consolidato è rappresentato dalle varie combinazioni dello schema a 'stelle' con la terza forma normale. Di solito, seguendo il principio: dati sorgente — 3NF, data mart — stelle. Questo approccio, collaudato nel tempo e supportato da un gran numero di ricerche, è il primo (e a volte l'unico) pensiero che viene in mente a un esperto di DWH quando si considera come dovrebbe apparire un data warehouse analitico.

D'altra parte, le esigenze dell'azienda in generale e del cliente in particolare tendono a cambiare rapidamente, così come i dati possono crescere sia 'in profondità' che 'in larghezza'. E qui si manifesta il principale svantaggio della stella — la sua limitata flessibilità.

E se improvvisamente nella vostra vita tranquilla e confortevole di sviluppatore di DWH:

si presenta la necessità di 'fare rapidamente qualcosa, poi vedremo';
compare un progetto in rapida crescita, con l'integrazione di nuove fonti e la modifica del modello di business almeno una volta a settimana;
si presenta un cliente che non ha idea di come deve apparire il sistema e quali funzioni deve svolgere alla fine, ma è aperto agli esperimenti e all'affinamento graduale del risultato desiderato avvicinandosi progressivamente ad esso;
un manager di progetto fa capolino con la lieta notizia: 'E ora abbiamo Agile!'.

Oppure, se siete semplicemente curiosi di scoprire come si possono costruire i data warehouse — benvenuti qui sotto!

Cosa significa "flessibilità"

Per prima cosa, definiamo quali caratteristiche deve avere un sistema per poter essere definito 'flessibile'.

È importante sottolineare che le proprietà descritte devono riferirsi precisamente a sistema, e non a il processo di sviluppo. Pertanto, se desideravate leggere di Agile come metodologia di sviluppo, è meglio consultare altri articoli. Ad esempio, qui su Habr, ci sono molti materiali interessanti (come articoli di revisione e pratici, sia problemi).

Ciò non significa che il processo di sviluppo e la struttura del data warehouse siano completamente slegati. In generale, sviluppare un repository di architettura flessibile seguendo il metodo Agile dovrebbe essere significativamente più facile. Tuttavia, nella pratica, si incontrano più spesso varianti in cui si utilizza il metodo Agile per un DWH classico secondo Kimball e Data Vault usando il waterfall, piuttosto che felici coincidenze di flessibilità in entrambe le sue forme nello stesso progetto.

Quindi, quali devono essere le capacità di un data warehouse flessibile? Qui possiamo evidenziare tre punti:

Consegna anticipata e rapidi sviluppi — ciò significa che, in ideale, il primo risultato commerciale (ad esempio, i primi report funzionanti) dovrebbe essere ottenuto il prima possibile, prima che l'intero sistema sia progettato e implementato completamente. Ogni successivo sviluppo dovrebbe richiedere il minor tempo possibile.
Sviluppo iterativo — ciò significa che ogni sviluppo successivo in ideale non dovrebbe influenzare le funzionalità già attive. Questo elemento diventa spesso il maggiore incubo nei progetti di grandi dimensioni: prima o poi, singoli oggetti iniziano ad accumulare così tante relazioni che diventa più semplice replicare completamente la logica in una copia accanto, piuttosto che aggiungere un campo a una tabella esistente. E se ti sorprende che l'analisi dell'impatto dello sviluppo sugli oggetti esistenti possa richiedere più tempo dello sviluppo stesso, probabilmente non hai ancora lavorato con grandi DWH nel settore bancario o delle telecomunicazioni.
Costante adattamento ai requisiti aziendali in evoluzione — la struttura oggettuale generale deve essere progettata non solo tenendo conto di possibili ampliamenti, ma calcolando che il nuovo indirizzo di ampliamento potrebbe non esserti nemmeno venuto in mente durante la fase di progettazione.

E sì, corrispondere a tutti questi requisiti in un unico sistema è possibile (naturalmente, in determinati casi e con alcune riserve).

Di seguito esaminerò due delle metodologie di progettazione flessibile più popolari per i DWH — Anchor model e Data Vault. Tra parentesi rimangono ottimi approcci, come ad esempio EAV, 6NF (nella sua forma pura) e tutto ciò che riguarda le soluzioni NoSQL - non perché siano inferiori, e nemmeno perché in questo caso l'articolo rischierebbe di acquisire il volume di una tesi media. Semplicemente, tutto ciò appartiene a soluzioni di un altro tipo - o a metodi che potete applicare in casi specifici, indipendentemente dall'architettura generale del vostro progetto (come EAV), oppure a paradigmi completamente diversi di archiviazione delle informazioni (come, ad esempio, i database a grafo e altre varianti NoSQL).

Problemi del metodo “classico” e le loro soluzioni nelle metodologie agili

Per “approccio classico” intendo la vecchia cara stella (indipendentemente dall'implementazione specifica dei livelli sottostanti, perdonatemi adepti di Kimball, Inmon e CDM).

1. Rigidità della cardinalità dei legami

Alla base di questo modello c'è una chiara suddivisione dei dati in dimensioni (Dimensione) e fatti (Fatto). E questo, accidenti, ha senso - poiché l'analisi dei dati, nella stragrande maggioranza dei casi, si riduce proprio all'analisi di specifici indicatori numerici (fatti) in specifici contesti (dimensioni).

In questo caso, i legami tra gli oggetti sono stabiliti sotto forma di relazioni tra tabelle tramite chiavi esterne. Questo appare del tutto naturale, ma porta immediatamente al primo limite di flessibilità - rigida definizione della cardinalità dei legami.

Ciò significa che nella fase di progettazione delle tabelle dovete definire con precisione per ogni coppia di oggetti correlati se possono avere una relazione di molti a molti, oppure solo 1 a molti, e “in quale direzione”. Questo influisce direttamente su quale tabella avrà la chiave primaria e quale avrà la chiave esterna. La modifica di questa relazione in seguito all'ottenimento di nuove esigenze porterà con alta probabilità a un ripensamento del database.

Ad esempio, progettando l'oggetto “scontrino fiscale”, basandovi sulle solenni promesse del reparto vendite, avete previsto la possibilità che una promozione possa agire su più voci di scontrino (ma non viceversa):

E dopo un po', i colleghi hanno introdotto una nuova strategia di marketing, in cui più promozioni possono agire contemporaneamente su la stessa voce. E ora dovete rielaborare le tabelle, estraendo il legame in un oggetto separato.

(Tutti gli oggetti derivati in cui avviene il join di un controllo promozionale ora necessitano di modifiche).

Collegamenti in Data Vault e Anchor Model

Evitare tale situazione si è rivelato piuttosto semplice: non bisogna fidarsi del reparto vendite. Baste memorizzare tutti i collegamenti in tabelle separate e gestirli come molti-a-molti.

Questo approccio è stato proposto da Dan Linstedt come parte della paradigmi Data Vault ed è completamente supportato da Lars Rönnbäck in Anchor Model.

Alla fine otteniamo la prima caratteristica distintiva delle metodologie flessibili:

I collegamenti tra gli oggetti non sono memorizzati negli attributi delle entità genitore, ma rappresentano un tipo di oggetto separato.

In Data Vault Tali tabelle di associazione sono chiamate Link, e in Anchor Model — Tie. A prima vista sembrano molto simili, anche se le loro differenze non si esauriscono nel nome (di cui si discuterà più avanti). In entrambe le architetture, le tabelle di associazione possono collegare un numero qualsiasi di entità (non necessariamente 2).

Questa apparente ridondanza offre una notevole flessibilità nelle modifiche. Questa struttura diventa tollerante non solo ai cambiamenti nelle cardinalità delle relazioni esistenti, ma anche all'aggiunta di nuove: se ora a una voce di controllo viene aggiunto anche un riferimento al cassiere che l'ha registrata, la creazione di tale collegamento diventa semplicemente un'estensione delle tabelle esistenti senza influenzare alcun oggetto o processo già esistente.

2. Duplicazione dei dati

Il secondo problema affrontato dalle architetture flessibili è meno ovvio e caratteristico, in primo luogo per dimensioni di tipo SCD2 (slowly changing dimensions di secondo tipo), anche se non solo per esse.

In un classico data warehouse, una dimensione di solito è rappresentata da una tabella che contiene una chiave surrogata (come PK) oltre a un insieme di chiavi aziendali e attributi in colonne separate.

Se la dimensione supporta la versione, al set standard di campi vengono aggiunti i limiti di tempo di validità della versione, e per ogni riga nella fonte ci sono più versioni nel magazzino (una per ogni modifica degli attributi di versione).

Se la misura contiene almeno un attributo versionato soggetto a frequenti modifiche, il numero di versioni di tale misura sarà considerevole (anche se gli altri attributi non sono versionati o non cambiano mai) e, se ci sono più di tali attributi, il numero di versioni può crescere in modo esponenziale in base al loro numero. Tale misura può occupare una notevole quantità di spazio su disco, anche se la maggior parte dei dati memorizzati in essa cos'è semplicemente duplicati dei valori degli attributi immutabili di altre righe.

Inoltre, molto spesso viene applicata anche la denormalizzazione — parte degli attributi viene intenzionalmente memorizzata come valore, piuttosto che come riferimento a una tabella di consultazione o un'altra misura. Questo approccio accelera l'accesso ai dati, riducendo il numero di join quando si accede alla misura.

Di norma, ciò porta al fatto che la stessa informazione è memorizzata contemporaneamente in più luoghi. Ad esempio, le informazioni sulla regione di residenza e sull'appartenenza alla categoria del cliente possono essere memorizzate contemporaneamente nelle misure “Cliente”, e nei fatti “Acquisto”, “Consegna” e “Richieste al call center”, così come nella tabella di collegamento “Cliente — Manager del cliente”.

In generale, quanto descritto sopra si applica anche alle misure normali (non versionate), ma nelle versionate può avere un'altra portata: l'emergere di una nuova versione dell'oggetto (specialmente retroattivamente) non porta solo all'aggiornamento di tutte le tabelle correlate, ma a un'emergenza a cascata di nuove versioni degli oggetti correlati — quando la Tabella 1 è utilizzata per costruire la Tabella 2, e la Tabella 2 per costruire la Tabella 3, e così via. Anche se nessun attributo della Tabella 1 partecipa alla costruzione della Tabella 3 (e partecipano altri attributi della Tabella 2, ottenuti da altre fonti), l'aggiornamento versionato di questa struttura porterà almeno a costi aggiuntivi, e al massimo — a versioni superflue nella Tabella 3, che qui è completamente “estranea” e così via a catena.

3. Complessità non lineare dello sviluppo

In questo caso, ogni nuova vetrina costruita sulla base di un'altra aumenta il numero di luoghi in cui i dati possono “dispersarsi” quando vengono apportate modifiche all'ETL. Questo, a sua volta, porta a un aumento della complessità (e della durata) di ogni successivo sviluppo.

Se quanto descritto sopra riguarda sistemi con processi ETL raramente aggiornati, si può vivere in tale paradigma: è sufficiente prestare attenzione affinché i nuovi aggiornamenti siano correttamente integrati in tutti gli oggetti correlati. Se tuttavia gli aggiornamenti avvengono frequentemente, la probabilità di “trascurare” casualmente alcune relazioni aumenta notevolmente.

Se si considera inoltre che un ETL “versionato” è sostanzialmente più complesso di un ETL “non versionato”, diventa abbastanza difficile evitare errori durante frequenti aggiornamenti di tutto questo sistema.

Archiviazione di oggetti e attributi in Data Vault e Anchor Model

L'approccio proposto dagli autori di architetture flessibili può essere formulato come segue:

È necessario separare ciò che cambia da ciò che rimane invariato. Vale a dire, conservare le chiavi separatamente dagli attributi.

A questo proposito, non bisogna confondere non versionato l'attributo con immutabile: il primo non conserva la storia della sua modifica, ma può cambiare (ad esempio, a seguito di correzioni di errori di input o ricezione di nuovi dati), il secondo — non cambia mai.

Le opinioni su cosa possa essere considerato immutabile nel Data Vault e nel Modello Anchor sono divergenti.

Dal punto di vista architettonico Data Vault, si può considerare immutabile l'intero insieme di chiavi — naturali (codice fiscale dell'organizzazione, codice del prodotto nel sistema sorgente, ecc.) e surrogate. A questo punto, gli altri attributi possono essere suddivisi in gruppi per fonte e/o frequenza di cambiamenti e per ciascun gruppo mantenere una tabella separata con un insieme indipendente di versioni.

Nel paradigma del Modello Anchor si considera immutabile solo la chiave surrogata dell'entità. Tutto il resto (compresi i chiavi naturali) è semplicemente un caso particolare dei suoi attributi. In questo modo tutti gli attributi sono per default indipendenti tra loro, pertanto per ogni attributo deve essere creata una tabella separata..

In Data Vault Le tabelle contenenti le chiavi delle entità sono chiamate Hub.Gli Hub contengono sempre un insieme fisso di campi:

Chiavi naturali dell'entità
Chiave surrogata
Riferimento alla fonte
Data di aggiunta della registrazione

Le registrazioni negli Hub non vengono mai modificate e non hanno versioni.. Esternamente, gli hub assomigliano molto alle tabelle di tipo ID-map, usate in alcuni sistemi per la generazione di surrogate, ma come surrogate nel Data Vault si consiglia di utilizzare non una sequenza intera, ma un hash dell'insieme di chiavi aziendali. Questo approccio semplifica il caricamento delle relazioni e degli attributi dalle fonti (non è necessario effettuare join sull'hub per ottenere il surrogate, è sufficiente calcolare l'hash dalla chiave naturale), ma può creare altri problemi (relativi, ad esempio, a collisioni, maiuscole e caratteri non stampabili nelle chiavi stringa, ecc.), quindi non è universalmente accettato.

Tutti gli altri attributi delle entità sono memorizzati in tabelle speciali chiamate Satellite (Satellit). Un hub può avere diversi satelliti che memorizzano set di attributi differenti.

La distribuzione degli attributi nei satelliti avviene secondo il principio di modifica congiunta — in un satellite possono essere memorizzati attributi non versionati (ad esempio, la data di nascita e il codice fiscale per le persone fisiche), in un altro attributi versionati a cambiamento raro (ad esempio, il cognome e il numero di passaporto), in un terzo attributi soggetti a frequenti modifiche (ad esempio, indirizzo di consegna, categoria, data dell'ultimo ordine, ecc.). La versionabilità è gestita a livello di singoli satelliti, e non dell'entità nel complesso, quindi è opportuno distribuire gli attributi in modo da minimizzare l'intersezione delle versioni all'interno di un singolo satellite (ciò riduce il numero totale di versioni memorizzate).

Inoltre, per ottimizzare il processo di caricamento dei dati, in satelliti separati vengono spesso spostati attributi provenienti da diverse fonti.

I satelliti sono collegati all'HUB tramite chiavi esterne (il che corrisponde a una cardinalità 1-a-molti). Ciò significa che molteplici valori di attributi (ad esempio, diversi numeri di telefono di contatto per un singolo cliente) sono supportati da questa architettura “per impostazione predefinita”.

In Modello Ancorato (Anchor Model) le tabelle che memorizzano le chiavi sono chiamate Anchor (Ancoraggi). E memorizzano:

Solo chiavi surrogate
Riferimento alla fonte
Data di aggiunta della registrazione

Le chiavi naturali, dal punto di vista del Modello Ancorato, sono considerate attributi normali. Questa opzione può sembrare più complessa da comprendere, ma consente una maggiore libertà nell'identificazione dell'oggetto.

Ad esempio, se i dati su una stessa entità possono provenire da sistemi diversi, ognuno dei quali utilizza la propria chiave naturale. Nel Data Vault questo può portare a strutture piuttosto ingombranti formate da più hub (uno per sorgente + una versione master consolidante), mentre nel modello Ancorato la chiave naturale di ciascuna sorgente viene inserita nel proprio attributo e può essere utilizzata al momento del caricamento indipendentemente dagli altri.

Ma qui si nasconde un aspetto insidioso: se in un'entità vengono combinati attributi di sistemi diversi, probabilmente esistono alcune regole di “fusione”, secondo le quali il sistema deve comprendere che le registrazioni provenienti da diverse fonti corrispondono a un'istanza unica dell'entità.

In Data Vault Queste regole probabilmente determineranno la formazione di un “hub surrogato” per l'entità master e non influiranno sugli Hub, che conservano le chiavi naturali delle sorgenti e i loro attributi originali. Se in qualche momento le regole di fusione cambiano (o viene ricevuto un aggiornamento degli attributi su cui essa si basa), basterà riformare gli hub surrogati.

In Nel modello Ancorato tale entità sarà probabilmente conservata in un'unica ancora. Questo significa che tutti gli attributi, indipendentemente dalla fonte da cui provengono, saranno legati a un unico surrogato. Separare registrazioni erroneamente unite e monitorare l'attualità della fusione in un tale sistema può risultare notevolmente più difficile, specialmente se le regole sono piuttosto complesse e cambiano frequentemente, e lo stesso attributo può essere ottenuto da fonti diverse (anche se è certamente possibile, poiché ogni versione dell'attributo conserva un riferimento alla propria fonte).

In ogni caso, se nel vostro sistema è prevista l'implementazione della funzionalità di deduplicazione, fusione di registrazioni e altri elementi MDM, è consigliabile prestare particolare attenzione agli aspetti di conservazione delle chiavi naturali nelle metodologie flessibili. È probabile che la struttura più complessa del Data Vault si riveli improvvisamente più sicura dal punto di vista degli errori di fusione.

Il modello Ancorato prevede anche un ulteriore tipo di oggetto, chiamato Nodo (Knot) , che è essenzialmente un tipo degenerato di ancora, che può contenere solo un attributo. I nodi sono previsti per la memorizzazione di dizionari piatti (come sesso, stato civile, categoria di servizio clienti, ecc.). A differenza dell'Ancora, il Nodo non ha tabelle di attributi collegate, e il suo unico attributo (nome) è sempre memorizzato in una tabella con la chiave. I nodi si collegano agli Ancoraggi tramite tabelle di collegamento (Tie) allo stesso modo in cui gli ancoraggi si collegano tra loro.

Non c'è un'opinione univoca sull'uso dei Nodi. Ad esempio, Nikolai Golov, che promuove attivamente l'uso del modello ad Ancoraggio in Russia, ritiene (non senza fondamento) che per nessun dizionario si possa affermare con certezza che esso sempre sarà statico e unilivello, quindi per tutti gli oggetti è meglio utilizzare subito un Ancoraggio completo.

Un'altra importante differenza tra Data Vault e il modello ad Ancoraggio risiede nella presenza di attributi nelle relazioni:

In Data Vault Le relazioni sono oggetti completi, proprio come gli Hub, e possono avere attributi propri. In Nel modello Ancorato Le relazioni sono utilizzate solo per collegare gli Ancoraggi e non possono avere attributi propri. Questa differenza porta a approcci sostanzialmente diversi nella modellazione dei fatti, di cui si parlerà successivamente.

Memorizzazione dei fatti

Fino a questo punto abbiamo parlato principalmente della modellazione delle misure. Per quanto riguarda i fatti, la situazione è leggermente meno chiara.

In Data Vault Un oggetto tipico per la memorizzazione dei fatti è Collegamento (Link), nei Satelliti dei quali vengono memorizzati i dati reali.

Questo approccio sembra intuitivamente comprensibile. Fornisce un accesso semplice ai dati analizzati e in generale assomiglia a una tradizionale tabella dei fatti (solo che i dati non sono memorizzati nella tabella stessa, ma in una "vicina"). Ma ci sono anche insidie: una delle modifiche standard al modello — l'estensione della chiave del fatto — comporta la necessità di aggiungere una nuova chiave esterna nel Link. E questo, a sua volta, "rompe" la modularità e potenzialmente richiede modifiche ad altri oggetti.

In Nel modello Ancorato Il Collegamento non può avere attributi propri, quindi questo approccio non funzionerà: tutti gli attributi e i dati devono essere legati a un'unica Ancora concreta. La conclusione è semplice — per ogni fatto è necessaria anche la propria Ancora.. Per una parte di ciò che siamo abituati a considerare come fatti, questo può sembrare naturale: ad esempio, il fatto di un acquisto si riduce bene a un oggetto "ordine" o "scontrino", la visita di un sito web a una sessione, e così via. Ma ci sono anche fatti per i quali non è così semplice trovare un "oggetto-portante" naturale, come ad esempio le rimanenze di merci nei magazzini all'inizio di ogni giorno.

Di conseguenza, non ci sono problemi di modularità nell'espandere la chiave del fatto nel modello Anchor (è sufficiente aggiungere una nuova Relazione all'Anchor corrispondente), ma la progettazione del modello per rappresentare i fatti è meno chiara, possono apparire "Anchor" "artificiali" che rappresentano il modello aziendale in modo poco evidente.

Come si raggiunge la flessibilità

La struttura risultante in entrambi i casi contiene notevolmente più tabelle, rispetto a una misura tradizionale. Ma può occupare notevolmente meno spazio su disco con lo stesso insieme di attributi di versione, esattamente come la misura tradizionale. Non c'è magia qui, ovviamente — è tutta questione di normalizzazione. Distribuendo gli attributi tra i Satelliti (in Data Vault) o tabelle separate (Anchor Model), riduciamo (o escludiamo completamente) la duplicazione dei valori di alcuni attributi quando si modificano altri.

Per Data Vault il guadagno dipenderà dalla distribuzione degli attributi tra i Satelliti, e per Nel modello Ancorato — è praticamente direttamente proporzionale al numero medio di versioni per oggetto di misura.

Tuttavia, il guadagno in termini di spazio occupato è un vantaggio importante, ma non il principale, del deposito separato degli attributi. Insieme al deposito separato delle relazioni, questo approccio rende il deposito una costruzione modulare. Questo significa che l'aggiunta di attributi separati o addirittura di nuove aree tematiche in un modello simile sembra una sovrastruttura sul set esistente di oggetti senza modificarli. Ed è proprio questo che rende flessibili le metodologie descritte.

Ricorda anche il passaggio dalla produzione unitario a quella di massa — se nell'approccio tradizionale ogni tabella del modello è unica e richiede attenzione separata, nelle metodologie flessibili esse diventano un insieme di "componenti" standard. Da un lato, il numero di tabelle aumenta, i processi di caricamento e recupero dei dati devono sembrare più complessi. D'altra parte, diventano standardizzati. E ciò significa che possono essere automatizzati e gestiti dai metadati. La domanda “come procederemo con la pianificazione?”, la cui risposta poteva occupare una parte significativa del lavoro di progettazione delle modifiche, ora semplicemente non si pone (così come la domanda sull'impatto del cambiamento del modello sui processi esistenti).

Questo non significa che gli analisti non siano affatto necessari in un sistema del genere: qualcuno deve comunque lavorare su un insieme di oggetti con attributi e capire da dove e come caricarli. Ma il volume di lavoro, così come la probabilità e il costo di errore, diminuiscono significativamente. Sia nella fase di analisi che nello sviluppo dell'ETL, che in buona parte può essere ridotto all'editing dei metadati.

Lato oscuro

Tutto quanto detto sopra rende entrambi gli approcci davvero flessibili, tecnologici e adatti per modifiche iterative. Naturalmente, c'è anche un 'barile di pece' di cui, credo, avete già un'idea.

La decomposizione dei dati, che sta alla base della modularità delle architetture flessibili, porta a un aumento del numero di tabelle e, di conseguenza, costi aggiuntivi per i join durante le selezioni. Per ottenere semplicemente tutti gli attributi di misurazione, in un classico magazzino è sufficiente un'unica selezione, mentre un'architettura flessibile richiede una serie di join. E se per i report tutti questi join possono essere scritti in anticipo, gli analisti che sono abituati a scrivere SQL a mano soffriranno di più.

Ci sono alcuni fattori che semplificano questa situazione:

Quando si lavora con grandi misure, quasi mai vengono utilizzati simultaneamente tutti i suoi attributi. Questo significa che i join potrebbero essere meno di quanto sembri a prima vista. Nel Data Vault, si può anche tenere conto della frequenza prevista di utilizzo congiunto nella distribuzione degli attributi tra i satelliti. I Hub o Ancore sono necessari principalmente per la generazione e il mapping dei surrogati nella fase di caricamento e sono raramente utilizzati nelle query (soprattutto per quanto riguarda le Ancore).

Tutti i join — per chiave. Inoltre, un metodo di archiviazione dei dati più "compresso" riduce i costi indiretti per la scansione delle tabelle dove necessario (ad esempio durante il filtraggio per valore dell'attributo). Questo può portare a risultati più rapidi da un database normalizzato con molti join, rispetto alla scansione di una singola misura pesante con molte versioni per riga.

Ad esempio, qui in questo questo articolo c'è un dettagliato test comparativo delle prestazioni del modello Anchora con un campionamento da una singola tabella.

Molto dipende dal motore. Molte piattaforme moderne hanno meccanismi interni per ottimizzare i join. Ad esempio, MS SQL e Oracle possono "saltare" i join su tabelle se i loro dati non vengono utilizzati altrove, tranne che per altri join, e non influiscono sul risultato finale (eliminazione delle tabelle/join), mentre MPP Vertica, secondo le esperienze dei colleghi di Avito, si è dimostrato un ottimo motore per il modello Anchora con una certa ottimizzazione manuale del piano di query. D'altra parte, memorizzare il modello Anchora, ad esempio, su Click House, che ha un supporto limitato per i join, al momento sembra non essere una buona idea.

Inoltre, per entrambe le architetture esistono tecniche speciali, che facilitano l'accesso ai dati (sia dal punto di vista delle prestazioni delle query che per gli utenti finali). Ad esempio, le tabelle Point-In-Time in Data Vault o funzioni tabulari speciali nel modello Anchora.

Totale

Il punto principale delle architetture flessibili considerate è la modularità della loro "struttura".

Questa caratteristica consente:

Dopo un certo inizio di preparazione, legato al dispiegamento dei metadati e alla scrittura degli algoritmi ETL di base, di fornire rapidamente al cliente il primo risultato sotto forma di un paio di report contenenti dati di appena alcuni oggetti sorgente. Non è necessario pensare completamente (anche a livello alto) a tutto il modello di oggetti per questo.
Il modello di dati può iniziare a funzionare (e portare benefici) con solo 2-3 oggetti, e poi espandersi gradualmente (riguardo al modello Anchora, Nikolay ha applicato un bel confronto con il micelio).
La maggior parte delle modifiche, inclusa l'espansione dell'area tematica e l'aggiunta di nuove sorgenti non influisce sulla funzionalità esistente e non comporta il rischio di rompere qualcosa che già funziona..
Grazie alla decomposizione in elementi standard, i processi ETL in tali sistemi appaiono omogenei, la loro scrittura si presta all'algoritmizzazione e, infine, all'automazione.

Il prezzo di questa flessibilità è prestazioni. Questo non significa che raggiungere prestazioni accettabili in tali modelli sia impossibile. Nella maggior parte dei casi, è probabile che vi serva semplicemente più impegno e attenzione ai dettagli per raggiungere le metriche desiderate.