For de fleste, om ikke alle organisasjoner, er data den viktigste forretningsressursen. Vi har tidligere sett på hva et moderne datavarehus innebærer og hvordan vurdere om man trenger det. Nå skal vi ta et steg videre og dykke ned i hvordan man kan bygge et moderne datavarehus i Microsoft Azure!
Målet med implemententering av et datavarehus
Å bygge og implementere et moderne datavarehus kan ta opptil tre år, og med tanke på alle aspektene du bør fokusere på, er det rett og slett ikke mulig å implementere hele løsningen på en gang. Det er derfor fornuftig å strukturere implementeringen av datavarehuset i mindre deler. Du vil med andre ord implementere datavarehuset ditt i faser, hvor hver fase har sine egne mål og krav.
Med det i tankene kan målene for den første fasen din typisk se slik ut:
- Bygg en sentral, enhetlig datamodell som utnytter data fra én enkelt virksomhet eller operasjonsområder som salg, markedsføring eller menneskelige ressurser, men som tilstrekkelig tillater utvidelse til andre operasjonsområder i fremtiden.
- Integrer data fra ditt største forretningssystem i datavarehuset.
- Gjør data tilgjengelig innen et spesifisert lokalt tidspunkt uavhengig av når dataene samles inn eller type data.
- Nye data fra ditt forretningssystem bør regelmessig lastes inn i datavarehuset.
- Data i datavarehuset bør være klargjort for bruk av alle ansatte på tvers av organisasjonen, og sikkerhetsinnstillinger sikrer at dataforbrukere har tilgang til relevante data og er skjermet fra data som ikke er relevante.
- Den analytiske modellen som vil gi deg verdifull innsikt i dataene dine, vil inneholde enorme mengder historiske forretningsdata.
- Utvikle et oversiktsdashbord for det spesifikke forretningsområdet med alle sikkerhetstiltak tatt i bruk og som reagerer på mindre enn noen få sekunder.
Selv om disse målene kan variere litt avhengig av dine spesifikke behov og krav, er dette ofte standardmål for mange datavarehusimplementeringer. Som du kan forestille deg, krever de imidlertid mye arbeid og kommer med et sett med utfordringer du må overvinne for å gjøre implementeringen din til en suksess.
Med det i tankene, la oss se på prosessen med å implementere et datavarehus for bedrifter.
Typisk moderne datavarehus arkitektur
For å se på implementeringsprosessen tar vi for oss hver komponent i en typisk moderne datavarehusarkitektur i Microsoft Azure. I dette eksemplet vil Microsoft Azure-arkitekturen bestå av:
- SQL Server som datakilde
- Blob-lagring i form av Azure Data Lake Gen 2 for lagring av data før de lastes inn i datavarehuset.
- SQL Elastic pool for å utføre analyser på enorme mengder data.
- Azure Analysis Services for å tilby datamodelleringsfunksjoner.
- Azure Active Directory for å autentisere brukere som kobler til Azure Analysis Services gjennom Power BI.
Vil du jobbe med data og analyse? Vi søker BI- og Analytics-konsulenter! Se ledige stillinger her!
Slik skaffer du data
Som nevnt ovenfor er et av de første målene med å implementere et datavarehus å bygge en sentral, enhetlig datamodell som bruker data fra et enkelt operasjonsområde. Du må også integrere data fra ditt største forretningssystem i datavarehuset.
For å gjøre dette, må du kombinere alle strukturerte, ustrukturerte og semistrukturerte data. Vanligvis vil ustrukturerte data bestå av logger, filer og ulike typer medier. På den annen side vil strukturerte data være dataene du får fra forretningsapplikasjonene dine som CRM, markedsføringsplattform eller salgsplattform. Som nevnt tidligere, i dette eksemplet vil vi bare bruke én datakilde.
Lagring av dataene
Når du vet hvordan og hvilke data du vil ta inn i datavarehuset ditt, er neste trinn å trekke ut alle dataene fra de respektive kildene til filer. Her vil du møte en av hovedutfordringene med et moderne datavarehus: hvordan lagrer du data effektivt?
For å svare på dette spørsmålet må du vanligvis vurdere tre viktige ting:
- Hvor du skal lagre filene og hvordan du skal strukturere og organisere dem.
- Hvordan du vil dele filene og hvor mye data hver fil skal inneholde.
- Hvilket filformat du vil trekke ut dataene til.
La oss se på disse spørsmålene mer detaljert.
1. Hvor vil du lagre filene og hvordan vil du strukturere og organisere dem?
Det er svært viktig å planlegge hvordan dine ustrukturerte, semistrukturerte og strukturerte rådata fra datakildene dine skal lagres. Vanligvis, når du implementerer et moderne datavarehus på Microsoft Azure, kan du lagre filene dine i en data lake eller Blob-lagring.
Blob storage er Microsofts objektlagringsløsning for skyen. Den er spesielt designet og optimalisert for lagring av store mengder ustrukturerte data. Den er fullt i stand til å:
- Viser bilder, filer eller dokumenter direkte til en nettleser.
- Lagre filer for distribuert tilgang på tvers av en hel bedrift.
- Streaming av video og lyd.
- Skrive data til loggfiler.
- Lagring av data for sikkerhetskopiering og gjenoppretting, arkivering eller katastrofegjenoppretting.
- Lagre data for analyse av en Azure-hosted eller on-prem dataanalyseløsning.
I kontrast, bygget på Azure Blob Storage, har Azure Data Lake Storage Gen2 et sett med funksjoner som er spesifikt rettet mot big data-analyse. Den kombinerer effektivt egenskapene til Azure Data Lake Storage Gen1 med Azure Blob Storage. Som gir Data Lake Storage Gen 2:
- Et hierarkisk filsystem
- Filsystem semantikk
- Sikkerhet på filnivå
- Skalerbarhet
- Lavpris, lagdelt lagring
- Høy tilgjengelighet
- Sterk konsistens
- Muligheter for gjenoppretting etter katastrofe
Selv om valget av riktig lagringsløsning avhenger av dine spesifikke behov og krav, er moderne datavarehus designet og implementert med tanke på big data-analyse. Som sådan, når du implementerer et moderne datavarehus, kan Azure Data Lake Storage Gen 2 være det mest passende valget.
Når du velger å implementere det, vil du vanligvis nyte følgende fordeler:
- Sentralisert tilgang til en replika av dataene i de ulike datakildene
- Ytelsen til datavarehuset ditt vil bli optimalisert fordi du ikke trenger å kopiere eller transformere data som et krav for analyse. Hvis du sammenligner dette med Blob Storage sitt flate navneområde, lar det hierarkiske navneområdet deg forbedre den generelle ytelsen ved å forbedre ytelsen til administrasjonsoppgaver.
- Databehandling blir enklere fordi du kan organisere dataene dine i mapper og undermapper.
- Fordi du kan definere POSIX-tillatelser på mapper eller individuelle filer, kan sikkerhet håndheves.
- Fordi den er bygget på Azure Blob-lagring som er lavkostnadsdesignet, er den svært kostnadseffektiv og tilleggsfunksjonene reduserer eierkostnadene ytterligere.
2. Hvordan vil du dele filene og hvor mye data vil hver fil inneholde?
Når du har bestemt deg for hvilken lagringsløsning du skal bruke, er den neste viktige tingen du må bestemme deg for, og planlegge hvordan dataene i data laken skal struktureres. Med andre ord, du må planlegge hvilke mapper du skal bruke til å lagre dataene i, hvordan disse mappene skal deles opp, og hvordan du navngir mappene og individuelle filer.
Det er avgjørende at du planlegger disse aspektene nøye, da de til syvende og sist vil avgjøre hvor enkelt du vil være i stand til å navigere gjennom dataene som er lagret i data laken.
Det neste trinnet vil være å planlegge hvordan du skal dele filene og hvor mye data hver fil skal inneholde. Her må du vanligvis vurdere mengden data du allerede har, og hvor raskt volumet av dataene dine øker. Ved å bruke denne informasjonen kan du bestemme hvordan du deler data i filer.
For eksempel, med ordbokdata vil du vanligvis bruke én fil for alle dataene i en ordboktabell, uavhengig av hvor mye data tabellen lagrer. I motsetning til dette, med transaksjonsdata, har du valget mellom å lagre data i én dag, én måned, ett år eller lengre eller kortere avhengig av dine spesifikke behov og krav.
3. Hvilket format vil du bruke for å ta uttrekk av data?
Den neste avgjørelsen du vil bli møtt med, er hvilket format du vil bruke for å trekke ut dataene til. Selv om dette kan høres ut som et enkelt valg, er det avgjørende å få det riktig ettersom filformatet har en betydelig innvirkning på den endelige datastørrelsen.
Vanligvis vil du ha et valg mellom følgende filformater:
- Avro format
- Binært format
- Avgrenset tekstformat
- Excel-format
- JSON-format
- ORC-format
- Parquet format
- XML-format
Bruk av dataene fra datavarehuset i Microsoft Azure
Husk at det endelige målet med å ha et moderne datavarehus bygget på Microsoft Azure er å levere dataene til for eksempel et Microsoft Power BI-dashbord på tvers av bedriften. For å oppnå det, må du laste filene i data laken inn i datavarehuset.
Her bruker du Polybase til å laste filene inn i datavarehuset. Den bruker Azure Synapses Massively Parallel Processing (MPP) som gjør det til den raskeste måten å laste data inn i Azure Synapse.
Å laste inn data til Azure Synapse er en to-trinns prosess. I løpet av det første trinnet oppretter du et sett med eksterne tabeller for dataene. Disse eksterne tabellene er bare tabelldefinisjoner som peker på data lagret utenfor Azure Synapse, i vårt tilfelle, i data laken. Det er viktig å merke seg at dette trinnet ikke flytter noen data inn i lageret.
I løpet av neste trinn oppretter du oppsamlingstabeller og laster dataene inn i disse oppsamlingstabellene. I løpet av dette trinnet kopieres dataene til lageret. Når dataene er kopiert til Azure Synapse, vil du transformere dataene og flytte dem til produksjonstabeller som er egnet for semantisk modellering.
Deretter laster du dataene inn i en tabellmodell i Azure Analysis Services. I løpet av dette trinnet vil du vanligvis lage en semantisk modell ved hjelp av SQL Server Data Tools (SSDT). Her har du også muligheten til å lage en semantisk modell ved å importere den fra en Power BI Desktop-fil.
Det er viktig å huske på her at du må legge til relasjonene til den semantiske modellen slik at du kan slå sammen data på tvers av tabeller. Dette er ganske enkelt fordi Azure Synapse ikke støtter fremmednøkler. Når du er ferdig med dette trinnet, vil du kunne visualisere dataene dine i Power BI.
Power BI har to alternativer for å koble til Azure Analysis Services slik at du kan visualisere dataene dine. Den første er å importere dataene dine til Power BI. Det andre alternativet er å bruke Live Connection der Power BI henter data direkte fra Azure Analysis Services.
Selv om valget til syvende og sist avhenger av dine spesifikke behov og krav, anbefales det å bruke Live Connection fordi du ikke trenger å kopiere data til Power BI.
Når du visualiserer dataene dine, er det også noen ting du må vurdere. For det første er Azure Analytics Services spesielt utviklet for å håndtere forespørsler om kravene til et Power BI-dashbord. Som et resultat er det en anbefalt praksis å spørre Azure Analytics Services direkte fra Power BI.
Med tanke på det ovennevnte, er den andre tingen du må huske på at du bør unngå å kjøre spørringer direkte mot datavarehuset. Dette kan påvirke ytelsen ettersom oppdatering av dashbordet vil telle mot antallet samtidige søk.
Utvide mulighetene og funksjonene
Vi nevnte tidligere at et moderne datavarehus bør implementeres i faser og vårt eksempel ovenfor illustrerer perfekt hvordan den første fasen av implementeringen kan se ut. Så, hvordan ser implementeringen ut i senere stadier når vi ønsker å inkorporere flere funksjoner i datavarehuset?
I dette eksemplet bygger vi på det forrige eksemplet og legger til noen viktige funksjoner som er avgjørende for moderne implementering av datavarehus. Disse funksjonene inkluderer:
- Automatisering av pipeline ved hjelp av Data Factory.
- Inkrementell lasting av data.
- Integrering av data fra flere kilder.
- Laste inn og bruke binære data som geospatiale data, bilder og andre medier.
I dette eksemplet består Azure-arkitekturen av:
- Lokale SQL Server og eksterne data som datakilder.
- Blob-lagring for lagring av data før de lastes inn i Azure Synapse.
- Azure Data Factory for å orkestrere og automatisere bevegelse og transformasjon av data og koordinere de ulike stadiene av uttrekk, last, transformasjon (ELT) prosessen.
- Azure Analysis Services som gir datamodelleringsfunksjoner.
- Power BI for dataanalyse.
- Azure Active Directory for å autentisere brukere som bruker Power BI for å koble til Azure Analysis Services.
Data pipeline og inkrementell lasting
For å få inn dataene dine i datavarehuset, bruker du Data Factory pipeline. Disse pipelinene er logiske grupperinger av aktiviteter som fungerer sammen for å utføre en spesifikk oppgave. For eksempel kan en pipeline inneholde et sett med aktiviteter som tar inn og renser data fra en rekke systemer og deretter starter en dataflyt for å analysere disse dataene.
Et annet eksempel kan være når du bruker en kopieringsaktivitet til å kopiere eksterne data fra for eksempel en SQL-database til Azure Blob Storage. Dette ligner på vårt eksempel der vi bruker en pipeline for å laste og transformere data til Azure Synapse.
En av hovedfordelene ved å bruke disse rørledningene er at det lar deg administrere aktivitetene sammen i stedet for hver enkelt. Du distribuerer og planlegger derfor pipelinen i stedet for å distribuere hver aktivitet uavhengig.
I motsetning til vårt første eksempel, vil denne arkitekturen også implementere inkrementell lasting av data. Når du bruker en automatisert ELT-prosess, er det langt mer effektivt å laste kun nye data, eller med andre ord kun data som har endret seg, inn i datavarehuset sammenlignet med å laste inn alle dataene.
Også kjent som systemversjonstabeller, gir disse tabellene informasjon om dataene som er lagret i tabellen til enhver tid. Den gjør dette ved automatisk å registrere historikken til alle endringer i en egen historietabell. Fra et ETL-perspektiv kan du deretter spørre etter de historiske dataene for å avgjøre om en inkrementell belastning skal utføres.
Til syvende og sist vil Data Factory utføre en inkrementell belastning hvis det er noen endringer. Husk at etter at en ny batch med data er lastet inn i lageret, må du oppdatere Analysis Services-tabellmodellen. Det er også viktig å huske på at datarensing bør være en del av ELT-prosessen for å sikre data av god kvalitet.
Flere datakilder
I motsetning til vårt første eksempel, skal vi nå inkorporere flere datakilder. Her vil datafabrikken din organisere og koordinere utvinningen av data fra de eksterne kildene til vår Blob-lagring eller Azure Data Lake Storage Gen 2 ved å bruke en kopiaktivitet for å flytte dataene fra både lokale og skydatakilder. Som før kan du kopiere data til data laken i et av filformatene nevnt tidligere.
Herfra kan den kopiere data direkte til Azure Synapse ved å bruke blob-lagringskontakten. Det er imidlertid viktig å huske på at blob-lagringskoblingen bare støtter visse autentiseringstyper som kontonøkkelautentisering, autentisering av delt tilgangssignatur og systemtilordnet administrert identitetsautentisering, blant annet.
Så krever den en tilkoblingsstreng eller delt tilgangssignatur og kan derfor ikke brukes til å kopiere en blob med offentlig lesetilgang. For en blob med offentlig lesetilgang, må du bruke Polybase til å opprette en ekstern tabell over blob-lagringen og kopiere den eksterne tabellen til Azure Synapse.
Binære data
Når du arbeider med binære data, vil Data Factorys Copy Activity også kunne kopiere fra datakilden til data laken og videre til Azure Synapse. Det er imidlertid viktig å merke seg at når du bruker kopieringsaktiviteten, kan du bare kopiere fra binære data til binære data.
Du bør også huske på at når du bruker Polybase som en løsning beskrevet ovenfor, støtter den kun maksimale kolonnestørrelser på 8000 byte. I dette tilfellet må du dele opp dataene i mindre biter under kopiering og deretter sette sammen bitene igjen etter at kopieringen er ferdig.
Til slutt
Det er ingen hemmelighet at i dagens konkurranseutsatte marked er smidighet helt avgjørende for suksess. Ikke bare lar det organisasjoner tilpasse seg endrede markedsforhold og dra nytte av forretningsmuligheter når de oppstår, men det gjør dem også mer effektive.
Så når du ønsker å gi organisasjonen smidigheten og fleksibiliteten som kreves av dagens konkurranseutsatte marked, er det viktig at du implementerer eller moderniserer datavarehuset ditt. Den lar deg kombinere dataene fra alle operasjonsområdene dine til én kilde til sannhet og gir deg økt skalerbarhet, fleksibilitet og automatiseringsevner.
Forhåpentligvis hjalp dette innlegget med å illustrere hvordan du kan implementere et moderne datavarehus. For å lære mer om moderne datavarehus eller om hvordan vår automatiserte, lavkode, dra-og-slipp Data Estate Builder kan hjelpe deg med å implementere og drifte et moderne datavarehus uten å skrive noen kode, besøk nettstedet vårt for mer informasjon.