Auswählen eines Analysedatenspeichers in Azure
In einer Big Data-Architektur wird häufig ein Analysedatenspeicher benötigt, der verarbeitete Daten in einem strukturierten Format bereitstellt, das Abfragen mit Analysetools ermöglicht. Analysedatenspeicher, die sowohl das Abfragen von Hot-Path- als auch von Cold-Path-Daten unterstützen, werden zusammenfassend als Bereitstellungsebene oder Datenbereitstellungsspeicher bezeichnet.
Die Bereitstellungsebene wird für verarbeitete Hot-Path- und Cold-Path-Daten verwendet. In der Lambda-Architektur ist die Bereitstellungsebene in zwei Ebenen unterteilt: eine Ebene für die schnelle Bereitstellung, auf der inkrementell verarbeitete Daten gespeichert werden, und eine Ebene für die Batchbereitstellung, die die Ausgabe der Batchverarbeitung enthält. Für die Bereitstellungsebene ist eine starke Unterstützung für zufällige Lesevorgänge mit kurzer Wartezeit erforderlich. Der Datenspeicher für die Geschwindigkeitsebene sollte außerdem zufällige Schreibvorgänge unterstützen, da es beim Batchladen von Daten in diesen Speicher zu unerwünschten Verzögerungen kommen kann. Andererseits wird für die Datenspeicherung für die Batchebene keine Unterstützung von zufälligen Schreibvorgängen benötigt, sondern von Batchschreibvorgängen.
Es gibt keine Lösung für die Datenverwaltung, die für alle Datenspeicheraufgaben am besten geeignet ist. Verschiedene Datenverwaltungslösungen sind für unterschiedliche Aufgaben optimiert. Die meisten Cloud-Apps und Big Data-Prozesse aus der Praxis verfügen über viele verschiedene Datenspeicheranforderungen, und häufig wird eine Kombination von Datenspeicherlösungen genutzt.
Welche Möglichkeiten haben Sie bei der Auswahl eines Analysedatenspeichers?
Es gibt mehrere Optionen für die Datenbereitstellungsspeicherung in Azure. Dies richtet sich nach Ihren jeweiligen Anforderungen:
- Azure Synapse Analytics
- Azure Synapse Spark-Pools
- Azure Databricks
- Azure Data Explorer
- Azure SQL-Datenbank
- SQL Server auf einer Azure-VM
- HBase/Phoenix in HDInsight
- Hive LLAP in HDInsight
- Azure Analysis Services
- Azure Cosmos DB
Im Rahmen dieser Optionen gibt es verschiedene Datenbankmodelle, die für unterschiedliche Arten von Aufgaben optimiert sind:
- Schlüssel-Wert-Datenbanken enthalten für jeden Schlüsselwert ein serialisiertes Objekt. Diese eignen sich gut zum Speichern von großen Datenmengen, bei denen Sie ein Element für einen bestimmten Schlüsselwert abrufen möchten und keine Abfrage basierend auf anderen Eigenschaften des Elements durchführen müssen.
- Dokumentdatenbanken sind Schlüssel-Wert-Datenbanken, in denen die Werte Dokumente sind. Ein „Dokument“ ist in diesem Zusammenhang eine Sammlung mit benannten Feldern und Werten. In der Datenbank werden die Daten normalerweise in einem bestimmten Format gespeichert, z. B. XML, YAML, JSON oder binäres JSON (BSON), aber es kann auch Nur-Text verwendet werden. In Dokumentdatenbanken können Abfragen für Felder durchgeführt werden, bei denen es sich nicht um Schlüsselfelder handelt, und es können sekundäre Indizes definiert werden, um das Abfragen effizienter zu gestalten. Eine Dokumentdatenbank ist daher besser für Anwendungen geeignet, für die Daten basierend auf Kriterien abgerufen werden müssen, die komplexer als der Wert des Dokumentschlüssels sind. Sie können beispielsweise Abfragen für Felder wie Produkt-ID, Kunden-ID oder Kundenname durchführen.
- Columnstore-Datenbanken sind Schlüssel-Wert-Datenspeicher, in denen jede Spalte separat auf dem Datenträger gespeichert wird. Eine Wide Columnstore-Datenbank ist ein Typ von Columnstore-Datenbank, in der Spaltenfamilien und nicht nur einzelne Spalten gespeichert werden. Eine Datenbank für eine Erhebung kann beispielsweise eine Spaltenfamilie für den Namen einer Person (Vorname, Zweiter Vorname, Nachname), eine Familie für die Adresse der Person und eine Familie für die Profilinformationen der Person (Geburtsdatum, Geschlecht) enthalten. In der Datenbank kann jede Spaltenfamilie auf einer separaten Partition gespeichert werden, während alle Daten für eine Person demselben Schlüssel zugeordnet bleiben. Eine Anwendung kann eine einzelne Spaltenfamilie lesen, ohne sich alle Daten einer Entität durchzulesen.
- In Diagrammdatenbanken werden Informationen als Sammlung mit Objekten und Beziehungen gespeichert. Eine Diagrammdatenbank kann auf effiziente Weise Abfragen durchführen, die das Netzwerk der Objekte und die dazugehörigen Beziehungen 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 effizient Daten in einer Vielzahl von Spaltenspeichern und In-Memory-Strukturen. Dadurch stellen Sie die optimale Wahl zum Speichern und Analysieren großer Mengen von Telemetrie- und Zeitreihendaten dar.
Wichtige Auswahlkriterien
Beantworten Sie die folgenden Fragen, um die Auswahl einzuschränken:
Benötigen Sie Bereitstellungsspeicher, der als langsamster Pfad (Hot Path) für Ihre Daten dienen kann? Wenn ja, können Sie sich auf die Optionen beschränken, die für eine Ebene für die schnelle Bereitstellung optimiert sind.
Muss die hochgradig parallelisierte Verarbeitung (Massively Parallel Processing, MPP) unterstützt werden, bei der Abfragen automatisch auf 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 ja, können Sie sich auf die Optionen mit einem relationalen Datenbankmodell beschränken. Beachten Sie aber, dass einige nicht relationale Speicher die SQL-Syntax für Abfragen unterstützen und dass Tools wie PolyBase genutzt werden können, um nicht relationale Datenspeicher abzufragen.
Sammeln Sie Zeitreihendaten? Verwenden Sie nur zum Anfügen gedachte Daten?
Funktionsmatrix
In den folgenden Tabellen sind die Hauptunterschiede der Funktionen zusammengefasst:
Allgemeine Funktionen
Funktion | SQL-Datenbank | Azure Synapse SQL-Pool | Azure Synapse-Spark-Pool | Azure-Daten-Explorer | HBase/Phoenix in HDInsight | Hive LLAP in HDInsight | Azure Analysis Services | Azure Cosmos DB |
---|---|---|---|---|---|---|---|---|
Verwalteter Dienst | Ja | Ja | Ja | Ja | Ja 1 | Ja 1 | Ja | Ja |
Primäres Datenbankmodell | Relational (Spaltenspeicherformat bei Verwendung von Columnstore-Indizes) | Relationale Tabellen mit Spaltenspeicher | Wide Columnstore | Relationaler Speicher (Spaltenspeicher), Telemetrie- und Zeitreihenspeicher | Wide Columnstore | Hive/In-Memory | Tabellarische Semantikmodelle | Dokumentspeicher, Diagramm, Schlüssel-Wert-Speicherung, Wide Columnstore |
SQL-Sprachunterstützung | Ja | Ja | Ja | Ja | Ja (mit Phoenix-JDBC-Treiber) | Ja | Keine | Ja |
Optimiert für Ebene für schnelle Bereitstellung | Ja2 | Ja 3 | Ja | Ja | Ja | Ja | Keine | Ja |
[1] Mit manueller Konfiguration und Skalierung
[2] Mit speicheroptimierten Tabellen und Hashindex oder nicht gruppierten Indizes
[3] Unterstützt als Azure Stream Analytics-Ausgabe
Skalierbarkeitsfunktionen
Funktion | SQL-Datenbank | Azure Synapse SQL-Pool | Azure Synapse-Spark-Pool | Azure-Daten-Explorer | HBase/Phoenix in HDInsight | Hive LLAP in HDInsight | Azure Analysis Services | Azure Cosmos DB |
---|---|---|---|---|---|---|---|---|
Redundante regionale Server für Hochverfügbarkeit | Ja | Nr. | Nein | Ja | Ja | Keine | Ja | Ja |
Unterstützung der horizontalen Skalierung von Abfragen | Nein | Ja | Ja | Ja | Ja | Ja | Ja | Ja |
Dynamische Skalierbarkeit (Hochskalieren) | Ja | Ja | Ja | Ja | Nr. | Nein | Ja | Ja |
Unterstützung der speicherinternen Zwischenspeicherung von Daten | Ja | Ja | Ja | Ja | Keine | Ja | Ja | Nein |
Sicherheitsfunktionen
Funktion | SQL-Datenbank | Azure Synapse | Azure-Daten-Explorer | HBase/Phoenix in HDInsight | Hive LLAP in HDInsight | Azure Analysis Services | Azure Cosmos DB |
---|---|---|---|---|---|---|---|
Authentifizierung | SQL/Microsoft Entra ID | SQL/Microsoft Entra ID | Microsoft Entra ID | lokal/Microsoft Entra ID 1 | lokal/Microsoft Entra ID 1 | Microsoft Entra ID | Datenbankbenutzer /Microsoft Entra ID über Zugriffssteuerung (Identitäts- und Zugriffsverwaltung (IAM)) |
Datenverschlüsselung ruhender Daten | Ja2 | Ja2 | Ja | Ja 1 | Ja 1 | Ja | Ja |
Sicherheit auf Zeilenebene | Ja | Ja3 | Ja | Ja 1 | Ja 1 | Ja | Nein |
Unterstützung von Firewalls | Ja | Ja | Ja | Ja 4 | Ja 4 | Ja | Ja |
Dynamische Datenmaskierung | Ja | Ja | Ja | Ja1 | Ja | Nr. | Nein |
[1] Erfordert die Verwendung eines in die Domäne eingebundenen HDInsight-Clusters.
[2] Erfordert die Verwendung von Transparent Data Encryption zum Verschlüsseln und Entschlüsseln ruhender Daten.
[3] Nur Filterprädikate. Siehe Sicherheit auf Zeilenebene
[4] Bei Verwendung in einem virtuellen Azure-Netzwerk. Weitere Informationen finden Sie unter Erweitern von Azure HDInsight mit einem virtuellen Azure-Netzwerk.
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautor:
- Zoiner Tejada | CEO und Architekt
Nächste Schritte
- Analysieren von Daten in einem relationalen Data Warehouse
- Erstellen einer Einzeldatenbank: Azure SQL-Datenbank
- Erstellen eines Azure Databricks-Arbeitsbereichs
- Erstellen eines Apache Spark-Clusters in Azure HDInsight im Azure-Portal
- Erstellen eines Synapse-Arbeitsbereichs
- Erkunden der Azure-Datendienste für moderne Analysen
- Einführung in Azure-Datenbank- und Analysedienste
- Abfragen von Azure Cosmos BD mithilfe der API für NoSQL