Data Warehouse

Data Warehouse er hjertet i de fleste applikationer og datamodeller.
Derfor fortjener platformen også ekstra opmærksomhed og ekspertise.

Se sandheden om jeres forretning. Og basér beslutninger på den

Det er afgørende at have ét sted, hvor forretningen er enige om, at dette er sandheden om vores virksomheds data.

Hvad er en kunde i vores virksomhed? Hvornår er et salg, et salg? Er det når ordren er afgivet, eller når varen er leveret?

Den indsigt kræver, at I træffer nogle beslutninger om jeres data; hvad er gældende? hvad skal de bruges til? Og hvordan sætter I dem i spil, i den rigtige data warehouse-løsning, så I kan trække effektivt på dem?

Hvordan arbejder du med et data warehouse?

I kan arbejde med Data Warehouse lag på forskellige måder. Vi benytter typisk SQL schemas til det, men hvis det er et meget stort setup, så kan det sagtens være, at lagene er delt i flere forskellige databaser.

Kimballs Data Warehouse metode introducerer også to typer af schemas: Star- og Snowflake schema.

Det hedder et star schema, fordi der er relation mellem en fact og flere dimensionstabeller, hvilket visuelt kan illustreres som en stjerne:

Få det rigtige grundlag til jeres Business Intelligence

Måske er jeres behov eller data for avancerede til basale transformationer, og så kan det være, vi skal skabe et snowflake schema. Det kommer helt an på jeres behov.

For vi tilgår et BI-projekt med den samme agilitet, som vi har fokus på i alle vores projekter. For jer betyder det, at vi sætter fokus på at bygge en platform og en datamodel, der styrker og flytter jeres forretning - uden at bygge noget, der er mere avanceret, end I behøver. For det er jer og jeres forretning, løsningen skal løfte.

Gå effektivt fra kilder til data

Processen fra kilder til Data Warehouse

Det er vigtigt, at træffe nogle beslutninger om jeres data, inden de transformeres og loades ind i et Data Warehouse. Det begynder typisk med at identificere en forretningsproces, hvor der skabes nogle facts og dimensionstabeller. Disse loades via ETL proces i SSIS (Extract, Transform Load).

Når man har identificeret, hvad det er, der skal måles på (facts,) så bygges processen, der integrerer data fra kilder til Data Warehouse. Data hentes fra kilder (NAV, AX, CRM osv.), transformeres og loades ind i Data Warehouse. Denne proces kaldes ETL, som står for Extract, Transform, load. Processen er ikke software afhængig, det kan gøres på mange måder.

I Unit IT bruger vi SQL Server Integration Service (SSIS) samt T-SQL til denne proces, når det er on-prem. I Azure er der yderligere mulighed for at bruge Data factory (SSIS i skyen), Data Lake, Azure automation, Data Bricks osv. Typisk styres ETL flowet af et SQL-job, som så afvikler SSIS pakkerne og opdaterer Data Warehouse data.

Data Warehouse koncept

Konceptuelt findes der to anerkendte metoder, som man kan ”bygge” et Data Warehouse på. Inmon og Kimball. De har en meget forskellig tilgang til opbygningen.

Inmon benytter normaliseret data model, hvor Kimball er bygget over et star schema.

Kimball er hurtigere og billigere at komme i gang med. Vi benytter Kimballs model for opbygning af et Data Warehouse, baseret på en Microsoft SQL Server.

Valget af software er ikke afhængigt af metoden man vælger, og man kan sagtens bygge efter Kimballs metode på Postgres, MySQL, Oracle osv.

I Unit IT har vi rigtig mange års erfaring med Microsoft SQL Server og opsætning, samt performance og vedligehold heraf, så derfor er vores software base til et Data Warehouse en Microsoft SQL Server, det kan både være on-prem og i Azure.

Skab en datadreven kultur med et optimeret Data Warehouse

Data Warehouse ”lag”

I vores Data Warehouse framework arbejder vi med lag til at styre processen. Extract, Archive, Staging, Dimension og Fact. (Disse er implementeret som SQL Schemas)

Extract:

Her hentes data direkte fra kilderne. Vi henter altid 1:1, det vil sige alle kolonner og alle rækker fra kilderne.
Første gang hentes alt fra kilden herefter læses der kun ændret data ud, dette giver et minimalt performance hit på kilderne, og er samtidig også en af de store gevinster ved et Data Warehouse.

Archive:

Her ligger data også 1:1. Arkivlaget opdateres fra extract-laget. Fordelen er, at der kan skabes en historik, som ikke nødvendigvis er på kilderne. Vi benytter en type 2 historik, som betyder, at vi gemmer rækken som den så ud, når den opdateres og indsætter en ny gældende række i arkivet. Fordelen er at arkivlaget altid afspejler, hvordan data så ud i et givent tidsrum. F.eks. en vare, der er på kampagne; her er gemt både prisen før, under og efter kampagnen så når der kigges i data, vil det altid afspejle den rigtige pris for denne vare på det pågældende tidspunkt.

Staging:

Dette Data Warehouse lag benyttes til at forberede data på vej mod dimension og fact tabellerne. Her begynder der at komme forretningslogik ind i processen, hvor extract og archive lagene er en kopi af kilderne 1:1 (med historik) så tages der stilling til hvilke kolonner og rækker der skal med samt fra hvilke tabeller.

Dimension:

Dimensionstabeller er tabeller som fortæller noget om det, vi vil måle på f.eks. en kunde. I tabellen ligger der informationer om navn, adresse, mail osv. Hver kunde får et unikt ID i Data Warehouse, dette ID skal bruges, når der refereres til kunden i fact-tabellen. Dimensionstabellen kan også have historik, typisk benyttes Type-2 historik.

Fact:

I disse tabeller ligger det data, der kan måles på, f.eks. prisen for en varer, et samlet salg. Ud over det, der kan måles på (altså tal der kan lægges sammen), så er der også referencer til det, som fortæller noget om, hvad der måles på, der er en ID fra den/de dimensionstabeller.

Den rigtige arkitektur er afgørende for et stærkt Data Warehouse

Konceptuelt kan et Data Warehouse, ikke en database, have forskellig arkitektur. Der kan være et centraliseret Data Warehouse, hvor alle rapporter og ad-hoc forespørgsler trækker på en og samme database. Denne arkitektur er meget almindelig at benytte som opstart. Det er også muligt at bygge et Data Warehouse med flere ”Data Marts” – f.eks. lavet til forskellige afdelinger, eller dele af firmaet – Et Data Mart er flere databaser som hver indeholder en lille del af Data Warehouse. Endelig kan der også være et centraliseret Data Warehouse, hvor der hentes data fra til Data Marts det kaldes hub-and-spoke arkitektur.

Data Warehouse er ikke et stykke software, men et koncept. Så om det ligger i Azure eller på egne servere er underordnet. Laves et Data Warehouse i Azure, så er der også her flere forskellige løsningsmuligheder for at implementere det. I Azure er der nogle tools, som kan gøre det lettere at samle data fra forskellige devices f.eks. ved brug af data lakes eller data factory. Microsoft Azure har også en komplet løsning; Azure Synapse, som er ideelt til big data. Vi vejleder meget gerne om den helt rigtige løsning baseret på dit behov og datamængde.

Der bliver i de fleste virksomheder over tid trukket flere og flere rapporter på kilde systemerne, disse rapporter kunne være udstillet i Power BI, i Reporting Services (SSRS) eller direkte fra Excel. Ved øget rapportbrug belastes kildesystemerne mere og mere. Ved at bygge et Data Warehouse flyttes belastningen af rapportforespørgsler fra kildesystemerne over til Data Warehouse. En anden gevinst ved at bygge et Data Warehouse er, at virksomheden bliver bevist om sine data og får et fælles billede af f.eks. en kunde, et salg osv. I Data Warehouse forberedes data og kommer ind i en model, der er lavet til netop rapportering. Vi benytter primært Power BI, men det kan udstilles i alt software lavet til at vise rapporter.

I Unit IT har vi vores eget Data Warehouse framework, som er bygget efter mange års erfaring med SQL Server drift. Det er vigtigt at have et godt fundament, når et Data Warehouse skal skabes. Desuden har vi udviklet vores egne værktøjer, som bl.a benytter BIML express til hurtigt at trække data ud fra langt de fleste kildesystemer. Det vil sige, at vi altid bygger Data Warehouses på den samme måde, men er alligevel fleksible og tilpasser altid løsningen efter jeres behov – vi vil ikke bygge en raket, hvis behovet kan dækkes af en papirsflyver. Raketten kan altid komme, og vores løsning er designet til at fungere både til mindre Data Warehouses og til de helt store.

Det kræver selvfølgelig viden om at udvikle i SQL, hvis I selv vil rette i back-end, eller viden om Power BI, hvis der skal rettes i rapporten. Vi hjælper gerne med det og deler også meget gerne vores viden med jer, så I er så godt klædt på som muligt. Udviklingen af et Data Warehouse er et tæt samarbejde mellem Unit IT og jeres forretning, hvor viden forankres hos jer, hvis I ønsker det. Vi kan også stå for det hele både udvikling, test og drift. Det kommer helt an på, hvad jeres behov er ,og hvilke kompetencer I har hos jer. Vi er gode til at dele vores viden og laver derfor gerne kurser eller sidemandsoplæring for at højne vidensniveauet i huset.

Det tager selvfølgelig tid at bygge et Data Warehouse, både at forstå jeres forretning og blive enige om en datamodel der passer til jer. Vi skal beslutte hvilken Data Warehouse arkitektur, der skal benyttes, og om vi skal bygge på jeres servere, hos en host eller i Azure.

Ved at benytte Kimballs model kan et Data Warehouse bygges væsentligt hurtigere og til en noget lavere startomkostning end ved at bruge Inmons model. Kimballs model er også skalerbar, så det giver god mening at starte småt med en proces, der skaber værdi for jeres forretning, og som er relativt hurtig at implementere. Det giver hurtig værdi, når I begynder at få et fælles billede af data.

Et Data Warehouse er en samling af data, designet til at gøre det muligt at foretage målinger. Det er ikke en enkeltstående softwareløsning, men snarere et integreret system af forskellige softwaretyper. Hos Unit IT anvender vi for eksempel Microsoft SQL Server som databasen og bruger ofte Microsoft Power BI til at udarbejde rapporter.

Et Data Warehouse er ikke en database, men et Data Warehouse ligger fysisk i en eller flere databaser alt efter, hvordan det er sat op.