Auswählen eines Analysedatenspeichers in Azure

Die Big Data-Architektur benötigt häufig einen analytischen Datenspeicher, der verarbeitete Daten in einem strukturierten Format liefert. Sie können diese Daten mithilfe von Analysetools abfragen. Analytische Datenspeicher, die das Abfragen von Hot-Path- und Cold-Path-Daten unterstützen, werden zusammen als Dienstebene oder Datenspeicher bezeichnet.

Die Dienstschicht handhabt verarbeitete Daten sowohl vom heißen Pfad als auch vom kalten Pfad. In der Lambda-Architektur wird die Serving-Schicht in zwei Schichten unterteilt. Die Geschwindigkeitsbereitstellungsebene enthält die inkrementell verarbeiteten Daten. Die Batchverarbeitungsebene enthält die batchverarbeitete Ausgabe.

Während die gesamte Bereitstellungsschicht eine starke Unterstützung für zufällige Lesevorgänge mit geringer Latenz erfordert, sollte die Datenspeicherung für die Geschwindigkeitsschicht auch zufällige Schreibvorgänge unterstützen, da beim Laden von Batchdaten in diesen Speicher unerwünschte Verzögerungen auftreten. Umgekehrt muss die Datenspeicherung für die Batchschicht Batchschreibvorgänge unterstützen, nicht zufällige Schreibvorgänge.

Keine einzelne Datenverwaltungslösung passt zu jeder Datenspeicherungsaufgabe. Für bestimmte Aufgaben sind unterschiedliche Lösungen optimal. Die meisten realen Cloud-Apps und Big Data-Prozesse haben verschiedene Anforderungen an die Datenspeicherung und verwenden häufig eine Kombination aus Speicherlösungen.

Moderne analytische Lösungen wie Microsoft Fabric bieten eine umfassende Plattform, die verschiedene Datendienste und Tools integriert, um vielfältige analytische Anforderungen zu erfüllen. Fabric enthält OneLake, bei dem es sich um einen einzigen, einheitlichen, logischen Datensee für Ihre gesamte Organisation handelt. OneLake wurde entwickelt, um alle Organisationsdaten an einem Ort zu speichern, zu verwalten und zu schützen. Diese Flexibilität ermöglicht Es Ihrer Organisation, eine vielzahl von Anforderungen an die Datenspeicherung und -verarbeitung zu erfüllen.

Auswählen eines Analysedatenspeichers

Microsoft bietet je nach Ihren Anforderungen mehrere Optionen für die Speicherung von Daten.

Verschiedene Datenbankmodelle eignen sich für verschiedene Aufgabentypen:

Schlüsselwert-Datenspeicher enthalten ein einzelnes serialisiertes Objekt für jeden Schlüsselwert. Sie können große Datenmengen verwalten, wenn der Abruf auf einem bestimmten Schlüssel basiert, ohne andere Elementeigenschaften abfragen zu müssen.
Dokumentdatenspeicher sind Schlüsselwert-Datenspeicher, in denen es sich bei den Werten um Dokumente handelt. In diesem Zusammenhang ist ein Dokument eine Auflistung benannter Felder und Werte. Der Datenspeicher speichert die Daten in der Regel in einem Format wie XML, YAML, JSON oder binärem JSON, kann jedoch Nur-Text verwenden. Dokumentdatenspeicher können Nichtschlüsselfelder abfragen und sekundäre Indizes definieren, um die Abfrageeffizienz zu verbessern. Diese Funktion macht eine Dokumentdatenbank für Anwendungen besser geeignet, die Daten basierend auf Kriterien abrufen müssen, die komplexer sind als der Wert des Dokumentschlüssels. Sie können z. B. Felder wie Produkt-ID, Kunden-ID oder Kundenname abfragen.
Spaltenfamiliendatenspeicher sind Schlüsselwert-Datenspeicher, die jede Spalte separat auf dem Datenträger speichern. Ein breiter Spaltenspeicher speichert Spaltenfamilien, nicht nur einzelne Spalten. Eine Zählungsdatenbank kann z. B. eine separate Spaltenfamilie für jedes einzelne Attribut aufweisen:
- Vorname, zweiter Vorname und Nachname
- Postanschrift
- Profilinformationen, z. B. Geburtsdatum oder Geschlecht
Der Datenspeicher kann jede Spaltenfamilie in einer separaten Partition speichern und gleichzeitig alle Daten für eine Person im Zusammenhang mit demselben Schlüssel aufbewahren. Eine Anwendung kann eine einzelne Spaltenfamilie lesen, ohne alle Daten für eine Entität zu scannen.
Graph-Daten speichern Informationen als Sammlung von Objekten und Beziehungen. Ein Diagrammdatenspeicher kann Abfragen effizient ausführen, die das Netzwerk von Objekten und die Beziehungen zwischen diesen durchlaufen. Die Objekte können beispielsweise Mitarbeiter in einer Personalverwaltungsdatenbank sein, und Sie können Abfragen der Art „Alle Mitarbeiter ermitteln, die direkt oder indirekt für Stephan arbeiten“ durchführen.
Telemetrie- und Zeitreihendatenbanken sind nur zum Anfügen gedachte Sammlungen von Objekten. Telemetriedatenbanken indizieren Daten effizient in verschiedenen Spaltenspeichern und In-Memory-Strukturen. Diese Funktion macht sie zur optimalen Wahl, um große Mengen an Telemetrie- und Zeitreihendaten zu speichern und zu analysieren.

Fabric unterstützt verschiedene Datenbankmodelle, einschließlich Schlüsselwert-, Dokument-, Spaltenspeicher-, Diagramm- und Telemetriedatenbanken. Diese Flexibilität sorgt für Skalierbarkeit für eine vielzahl analytischer Aufgaben. Informationen zum Auswählen des richtigen Fabric Datenspeichers für Ihre analytischen Workloads finden Sie in Fabric Entscheidungshandbuch: Auswählen eines Datenspeichers.

Wichtige Auswahlkriterien

Berücksichtigen Sie die folgenden Kriterien, um den Auswahlprozess zu verfeinern:

Benötigen Sie Bereitstellungsspeicher, der als langsamster Pfad (Hot Path) für Ihre Daten dienen kann? Wenn ja, wählen Sie Optionen, die für eine auf Geschwindigkeit optimierte Bereitstellungsebene geeignet sind.
Benötigen Sie massive parallele Verarbeitungsunterstützung, bei der Abfragen automatisch über mehrere Prozesse oder Knoten verteilt werden? Wenn ja, sollten Sie eine Option wählen, die die horizontale Skalierung für Abfragen unterstützt.
Bevorzugen Sie die Verwendung eines relationalen Datenspeichers? Wenn Sie dies tun, wählen Sie Optionen mit einem relationalen Datenbankmodell aus. Einige nichtrelationale Speicher unterstützen jedoch die SQL-Syntax für abfragen, und Sie können Tools wie SQL-Analyseendpunkte verwenden, um nichtrelationale Datenspeicher wie OneLake abzufragen.
Sammeln Sie Zeitreihendaten? Verwenden Sie nur zum Anfügen gedachte Daten? OneLake unterstützt mehrere Analysemodule, einschließlich Analysis Services, T-SQL und Apache Spark. Eventhouse eignet sich gut für verschiedene Zeitreihen-Datenverarbeitungs- und Abfrageanforderungen.

Funktionsmatrix

In den folgenden Tabellen sind die wichtigsten Unterschiede zwischen den Funktionen dieser verwalteten Dienste zusammengefasst.

Allgemeine Funktionen

Fähigkeit	Lakehouse	Data Warehouse	Eventhouse	Fabric SQL-Datenbank	Azure SQL-Datenbank	Azure Cosmos DB (ein Microsoft-Datenbankdienst)	Analyse-Services
Primäres Datenbankmodell	Einheitliches Data Lake-, relationales, benutzerverwaltetes Delta-Lake-Format mit Apache Parquet	Einheitlicher Data Lake, relationales, systemverwaltetes Delta-Lake-Format mit Apache-Parkett	Anfügeorientierter Datenspeicher für Zeitreihen, Diagramm, Vektor	Relational (Spaltenspeicherformat bei Verwendung von Spaltenspeicherindizes)	Relational (Spaltenspeicherformat bei Verwendung von Spaltenspeicherindizes)	Dokumentspeicher, Diagramm, Schlüssel-Wert-Speicherung, Wide Columnstore	Tabellarische Semantikmodelle
SQL-Sprachunterstützung	Ja¹	Ja	Ja²	Ja	Ja	Ja	Keine
Optimiert für Ebene für schnelle Bereitstellung	Ja	Ja	Ja³	Ja⁴	Ja⁵	Ja	Keine

[1] T-SQL über DEN SQL-Analyseendpunkt.

[2] Kusto Query Language (KQL) verfügt über teilweise T-SQL-Sprachunterstützung.

[3] Unterstützt die Aufnahme in die Warteschlange und die Streamingaufnahme.

[4] Unterstützt transaktionale Präzision mit niedrigem Latenzzugriff und Echtzeitaktualisierungen.

[5] Mithilfe von speicheroptimierten Tabellen und Hash- oder nicht gruppierten Indizes.

Skalierbarkeitsfunktionen

Fähigkeit	Lakehouse	Data Warehouse	Eventhouse	Fabric SQL-Datenbank	Azure SQL-Datenbank	Azure Cosmos DB (ein Microsoft-Datenbankdienst)	Analyse-Services
Redundante regionale Server für Hochverfügbarkeit	Ja^1,2	Ja^1,2	Ja	Ja	Ja	Ja	Ja
Unterstützung der horizontalen Skalierung von Abfragen	Ja³	Ja⁴	Ja⁵	Ja	Keine	Ja	Ja
Dynamische Skalierbarkeit (Hochskalieren)	Ja³	Ja⁴	Ja⁵	Ja	Ja	Ja	Ja
Unterstützung der speicherinternen Zwischenspeicherung von Daten	Ja⁶	Ja⁶	Ja⁷	Ja	Ja	Ja	Keine

SQL-Endpunkte werden über globale Traffic-Manager geleitet, die Daten werden jedoch immer in der zugewiesenen Fabric-Kapazitätsregion verarbeitet.

[2] Lakehouses und Warehouses speichern Daten in OneLake im Delta-Parquet-Format, das das Abfragen und die Replikation über verschiedene Engines hinweg unterstützt.

[3] Lakehouse unterstützt Spark-basiertes Scaleout für unstrukturierte und strukturierte Daten.

[4] Warehouse verwendet T-SQL und unterstützt multitable Transaktionen, autonome Workloadverwaltung und verteilte Abfrageverarbeitung (Distributed Query Processing, DQP). DQP fungiert als Cluster-Manager, wobei Computeressourcen basierend auf der Abfragekomplexität dynamisch zugeordnet werden.

[5] Eventhouse unterstützt KQL- und SQL-Föderation für Echtzeitanalysen über mehrere Quellen hinweg sowie zum Hochskalieren der Computeressourcen, wenn die Nutzung des Hot Cache ~95 % überschreitet.

[6] Intelligenter Cache für Spark-Aufträge, speicherinterne Zwischenspeicherung, Zwischenspeicherung von Ergebnismengen für SQL-Analyseendpunkte.

[7] Häufig abgerufene Daten werden in einem Hot-Cache gespeichert, der Arbeitsspeicher und SSD-Speicher umfasst.

Sicherheitsfunktionen

Fähigkeit	Lakehouse	Data Warehouse	Eventhouse	Fabric SQL-Datenbank	Azure SQL-Datenbank	Azure Cosmos DB (ein Microsoft-Datenbankdienst)	Analyse-Services
Authentifizierung	Microsoft Entra ID	Microsoft Entra ID	Microsoft Entra ID	Microsoft Entra ID	SQL oder Microsoft Entra ID	Datenbankbenutzer oder Microsoft Entra-ID über Zugriffssteuerung (Identitäts- und Zugriffsverwaltung)	Microsoft Entra ID
Datenverschlüsselung ruhender Daten	Ja	Ja	Ja	Ja	Ja¹	Ja	Ja
Zeilenbasierte Sicherheit	Ja	Ja	Ja	Ja	Ja	Keine	Ja
Unterstützung von Firewalls	Ja²	Ja²	Ja³	Ja	Ja	Ja	Ja
Dynamische Datenmaskierung	Ja⁴	Ja⁴	Keine	Ja	Ja	Keine	Keine

[1] Hierfür müssen Sie Transparente Datenverschlüsselung verwenden, um Ihre Ruhedaten zu verschlüsseln und zu entschlüsseln.

[2] Verwenden Sie private Links und Microsoft Entra Conditional Access, um den Zugriff auf Fabric Ressourcen einzuschränken.

[3] Fabric Eventhouse- und Real-Time Intelligence-Workloads können Daten aus sicheren Quellen wie Kafka, Azure Event Hubs und AMQP mit Routing über sichere Endpunkte aufnehmen.

[4] Wenden Sie sie auf Fabric SQL-Endpunktebene an.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

Mohit Agarwal | Principal Cloud Solution Architect

Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

Feedback

War diese Seite hilfreich?

Last updated on 2026-08-29