Under de senaste åren har vi fått ta hand om ett flertal datalager (Data Warehouse, eller DW) som sett helt förskräckliga ut — inte konstigt att många tycker att datalager bara är dyra och dåliga. Denna åsikt har även basunerats ut av diverse leverantörer av BI-verktyg, vilket säkert har förstärkt uppfattningen. Men ett välkonstruerat datalager är faktiskt den bästa grunden för ett effektivt beslutstöd.

Lite historik

Genom årens lopp har best practice för datalager förändrats flertalet gånger. Den första etablerade modellen kom från Bill Inmon år 1992 och byggde helt och hållet på tredje normalform. Inmon definierade begreppet datalager enligt följande:

 A data warehouse is a subject-oriented, integrated, time-variant, nonvolatile collection of data in support of management’s decision-making process.

De hade funnits beslutstödssystem tidigare, men de byggde inte så ofta på relationsdatabaser utan ofta på andra tekniker som t.ex. OLAP eller andra helt proprietära tekniker.

I mitten på 1990-talet började ETL-verktyg med grafiska gränssnitt komma ut på marknaden (fram till dess hade hela ETL-processen handkodats) vilket drastiskt kunde reducera utvecklingstiden.

Under slutet på 1990-talet och början på 2000-talet tog Ralph Kimball fram en ny modell, dimensionsmodellerade data marts. Dessa optimerades bland annat för prestanda, vilket var en förutsättning för att kunna få vettiga svarstider på frågor mot databasen. Alla rapport- och frågeverktyg på marknaden kan med bravur hantera en välkonstruerad dimensionsmodellerad data mart. Modellen beskrivs mer ingående i boken ”The Data Warehouse Lifecycle Toolkit” som fick ett enormt genomslag och har påverkat sättet att bygga datalager ända fram till idag.

Problem kunde dock uppstå eftersom data marts ibland betraktades som mer situationsanpassade och installerades för ett tidsbegränsat ändamål. Därför började man ofta bygga en trelagerarkitektur, med stage-area som landningsbana från källsystem, ett EDW i tredje normalform i mitten som höll all historik, och data marts där fråge- och rapportverktygen kopplade upp sig.  Detta var den arkitektur som var best practice fram till ungefär 2014. Om man besiktigar ett datalager kan man ofta enbart på modelleringen se vid vilken tidpunkt som det konstruerades.

Vid åren runt 2000, d.v.s. 8 år efter att begreppet datalager hade definierats, byggdes det datalager för såväl stora som små organisationer. De stora använde gärna det som sågs som best practice vid den tidpunkten, d.v.s. Informatica för ETL, Oracle för databasen och Business Objects för rapport- och frågeverktyg.

När man konstruerar ett datalager idag använder man också en trelagers arkitektur, men i stället för ett normalformsmodellerat EDW i mitten så använder man en så kallad Data Vault-modell. Den har ett antal fördelar, bl.a. är den stegvis utbyggbar på ett annat sätt en ett tredje normalforms EDW.

Det tredje lagret, data marts är ofta virtuella eller semivirtuella, består av vyer mot data vault och kanske någon fysisk tabell. Fördelen med detta är att man slipper konstruera och förvalta onödigt många ETL-mappningar.

Vad kännetecknar ett dåligt datalager?

  • Arkitektur. Under åren har best practice för ett datalagers arkitektur förändrats flertalet gånger, med olika fördelar och nackdelar. Men så länge ett datalager är byggt enligt någon best practice speglar det ändå sin tid. Dåliga datalager är istället byggda utan en vettig tanke bakom arkitekturen, förmodligen på grund av att ingen DW-arkitekt har varit inblandad — de som byggt datalagret kanske kan databaser, men saknar erfarenhet att designa ett datalager.
  • Dåliga vanor. DW-utvecklare som inte är vana att arbeta med ETL-verktyg återgår lätt till gamla vanor som att skriva för mycket egen programkod som bara orkestreras av ETL-verktyget. Detta märker vi till exempel om mycket logik finns i egenskrivna procedurer, vilket leder till dålig prestanda i laddprocessen och en tidskrävande förvaltning. En annan ovana är att lägga logik i komplicerade vyer som aldrig syns i ETL-verktyget.
  • Filer som indatamedium. Det är inte nödvändigtvis fel att använda sig av filer, men de ställer ofta till fler problem än de löser. Ett exempel kan vara om data är uppdelat, kanske i en fil för projekt och i en annan för motsvarande händelser. Om det då finns händelser för projekt som saknas i projektfilen så smäller det så småningom till rejält i inläsningen. Det här fenomenet har vi tyvärr sett alldeles för mycket av på sista tiden.
  • Datalagret är alldeles för krångligt. Normalt sett används en treskikts-arkitektur med Staging, Warehouse och Data Marts, men vi har ibland sett datalager med fem eller sex skikt. Detta leder inte bara till längre konstruktions- och laddningstider utan ökar även risken att det smyger sig in fel som är svåra att upptäcka i efterhand. Ett exempel på detta var en kund till oss som hade ett tillkrånglat datalager och som ville migrera det till en ny plattform; vi insåg nästan omgående att det skulle gå snabbare att skriva om det helt med ny teknik. Det var klart efter några få veckor, och skulle då stämmas av mot det äldre lagret, varpå det upptäcktes en mängd avvikelser. Det visade sig emellertid att det gamla datalagret innehöll ett antdal fel som ingen upptäckt tidigare.

Principer vid nykonstruktion

  • Använd en treskikts-arkitektur. Med Staging, EDW och Data Marts. Vill man använda sig av fler än tre lager bör man vara medveten om nackdelarna och veta vad man gör.
  • Använd färre men bredare tabeller. Detta kan i och för sig ta lite extra diskutrymme, men disk är billigt idag. Dessutom har alla relationsdatabaser komprimering av tabellerna idag, som biter bättre på lite bredare tabeller. En vanlig komprimeringsteknik idag är kolumnkomprimering, som används vid in-memory lagring, som enligt våra tester komprimerar tabeller till ca en tiondel av sin originalstorlek på just breda tabeller. Exempel på när kolumnkomprimering används är SAP Hana, MS SQL server column store index, Oracle in Memory option, Oracle Exadata och Qlikview. Färre men bredare tabeller medför också färre mappningar vilket reducerar kostnaderna för utveckling och förvaltning.
  • Sprid inte ut affärslogik över hela datalagret. Den ska helst ligga på samma ställe till exempel mellan EDW och Data Marts om det är möjligt. Vi har sett femskikts datalager med massor av affärsregler i alla lager, vilket var ett rent elände att ens hitta runt i.
  • Använd ETL-verktyget på ett förnuftigt sätt. För att mappningarna ska vara förvaltningsbara måste det gå att se vad som sker i olika mappningarna. Vi har sett mappningar i olika verktyg, där man får sitta och analysera flera timmar för att se vad som händer i mappningen. Det värsta hittills var nog när man använt en så kallad query factory, dvs. with-sats som indata till mappningen. Den var naturligtvis helt okommenterad och tog flera dagar att bena ut. Till råga på allt visade sig den vara felaktig i slutändan. Det är också betydligt bättre med två enkla mappningar, än en komplicerad.
  • Modellera EDW enligt en data vault-modell. Den har så många fördelar jämfört med alla andra EDW-modeller jag sett. Det jag uppskattar mest är att man kan komplettera den enkelt utan att ändra i de befintliga tabellerna. I ett driftsläge har den även fördelen att man kan ladda mycket parallellt.
  • Använd hashade syntetiska nycklar. Ger enklare mappningar utan lookups för att hämta syntetisk nyckel som genererats via sekvenser. Enklare mappningar ger kortare laddtider. Hashade nycklar är en av nyheterna i Data Vault 2.0. Vill man kombinera ihop data från relationsdatabas med data lagrat i Hadoop-kluster får man välja en hashningsalgoritm som finns i bägge miljöerna.
  • Använd en enkel design. Utmaningen är ofta att ta fram en så enkel, rak och snygg design som möjligt såväl när det gäller datamodell som ETL-design. Tvärtom mot vad många tror, krävs det betydligt mer tankeverksamhet för att konstruera en enkel modell än en krånglig.

Nyfiken att veta mer? Hör av dig!

Anders Lernberg
+ 46 761 13 16 13
anders.lernberg@affecto.com