Architettura del data warehouse per lo schema mutante

Question

Architettura del data warehouse per lo schema mutante

#1 da (2 voti)
#2 da (1 voti)

3

Sto configurando un processo ETL e un piccolo data warehouse per interrogare i dati in poche dimensioni diverse. Un problema è che lo schema degli oggetti può mutare nel tempo, principalmente che alcuni campi verranno aggiunti e alcuni rimossi. Quali sono alcune metodologie o approcci per gestirlo?

(Si noti che i dati di origine sono gestiti come EAV, che è difficile da interrogare ed è lento, quindi l'approccio DW in primo luogo).

Ciò che sembra un approccio ingenuo (che spesso può essere il migliore) è semplicemente aggiungere colonne nel tempo alle forme di destinazione nel magazzino e recuperare gli oggetti esistenti con alcuni dati segnaposto validi per le query.

Questo è un po 'fuori dalla mia esperienza di dominio, quindi, cercando input.

data-warehouse etl

posta Rex M 22.03.2013 - 19:58

fonte

2 risposte

Leggi altre domande sui tag data-warehouse etl

Perché di solito c'è un riferimento a Java quando le persone parlano di C #? Errore del software a causa di errori di manutenzione esempio / caso di studio

score 2 · Answer 1

Dal lato del magazzino avrei una tabella di staging da ciascuna origine (logica e temporale), quindi per tutti i dati provenienti dalla sorgente 1, ci sarebbe una tabella per source 1-version 1, source 1-version 2 e così on.

Hai quindi un secondo schema (o database) che è 'refertabile' e che viene riempito dalle tabelle di staging. È possibile aggiungere e non è necessario rimuovere le colonne quando i dati aggiuntivi sono online. *

* Potresti decidere di rimuovere le colonne da esso come misura di manutenzione se non vengono più segnalate, ma di nuovo si conservano i dati nella tabella di staging per uso futuro

score 1 · Answer 2

I data warehouse in genere possono essere "riempiti" completamente da un qualche tipo di database OLTP. Non è insolito farlo una volta a notte, in modo asincrono. Pertanto, ogni volta che si presenta un nuovo requisito in cui è necessario modificare uno schema, una possibile strategia consiste semplicemente nel definirla come una nuova "versione" del data warehouse, adattare il processo ETL alla nuova versione, eliminare tutti i dati precedenti e ricaricare il DW completamente da zero dalla tua fonte OLTP di nuovo. Ciò rende le modifiche dello schema molto semplici, dal momento che è possibile assumere un database completamente vuoto durante la modifica. In questo modo, non avrai bisogno di script di "schema change", ma solo di eliminare l'intero schema ed eseguire un set completo di% script di% co_de per la versione più recente del tuo DW.

Quello che devi testare è se quella semplice strategia è abbastanza veloce per il tuo caso e soffre le tue esigenze. Se il tuo data warehouse è piccolo (qualunque cosa significhi ai tuoi occhi), come hai detto, potresti non avere problemi a fornire versioni diverse del tuo data warehouse in parallelo, in modo che i tuoi utenti possano usare la versione "(n-1)" mentre il Il processo ETL per la versione n è ancora in esecuzione.