Een analytische gegevensopslag kiezen in Azure

Big data-architectuur heeft vaak een analytische gegevensopslag nodig die verwerkte gegevens in een gestructureerde indeling verwerkt. U kunt query's uitvoeren op die gegevens 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 verwerkt gegevens van zowel het dynamische pad als het koude pad. In de Lambda-architectuur wordt de ondersteunende laag onderverdeeld in twee lagen. De serverlaag voor snelheid bevat de incrementeel verwerkte gegevens. De batchverwerkingslaag bevat de batchverwerkingsuitvoer.

Hoewel voor de algehele serverlaag sterke ondersteuning is vereist voor willekeurige leesbewerkingen met een lage latentie, moet gegevensopslag voor de snelheidslaag ook willekeurige schrijfbewerkingen ondersteunen, omdat batchlaadgegevens in dit archief ongewenste vertragingen veroorzaken. Daarentegen moet gegevensopslag voor de batchlaag ondersteuning bieden voor batch-schrijfbewerkingen, niet willekeurige schrijfbewerkingen.

Geen enkele oplossing voor gegevensbeheer past bij elke gegevensopslagtaak. Verschillende oplossingen zijn optimaal voor specifieke taken. De meeste echte cloud-apps en big data-processen hebben verschillende vereisten voor gegevensopslag en maken vaak gebruik van een combinatie van opslagoplossingen.

Moderne analytische oplossingen, zoals Microsoft Fabric, bieden een uitgebreid platform dat verschillende gegevensservices en hulpprogramma's integreert om te voldoen aan diverse analytische behoeften. Fabric bevat OneLake, een enkele, geïntegreerde, logische data lake voor uw hele organisatie. OneLake is ontworpen voor het opslaan, beheren en beveiligen van alle organisatiegegevens op één locatie. Dankzij deze flexibiliteit kan uw organisatie voldoen aan een breed scala aan vereisten voor gegevensopslag en -verwerking.

Een analytische gegevensopslag kiezen

Microsoft biedt verschillende opties voor opslag van gegevens, afhankelijk van uw behoeften:

Verschillende databasemodellen passen bij verschillende typen taken:

Sleutel-waardegegevensarchieven bevatten één geserialiseerd object voor elke sleutelwaarde. Ze kunnen grote hoeveelheden gegevens beheren wanneer het ophalen is gebaseerd op een specifieke sleutel, zonder dat andere itemeigenschappen hoeven te worden opgevraagd.
Documentgegevensarchieven zijn sleutel-waardegegevensarchieven waarin de waarden documenten zijn. In deze context is een document een verzameling benoemde velden en waarden. In de gegevensopslag worden de gegevens doorgaans opgeslagen in een indeling zoals XML, YAML, JSON of binaire JSON, maar kan ook platte tekst worden gebruikt. Documentgegevensarchieven kunnen query's uitvoeren op niet-sleutelvelden en secundaire indexen definiëren om de efficiëntie van query's te verbeteren. Deze mogelijkheid maakt 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.
Kolomfamiliegegevensarchieven zijn sleutel-waardegegevensarchieven die elke kolom afzonderlijk op schijf houden. In een breed kolomarchief wordenkolomfamilies, niet alleen afzonderlijke kolommen, opgeslagen. Een volkstellingsdatabase kan bijvoorbeeld een afzonderlijke kolomfamilie hebben voor elk van de kenmerken van een persoon:
- Voornaam, midden en achternaam
- Postadres
- Profielgegevens, zoals geboortedatum of geslacht
In het gegevensarchief kan elke kolomfamilie in een afzonderlijke partitie worden opgeslagen, terwijl alle gegevens voor één persoon met dezelfde sleutel worden bewaard. Een toepassing kan één kolomfamilie lezen zonder alle gegevens voor een entiteit te scannen.
Grafiekgegevensarchieven bevatten informatie als een verzameling objecten en relaties. Een grafiekgegevensarchief 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. Deze mogelijkheid maakt ze de optimale keuze voor het opslaan en analyseren van grote hoeveelheden telemetrie en tijdreeksgegevens.

Fabric ondersteunt verschillende databasemodellen, waaronder sleutelwaarde, document, kolomarchief, grafiek en telemetriedatabases. Deze flexibiliteit zorgt voor schaalbaarheid voor een breed scala aan analytische taken. Als u het juiste Fabric gegevensarchief voor uw analytische workloads wilt kiezen, raadpleegt u Fabric handleiding voor beslissingen: kies een gegevensarchief.

Criteria voor sleutelselectie

Houd rekening met de volgende criteria om het selectieproces te verfijnen:

Heeft u opslag nodig die kan dienen als een hot path voor uw gegevens? Zo ja, kies opties die optimaal zijn voor een snelle servinglaag.
Hebt u ondersteuning voor grootschalige parallelle verwerking 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? Als u dit doet, kiest u opties met een relationeel databasemodel. Sommige niet-relationele archieven ondersteunen echter SQL-syntaxis voor het uitvoeren van query's en u kunt hulpprogramma's zoals SQL Analytics-eindpunten gebruiken om query's uit te voeren op niet-relationele gegevensarchieven, zoals OneLake.
Verzamelt u tijdreeksgegevens? Gebruikt u alleen toevoeggegevens? OneLake ondersteunt meerdere analytische engines, waaronder Analysis Services, T-SQL en Apache Spark. Eventhouse is zeer geschikt voor diverse tijdreeksgegevensverwerkings- en querybehoeften.

Mogelijkheidsmatrix

De volgende tabellen geven een overzicht van de belangrijkste verschillen in mogelijkheden tussen deze beheerde services.

Algemene mogelijkheden

Mogelijkheid	Lakehouse	Data Warehouse	Eventhouse	Fabric SQL Database	Azure SQL Database	Azure Cosmos DB	Analyse diensten
Het primaire databasemodel	Unified Data Lake, relationele, door de gebruiker beheerde Delta Lake-indeling met Apache Parquet	Unified Data Lake, relationele, door het systeem beheerde Delta Lake-indeling met apache Parquet	Op tijdreeksen georiënteerde gegevensopslag, grafiek, vector	Relationeel (kolomgebaseerde opslagindeling wanneer u kolomopslagindexen gebruikt)	Relationeel (kolomgebaseerde opslagindeling wanneer u kolomopslagindexen gebruikt)	Documentdatastore, graaf, sleutel-waardedatabase, brede kolomdatastore	Semantische modellen in tabelvorm
Ondersteuning voor SQL-taal	Ja¹	Ja	Ja²	Ja	Ja	Ja	Nee
Geoptimaliseerd voor een snelle bedieningslaag	Ja	Ja	Ja³	Ja⁴	Ja⁵	Ja	Nee

[1] T-SQL via SQL Analytics-eindpunt.

[2] Kusto Query Language (KQL) heeft gedeeltelijke T-SQL-taalondersteuning.

[3] Ondersteunt opname in de wachtrij en streamingopname.

[4] Ondersteunt transactionele precisie met toegang met lage latentie en realtime-updates.

[5] Door geheugen-geoptimaliseerde tabellen en hash- of niet-geclusterde indexen te gebruiken.

Schaalbaarheidsmogelijkheden

Mogelijkheid	Lakehouse	Data Warehouse	Eventhouse	Fabric SQL-database	Azure SQL Database	Azure Cosmos DB	Analyse diensten
Redundante regionale servers voor hoge beschikbaarheid	Ja^1,2	Ja^1,2	Ja	Ja	Ja	Ja	Ja
Ondersteunt het uitschalen van query's	Ja³	Ja⁴	Ja⁵	Ja	Nee	Ja	Ja
Dynamische schaalbaarheid (opschalen)	Ja³	Ja⁴	Ja⁵	Ja	Ja	Ja	Ja
Ondersteunt in-memory caching van gegevens	Ja⁶	Ja⁶	Ja⁷	Ja	Ja	Ja	Nee

[1] SQL-eindpunten worden gerouteerd via globale verkeersbeheerders, maar de toegewezen Fabric capaciteitsregio verwerkt altijd de gegevens.

[2] Lakehouse en Warehouse slaan gegevens op in OneLake in de Delta Parquet-indeling, die ondersteuning biedt voor het uitvoeren van query's en replicatie tussen engines.

[3] Lakehouse biedt ondersteuning voor uitschalen op basis van Spark voor ongestructureerde en gestructureerde gegevens.

[4] Warehouse maakt gebruik van T-SQL en ondersteunt multitabele transacties, autonome workloadbeheer en gedistribueerde queryverwerking (DQP). DQP fungeert als een clusterbeheerder, waarbij rekenresources dynamisch worden toegestuurd op basis van querycomplexiteit.

[5] Eventhouse ondersteunt KQL- en SQL-federatie voor realtime analyses in meerdere bronnen en voor het omhoog schalen van rekenresources als het hot-cachegebruik meer dan ~95%overschrijdt.

[6] Intelligente cache voor Spark-taken, in-memory caching, resultatensetcaching voor SQL Analytics-eindpunten.

[7] Veelgebruikte gegevens worden opgeslagen in een hot-cache met in-memory en SSD-opslag.

Beveiligingsmogelijkheden

Mogelijkheid	Lakehouse	Data Warehouse	Eventhouse	Fabric SQL-database	Azure SQL Database	Azure Cosmos DB	Analyse diensten
Verificatie	Microsoft Entra ID	Microsoft Entra ID	Microsoft Entra ID	Microsoft Entra ID	SQL / Microsoft Entra ID	Databasegebruikers of Microsoft Entra-id via toegangsbeheer (identiteits- en toegangsbeheer)	Microsoft Entra ID
Versleuteling van gegevens in rust	Ja	Ja	Ja	Ja	Ja¹	Ja	Ja
Beveiliging op rijniveau	Ja	Ja	Ja	Ja	Ja	Nee	Ja
Ondersteunt firewalls	Ja²	Ja²	Ja³	Ja	Ja	Ja	Ja
Dynamische gegevensmaskering	Ja⁴	Ja⁴	Nee	Ja	Ja	Nee	Nee

[1] Vereist het gebruik van transparante gegevensversleuteling om uw in rust opgeslagen gegevens te versleutelen en te ontsleutelen.

[2] Gebruik privékoppelingen en Microsoft Entra Voorwaardelijke toegang om de toegang tot Fabric resources te beperken.

[3] Fabric Eventhouse- en Real-Time Intelligence-workloads kunnen gegevens opnemen uit beveiligde bronnen, zoals Kafka, Azure Event Hubs en AMQP, met routering via beveiligde eindpunten.

[4] Pas deze toe op Fabric SQL-eindpuntniveau.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteur:

Mohit Agarwal | Principal Cloud Solution Architect

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Feedback

Is deze pagina nuttig?

Last updated on 2026-08-29