Hur närmar man sig ett ETL-uppdrag?

Några allmänna ETL-tips

1. Överväg att organisera det efter destination (till exempel, all kod för att producera kunddimensionen finns i samma modul, oavsett källa). Detta kallas ibland för ämnesorienterad ETL. Det gör det mycket lättare att hitta saker och kommer att öka underhållbarheten för din kod.

2. Om SQL2000-databasen är en enda röra kommer du förmodligen att upptäcka att SSISdataflöden är ett klumpigt sätt att hantera data. Som regel skalar ETL-verktyg dåligt med komplexitet; ungefär hälften av alla datawarehouse-projekt i finansbolag görs med lagrad procedurkod som ett explicit arkitektoniskt beslut - av just denna anledning. Om du måste lägga in en stor mängd kodinsprocs, överväg att lägga in alla av koden i sprocs.
   
   För ett system som involverar mycket komplex skrubbning eller transformationer är en 100 % sproc-metod mycket mer underhållbar eftersom det är det enda möjliga sättet att placera alla transformationer och affärslogik på ett ställe. Med blandade ETL/sproc-system måste du leta på flera ställen för att spåra, felsöka, felsöka eller ändra hela transformationen.

3. Den söta punkten med ETL-verktyg är på system där du har ett större antal datakällor med relativt enkla transformationer.

4. Gör koden testbar, så att du kan plocka isär komponenterna och testa isolering. Kod som bara kan exekveras från mitten av ett komplext dataflöde i ett ETL-verktyg är mycket svårare att testa.

5. Gör dataextraheringen dum med nobusiness-logik och kopiera in i astaging-området. Om du har affärslogik spridd över extrakt- och omvandlingsskikten kommer du att få transformationer som inte kan testas isolerat och göra det svårt att spåra buggar. Om transformationen körs från ett iscensättningsområde minskar du det hårda beroendet av källsystemet, vilket återigen förbättrar testbarheten. Detta är en speciell vinst på sproc-baserade arkitekturer eftersom det tillåter en nästan helt homogen kodbas.

6. Bygg en generisk hanterare för långsamt föränderliga dimensioner eller använd en från hyllan om tillgänglig. Detta gör det enklare att enhetstesta denna funktion. Om detta kan enhetstestas, behöver systemtestningen inte testa alla hörnfall, bara om de data som presenteras för den är korrekta. Det här är inte så komplicerat som det låter - Det sista jag skrev var ungefär 600 eller 700 rader T-SQL-kod. Detsamma gäller för alla generiska skurfunktioner.

7. Ladda inkrementellt om möjligt.

8. Instrumentera din kod - låt den göra loggposter, eventuellt registrera diagnostik som kontrollsummor eller räkningar. Utan detta är felsökning nästan omöjligt. Påståendekontroll är också ett bra sätt att tänka på felhantering för detta (räknas rader lika med rader i b, är förhållandet A:B verkligen 1:1).

9. Använd syntetiska nycklar. Att använda naturliga nycklar från källsystemen binder ditt system till datakällorna och gör det svårt att lägga till extra källor. Nycklarna och relationerna i systemet ska alltid ligga i linje - inga nollor. För fel, "inte registrerat", gör du ett specifikt "fel" eller "inte registrerat" i dimensionstabellen och matchar dem.

10. Om du bygger ett operativt datalager (ämnet för många religionskrig) återvinn inte ODS-nycklarna i stjärnschemana. Gå med alla medel på ODS-nycklar för att konstruera dimensioner, men matcha på en naturlig nyckel. Detta tillåter dig att godtyckligt släppa och återskapa ODS - eventuellt ändra dess struktur - utan att störa stjärnscheman. Att ha denna förmåga är en riktig underhållsvinst, eftersom du kan ändra ODS-strukturen eller göra en brute-force-omplacering av ODS när som helst.

Punkterna 1-2 och 4-5 innebär att du kan bygga ett system där alla av koden för ett givet delsystem (t.ex. en enstaka dimension eller faktatabell) finns på en och endast en plats i systemet. Den här typen av arkitektur är också bättre för ett större antal datakällor.

Punkt 3 är en motpol till punkt 2. I grund och botten är valet mellan SQL- och ETL-verktyg en funktion av transformationskomplexiteten och antalet källsystem. Ju enklare data och större antal datakällor, desto starkare argument för ett verktygsbaserat tillvägagångssätt. Ju mer komplexa data är, desto starkare är det för att gå över till en arkitektur baserad på lagrade procedurer. I allmänhet är det bättre att uteslutande eller nästan uteslutande använda det ena eller det andra men inte båda.

Punkt 6 gör ditt system lättare att testa. Att testa SCD:er eller någon förändringsbaserad funktionalitet är krångligt, eftersom du måste kunna presentera mer än en version av källdata till systemet. Om du flyttar ändringshanteringsfunktionen till infrastrukturkoden kan du testa den isolerat med testdatauppsättningar. Detta är en vinst i testning, eftersom det minskar komplexiteten i dina systemtestkrav.

Punkt 7 är ett allmänt prestandatips som du måste följa för stora datamängder. Observera att du kanske bara behöver inkrementell laddning för vissa delar av ett system; för mindre referenstabeller och dimensioner kanske du inte behöver det.

Punkt 8 är relevant för alla huvudlösa processer. Om det blir tuttar under natten vill du ha en chans att se vad som gick fel nästa dag. Om koden inte loggar vad som händer ordentligt och fångar upp fel kommer du att ha ett mycket svårare jobb att felsöka den.

Punkt 9 ger datalagret ett eget liv. Du kan enkelt lägga till och släppa källsystem när lagret har sina egna nycklar. Lagernycklar är också nödvändiga för att implementera långsamt föränderliga dimensioner.

Punkt 10 är en vinst för underhåll och driftsättning, eftersom ODS kan omstruktureras om du behöver lägga till nya system eller ändra kardinaliteten för en post. Det betyder också att en dimension kan laddas från mer än en plats i ODS (tänk:lägga till manuella redovisningsjusteringar) utan beroende av ODS-nycklarna.