Datalagerhantering

  • Artikel
  • 10 minuter för att läsa

Ett informationslager är en central lagringsplats med integrerade data från en eller flera olika källor. Informationslager lagrar aktuella och historiska data. De används för rapportering och analys av data.

Informationslager i Azure

För att flytta data till ett informationslager extraheras data regelbundet från olika källor som innehåller viktig affärsinformation. När data flyttas kan de formateras, rensas, valideras, sammanfattas och organiseras om. Alternativt kan data lagras på den lägsta detaljnivån, med aggregerade vyer i informationslagret för rapportering. I båda fallen blir informationslagret ett permanent datalager för rapportering, analys och business intelligence (BI).

Informationslagerarkitekturer

Följande referensarkitekturer visar arkitekturer för informationslager från start till slut i Azure:

När du ska använda den här lösningen

Välj ett informationslager när du behöver omvandla stora mängder data från driftsystem till ett format som är lätt att förstå. Informationslager behöver inte följa samma terse-datastruktur som du kanske använder i DINA OLTP-databaser. Du kan använda kolumnnamn som är meningsfulla för företagsanvändare och analytiker, strukturera om schemat för att förenkla relationer och konsolidera flera tabeller till en. De här stegen hjälper användare som behöver skapa rapporter och analysera data i BI-system, utan hjälp av en databasadministratör (DBA) eller datautvecklare.

Överväg att använda ett informationslager när du behöver hålla historiska data åtskilda från källtransaktionssystemen av prestandaskäl. Informationslager gör det enkelt att komma åt historiska data från flera platser genom att tillhandahålla en central plats med hjälp av vanliga format, nycklar och datamodeller.

Eftersom informationslager är optimerade för läsåtkomst går det snabbare att generera rapporter än att använda källtransaktionssystemet för rapportering.

Andra fördelar är:

  • Informationslagret kan lagra historiska data från flera källor, som representerar en enda sanningskälla.
  • Du kan förbättra datakvaliteten genom att rensa data när de importeras till informationslagret.
  • Rapporteringsverktygen konkurrerar inte med transaktionssystemen för frågebearbetningscykler. Med ett informationslager kan transaktionssystemet fokusera på att hantera skrivningar, medan informationslagret uppfyller de flesta läsförfrågningar.
  • Ett informationslager kan konsolidera data från olika program.
  • Datautvinningsverktyg kan hitta dolda mönster i data med hjälp av automatiska metoder.
  • Informationslager gör det enklare att ge säker åtkomst till behöriga användare, samtidigt som åtkomsten till andra begränsas. Företagsanvändare behöver inte åtkomst till källdata, vilket tar bort en potentiell attackvektor.
  • Informationslager gör det enklare att skapa business intelligence lösningar, till exempel OLAP-kuber.

Utmaningar

Att konfigurera ett informationslager korrekt så att det passar behoven i din verksamhet kan medföra några av följande utmaningar:

  • Ta den tid som krävs för att korrekt modellera dina affärsbegrepp. Informationslager är informationsdrivna. Du måste standardisera företagsrelaterade termer och vanliga format, till exempel valuta och datum. Du måste också strukturera om schemat på ett sätt som är meningsfullt för företagsanvändare men ändå säkerställa korrekthet för dataaggregeringar och relationer.

  • Planera och konfigurera din dataorkestrering. Överväg hur du kopierar data från källtransaktionssystemet till informationslagret och när du ska flytta historiska data från driftdatalager till lagret.

  • Underhålla eller förbättra datakvaliteten genom att rensa data när de importeras till lagret.

Informationslager i Azure

Du kan ha en eller flera datakällor, oavsett om de kommer från kundtransaktioner eller affärsprogram. Dessa data lagras traditionellt i en eller flera OLTP-databaser. Data kan bevaras i andra lagringsmedier, till exempel nätverksresurser, Azure Storage blobar eller en datasjö. Data kan också lagras av själva informationslagret eller i en relationsdatabas, till exempel Azure SQL Database. Syftet med lagret för analysdatalager är att uppfylla frågor som utfärdats av analys- och rapporteringsverktyg mot informationslagret. I Azure kan den här analyslagringsfunktionerna uppfyllas med Azure Synapse, eller med hjälp Azure HDInsight Hive eller Interaktiv fråga. Dessutom behöver du någon nivå av orkestrering för att flytta eller kopiera data från datalagringen till informationslagret, vilket kan göras med hjälp av Azure Data Factory eller Oozie på Azure HDInsight.

Det finns flera alternativ för att implementera ett informationslager i Azure, beroende på dina behov. Följande listor är uppdelade i två kategorier, symmetrisk flerbearbetning (SMP) och massivt parallell bearbetning (MPP).

SMP:

MPP:

Som en allmän regel passar SMP-baserade lager bäst för små till medelstora datauppsättningar (upp till 4–100 TB), medan MPP ofta används för stordata. Definitionen mellan små/medelstora data och stordata har delvis att göra med organisationens definition och stödinfrastruktur. (Se Välja ett OLTP-datalager.)

Utöver datastorlekar är typen av arbetsbelastningsmönster förmodligen en större faktor. Komplexa frågor kan till exempel vara för långsamma för en SMP-lösning och kräva en MPP-lösning i stället. MPP-baserade system har vanligtvis ett prestandaförseningar med små datastorlekar på grund av hur jobb distribueras och konsolideras mellan noder. Om dina datastorlekar redan överstiger 1 TB och förväntas växa kontinuerligt bör du överväga att välja en MPP-lösning. Men om dina datastorlekar är mindre, men dina arbetsbelastningar överskrider de tillgängliga resurserna i din SMP-lösning, kan MPP vara det bästa alternativet också.

Data som används eller lagras av ditt informationslager kan komma från ett antal datakällor, inklusive en datasjö, till exempel Azure Data Lake Storage. En videosession som jämför de olika starka MPP-tjänsterna som kan använda Azure Data Lake finns i Azure Data Lake och Azure Data Warehouse: Tillämpa moderna metoder på din app.

SMP-system kännetecknas av en enda instans av ett hanteringssystem för relationsdatabaser som delar alla resurser (CPU/minne/disk). Du kan skala upp ett SMP-system. Om SQL Server körs på en virtuell dator kan du skala upp VM-storleken. Du Azure SQL Database skala upp genom att välja en annan tjänstnivå.

MPP-system kan skalas ut genom att lägga till fler beräkningsnoder (som har egna processor-, minnes- och I/O-undersystem). Det finns fysiska begränsningar för att skala upp en server. Då är det mer önskvärt att skala ut beroende på arbetsbelastningen. Skillnaderna i fråge-, modellerings- och datapartitionering innebär dock att MPP-lösningar kräver en annan kompetensuppsättning.

När du bestämmer vilken SMP-lösning som ska användas kan du titta närmare på Azure SQL Database och SQL Server på virtuella Azure-datorer.

Azure Synapse (tidigare Azure SQL Data Warehouse) kan också användas för små och medelstora datauppsättningar, där arbetsbelastningen är beräknings- och minnesintensiv. Läs mer om Azure Synapse mönster och vanliga scenarier:

Viktiga urvalsvillkor

Börja med att besvara de här frågorna för att begränsa alternativen:

  • Vill du ha en hanterad tjänst i stället för att hantera dina egna servrar?

  • Arbetar du med mycket stora datamängder eller mycket komplexa, långvariga frågor? Om ja, överväg ett MPP-alternativ.

  • Är datakällan strukturerad eller ostrukturerad för en stor datauppsättning? Ostrukturerade data kan behöva bearbetas i en stordatamiljö som Spark på HDInsight, Azure Databricks, Hive LLAP på HDInsight eller Azure Data Lake Analytics. Alla dessa kan fungera som ELT-motorer (extrahering, laddning, transformering) och ETL-motorer (extrahering, transformering, laddning). De kan mata ut bearbetade data till strukturerade data, vilket gör det enklare att läsa in Azure Synapse eller något av de andra alternativen. För strukturerade data Azure Synapse en prestandanivå som kallas Optimerad för beräkning, för beräkningsintensiva arbetsbelastningar som kräver ultrahög prestanda.

  • Vill du separera dina historiska data från dina aktuella driftdata? I så fall väljer du något av alternativen där orkestrering krävs. Dessa är fristående lager som är optimerade för tung läsåtkomst och passar bäst som ett separat historikdatalager.

  • Behöver du integrera data från flera källor utöver OLTP-datalagret? I så fall bör du överväga alternativ som enkelt integrerar flera datakällor.

  • Har du ett krav för flera innehavare? I så fall Azure Synapse inte idealiskt för det här kravet. Mer information finns i Azure Synapse mönster och antimönster.

  • Föredrar du ett relationsdatalager? I så fall väljer du ett alternativ med ett relationsdatalager, men observera också att du kan använda ett verktyg som PolyBase för att fråga efter icke-relationella datalager om det behövs. Om du väljer att använda PolyBase kan du dock köra prestandatester mot dina ostrukturerade datauppsättningar för din arbetsbelastning.

  • Har du rapporteringskrav i realtid? Om du behöver snabba frågesvarstider på stora volymer singleton-infogningar väljer du ett alternativ som stöder realtidsrapportering.

  • Behöver du stöd för ett stort antal samtidiga användare och anslutningar? Möjligheten att stödja ett antal samtidiga användare/anslutningar beror på flera faktorer.

  • Vilken typ av arbetsbelastning har du? I allmänhet passar MPP-baserade lagerlösningar bäst för analytiska, batchorienterade arbetsbelastningar. Om dina arbetsbelastningar är transaktionella till sin natur, med många små läs-/skrivåtgärder eller flera rad för rad-åtgärder, bör du överväga att använda något av SMP-alternativen. Ett undantag till den här riktlinjen är när du använder dataströmbearbetning i ett HDInsight-kluster, till exempel Spark Streaming, och lagrar data i en Hive-tabell.

Kapacitetsmatris

I följande tabeller sammanfattas de viktigaste skillnaderna i funktioner.

Allmänna funktioner

Funktion Azure SQL Database SQL Server (VM) Azure Synapse Apache Hive på HDInsight Hive LLAP på HDInsight
Är hanterad tjänst Ja Inga Ja Ja 1 Ja 1
Kräver dataorkestrering (innehåller kopia av data/historiska data) Inga Inga Ja Ja Ja
Integrera enkelt flera datakällor Inga Inga Ja Ja Ja
Stöd för att pausa beräkning Inga Inga Ja Nej 2 Nej 2
Relationsdatalager Ja Ja Ja Inga Inga
Realtidsrapportering Ja Ja Inga Inga Ja
Flexibla återställningspunkter för säkerhetskopiering Ja Ja Nej 3 Ja 4 Ja 4
SMP/MPP SMP SMP MPP MPP MPP

[1] Manuell konfiguration och skalning.

[2] HDInsight-kluster kan tas bort när de inte behövs och sedan skapas på nya sätt. Koppla ett externt datalager till klustret så att dina data bevaras när du tar bort klustret. Du kan använda Azure Data Factory för att automatisera klustrets livscykel genom att skapa ett HDInsight-kluster på begäran för att bearbeta din arbetsbelastning och sedan ta bort den när bearbetningen är klar.

[3] Med Azure Synapse kan du återställa en databas till valfri tillgänglig återställningspunkt under de senaste sju dagarna. Ögonblicksbilder startar var fjärde till åttonde timme och är tillgängliga i sju dagar. När en ögonblicksbild är äldre än sju dagar upphör den att gälla och dess återställningspunkt är inte längre tillgänglig.

[4] Överväg att använda ett externt Hive-metaarkiv som kan säkerhetskopieras och återställas efter behov. Standardalternativ för säkerhetskopiering och återställning som gäller för Blob Storage eller Data Lake Storage kan användas för data, eller lösningar för säkerhetskopiering och återställning av HDInsight från tredje part, till exempel Imanis Data, kan användas för större flexibilitet och enkel användning.

Skalbarhetsfunktioner

Funktion Azure SQL Database SQL Server (VM) Azure Synapse Apache Hive på HDInsight Hive LLAP på HDInsight
Redundanta regionala servrar för hög tillgänglighet Ja Ja Ja Inga Inga
Stöder frågeutskalning (distribuerade frågor) Inga Inga Ja Ja Ja
Dynamisk skalbarhet Ja Nej Ja 1 Inga Inga
Stöder minnescachelagring av data Ja Ja Ja Ja Ja

[1] Azure Synapse kan du skala upp eller ned genom att justera antalet informationslagerenheter (DWUs). Se Hantera beräkningskraft i Azure Synapse.

Säkerhetsfunktioner

Funktion Azure SQL Database SQL Server på en virtuell dator Azure Synapse Apache Hive på HDInsight Hive LLAP på HDInsight
Autentisering SQL/Azure Active Directory (Azure AD) SQL/Azure AD/Active Directory SQL/Azure AD local/Azure AD 1 local/Azure AD 1
Auktorisering Ja Ja Ja Ja Ja 1
Granskning Ja Ja Ja Ja Ja 1
Datakryptering i vila Ja 2 Ja 2 Ja 2 Ja 2 Ja 1
Säkerhet på radnivå Ja Ja Ja Nej Ja 1
Stöder brandväggar Ja Ja Ja Ja Ja 3
Dynamisk datamaskning Ja Ja Ja Nej Ja 1

[1] Kräver att du använder ett domän-ansluten HDInsight-kluster.

[2] Kräver att du använder transparent datakryptering (TDE) för att kryptera och dekryptera dina vilodata.

[3] Stöds när det används i en Azure Virtual Network.

Läs mer om att skydda ditt informationslager: