Hur bygger man ett modernt datalager i Microsoft Azure?

För de flesta, om inte alla organisationer, är data den viktigaste affärsresursen. Vi har tidigare tittat på vad ett modernt datalager innebär och hur man bedömer om det behövs. Nu ska vi ta ett steg längre och djupdyka i hur man bygger ett modernt datalager i Microsoft Azure!

Målet med att implementera ett datalager

Att bygga och implementera ett modernt datalager kan ta upp till tre år och med tanke på alla aspekter du bör fokusera på är det helt enkelt inte möjligt att implementera hela lösningen på en gång. Det är därför vettigt att strukturera implementeringen av datalagret i mindre delar. Du vill med andra ord implementera ditt datalager i faser, där varje fas har sina egna mål och krav.

Med det i åtanke kan målen för din första fas vanligtvis se ut så här:

• Bygg en central, enhetlig datamodell som använder data från en enskild verksamhet eller verksamhetsområde som försäljning, marknadsföring eller mänskliga resurser, men som på ett adekvat sätt tillåter expansion till andra verksamhetsområden i framtiden.
• Integrera data från ditt största affärssystem i datalagret.
• Gör data tillgänglig inom en angiven lokal tid oavsett när data samlas in eller typ av data.
• Ny data från ditt affärssystem bör regelbundet laddas in i datalagret.
• Data i datalagret bör förberedas för användning av alla anställda i hela organisationen, och säkerhetsinställningar säkerställer att data-användare har tillgång till relevant data och är skyddade från data som inte är relevant.
• Den analytiska modellen som ger dig värdefull insikt i din data kommer att innehålla enorma mängder historisk affärsdata.
• Utveckla en dashboard med översikt för det specifika affärsområdet med alla säkerhetsåtgärder implementerade som svarar på mindre än några sekunder.

Även om dessa mål kan variera något beroende på dina specifika behov och krav, är dessa ofta standardmål för många datalagerimplementeringar. Som du säkert kan föreställa dig kräver de dock mycket arbete och kommer med en rad utmaningar som du måste övervinna för att din implementering ska bli framgångsrik.

Med det i åtanke, låt oss titta på processen för att implementera ett datalager för företag.

Typisk modern datalagerarkitektur

För att titta på implementeringsprocessen överväger vi varje komponent i en typisk modern datalagerarkitektur i Microsoft Azure. I det här exemplet kommer Microsoft Azure-arkitekturen att överleva:

• SQL Server som datakälla
• Blob-lagring i form av Azure Data Lake Gen 2 för lagring av data innan den läses in i datalagret.
• SQL Elastic pool för att utföra analyser på enorma mängder data.
• Azure Analysis Services för att tillhandahålla datamodelleringsfunktioner.
• Azure Active Directory för att autentisera användare som ansluter till Azure Analysis Services via Power BI.

Så skaffar du data

Som vi har nämnt ovan är ett av de första målen med att implementera ett datalager att bygga en central, enhetlig datamodell som använder data från ett enda verksamhetsområde. Du behöver också integrera data från ditt största affärssystem i datalagret.

För att göra detta måste du kombinera all strukturerad, ostrukturerad och semistrukturerad data. Vanligtvis kommer ostrukturerad data att bestå av loggar, filer och olika typer av media. Å andra sidan kommer strukturerad data att vara den data du får från dina affärsapplikationer som CRM, marknadsföringsplattform eller försäljningsplattform. Som nämnts tidigare kommer vi i detta exempel bara att använda en datakälla.

Lagring av data

När du vet hur och vilken data du vill ta in i ditt datalager är nästa steg att extrahera all data från respektive filkällor. Här möter du en av huvudutmaningarna med ett modernt datalager: hur lagrar du data effektivt?

För att svara på denna fråga behöver du vanligtvis överväga tre viktiga saker:

1. Var man lagrar filerna och hur man strukturerar och organiserar dem.
2. Hur du vill dela filerna och hur mycket data varje fil ska innehålla.
3. Vilket filformat du vill extrahera data till.

Låt oss titta närmare på dessa frågor.

1. Var vill du lagra filerna och hur vill du strukturera och organisera dem?

Det är väldigt viktigt att planera hur din ostrukturerade, semistrukturerade och strukturerade rådata från dina datakällor kommer att lagras. Vanligtvis när du distribuerar ett modernt datalager på Microsoft Azure kan du spara dina filer i en datasjö eller Blob-lagring.

Blob storage är Microsofts objektlagringslösning för molnet. Den är speciellt designad och optimerad för att lagra stora mängder ostrukturerad data. Den är fullt kapabel till:

• Visa bilder, filer eller dokument direkt i en webbläsare.
• Spara filer för distribuerad åtkomst över ett helt företag.
• Streaming av video och ljud.
• Skriv data till loggfiler.
• Lagring av data för säkerhetskopiering och återställning, arkivering eller katastrofåterställning.
• Spara data för analys av en Azure-värd eller lokal dataanalyslösning.

Däremot, byggd på Azure Blob Storage, har Azure Data Lake Storage Gen2 en uppsättning funktioner specifikt inriktade på big data-analys. Den kombinerar effektivt funktionerna i Azure Data Lake Storage Gen1 med Azure Blob Storage. Vilket ger Data Lake Storage Gen 2:

• Ett hierarkiskt filsystem
• Filsystems semantik
• Säkerhet på filnivå
• Skalbarhet
• Låg kostnad lagring i lager
• Hög tillgänglighet
• Stark konsistens
• Möjligheter till katastrofåterställning

Även om valet av rätt lagringslösning beror på dina specifika behov och krav, är moderna datalager designade och implementerade med big data-analys i åtanke. Som sådan, när du implementerar ett modernt datalager, kan Azure Data Lake Storage Gen 2 vara det lämpligaste valet.

När du väljer att implementera det kommer du vanligtvis att njuta av följande fördelar:

• Centraliserad tillgång till en kopia av data i de olika datakällorna
• Prestandan för ditt datalager kommer att optimeras eftersom du inte behöver kopiera eller transformera data som ett krav för analys. Om du jämför detta med Blob Storages platta namnutrymme, låter den hierarkiska namnrymden dig förbättra övergripande prestanda genom att förbättra prestanda för hanteringsuppgifter.
• Databehandlingen blir enklare eftersom du kan organisera dina data i mappar och undermappar.
• Eftersom du kan definiera POSIX-behörigheter för mappar eller enskilda filer, kan säkerheten upprätthållas.
• Eftersom den är byggd på Azure Blob-lagring, som är lågkostnadsdesignad, är den mycket kostnadseffektiv och de ytterligare funktionerna minskar ägandekostnaderna ytterligare.

2. Hur kommer du att dela filerna och hur mycket data kommer varje fil att innehålla?

När du väl har bestämt dig för vilken lagringslösning du ska använda är nästa viktiga sak du behöver bestämma dig för hur du strukturerar data i databladet. Med andra ord måste du planera vilka mappar som ska användas för att lagra data i, hur man delar upp dessa mappar och hur man namnger mappar och enskilda filer.

Det är avgörande att du planerar dessa aspekter noggrant, eftersom de i slutändan kommer att avgöra hur lätt du kommer att kunna navigera genom data som lagras i databladet.

Nästa steg blir att planera hur man delar upp filerna och hur mycket data varje fil ska innehålla. Här behöver du vanligtvis överväga mängden data du redan har och hur snabbt volymen på din data ökar. Med hjälp av denna information kan du bestämma hur du ska dela upp data i filer.

Till exempel, med ordboksdata skulle du vanligtvis använda en fil för all data i en ordbokstabell, oavsett hur mycket data tabellen lagrar. Däremot har du med transaktionsdata valet att lagra data under en dag, en månad, ett år eller längre eller kortare beroende på dina specifika behov och krav.

3. Vilket format vill du använda för att extrahera data?

Nästa beslut du kommer att ställas inför är vilket format du vill använda för att extrahera data till. Även om detta kan låta som ett enkelt val, är det avgörande att få det rätt eftersom filformatet har en betydande inverkan på den slutliga datastorleken.

Vanligtvis har du ett val mellan följande filformat:

• Avro-format
• Binärt format
• Begränsat textformat
• Excel-format
• JSON-format
• ORC-format
• Parkett format
• XML-format

Du måste noga överväga vilket filformat din data är i och vad effekten blir om du sparar den i något av formaten ovan. Att flytta data från textfiler skapade från en SQL-databas kan till exempel öka datastorleken avsevärt med vissa format, medan den kan minskas med andra.

Att göra rätt val har potentialen att inte bara avsevärt minska mängden lagringsutrymme du behöver, utan kan också avsevärt minska tiden det tar att överföra din data till molnet.

När planeringen är klar kan du fortsätta att extrahera data och överföra den till databladet. Här har du många alternativ som Azure CLI och PowerShell. Ett av de bästa alternativen är dock TimeXtender. Speciellt designad för högpresterande kopiering av data till Azure blob-lagring, är det ett snabbt och effektivt sätt att överföra din data från din lokala lagring till Azure.

Det finns dock några saker att tänka på när du kopierar dina data till Azure Data Lake Storage Gen 2. Kör först inte verktyget på samma maskin som kör dina produktionsbelastningar, eftersom de resurser som behövs kan störa produktionsarbetet.

Du bör också sträva efter att skapa ett lagringskonto i en region nära din lokala lagring för att säkerställa att överföringen går snabbare. Slutligen skapar AzCopy en tillfällig journalfil när data överförs, vilket gör att den kan starta om överföringen om den avbryts. Du bör därför se till att du har tillräckligt med lagringsutrymme tillgängligt för att lagra journalfilerna.

Användning av data från Microsoft Azure data warehouse

Kom ihåg att det slutliga målet med att ha ett modernt datalager byggt på Microsoft Azure är att leverera data till till exempel en Microsoft Power BI-instrumentpanel i hela företaget. För att uppnå detta måste du ladda filerna i databladet till datalagret.

Här använder du Polybase för att ladda in filerna i datalagret. Den använder Azure Synapses Massively Parallel Processing (MPP) vilket gör det till det snabbaste sättet att ladda data till Azure Synapse.

Att ladda upp data till Azure Synapse är en process i två steg. Under det första steget skapar du en uppsättning externa tabeller för data. Dessa externa tabeller är bara tabelldefinitioner som pekar på data som lagras utanför Azure Synapse, i vårt fall i databladet. Det är viktigt att notera att detta steg inte flyttar någon data till förvaret.

Under nästa steg skapar du kompileringstabeller och laddar in data i dessa kompileringstabeller. Under detta steg kopieras data till förvaret. När data har kopierats till Azure Synapse kommer du att transformera data och flytta den till produktionstabeller som är lämpliga för semantisk modellering.

Läs sedan in data till en tabellmodell i Azure Analysis Services. Under detta steg kommer du vanligtvis att skapa en semantisk modell med hjälp av SQL Server Data Tools (SSDT). Här har du också möjlighet att skapa en semantisk modell genom att importera den från en Power BI Desktop-fil.

Det är viktigt att komma ihåg här att du måste lägga till relationerna till den semantiska modellen så att du kan slå samman data över tabeller. Detta beror helt enkelt på att Azure Synapse inte stöder främmande nycklar. När du har slutfört detta steg kommer du att kunna visualisera dina data i Power BI.

Power BI har två alternativ för att ansluta till Azure Analysis Services så att du kan visualisera din data. Det första är att importera dina data till Power BI. Det andra alternativet är att använda Live Connection där Power BI hämtar data direkt från Azure Analysis Services.

Även om valet i slutändan beror på dina specifika behov och krav, rekommenderas det att använda Live Connection eftersom du inte behöver kopiera data till Power BI.

När du visualiserar din data finns det också några saker du måste tänka på. För det första är Azure Analytics Services speciellt utformade för att hantera förfrågningar för kraven för en Power BI-instrumentpanel. Som ett resultat är det en rekommenderad praxis att fråga Azure Analytics Services direkt från Power BI.

Med ovanstående i åtanke är det andra du behöver tänka på att du bör undvika att köra frågor direkt mot datalagret. Detta kan påverka prestandan eftersom uppdatering av instrumentpanelen kommer att räknas in i antalet samtidiga sökningar.

Utöka möjligheterna och funktionerna

Vi nämnde tidigare att ett modernt datalager bör implementeras i faser och vårt exempel ovan illustrerar perfekt hur den första fasen av implementeringen kan se ut. Så, hur ser implementeringen ut i senare skeden när vi vill införliva fler funktioner i datalagret?

I det här exemplet bygger vi på det tidigare exemplet och lägger till några viktiga funktioner som är avgörande för modern implementering av datalager. Dessa funktioner inkluderar:

• Pipeline-automatisering med Data Factory.
• Inkrementell laddning av data.
• Integrering av data från flera källor.
• Ladda och använd binär data som geospatial data, bilder och andra media.

I det här exemplet består Azure-arkitekturen av:

• Lokal SQL Server och extern data som datakällor.
• Blob-lagring för att lagra data innan den läses in i Azure Synapse.
• Azure Data Factory för att orkestrera och automatisera rörelsen och transformationen av data och koordinera de olika stadierna av extrahering, laddning, transformation (ELT) processen.
• Azure Analysis Services som tillhandahåller datamodelleringsfunktioner.
• Power BI för dataanalys.
• Azure Active Directory för att autentisera användare som använder Power BI för att ansluta till Azure Analysis Services.

Datapipeline och inkrementell laddning

För att få in din data i datalagret, använd Data Factory-pipeline. Dessa pipelines är logiska grupperingar av aktiviteter som samverkar för att utföra en specifik uppgift. Till exempel kan en pipeline innehålla en uppsättning aktiviteter som tar in och rensar data från en mängd olika system och sedan initierar ett dataflöde för att analysera dessa data.

Ett annat exempel kan vara när du använder en kopieringsaktivitet för att kopiera extern data från till exempel en SQL-databas till Azure Blob Storage. Detta liknar vårt exempel där vi använder en pipeline för att ladda och transformera data till Azure Synapse.

En av de största fördelarna med att använda dessa pipelines är att det låter dig hantera dina aktiviteter tillsammans istället för individuellt. Du distribuerar och planerar därför pipelinen istället för att fördela varje aktivitet självständigt.

Till skillnad från vårt första exempel kommer den här arkitekturen också att implementera inkrementell dataladdning. När man använder en automatiserad ELT-process är det mycket effektivare att bara ladda in ny data, eller med andra ord bara data som har förändrats, till datalagret jämfört med att ladda all data.

Dessa tabeller, även kända som systemversionstabeller, ger alltid information om data som lagras i tabellen. Den gör detta genom att automatiskt registrera historiken för alla ändringar i en separat historiktabell. Ur ett ETL-perspektiv kan du sedan fråga efter historiska data för att avgöra om en inkrementell belastning ska utföras.

I slutändan kommer Data Factory att utföra en inkrementell belastning om det finns några ändringar. Kom ihåg att efter att en ny batch med data har laddats in i arkivet måste du uppdatera Analysis Services-tabellmodellen. Det är också viktigt att komma ihåg att datarensning bör vara en del av ELT-processen för att säkerställa data av god kvalitet.

Flera datakällor

Till skillnad från vårt första exempel kommer vi nu att införliva fler datakällor. Här kommer din datafabrik att organisera och koordinera utvinningen av data från de externa källorna till vår Blob-lagring eller Azure Data Lake Storage Gen 2 med hjälp av en kopieringsaktivitet för att flytta data från både lokala och molndatakällor. Som tidigare kan du kopiera data till databladet i något av de filformat som nämnts tidigare.

Härifrån kan den kopiera data direkt till Azure Synapse med hjälp av blob-lagringsanslutningen. Det är dock viktigt att komma ihåg att bloblagringslänken endast stöder vissa typer av autentisering, såsom autentisering av kontonyckel, autentisering med delad åtkomstsignatur och systemtilldelad hanterad identitetsautentisering, bland annat.

Då kräver den en anslutningssträng eller delad åtkomstsignatur och kan därför inte användas för att kopiera en blob med offentlig läsbehörighet. För en blob med offentlig läsbehörighet, använd Polybase för att skapa en extern tabell med bloblagring och kopiera den externa tabellen till Azure Synapse.

Binära data

När du arbetar med binär data kommer Data Factorys Copy Activity även att kunna kopiera från datakällan till databladet och vidare till Azure Synapse. Det är dock viktigt att notera att när du använder kopieringsaktiviteten kan du bara kopiera från binär data till binär data.

Du bör också komma ihåg att när du använder Polybase som lösningen som beskrivs ovan, stöder den endast maximala kolumnstorlekar på 8000 byte. I det här fallet delar du upp data i mindre bitar under kopieringen och sätter sedan ihop delarna igen efter att kopieringen är klar.

Till sist

Det är ingen hemlighet att det på dagens konkurrensutsatta marknad är flexibilitet som är avgörande för framgång. Det tillåter inte bara organisationer att anpassa sig till förändrade marknadsförhållanden och dra nytta av affärsmöjligheter när de uppstår, utan det gör dem också mer effektiva.

Så när du vill ge din organisation den smidighet och flexibilitet som krävs av dagens konkurrensutsatta marknad, är det viktigt att du implementerar eller moderniserar ditt datalager. Det låter dig kombinera data från alla dina verksamhetsområden till en källa till sanning och ger dig ökad skalbarhet, flexibilitet och automationsmöjligheter.

Förhoppningsvis hjälpte det här inlägget att illustrera hur du kan implementera ett modernt datalager. För att lära dig mer om moderna datalager eller hur vår automatiserade, lågkodade, dra-och-släpp Data Estate Builder kan hjälpa dig att implementera och driva ett modernt datalager utan att skriva någon kod, besök vår webbplats för mer information.