Lager i ett data warehouse

De flesta BI-lösningar brukar vara lämpliga att strukturera i flera lager. I det här inlägget beskrivs hur detta kan göras.

Arkitekturen ovan är ett beprövat designmönster för större datalager. I många fall kan det förenklas, i andra fall kan det behövas utvidgas med flera landningsytor för olika källsystem samt flera analyslager, åtkomstlager och kuber för olika analysbehov eller krav på stabilitet samt sekretess.

Ett populärt begrepp på senare tid är medaljarkitektur, där de centrala lagren benämns brons, silver och guld, med ökande förädlingsgrad och lättillgänglighet för analys. Guld är det viktigaste lagret, men som tvåa håller jag rålagret: brons.

Landningsyta

Landningsyta (ofta kallad Stage) är där data från källsystemen först landar. Där görs ofta en teknisk kvalitetskontroll för att hindra att grovt felaktigt data laddas vidare in i datalagret. Landningsytan kan vara till stor hjälp för att felsöka problem med indata och återrapportera till källan för åtgärd.

I landningsytan görs ingen transformation av data, utan data där ska spegla vad som levererats.

Rålager

Ett rålager är i princip en kopia av landningsytan med historik. Normalt tillförs ytterligare data som tidpunkt för inläsning, källsystem etc. Rålagret kan vara implementerad som en SQL-databas, men trenden går mot data lakes. Normalt görs ingen tvättning och transformering av data i ett rålager, då det riskerar att förvanska informationen.

Både landningsyta och rålager är relativt billiga att bygga och underhålla, då både datastruktur och laddningsprocedurer kan skapas med automatik utifrån metadata som beskriver data från källsystemen. Datamängden i ett rålager kan dock bli betydande, men moderna verktyg blir allt bättre på att hantera stora datamängder.

Ett rålager är inte tänkt för analys, men visst initialt utforskande kan ske där för att undersöka datakvalitet och hur informationen ska modelleras i efterkommande lager. Allt data i ett rålager kanske inte går vidare, utan sparas bara för eventuell användning i framtiden eller analyser ad-hoc.

Grundlager

Ett grundlager eller Enterprise Data Warehouse (EDW) kan vara lämpligt i större datalager. Där transformeras data till en form som kan vara till grund för senare lager. Det är särskilt användbart för data som sammanställs från flera källsystem där man vill ha en gemensam bild, till exempel ett kundregister med uppgifter från både ekonomi- och CRM-system där även potentiella kunder ingår, eller redovisningsdata från flera olika ekonomisystem, vilket är vanligt i företag med flera dotterbolag. Data i grundlagret är ofta kvalitetssäkrat.

Det kan dock vara svårt och kostsamt att ta fram en generell datamodell för ett grundlager som täcker alla behov. Därför skippar man ofta grundlagret och analyslagret läser data direkt från rålagret eller landningsytan. Rålager har på senare tid ofta ersatt behovet av grundlager.

Ett grundlager är ofta modellerat med en normaliserad relationsmodell (3NF) eller en Data Vault-liknande modeller. Data där är inte avsett för analys, utan ska vara en konsoliderad källa för följande lager.

Analyslager

Analyslager, även kallat data mart, innehåller data strukturerat för analys, ofta i form av en dimensionsmodell, även kallad stjärna. I större organisationer kan det vara lämpligt med flera analyslager för olika analysområden, till exempel ekonomi, säljanalys och kvalitetsuppföljning.

Åtkomstslager

Ofta vill man ha ett isolerande lager mellan analyslagret och konsumenterna. Det kan bestå av vyer eller lagrade procedurer i SQL. En fördel med detta är att man tydligt kan se vilket data olika konsumenter använder, så att man enkelt kan bedöma konsekvenser av förändringar i analyslagret.

Ett åtkomstslager kan ägas av det konsumerande systemet och de kan då själva göra förändringar där utan att riskera stabiliteten i analyslagret eller påverka övriga konsumenters rapportering. Erfarenhetsmässigt är också ett lager av SQL-frågor smidigt vid utveckling och test, då de är enkla att modifiera.

Ofta Ändrar man namnsättningen kolumner och värden så att de går direkt att använda i rapporter. Till exempel kan man tillåta mellanslag i kolumnnamn och byta ut koderna 1 och 0 till ”Ja” och ”Nej”.

Kuber

Kuber är analyslager optimerade för bra prestanda och enkel analys utan behov av att skriva SQL. Dessa byggs på databasteknik optimerad för analys av data i stjärnor, ofta kolumnorienterade (tabulära) databaser.

I kuber kan man ytterligare finslipa vad användarna ser och dölja tekniska tabeller och kolumner, och bara visa vad som är relevant för användarna.

Ofta skapas beräknade mätvärden i en kub, men transformeringar på radnivå (beräknade kolumner) görs oftast enklast redan i åtkomstslagret.

Varje kub bör ha sitt eget åtkomstslager, implementerat som en egen databas eller eget schema i en gemensamt åtkomstslager. Eftersom åtkomstslagren inte lagrar något data, ger det ingen duplicering av data.

Rapporter

Rapporter är ofta sista lagret mot användarna. Rapporter kan läsa data från kuber eller direkt från ett åtkomstlager. I rapporter kan ytterligare rapportspecifika mätvärden skapas. Det är också vanlig att ändra formatering på vissa värden. Men överlag bör de flesta generella transformeringar göras i åtkomstslager eller i kuber.

Annan segmentering

Utöver den här beskrivna skiktningen av ett datalager, kan det även segmenteras ämnesvis på andra ledden. Det är vanligt att analyslagret och följande lager delas upp efter olika analysområden, till exempel: sälj, ekonomi och verksamhetsuppföljning. På indatasidan kan landningsytan delas upp efter källsystem.

Det kan även finnas andra skäl att dela upp dataflödet, till exempel av stabilitetsskäl. Ekonomidata till kvartalsrapporten måste alltid fungera, medan de som analyserar säljkampanjer kanske prioriterar flexibilitet framför extrem stabilitet.

Slutord

Historisk har det varit vanligt att datalager byggs som en stor databas. Men att bryta upp system i mindre delar är en beprövad teknik för att bygga IT-lösningar som är mer flexibla, robusta och enklare att förvalta. Idag är datalagring billigt, så duplicering av en del information är inte så kostsamt. Dessutom är vissa lager virtuella och ger ingen ökad lagrad datamängd. Den stora kostnaden för datalager är ofta utveckling och underhåll. Därför bör designen prioritera att minska kostnaden där.

Man bör aldrig skapa lager och segment som inte fyller en väsentlig funktion. En enkel design är alltid något att sträva efter.