Datalager, vad är ett datalager?

Vad är ett datalager?

Det här härliga begreppet myntades redan på 1980-talet av IBM-forskarna Barry Devlin och Paul Murphy för att stötta s.k. ”decision support environments” vilket i modernt tal kallas business intelligence eller beslutsstödsystem. Det är lite otydligt vem som egentligen uppfann begreppet data warehouse, men Bill Imnon industrialiserade det på 1990-talet och ungefär samtidigt kom Ralph Kimball att lansera dimensionsmodeller som Den Sanna Vägen. Därefter följde ett ideologiskt krig mellan nördar på Inmon- och Kimball-sidan. Ibland flammar kriget upp även i nutid, med ytterligare kombattanter på spelplanen, särskilt ivriga Data Vault-anhängare som tycker att alla andra har fel. Men det som kanske är mest intressant är att datalager som begrepp har överlevt i drygt 25 år!

De senaste 5-10 åren har datalagret ifrågasatts både av kunder, mjukvaruleverantörer och utvecklare av olika skäl som t.ex. leveranstid och kostnad. Intensiteten i dessa ”angrepp” har inte sällan ökat vid introduktion av nya produkter som lovar stora besparingar, snabbare utveckling, m.m. Då det kommer någonting som verkar nytt spetsar såklart både vi och våra kunder på öronen. Vad är det som är The Next Big Thing™? Vem vill inte ha saker billigare, bättre, snabbare och kanske med flashigare grafer?

Varför bygger vi fortfarande datalager, egentligen? Finns det verkligen inte produkter som går att köpa som löser de problemen datalager är till för att lösa? Det beror på. Det går att kapa kostnader, korta ner leveranstiden, men det är vanligtvis någonting annat som måste uppoffras. Jag tänker på den berömda triangeln med låg kostnad, hög kvalitet och snabb leverans. Man kan inte få allt samtidigt. Därutöver finns det andra aspekter som man ofta överser, som t.ex. skiktad arkitektur.

Sila snacket! Vad får vi när vi bygger datalager?

Skiktad arkitektur
En skiktad arkitektur innebär att arkitekturen består av flera lager med olika roller och ansvar. Datalagring/integration, dataleverans/analys, applikationer/analys.

Ett datalager består av självaste datalagret som använder sig av standard-SQL. Varför är detta bra? För att det möjliggör användande av olika ovanpåliggande mjukvaruplattformar samtidigt som datat lagras på en plats och därmed följer samma definition. Om behov finns att köra Microsoft-kuber, Qlik eller Cognos är datalager en nödvändig komponent för att inte skapa en splittrad arkitektur, som ofta producerar olika resultat. Ovanpå datalagret kan t.ex. kuber byggas med eller utan en SQL-datamart. Eller Qlik, Cognos, eller ditt favoritverktyg. Varför inte Tableau?

Tolkad, modellerad data
En stor del av insatsen när ett datalager byggs är att förstå all data och hur den hänger ihop. Vi bygger en eller flera datamodeller både för att kunna lagra och leverera data till både applikationer och användare. Det skiljer sig t.ex. från ”big data” som applicerar en schema-on-read-metod, d.v.s. tolkning och processning av data vid behov.

Integrerad data
Data kommer normalt sett från många källor och integreras i datalagret (vi idenfierar vad som är vad) för att till exempel förädla kunddata genom att läsa olika data från olika system. Detta möjliggör parallell analys över flera källor vilket är en av de stora vinsterna med ett datalager. Om vi har försäljning i ett system och kundinformation i ett annat, kan vi analysera försäljning och bryta ner den på information som endast är tillgänglig i kundsystemet.

Tvättad data
Det är väldigt vanligt att data inte ser ut som man vill ha den vid analys. Data kan då tvättas och omformas till ett format som är användbart för olika syften. I datatvätt räknas även affärslogik in för att omvandla datat till information som är användbar, till exempel om en kund inte har en adress i ett system kan vi ta den ifrån en annan källa.

 

 

På Advectas har vi lång erfarenhet av att bygga datalager både till stora och medelstora bolag. Om du har frågor kring inlägget eller datalager i stort får du gärna kontakta mig, skicka ett email till stefan.verzel@advectas.se, telenr 0732 316 352.

 

Stefan Verzel
stefan.verzel@advectas.se
Mitt namn är Stefan Verzel och jag leder kompetensområdet Data Management på Advectas. Saker som stimulerar mig är till exempel programmering, analys, optimering och problemlösning. Vill du veta mer om Data Management, datalager eller hur man lödar ihop en snabb drönare, tveka inte att kontakta mig!

Alla inlägg av Stefan Verzel

Besvara den svenska Business Intelligence- & Data Science-studien 2019

Till enkäten