Een analytische gegevensopslag kiezen in Azure

  • Artikel

In een big data-architectuur is er vaak behoefte aan een analytische gegevensopslag die verwerkte gegevens verwerkt in een gestructureerde indeling die kan worden opgevraagd met behulp van analytische hulpprogramma's. Analytische gegevensarchieven die ondersteuning bieden voor het uitvoeren van query's op zowel hot-path- als cold-path-gegevens, worden gezamenlijk aangeduid als de ondersteunende laag of gegevens die opslag leveren.

De ondersteunende laag behandelt verwerkte gegevens van zowel het dynamische pad als het koude pad. In de lambda-architectuur wordt de serverlaag onderverdeeld in een snelheidsbedienende laag, waarin gegevens die incrementeel zijn verwerkt, worden opgeslagen en een batchservicelaag , die de batchverwerkingsuitvoer bevat. De ondersteunende laag vereist sterke ondersteuning voor willekeurige leesbewerkingen met lage latentie. Gegevensopslag voor de snelheidslaag moet ook willekeurige schrijfbewerkingen ondersteunen, omdat batchlaadgegevens in dit archief ongewenste vertragingen veroorzaken. Aan de andere kant hoeft gegevensopslag voor de batchlaag geen ondersteuning te bieden voor willekeurige schrijfbewerkingen, maar batchschrijfbewerkingen.

Er is geen enkele beste keuze voor gegevensbeheer voor alle gegevensopslagtaken. Verschillende oplossingen voor gegevensbeheer zijn geoptimaliseerd voor verschillende taken. De meeste echte cloud-apps en big data-processen hebben verschillende vereisten voor gegevensopslag en maken vaak gebruik van een combinatie van oplossingen voor gegevensopslag.

Wat zijn uw opties bij het kiezen van een analytische gegevensopslag?

Er zijn verschillende opties voor gegevens die opslag in Azure leveren, afhankelijk van uw behoeften:

Deze opties bieden verschillende databasemodellen die zijn geoptimaliseerd voor verschillende typen taken:

  • Sleutel-/waardedatabases bevatten één geserialiseerd object voor elke sleutelwaarde. Ze zijn geschikt voor het opslaan van grote hoeveelheden gegevens waarbij u één item voor een bepaalde sleutelwaarde wilt ophalen en u geen query hoeft uit te voeren op basis van andere eigenschappen van het item.
  • Documentdatabases zijn sleutel-waardedatabases waarin de waarden documenten zijn. Een document in deze context is een verzameling benoemde velden en waarden. In de database worden de gegevens doorgaans opgeslagen in een indeling zoals XML, YAML, JSON of BSON, maar kunnen tekst zonder opmaak worden gebruikt. Documentdatabases kunnen query's uitvoeren op niet-sleutelvelden en secundaire indexen definiëren om query's efficiënter te maken. Hierdoor is een documentdatabase geschikter voor toepassingen die gegevens moeten ophalen op basis van criteria die complexer zijn dan de waarde van de documentsleutel. U kunt bijvoorbeeld query's uitvoeren op velden zoals product-id, klant-id of klantnaam.
  • Databases in het kolomarchief zijn sleutel-waardegegevensarchieven waarin elke kolom afzonderlijk op schijf wordt opgeslagen. Een brede kolomopslagdatabase is een type kolomarchiefdatabase waarin kolomfamilies, niet alleen enkele kolommen, worden opgeslagen. Een volkstellingsdatabase kan bijvoorbeeld een kolomfamilie hebben voor de naam van een persoon (voornaam, middelste, laatste), een gezin voor het adres van de persoon en een gezin voor de profielgegevens van de persoon (geboortedatum, geslacht). De database kan elke kolomfamilie opslaan in een afzonderlijke partitie, terwijl alle gegevens voor één persoon met dezelfde sleutel worden bewaard. Een toepassing kan één kolomfamilie lezen zonder alle gegevens voor een entiteit te lezen.
  • Grafiekdatabases slaan gegevens op als een verzameling objecten en relaties. Een grafiekdatabase kan efficiënt query's uitvoeren die het netwerk van objecten en de relaties tussen deze objecten doorkruisen. De objecten kunnen bijvoorbeeld werknemers zijn in een human resources-database en u wilt query's vergemakkelijken, zoals 'alle werknemers zoeken die direct of indirect voor Scott werken'.
  • Telemetrie- en tijdreeksdatabases zijn een verzameling objecten die alleen kunnen worden toegevoegd. Telemetriedatabases indexeren efficiënt gegevens in verschillende kolomarchieven en in-memory structuren, waardoor ze de optimale keuze zijn voor het opslaan en analyseren van grote hoeveelheden telemetrie- en tijdreeksgegevens.

Criteria voor sleutelselectie

Om de keuzes te beperken, beantwoordt u eerst deze vragen:

  • Hebt u opslag nodig die kan fungeren als een dynamisch pad voor uw gegevens? Zo ja, besmal uw opties tot de opties die zijn geoptimaliseerd voor een laag voor snelheidsbediening.

  • Hebt u MPP-ondersteuning (Massively Parallel Processing) nodig, waarbij query's automatisch worden gedistribueerd over verschillende processen of knooppunten? Zo ja, selecteert u een optie die ondersteuning biedt voor uitschalen van query's.

  • Wilt u liever een relationeel gegevensarchief gebruiken? Zo ja, dan kunt u uw opties beperken tot personen met een relationeel databasemodel. Houd er echter rekening mee dat sommige niet-relationele archieven SQL-syntaxis ondersteunen voor het uitvoeren van query's en hulpprogramma's zoals PolyBase kunnen worden gebruikt om query's uit te voeren op niet-relationele gegevensarchieven.

  • Verzamelt u tijdreeksgegevens? Gebruikt u alleen toevoeggegevens?

Mogelijkheidsmatrix

De volgende tabellen bevatten een overzicht van de belangrijkste verschillen in mogelijkheden.

Algemene mogelijkheden

Mogelijkheid SQL Database Azure Synapse SQL-pool Azure Synapse Spark-pool Azure Data Explorer HBase/Phoenix in HDInsight Hive LLAP in HDInsight Azure Analysis Services Azure Cosmos DB
Is beheerde service Ja Ja Ja Ja Ja 1 Ja 1 Ja Ja
Primair databasemodel Relationeel (kolomarchiefindeling bij gebruik van columnstore-indexen) Relationele tabellen met kolomopslag Breed kolomarchief Relationeel (kolomarchief), telemetrie en tijdreeksarchief Breed kolomarchief Hive/In-Memory Semantische modellen in tabelvorm Documentarchief, grafiek, sleutel-waardearchief, breed kolomarchief
Ondersteuning voor SQL-taal Ja Ja Ja Ja Ja (met phoenix JDBC-stuurprogramma) Ja No Ja
Geoptimaliseerd voor snelheidsbedieningslaag Ja 2 Ja 3 Ja Ja Ja Ja No Ja

[1] Met handmatige configuratie en schaalaanpassing.

[2] Gebruik van tabellen met geoptimaliseerd geheugen en hash of niet-geclusterde indexen.

[3] Ondersteund als een Azure Stream Analytics-uitvoer.

Schaalbaarheidsmogelijkheden

Mogelijkheid SQL Database Azure Synapse SQL-pool Azure Synapse Spark-pool Azure Data Explorer HBase/Phoenix in HDInsight Hive LLAP in HDInsight Azure Analysis Services Azure Cosmos DB
Redundante regionale servers voor hoge beschikbaarheid Ja No No Ja Ja No Ja Ja
Ondersteunt uitschalen van query's Nee Ja Ja Ja Ja Ja Ja Ja
Dynamische schaalbaarheid (omhoog schalen) Ja Ja Ja Ja No No Ja Ja
Ondersteunt in-memory caching van gegevens Ja Ja Ja Ja No Ja Ja Nee

Beveiligingsmogelijkheden

Mogelijkheid SQL Database Azure Synapse Azure Data Explorer HBase/Phoenix in HDInsight Hive LLAP in HDInsight Azure Analysis Services Azure Cosmos DB
Verificatie SQL/Microsoft Entra-id SQL/Microsoft Entra-id Microsoft Entra ID lokaal/Microsoft Entra ID 1 lokaal/Microsoft Entra ID 1 Microsoft Entra ID databasegebruikers/Microsoft Entra-id via toegangsbeheer (IAM)
Versleuteling van inactieve gegevens Ja 2 Ja 2 Ja Ja 1 Ja 1 Ja Ja
Beveiliging op rijniveau Ja Ja 3 Ja Ja 1 Ja 1 Ja Nee
Ondersteunt firewalls Ja Ja Ja Ja 4 Ja 4 Ja Ja
Dynamische gegevensmaskering Ja Ja Ja Ja 1 Ja No Nee

[1] Vereist het gebruik van een HDInsight-cluster dat lid is van een domein.

[2] Vereist dat u TDE (Transparent Data Encryption) gebruikt om uw data-at-rest te versleutelen en ontsleutelen.

[3] Filterpredicaten alleen. Zie Beveiliging op rijniveau

[4] Bij gebruik in een virtueel Azure-netwerk. Zie Azure HDInsight uitbreiden met behulp van een virtueel Azure-netwerk.

Inzenders

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Volgende stappen