6 tips för ordning och reda i datalager

15 november 2016

Ett bra datalager ska vara stabilt och förhållandevis lätt att förvalta. Nya utvecklare ska kunna orientera sig snabbt i lösningen och förändringar ska kunna göras i rask takt utan att äventyra lösningen.

Att bygga ett bra datalager handlar i många fall mer om ordning och reda än själva tekniken och här tänkte jag presentera en bra struktur som jag ofta utgår från. Exemplet är gjort i SQL Server och SSIS men kan säkert tillämpas även i andra verktyg.

1. Dela upp datalagret

Dela alltid upp datalagret i minst tre lager och bestäm regler för respektive lager:

Staging

Första anhalten för data från de källor som vi läser in till datalagret. Ska vara så likt källan som möjligt.

DataWarehouse

Mellanlagret, det är här allt roligt händer. Här gör vi i ordning all data – tvättar, beräknar, aggregerar etc. All affärslogik ska ligga i detta lagret och beroende får endast finnas till Staging.

Datamart

Hel- eller delmängd av det som ligger i DataWarehouse. Ingen logik bör ske från DataWarehouse till Datamart och beroende får endast finnas till DataWarehouse-lagret.

Så med dessa enkla regler har vi en bra struktur i datalagret – tre databaser med tre olika roller.

databases

2. Skapa tabeller med meningsfulla namn

Slarva aldrig med namnsättning av tabeller. Tänk hellre efter en stund extra, det lönar sig i längden.
Jag har för vana att alltid sätta ”t” som prefix på tabeller och ”v” som prefix på vyer men det kan man göra som man vill så länge man är konsekvent.

Staging

Här ska tabellerna heta samma som i källan. I mitt exempel använder jag två tabeller: MRCLFG (dimensionsdata) och OFDLJR (försäljningsstatistik).

DataWarehouse

Dimensionstabellen i Staging kommer att brytas ut till fyra separata dimensionstabeller: tCustomer, tPeriod, tProduct och tSupplier. Försäljningsstatistiken döps till tSales. Bra namn allihopa.

Datamart

Behåll samma namn som i DataWarehouse men lägg på ”Dim” för dimensioner och ”Fact” för faktatabeller.

tables

3. Spegla databasstrukturen i SSIS

Vi har tre lager i databasen och skapar därför tre projekt i SSIS med samma namn. Eftersom vi har regler för respektive lager så vi vet vad som ska hända och inte hända i respektive SSIS-projekt.

projects

4. Gör ett SSIS-paket per måltabell

Skapa ett SSIS-paket per måltabell och döp paketen till samma namn som tabellen det skriver till. Inget paket får skriva till mer än en tabell.

packages

Skapa även ett paket per projekt som heter ”_LoadAll”. Detta paket ska sörja för att köra övriga paket i rätt ordning. Kan i sin enklaste form se ut enligt nedan.

loadall

5. Gör all ETL i SSIS

Det finns två skolor, de som tycker att all ETL ska göras i SSIS och de som tycker att det ska göras med lagrade procedurer. Och sen finns det de som gör lite som de känner för, ibland SSIS-paket och ibland lagrade procedurer.
Min bestämda uppfattning är att det ur förvaltningssynpunkt är ohållbart med lagrade procedurer och att all ETL därför ska göras i SSIS. Det finns goda argument mot SSIS, det är jag väl medveten om, men diskussionen om procedurer vs paket kan vi ta i ett annat blogginlägg. Min rekommendation är hur som helst att helt förbjuda lagrade procedurer.

6. Skapa ett skitenkelt jobb

Vi vill ju så klart schemalägga våra paket och det gör vi med hjälp av ett jobb i SQL Server. Skapa tre steg i jobbet: Staging, DataWarehouse och Datamart. Stegen pekas på paketet ”_LoadAll” i respektive projekt.

job

Slutsats

Nu har vi en riktigt bra struktur i databasen och ETL-processerna och det är lätt att orientera sig i lösningen. För varje lager i databasen finns ett SSIS-projekt och för varje tabell finns ett paket med samma namn.

all

Trots att verkligheten sällan är så enkel som mitt lilla exempel så tycker jag ändå att detta är en riktigt bra utgångspunkt. Sedan måste man såklart vara flexibel, t ex kan det i stora implementationer ibland vara en bra idé att dela upp projekten i dataområden isället för att följa databasstrukturen. Men om man utgår från tipsen ovan blir det enkelt att orientera sig i lösningen och svara på vanliga frågor, till exempel:

I vilken ordning laddas tabellerna i Datamart?
Titta i ”_LoadAll”-paketet i Datamart.

Fältet ”Customer Name” kommer att ändras från 30 till 40 tecken, vilka tabeller och paket behöver ändras?
Tabellerna MRCLFG, tCustomer och tDimCustomer behöver ändras samt paketen med samma namn.

Jag behöver ändra logiken för beräkning av försäljning, i vilket paket ligger den logiken?
All affärslogik ligger i DataWarehouse och paketet som skriver till tSales heter samma som tabellen.

Vilken tabell läser tDimCustomer från?
Tabellen med samma namn i DataWarehouse – tCustomer.

Vilken tabell läser tCustomer från då?
Det vet jag inte på rak arm, du får kolla i paketet.

Vilket paket?
Paketet med samma namn som tabellen – tCustomer. Det borde nu har lärt dig vid detta laget.

Jag tänkte göra en lagrad procedur, är det okej?
Nej.