Välj ett analysdatalager i Azure

Stordataarkitekturen behöver ofta ett analysdatalager som hanterar bearbetade data i ett strukturerat format. Du kan köra frågor mot dessa data med hjälp av analysverktyg. Analytiska datalager som stöder frågekörning av både hot-path- och cold-path-data kallas gemensamt för det betjänande lagret eller data som betjänar lagring.

Servicelagret hanterar bearbetade data från både den snabba vägen och den långsamma vägen. I Lambda-arkitekturen delas serveringsskiktet in i två lager. Det hastighetsbetjäningslager som innehåller inkrementellt bearbetade data. Batch-serveringsskiktet innehåller batchbearbetade utdata.

Även om det övergripande serverlagret kräver starkt stöd för slumpmässiga läsningar som har låg svarstid, bör datalagring för hastighetslagret också ha stöd för slumpmässiga skrivningar eftersom batchinläsning av data i det här arkivet medför oönskade fördröjningar. Omvänt måste datalagring för batchlagret ha stöd för batchskrivningar, inte slumpmässiga skrivningar.

Ingen enskild datahanteringslösning passar för varje datalagringsuppgift. Olika lösningar är optimala för specifika uppgifter. De flesta verkliga molnappar och stordataprocesser har olika datalagringskrav och använder ofta en kombination av lagringslösningar.

Moderna analyslösningar, till exempel Microsoft Fabric, tillhandahåller en omfattande plattform som integrerar olika datatjänster och verktyg för att uppfylla olika analytiska behov. Fabric innehåller OneLake, som är en enda, enhetlig, logisk datasjö för hela organisationen. OneLake är utformat för att lagra, hantera och skydda alla organisationsdata på en plats. Med den här flexibiliteten kan din organisation hantera en mängd olika datalagrings- och bearbetningskrav.

Välj ett analysdatalager

Microsoft erbjuder flera alternativ för lagring för dataservering, beroende på dina behov:

Olika databasmodeller passar olika typer av uppgifter:

Nyckel/värde-datalager innehåller ett enda serialiserat objekt för varje nyckelvärde. De kan hantera stora mängder data när hämtningen baseras på en specifik nyckel, utan att behöva köra frågor mot andra objektegenskaper.
Dokumentdatalager är nyckel/värde-datalager där värdena är dokument. I det här sammanhanget är ett dokument en samling med namngivna fält och värden. Datalagret lagrar vanligtvis data i ett format som XML, YAML, JSON eller binär JSON, men kan använda oformaterad text. Dokumentdatalager kan köra frågor mot icke-nyckelfält och definiera sekundära index för att förbättra frågeeffektiviteten. Den här funktionen gör en dokumentdatabas mer lämplig för program som behöver hämta data baserat på kriterier som är mer komplexa än värdet för dokumentnyckeln. Du kan till exempel fråga efter fält som produkt-ID, kund-ID eller kundnamn.
Kolumnfamiljedatalager är nyckelvärdesdatalager som håller varje kolumn separat på disken. Ett brett kolumnlager lagrar kolumnfamiljer, inte bara enskilda kolumner. En censusdatabas kan till exempel ha en separat kolumnfamilj för var och en av en individs attribut:
- För-, mellan- och efternamn
- Postadress
- Profilinformation, till exempel födelsedatum eller kön
Datalagret kan lagra varje kolumnfamilj i en separat partition, samtidigt som alla data för en person som är relaterade till samma nyckel lagras. Ett program kan läsa en enskild kolumnfamilj utan att genomsöka alla data efter en entitet.
Graph-datalager innehåller information som en samling objekt och relationer. Ett diagramdatalager kan effektivt utföra frågor som passerar nätverket av objekt och relationerna mellan dem. Objekten kan till exempel vara anställda i en personaldatabas och du kanske vill underlätta frågor som "hitta alla anställda som direkt eller indirekt arbetar för Scott".
Telemetri- och tidsseriedatabaser är en samling av objekt som bara kan läggas till. Telemetridatabaser indexera effektivt data i olika kolumnlager och minnesinterna strukturer. Den här funktionen gör dem till det optimala valet för att lagra och analysera stora mängder telemetri- och tidsseriedata.

Fabric stöder olika databasmodeller, inklusive nyckelvärde, dokument, kolumnlager, graf- och telemetridatabaser. Den här flexibiliteten säkerställer skalbarhet för en mängd olika analytiska uppgifter. Information om hur du väljer rätt Fabric datalager för dina analytiska arbetsbelastningar finns i Fabric beslutsguide: välj ett datalager.

Kriterier för nyckelval

Tänk på följande kriterier för att förfina urvalsprocessen:

Behöver du serveringslagring som kan fungera som en frekvent sökväg för dina data? Om ja väljer du alternativ som är optimala för ett hastighetsbetjäningslager.
Behöver du stöd för massivt parallell bearbetning, där frågor distribueras automatiskt över flera processer eller noder? Om ja väljer du ett alternativ som stöder utskalning av frågor.
Föredrar du att använda ett relationsdatalager? Om du gör det väljer du alternativ som har en relationsdatabasmodell. Vissa icke-relationslager stöder dock SQL-syntax för frågor, och du kan använda verktyg som SQL-analysslutpunkter för att köra frågor mot icke-relationella datalager som OneLake.
Samlar du in tidsseriedata? Använder du data som enbart kan läggas till? OneLake stöder flera analysmotorer, inklusive Analysis Services, T-SQL och Apache Spark. Eventhouse passar bra för olika databearbetnings- och frågebehov i tidsserier.

Kapacitetsmatris

I följande tabeller sammanfattas de viktigaste skillnaderna i funktioner mellan dessa hanterade tjänster.

Allmänna funktioner

Kapacitet	Lakehouse	Data Warehouse	Eventhouse	Fabric SQL-databas	Azure SQL Database	Azure Cosmos DB	Analystjänster
Primär databasmodell	Enhetlig datasjö, relationsbaserat, användarhanterat Delta Lake-format med Apache Parquet	Enhetlig datasjö, relationellt, systemhanterat Delta Lake-format med Apache Parquet	Tidsseriebaserat datalager för sekventiell tilläggning, graf, vektor	Relationell (kolumnlagerformat när du använder kolumnlagerindex)	Relationell (kolumnlagerformat när du använder kolumnlagerindex)	Dokumentarkiv, diagram, nyckel/värde-arkiv, stort kolumnarkiv	Tabellsemantiska modeller
Stöd för SQL-språk	Ja¹	Ja	Ja²	Ja	Ja	Ja	Nej
Optimerad för snabbutleveranslager	Ja	Ja	Ja³	Ja⁴	Ja⁵	Ja	Nej

[1] T-SQL via SQL-analysslutpunkten.

[2] Kusto Query Language (KQL) har delvis stöd för T-SQL-språk.

[3] Stöder inmatning i kö och strömmande inmatning.

[4] Stöder transaktionsprecision med åtkomst med låg svarstid och realtidsuppdateringar.

[5] Genom att använda minnesoptimerade tabeller och hash- eller icke-grupperade index.

Skalbarhetsfunktioner

Kapacitet	Lakehouse	Data Warehouse	Eventhouse	Fabric SQL-databas	Azure SQL Database	Azure Cosmos DB	Analystjänster
Redundanta regionala servrar för hög tillgänglighet	Ja^1,2	Ja^1,2	Ja	Ja	Ja	Ja	Ja
Stöder skalning av frågebegäran	Ja³	Ja⁴	Ja⁵	Ja	Nej	Ja	Ja
Dynamisk skalbarhet (skala upp)	Ja³	Ja⁴	Ja⁵	Ja	Ja	Ja	Ja
Stöder minnesintern cachelagring av data	Ja⁶	Ja⁶	Ja⁷	Ja	Ja	Ja	Nej

SQL-slutpunkter dirigeras via globala trafikhanterare, men den tilldelade Fabric-kapacitetsregionen bearbetar alltid datan.

[2] Lakehouse och Warehouse lagrar data i OneLake i Delta Parquet-format, som stöder frågor och replikering mellan motorer.

[3] Lakehouse stöder Spark-baserad utskalning för ostrukturerade och strukturerade data.

[4] Warehouse använder T-SQL och stöder multitable-transaktioner, autonom arbetsbelastningshantering och distribuerad frågebearbetning (DQP). DQP fungerar som en klusterhanterare och allokerar dynamiskt beräkningsresurser baserat på frågekomplexitet.

[5] Eventhouse stöder KQL- och SQL-federation för realtidsanalys över flera källor och för att skala upp beräkningsresurser om användningen av frekvent cache överskrider ~95%.

[6] Intelligent cache för Spark-jobb, minnesintern cachelagring, cachelagring av resultatuppsättningar för SQL-analysslutpunkter.

[7] Data som används ofta lagras i en het cache som omfattar lagring i minnet och SSD-lagring.

Säkerhetsfunktioner

Kapacitet	Lakehouse	Data Warehouse	Eventhouse	Fabric SQL-databas	Azure SQL Database	Azure Cosmos DB	Analystjänster
Autentisering	Microsoft Entra ID	Microsoft Entra ID	Microsoft Entra ID	Microsoft Entra ID	SQL- eller Microsoft Entra-ID	Databasanvändare eller Microsoft Entra-ID via åtkomstkontroll (identitets- och åtkomsthantering)	Microsoft Entra ID
Datakryptering vid lagring	Ja	Ja	Ja	Ja	Ja¹	Ja	Ja
Säkerhet på radnivå	Ja	Ja	Ja	Ja	Ja	Nej	Ja
Stöder brandväggar	Ja²	Ja²	Ja³	Ja	Ja	Ja	Ja
Dynamisk dataskydd	Ja⁴	Ja⁴	Nej	Ja	Ja	Nej	Nej

[1] Kräver att du använder transparent datakryptering för att kryptera och dekryptera dina data i vila.

[2] Använd privata länkar och Villkorsstyrd åtkomst i Microsoft Entra för att begränsa åtkomsten till Fabric resurser.

[3] Arbetsbelastningar i Fabric Eventhouse och Real-Time Intelligence kan mata in data från säkra källor som Kafka, Azure Event Hubs och AMQP, med routning via säkra slutpunkter.

[4] Använd den på Fabric SQL-slutpunktsnivå.

Bidragsgivare

Microsoft ansvarar för den här artikeln. Följande deltagare skrev den här artikeln.

Huvudförfattare:

Mohit Agarwal | Huvudarkitekt för molnlösning

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg

Feedback

Var den här sidan till hjälp?

Last updated on 2026-08-29