Come affrontare una missione ETL?

Alcuni suggerimenti generali sull'ETL

1. Prendi in considerazione l'idea di organizzarlo per destinazione (ad esempio, tutto il codice per produrre la dimensione cliente risiede nello stesso modulo, indipendentemente dalla fonte). Questo è talvolta noto come ETL orientato al soggetto. Rende molto più facile trovare le cose e aumenterà la manutenibilità del tuo codice.

2. Se il database SQL2000 è un pasticcio, probabilmente scoprirai che i flussi di dati SSIS sono un modo goffo per gestire i dati. Di norma, gli strumenti ETL sono poco scalabili con la complessità; qualcosa come metà di tutti i progetti di datawarehouse nelle società finanziarie vengono eseguiti con codice di procedura memorizzato come decisione architettonica esplicita, proprio per questo motivo. Se devi inserire una grande quantità di codice insprocs, considera di inserire tutto del codice in sprocs.
   
   Per un sistema che prevede numerose ripuliture o trasformazioni complesse, un approccio 100% sproc è molto più gestibile in quanto è l'unico modo possibile per riunire tutte le trasformazioni e la logica aziendale in un unico posto. Con i sistemi misti ETL/sproc, devi cercare in più punti per monitorare, risolvere i problemi, eseguire il debug o modificare l'intera trasformazione.

3. Il vantaggio degli strumenti ETL è su sistemi in cui hai un numero maggiore di origini dati con trasformazioni relativamente semplici.

4. Rendi il codice testabile, in modo da poter separare i componenti e testare l'isolamento. Il codice che può essere eseguito solo all'interno di un flusso di dati complesso in uno strumento ETL è molto più difficile da testare.

5. Rendi l'estrazione dei dati stupida senza logica aziendale e copia nell'area di staging. Se la logica aziendale è distribuita tra i livelli di estrazione e trasformazione, si avranno trasformazioni che non possono essere testate in isolamento e renderanno difficile rintracciare i bug. Se la trasformazione viene eseguita da un'area di staging, si riduce la forte dipendenza dal sistema di origine, migliorando nuovamente la verificabilità. Questa è una vittoria particolare sulle architetture basate su sproc in quanto consente una base di codice quasi completamente omogenea.

6. Costruisci un gestore di dimensioni generico che cambia lentamente o usane uno pronto all'uso, se disponibile. Questo rende più facile testare questa funzionalità. Se questo può essere testato per unità, il test del sistema non deve testare tutti i casi d'angolo, semplicemente se i dati presentati sono corretti. Non è così complesso come sembra - L'ultimo che ho scritto era di circa 600 o 700 righe di codice T-SQL. Lo stesso vale per qualsiasi funzione di pulizia generica.

7. Carica in modo incrementale se possibile.

8. Strumenta il tuo codice:fai in modo che esegua voci di registro, possibilmente registrando la diagnostica come controllare totali o conteggi. Senza questo, la risoluzione dei problemi è quasi impossibile. Inoltre, il controllo delle asserzioni è un buon modo per pensare alla gestione degli errori per questo (le righe contano in un numero uguale di righe in b, la relazione A:B è davvero 1:1).

9. Usa chiavi sintetiche. L'uso di chiavi naturali dai sistemi di origine lega il tuo sistema alle origini dati e rende difficile l'aggiunta di fonti aggiuntive. Le chiavi e le relazioni nel sistema dovrebbero sempre essere allineate, senza valori nulli. Per gli errori "non registrati", inserisci una specifica voce "errore" o "non registrato" nella tabella dimensionale e abbinali.

10. Se costruisci un archivio dati operativo (oggetto di molte guerre di religione) non riciclare le chiavi ODS negli schemi a stella. Unisciti a tutti i mezzi su chiavi ODS per costruire dimensioni, ma abbina su una chiave naturale. Ciò consente di rilasciare e ricreare arbitrariamente l'ODS, eventualmente cambiandone la struttura, senza disturbare gli schemi stellari. Avere questa capacità è una vera vittoria per la manutenzione, poiché puoi modificare la struttura dell'ODS o eseguire una ridistribuzione a forza bruta dell'ODS in qualsiasi momento.

I punti 1-2 e 4-5 significano che puoi costruire un sistema in cui tutti del codice per un dato sottosistema (ad es. una singola dimensione o tabella dei fatti) risiede in uno e un solo posto nel sistema. Questo tipo di architettura è migliore anche per un numero maggiore di origini dati.

Il punto 3 è un contrappunto al punto 2. Fondamentalmente la scelta tra gli strumenti SQL ed ETL è una funzione della complessità della trasformazione e del numero di sistemi sorgente. Più semplici sono i dati e maggiore è il numero di fonti di dati, più forte sarà l'opportunità di un approccio basato su strumenti. Quanto più complessi sono i dati, tanto più convincente sarà il passaggio a un'architettura basata su stored procedure. In genere è meglio utilizzare esclusivamente o quasi esclusivamente l'uno o l'altro ma non entrambi.

Il punto 6 semplifica il test del sistema. Il test degli SCD o di qualsiasi funzionalità basata su modifiche è complicato, poiché devi essere in grado di presentare più di una versione dei dati di origine al sistema. Se sposti la funzionalità di gestione delle modifiche nel codice dell'infrastruttura, puoi testarla isolatamente con set di dati di test. Questa è una vittoria nei test, in quanto riduce la complessità dei requisiti di test del sistema.

Il punto 7 è un suggerimento generale sulle prestazioni che dovrai osservare per grandi volumi di dati. Si noti che potrebbe essere necessario il caricamento incrementale solo per alcune parti di un sistema; per tabelle di riferimento e dimensioni più piccole potrebbe non essere necessario.

Il punto 8 è pertinente a qualsiasi processo senza testa. Se si alza le tette durante la notte, vuoi avere qualche possibilità di combattere per vedere cosa è andato storto il giorno successivo. Se il codice non registra correttamente ciò che sta accadendo e rileva gli errori, sarà molto più difficile risolverlo.

Il punto 9 conferisce al data warehouse una vita propria. È possibile aggiungere e rimuovere facilmente i sistemi di origine quando il magazzino ha le proprie chiavi. Le chiavi del magazzino sono necessarie anche per implementare dimensioni che cambiano lentamente.

Il punto 10 è un vantaggio per la manutenzione e l'implementazione, poiché l'ODS può essere ristrutturato se è necessario aggiungere nuovi sistemi o modificare la cardinalità di un record. Significa anche che una dimensione può essere caricata da più di un punto nell'ODS (si pensi all'aggiunta di rettifiche contabili manuali) senza dipendere dalle chiavi ODS.