Välj ett analysdatalager i Azure

  • Artikel

I en stordataarkitektur finns det ofta ett behov av ett analysdatalager som hanterar bearbetade data i ett strukturerat format som kan efterfrågas 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.

Serveringslagret hanterar bearbetade data från både den heta sökvägen och den kalla sökvägen. I lambda-arkitekturen delas serveringslagret upp i ett hastighetsbearbetande lager som lagrar data som har bearbetats stegvis och ett batchbetjäningslager som innehåller batchbearbetade utdata. Serveringsskiktet kräver starkt stöd för slumpmässiga läsningar med låg svarstid. Datalagring för hastighetslagret bör också ha stöd för slumpmässiga skrivningar, eftersom batchinläsning av data i det här arkivet skulle medföra oönskade fördröjningar. Å andra sidan behöver datalagring för batchlagret inte stödja slumpmässiga skrivningar, utan batchskrivningar i stället.

Det finns inget enskilt bästa datahanteringsalternativ för alla datalagringsuppgifter. Olika datahanteringslösningar är optimerade för olika uppgifter. De flesta verkliga molnappar och stordataprocesser har olika krav på datalagring och använder ofta en kombination av datalagringslösningar.

Vilka alternativ har du när du väljer ett analysdatalager?

Det finns flera alternativ för data som hanterar lagring i Azure, beroende på dina behov:

De här alternativen innehåller olika databasmodeller som är optimerade för olika typer av uppgifter:

  • Nyckel-/värdedatabaser innehåller ett enda serialiserat objekt för varje nyckelvärde. De är bra för att lagra stora mängder data där du vill hämta ett objekt för ett visst nyckelvärde och du inte behöver fråga baserat på andra egenskaper för objektet.
  • Dokumentdatabaser är nyckel-/värdedatabaser där värdena är dokument. Ett "dokument" i den här kontexten är en samling namngivna fält och värden. Databasen lagrar vanligtvis data i ett format som XML, YAML, JSON eller BSON, men kan använda oformaterad text. Dokumentdatabaser kan köra frågor mot icke-nyckelfält och definiera sekundära index för att göra frågan mer effektiv. Detta 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.
  • Kolumnlagringsdatabaser är nyckel-/värdedatalager som lagrar varje kolumn separat på disk. En bred kolumnlagringsdatabas är en typ av kolumnlagringsdatabas som lagrar kolumnfamiljer, inte bara enskilda kolumner. En folkräkningsdatabas kan till exempel ha en kolumnfamilj för en persons namn (först, mitten, sista), en familj för personens adress och en familj för personens profilinformation (födelsedatum, kön). Databasen kan lagra varje kolumnfamilj i en separat partition, samtidigt som alla data för en person som är relaterade till samma nyckel bevaras. Ett program kan läsa en enda kolumnfamilj utan att läsa igenom alla data för en entitet.
  • Graph-databaser lagrar information som en samling objekt och relationer. En grafdatabas 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 tilläggssamling med objekt. Telemetridatabaser indexerar effektivt data i en mängd olika kolumnlager och minnesinterna strukturer, vilket gör dem till det optimala valet för att lagra och analysera stora mängder telemetri- och tidsseriedata.

Kriterier för nyckelval

För att begränsa alternativen börjar du med att svara på följande frågor:

  • Behöver du serveringslagring som kan fungera som en frekvent sökväg för dina data? Om ja, begränsa dina alternativ till de som är optimerade för ett hastighetsbetjäningslager.

  • Behöver du stöd för massivt parallell bearbetning (MPP), 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? I så fall begränsar du dina alternativ till dem med en relationsdatabasmodell. Observera dock att vissa icke-relationslager har stöd för SQL-syntax för frågor och att verktyg som PolyBase kan användas för att köra frågor mot icke-relationella datalager.

  • Samlar du in tidsseriedata? Använder du tilläggsdata?

Kapacitetsmatris

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

Allmänna funktioner

Kapacitet SQL Database Azure Synapse SQL-pool Azure Synapse Spark-pool Öppna Azure-datautforskaren HBase/Phoenix på HDInsight Hive LLAP på HDInsight Azure Analysis Services Azure Cosmos DB
Är hanterad tjänst Ja Ja Ja Ja Ja 1 Ja 1 Ja Ja
Primär databasmodell Relationell (kolumnlagringsformat när du använder kolumnlagringsindex) Relationstabeller med kolumnlagring Brett kolumnarkiv Relationsarkiv (kolumnarkiv), telemetri och tidsseriearkiv Brett kolumnarkiv Hive/In-Memory Tabellsemantiska modeller Dokumentarkiv, diagram, nyckel/värde-arkiv, stort kolumnarkiv
Stöd för SQL-språk Ja Ja Ja Ja Ja (med Phoenix JDBC-drivrutin) Ja No Ja
Optimerad för hastighetsbetjäningslager Ja 2 Ja 3 Ja Ja Ja Ja No Ja

[1] Med manuell konfiguration och skalning.

[2] Använda minnesoptimerade tabeller och hash- eller icke-grupperade index.

[3] Stöds som ett Azure Stream Analytics-utdata.

Skalbarhetsfunktioner

Kapacitet SQL Database Azure Synapse SQL-pool Azure Synapse Spark-pool Öppna Azure-datautforskaren HBase/Phoenix på HDInsight Hive LLAP på HDInsight Azure Analysis Services Azure Cosmos DB
Redundanta regionala servrar för hög tillgänglighet Ja No No Ja Ja No Ja Ja
Stöder utskalning av frågor Inga Ja Ja Ja Ja Ja Ja Ja
Dynamisk skalbarhet (skala upp) Ja Ja Ja Ja No No Ja Ja
Stöder minnesintern cachelagring av data Ja Ja Ja Ja No Ja Ja Nej

Säkerhetsfunktioner

Kapacitet SQL Database Azure Synapse Öppna Azure-datautforskaren HBase/Phoenix på HDInsight Hive LLAP på HDInsight Azure Analysis Services Azure Cosmos DB
Autentisering SQL/Microsoft Entra ID SQL/Microsoft Entra ID Microsoft Entra ID local/Microsoft Entra ID 1 local/Microsoft Entra ID 1 Microsoft Entra ID databasanvändare/Microsoft Entra-ID via åtkomstkontroll (IAM)
Datakryptering i vila Ja 2 Ja 2 Ja Ja 1 Ja 1 Ja Ja
Säkerhet på radnivå Ja Ja 3 Ja Ja 1 Ja 1 Ja Nej
Stöder brandväggar Ja Ja Ja Ja 4 Ja 4 Ja Ja
Dynamisk datamaskning Ja Ja Ja Ja 1 Ja No Nej

[1] Kräver att ett domänanslutet HDInsight-kluster används.

[2] Kräver att transparent datakryptering (TDE) används för att kryptera och dekryptera dina data i vila.

[3] Endast filterpredikat. Se Säkerhet på radnivå

[4] När det används i ett virtuellt Azure-nätverk. Se Utöka Azure HDInsight med hjälp av ett virtuellt Azure-nätverk.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Nästa steg