Hvordan nærmer man sig en ETL-mission?

Nogle generelle ETL-tip

1. Overvej at organisere det efter destination (for eksempel lever al koden til at producere kundedimensionen i det samme modul, uanset kilden). Dette er nogle gange kendt som emneorienteret ETL. Det gør det meget nemmere at finde ting og vil øge vedligeholdelsen af ​​din kode.

2. Hvis SQL2000-databasen er noget rod, vil du sandsynligvis opdage, at SSIS-datastrømme er en klodset måde at håndtere dataene på. Som regel skalerer ETL-værktøjer dårligt med kompleksitet; noget i retning af halvdelen af ​​alle datawarehouse-projekter i finansvirksomheder udføres med lagret procedurekode som en eksplicit arkitektonisk beslutning - netop af denne grund. Hvis du skal indsætte en stor mængde kodeinsprocs, kan du overveje at sætte alle af koden i sprocs.
   
   For et system, der involverer en masse kompleks skrubning eller transformationer, er en 100 % sproc-tilgang langt mere vedligeholdelsesdygtig, da det er den eneste gennemførlige måde at samle alle transformationerne og forretningslogikken på ét sted. Med blandede ETL/sproc-systemer skal du kigge flere steder for at spore, fejlfinde, fejlsøge eller ændre hele transformationen.

3. Det søde punkt ved ETL-værktøjer er på systemer, hvor du har et større antal datakilder med relativt enkle transformationer.

4. Gør koden testbar, så du kan skille komponenterne fra hinanden og teste isolering. Kode, der kun kan udføres fra midten af ​​et komplekst dataflow i et ETL-værktøj, er meget sværere at teste.

5. Gør dataudtrækket dumt med nobusiness-logik, og kopier ind i astaging-området. Hvis du har forretningslogik spredt ud over ekstrakt- og transformationslagene, vil du have transformationer, der ikke kan testes isoleret, og gøre det svært at spore fejl. Hvis transformationen kører fra et iscenesættelsesområde, reducerer du den hårde afhængighed af kildesystemet, hvilket igen forbedrer testbarheden. Dette er en særlig gevinst på sproc-baserede arkitekturer, da det tillader en næsten fuldstændig homogen kodebase.

6. Byg en generisk, langsomt skiftende dimensionshandler, eller brug en fra hylden, hvis den er tilgængelig. Dette gør det nemmere at enhedsteste denne funktionalitet. Hvis dette kan enhedstestes, behøver systemtestningen ikke at teste alle hjørnesager, blot om de data, der præsenteres for den, er korrekte. Dette er ikke så komplekst, som det lyder - Det sidste, jeg skrev, var omkring 600 eller 700 linjer T-SQL-kode. Det samme gælder for alle generiske skrubbefunktioner.

7. Indlæs trinvist, hvis det er muligt.

8. Instrumenter din kode - få den til at lave logindtastninger, eventuelt registrere diagnostik såsom kontroltotaler eller optællinger. Uden dette er fejlfinding nærmest umuligt. Påstandskontrol er også en god måde at tænke fejlhåndtering til dette på (tæller rækker i lige store rækker i b, er A:B forhold virkelig 1:1).

9. Brug syntetiske nøgler. Brug af naturlige nøgler fra kildesystemerne binder dit system til datakilderne og gør det vanskeligt at tilføje ekstra kilder. Nøglerne og relationerne i systemet skal altid være på linje - ingen nuller. For fejl, "ikke registreret", skal du foretage en specifik "fejl" eller "ikke registreret" indtastninger i dimensionstabellen og matche dem.

10. Hvis du bygger et operationelt datalager (genstand for mange religiøse krig), skal du ikke genbruge ODS-nøglerne i stjerneskemaerne. Slut med alle midler på ODS-nøgler for at konstruere dimensioner, men match på en naturlig nøgle. Dette giver dig mulighed for vilkårligt at droppe og genskabe ODS'en - muligvis ændre dens struktur - uden at forstyrre stjerneskemaerne. At have denne evne er en reel vedligeholdelsesgevinst, da du kan ændre ODS-strukturen eller udføre en brute-force-re-deployering af ODS'en til enhver tid.

Punkt 1-2 og 4-5 betyder, at du kan bygge et system, hvor alle af koden for et givet undersystem (f.eks. en enkelt dimension eller faktatabel) bor ét og kun ét sted i systemet. Denne type arkitektur er også bedre til et større antal datakilder.

Punkt 3 er et modspil til punkt 2. Grundlæggende er valget mellem SQL- og ETL-værktøjer en funktion af transformationskompleksitet og antallet af kildesystemer. Jo enklere data og større antal datakilder, jo stærkere argumenter for en værktøjsbaseret tilgang. Jo mere komplekse data er, jo stærkere er argumentet for at flytte til en arkitektur baseret på lagrede procedurer. Generelt er det bedre udelukkende eller næsten udelukkende at bruge det ene eller det andet, men ikke begge dele.

Punkt 6 gør dit system nemmere at teste. Det er besværligt at teste SCD'er eller enhver ændringsbaseret funktionalitet, da du skal kunne præsentere mere end én version af kildedataene til systemet. Hvis du flytter ændringsstyringsfunktionaliteten ind i infrastrukturkode, kan du teste den isoleret med testdatasæt. Dette er en gevinst i test, da det reducerer kompleksiteten af ​​dine systemtestkrav.

Punkt 7 er et generelt præstationstip, som du skal overholde for store datamængder. Bemærk, at du muligvis kun har brug for trinvis belastning for nogle dele af et system; for mindre referencetabeller og dimensioner har du muligvis ikke brug for det.

Punkt 8 er relevant for enhver hovedløs proces. Hvis den får brysterne op i løbet af natten, vil du gerne have en kæmpe chance for at se, hvad der gik galt næste dag. Hvis koden ikke logger, hvad der foregår korrekt, og fanger fejl, vil du have et meget sværere arbejde med at fejlfinde den.

Punkt 9 giver datavarehuset sit eget liv. Du kan nemt tilføje og slippe kildesystemer, når lageret har sine egne nøgler. Lagernøgler er også nødvendige for at implementere langsomt skiftende dimensioner.

Punkt 10 er en vedligeholdelses- og implementeringsgevinst, da ODS'en kan omstruktureres, hvis du har brug for at tilføje nye systemer eller ændre kardinaliteten af ​​en post. Det betyder også, at en dimension kan indlæses fra mere end ét sted i ODS (tænk:tilføjelse af manuelle regnskabsjusteringer) uden afhængighed af ODS-tasterne.