Fra kilder til data
Processen fra kilder til Data Warehouse
Det er vigtigt at have ét sted, hvor forretningen er enige om, at dette er sandheden om vores 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? Det er vigtigt at træffe nogle beslutninger om data inden de transformeres og loades ind i et Data Warehouse. Dette starter 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 det er 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.) og 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 2 anerkendte metoder at ”bygge” et Data Warehouse på. Inmon og Kimball. De har en meget forskellig tilgang til opbygningen af et Data Warehouse. Inmon benytter normaliseret data model, hvor Kimball er bygget over et star schema. Kimball er bl.a. også hurtigere og billigere at komme i gang med end inmons metode. I unit IT benytter vi 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, 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
Find klarhed i data,
når du har mest brug for det
Giv teammedlemmer mulighed for at opdage indsigter, der er skjult i dine data.
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:
Dimensions tabeller 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, typiske 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.
Download Power BI
Har din virksomhed også et ønske om, at du og resten af it-afdelingen fokuserer mere direkte på forretningen fremfor på teknikken?
Download gratis Power BI
Hvordan arbejder du
med et data warehouse?
Der kan arbejdes 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.
Et star schema hedder det fordi der er relation mellem en fact og flere dimensionstabeller, hvilket visuelt kan illustreres som en stjerne:
Gør det til en fordel at benytte star schema
SQL Serveren kan genkende star schema strukturen og kan derved optimere sine forespørgsler, hvilket gør det til en fordel at benytte star schema i sin Data Warehouse arkitektur. Dette vil være med til at øge performance.
Data Warehouse bygget
på kimballs metode
Da det typisk ikke er normaliseret data i et Data Warehouse bygget på kimballs metode der kan dog nogle gange være behov for at referere mellem 2 eller flere dimensionstabeller, når man har denne struktur, kaldes det et snowflake schema.
- Power BI er en nem og hurtig måde at komme i gang med at visualisere data på.
- Træf beslutninger ud fra data og ikke mavefornemmelse.
- Data understøtter beslutninger på strategisk-, taktisk- og operationelniveau.
Data Warehouse arkitektur
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. Illustreret her i dette Data Warehouse arkitektur diagram:
Data Warehouse i Azure
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 at 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 det helt rigtige løsning baseret på dit behov og datamængde.
Hvorfor bygge et Data Warehouse?
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.
Hvordan bygges et Data Warehouse?
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 ret fleksible og tilpasser altid løsningen efter kundernes 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.
Kræver det specialviden at administrere et Data Warehouse?
Det kræver selvfølgelig viden om at udvikle i SQL hvis I selv vil rette i backend, 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 er så godt klædt på som muligt. Udviklingen af et Data Warehouse er et tæt samarbejde mellem Unit IT og forretningen, hvor viden forankres i forretningen også hvis det er ønsket. Unit IT kan også stå for det hele både udvikling og test og drift, det kommer helt an på hvad jeres behov er og hvilke kompetencer der er i virksomheden. Vi er gode til at dele vores viden og laver derfor gerne kurser eller sidemandsoplæring for at højne vidensniveauet i huset.
Tager det lang tid at bygge?
Det tager selvfølgelig tid at bygge et Data Warehouse, både at forstå forretningen og blive enige om en datamodel internt i virksomheden, der skal besluttes hvilken Data Warehouse arkitektur der skal benyttes, og besluttes om det skal bygges på virksomhedens 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 forretningen og som er relativt hurtig at implementere, dette giver værdi til brugerne og virksomheden begynder at få et fælles billede af data.
”Folkene hos Unit IT er fagligt yderst kompetente, og for mig er der ingen tvivl om, hvad de står for: professionalisme og skarphed. De er dygtige mennesker, der kan sætte det rigtige hold til den opgave, de står overfor.”
Certificeringer
Microsoft Solutions Partner
Unit IT har opnået status som Microsoft Solutions Partner i Azure. For at opnå titlen er der krav til et højt kompetenceniveau, høj kundetilfredshed og gennemarbejdet dokumentation for veludført arbejde.
Danish Cloud Community
Vi er certificeret medlem af Danish Cloud Community i perioden 16.03.18 – 15.03.19, som dokumenterer at Unit IT efterlever krav om høj kvalitet og sikkerhed inden for kommerciel drift af forretningskritiske it-ydelser samt skaber øget gennemsigtighed for købere af disse ydelser.
