SQL/SSIS DataWareHouse Caricamento della tabella dei fatti, best practice?

Question

Sto costruendo il mio primo datawarehouse in SQL 2008/SSIS e sto cercando alcune best practice sul caricamento delle tabelle dei fatti.

Attualmente nel mio DW ho circa 20 dimensioni (uffici, dipendenti, prodotti, clienti, ecc.) Che sono di tipo 1 SCD. Nella mia struttura DW, ci sono alcune cose che ho già applicati:

• Non Null (sostituito con vuoto per il testo o 0 per numerici durante la messa in scena)
• membri chiave sconosciuti popolate in ogni dimensione (SK ID 0)
• UPSERT per tipo SCD 1 caricamento da stadio a tavola produzione
• SELECT DISTINCT mio carico di dimensioni

Nel mio Fact progetto caricamento SSIS, l'attuale metodo ho per dimensioni caricamento è avendo più ricerche (20+) su ciascuno dei DIM, quindi compilando la tabella FACT con i dati.

Per le mie ricerche ho impostato:

• cache piena
• Ignora guasti per "nessuna voce matching"
• Trasformazione Derivato con "ISNULL (surrogate_idkey) 0:? Surrogate_idkey" per ogni SK in modo che se le ricerche falliscono, verranno automaticamente impostate su SK ID 0 (membro sconosciuto).
• Alcuni dei miei ricerche di quota hanno più di una chiave di business

È questo l'approccio migliore? Immagini allegate per aiutare con la mia descrizione sopra.

Answer 1

guarda bene. Ci sono opzioni se si inizia a correre problemi di prestazioni, ma se questo è stabile (finisce nella finestra del tempo di caricamento dei dati, i sistemi di origine non vengono prosciugati di risorse, ecc.), Quindi non vedo alcun motivo per cambiare.

Alcuni problemi potenziali per tenere d'occhio ...

1. avere 20+ pieno di cache di ricerca-trasforma possono rappresentare un problema se le vostre dimensioni aumentano di dimensione ... a causa dei limiti di memoria sul SSIS sistema ... ma dal momento che sono di tipo 1, non mi preoccuperei.
2. ricerche full-Cache "idrato" pre-esecuzione ... avere 20+ di loro possono rallentare se

Un'alternativa comune (per quello che hai sopra) è di estrarre i dati della tabella fatto dal sistema di origine e atterrarlo in un'area di gestione prima di eseguire la ricerca della chiave di dimensione tramite una singola istruzione SQL. Alcuni addirittura mantengono una serie di tabelle di mappatura delle chiavi di dimensione nell'area di staging appositamente per questo scopo. Ciò riduce il blocco/blocco sul sistema di origine ... se hai un sacco di dati per ogni carico, e devi bloccare il sistema di origine mentre succhi i dati e li esegui attraverso quelle trasformazioni di ricerca 20+.

Avere una buona strategia di area di sosta diventa più importante quando si dispone di una grande quantità di dati, di grandi dimensioni, di mappature di tasti complesse (in genere dovute a più sistemi di origine) e finestre di tempo di caricamento dei dati brevi.