Bearbeiten

Data Warehousing in Microsoft Azure

Synapse Analytics

Ein Data Warehouse ist ein zentrales Repository für integrierte Daten aus einer einzelnen oder mehreren unterschiedlichen Quellen. In Data Warehouses werden aktuelle Daten und Verlaufsdaten gespeichert und zur Erstellung von Datenberichten und -analysen verwendet.

Abbildung: Data Warehousing in Azure

Laden Sie eine Visio-Datei dieser Architektur herunter.

Für ein Data Warehouse vorgesehene Daten werden in regelmäßigen Abständen aus verschiedenen Quellen mit wichtigen Unternehmensdaten extrahiert. Die Daten können im Zuge der Verschiebung formatiert, bereinigt, validiert, zusammengefasst und neu strukturiert werden. Alternativ können die Daten auf der niedrigsten Detailebene gespeichert werden – mit aggregierten Ansichten, die im Warehouse zur Berichterstellung zur Verfügung stehen. In beiden Fällen wird die Data Warehouse-Instanz zu einem dauerhaften Datenspeicher für Berichterstellung, Analyse und Business Intelligence (BI).

Data Warehouse-Architekturen

Mit den folgenden Referenzarchitekturen werden die End-to-End-Data Warehouse-Architekturen in Azure veranschaulicht:

Verwendung dieser Lösung

Entscheiden Sie sich für ein Data Warehouse, wenn Sie große Mengen von Daten aus betriebsbezogenen Systemen in ein leicht verständliches Format bringen müssen. Für Data Warehouses muss nicht die gleiche knappe Datenstruktur verwendet werden, die ggf. in Ihren OLTP-Datenbanken zur Anwendung kommt. Sie können Spaltennamen verwenden, die für geschäftliche Benutzer und Analytiker sinnvoll sind, das Schema zur Vereinfachung von Beziehungen umstrukturieren und mehrere Tabellen in einer zentralen Tabelle zusammenfassen. Auf diese Weise unterstützen Sie Benutzer bei der Erstellung von Berichten und der Analyse der Daten in BI-Systemen, damit diese die Schritte ohne Hilfe von einem Datenbankadministrator (DBA) oder Datenentwickler ausführen können.

Ziehen Sie die Verwendung eines Data Warehouse in Betracht, wenn historische Daten aus Leistungsgründen von den Quelltransaktionssystemen getrennt bleiben müssen. Data Warehouses sind ein zentraler Ort mit gängigen Formaten, Schlüsseln und Datenmodellen, um den Zugriff auf Verlaufsdaten von mehreren Orten aus zu vereinfachen.

Da Data Warehouses für Lesezugriff optimiert sind, ist das Generieren von Berichten schneller als die Verwendung des Quelltransaktionssystems für die Berichterstellung.

Weitere Vorteile sind:

  • In den Data Warehouses können Verlaufsdaten aus mehreren Quellen gespeichert werden, um eine zentrale Quelle mit Informationen zu erhalten.
  • Sie können die Datenqualität verbessern, indem Sie Daten bereinigen, wenn diese in das Data Warehouse importiert werden.
  • Berichterstellungstools konkurrieren nicht mit den Transaktionssystemen um Abfrageverarbeitungszyklen. Bei Nutzung eines Data Warehouse kann sich das Transaktionssystem um die Verarbeitung von Schreibvorgängen kümmern, während das Data Warehouse den Großteil der Leseanforderungen übernimmt.
  • Ein Data Warehouse kann zur Konsolidierung von Daten unterschiedlicher Software verwendet werden.
  • Mit Data Mining-Tools können durch den Einsatz von automatischen Methodiken verborgene Muster ermittelt werden.
  • Data Warehouses vereinfachen die Bereitstellung von sicherem Zugriff für autorisierte Benutzer sowie die Beschränkung des Zugriffs für andere. Da geschäftliche Benutzer keinen Zugriff auf die Quelldaten benötigen, wird ein potenzieller Angriffsvektor beseitigt.
  • Data Warehouses vereinfachen die Erstellung von Business Intelligence-Lösungen, z. B. OLAP-Cubes.

Herausforderungen

Benutzer, die ein Data Warehouse ordnungsgemäß für ihre geschäftlichen Anforderungen konfigurieren möchten, sehen sich unter Umständen mit einigen der folgenden Herausforderungen konfrontiert:

  • Zeitaufwand für die ordnungsgemäße Modellierung der Geschäftskonzepte: Data Warehouses sind informationsbasiert. Es ist daher erforderlich, dass Sie geschäftsbezogene Begriffe standardisieren und gemeinsame Formate verwenden, z. B. für Währungen und Datumsangaben. Darüber hinaus müssen Sie das Schema so umstrukturieren, wie es für geschäftliche Benutzer sinnvoll ist, aber gleichzeitig muss die Genauigkeit von Datenaggregaten und -beziehungen weiter gewährleistet sein.

  • Planung und Einrichtung Ihrer Datenorchestrierung: Sie sollten berücksichtigen, wie Daten aus dem Quelltransaktionssystem in das Data Warehouse kopiert und wann Verlaufsdaten aus den Speichern für Betriebsdaten in das Warehouse verschoben werden sollen.

  • Gewährleistung oder Optimierung der Datenqualität durch Bereinigung der Daten beim Importieren in das Warehouse

Data Warehousing in Azure

Sie verfügen ggf. über eine oder mehrere Datenquellen, z. B. im Rahmen von Kundentransaktionen oder Geschäftsanwendungen. Diese Daten sind üblicherweise in mindestens einer OLTP-Datenbank gespeichert. Die Daten können auf anderen Speichermedien wie Netzwerkfreigaben, in Azure Storage-Blobs oder in einem Data Lake gespeichert werden. Die Daten können auch vom Data Warehouse selbst oder in einer relationalen Datenbank wie Azure SQL-Datenbank gespeichert werden. Die Analysedatenspeicher-Ebene dient zum Abwickeln von Abfragen, die von Analyse- und Berichtstools für das Data Warehouse ausgegeben werden. In Azure kann für diese Analysespeicherfunktion Azure Synapse oder Azure HDInsight mit Hive oder Interactive Query verwendet werden. Darüber hinaus benötigen Sie ein gewisses Maß an Orchestrierung, um Daten aus dem Datenspeicher in das Data Warehouse zu verschieben oder zu kopieren. Hierzu können Sie Azure Data Factory oder Oozie in Azure HDInsight verwenden.

Ein Data Warehouse kann in Azure auf verschiedene Arten implementiert werden. Für welche Option Sie sich entscheiden, hängt ganz von Ihren Anforderungen ab. Die folgenden Listen sind in zwei Kategorien unterteilt: symmetrisches Multiprocessing (SMP) und Massively Parallel Processing (MPP).

SMP:

MPP:

Allgemein gilt: SMP-basierte Warehouses eignen sich am besten für kleine bis mittelgroße Datasets (4 bis 100 TB), während MPP häufig für Big Data verwendet wird. Die Abgrenzung zwischen kleinen/mittelgroßen Daten und Big Data hängt zum Teil mit der Definition und der unterstützenden Infrastruktur Ihres Unternehmens zusammen. (Weitere Informationen finden Sie unter Choosing an OLTP data store (Auswählen eines OLTP-Datenspeichers).)

Abgesehen davon hat die Art des Workloadmusters wahrscheinlich einen größeren Einfluss auf die Entscheidung als die Datengröße. So können beispielsweise komplexe Abfragen für eine SMP-Lösung zu langsam sein und die Verwendung einer MPP-Lösung erforderlich machen. Bei MPP-basierten Systemen ist normalerweise mit Leistungseinbußen bei geringen Datengrößen zu rechnen. Dies ist auf die knotenübergreifende Verteilung und Konsolidierung der Aufträge zurückzuführen. Wenn die Größe Ihrer Daten bereits 1 TB übersteigt und voraussichtlich weiter zunimmt, empfiehlt sich die Verwendung einer MPP-Lösung. Und auch wenn Ihre Daten einen geringeren Umfang haben, Ihre Workloads aber die verfügbaren Ressourcen Ihrer SMP-Lösung übersteigen, ist MPP wahrscheinlich die beste Wahl.

Die Daten, auf die Ihr Data Warehouse zugreift bzw. die von Ihrem Data Warehouse gespeichert werden, können aus verschiedensten Datenquellen stammen – unter anderem auch aus einem Data Lake wie Azure Data Lake Storage. Ein Video, in dem die verschiedenen Stärken von für Azure Data Lake geeigneten MPP-Diensten miteinander verglichen werden, finden Sie unter Azure Data Lake and Azure Data Warehouse: Applying Modern Practices to Your App (Azure Data Lake und Azure Data Warehouse: moderne Methoden für Ihre App).

SMP-Systeme zeichnen sich durch eine einzelne Instanz eines Managementsystems für relationale Datenbanken aus, die sämtliche Ressourcen (CPU/Arbeitsspeicher/Datenträger) gemeinsam nutzen. Ein SMP-System kann hochskaliert werden. Für SQL Server auf einem virtuellen Computer können Sie die VM-Größe hochskalieren. Für Azure SQL-Datenbank können Sie zum Hochskalieren eine andere Dienstebene auswählen.

MPP-Systeme können durch das Hinzufügen weiterer Computeknoten (mit eigener CPU, eigenem Arbeitsspeicher und eigenen E/A-Subsystemen) horizontal hochskaliert werden. Aufgrund physischer Einschränkungen kann ein Server nur bis zu einem gewissen Punkt zentral hochskaliert werden. Danach ist abhängig von der Workload horizontales Hochskalieren vorzuziehen. Die Unterschiede bei der Durchführung von Abfragen, der Modellierung und der Datenpartitionierung bedeuten aber, dass für MPP-Lösungen andere Fertigkeiten benötigt werden.

Der Abschnitt Genauere Betrachtung von Azure SQL-Datenbank und SQL Server auf Azure Virtual Machines enthält hilfreiche Informationen zur Wahl einer SMP-Lösung.

Azure Synapse (früher Azure SQL Data Warehouse) kann auch für kleine und mittelgroße Datasets mit rechen- und speicherintensiven Workloads verwendet werden. Erfahren Sie mehr zu Azure Synapse-Mustern und häufigen Szenarien:

Wichtige Auswahlkriterien

Beantworten Sie die folgenden Fragen, um die Auswahl einzuschränken:

  • Möchten Sie einen verwalteten Dienst verwenden, anstatt Ihre eigenen Server zu verwalten?

  • Arbeiten Sie mit sehr großen Datasets oder mit sehr komplexen Abfragen mit langer Ausführungszeit? Falls ja, empfiehlt sich die Verwendung einer MPP-Option.

  • Ist die Datenquelle bei einem großen Dataset strukturiert oder unstrukturiert? Unstrukturierte Daten müssen ggf. in einer Big Data-Umgebung wie Spark in HDInsight, Azure Databricks, Hive LLAP in HDInsight oder Azure Data Lake Analytics verarbeitet werden. Alle diese Optionen können als ELT-Modul (Extrahieren, Laden, Transformieren) sowie als ETL-Modul (Extrahieren, Transformieren, Laden) fungieren. Die verarbeiteten Daten können als strukturierte Daten ausgegeben werden, um sie leichter in Azure Synapse oder in eine der anderen Optionen laden zu können. Für strukturierte Daten bietet Azure Synapse die Leistungsstufe „Optimiert für Compute“, die für rechenintensive Workloads mit sehr hohen Leistungsanforderungen konzipiert ist.

  • Möchten Sie Ihre historischen Daten und Ihre aktuellen operativen Daten trennen? Falls ja, wählen Sie eine der Optionen, die eine Orchestrierung erfordern. Hierbei handelt es sich um eigenständige Warehouses, die für intensiven Lesezugriff optimiert und am besten als separater Speicher für historische Daten geeignet sind.

  • Müssen Sie Daten aus mehreren Quellen (abgesehen von Ihrem OLTP-Datenspeicher) integrieren? Ist dies der Fall, sollten Sie Optionen erwägen, die eine einfache Integration mehrerer Datenquellen ermöglichen.

  • Sind Sie auf Mehrinstanzenfähigkeit angewiesen? Wenn ja, ist Azure Synapse für diese Anforderung nicht ideal geeignet. Weitere Informationen finden Sie unter Azure Synapse-Muster und -Antimuster.

  • Bevorzugen Sie einen relationalen Datenspeicher? Falls ja, sollten Sie eine Option mit einem relationalen Datenspeicher wählen. Bedenken Sie hierbei aber, dass Sie relationale Datenspeicher bei Bedarf nicht mithilfe eines Tools wie PolyBase abfragen können. Sollten Sie sich für die Verwendung von PolyBase entscheiden, führen Sie anhand Ihrer unstrukturierte Datasets Leistungstests für Ihre Workload aus.

  • Benötigen Sie Echtzeitberichte? Wenn Sie bei großen Mengen von Singleton-Einfügungen kurze Reaktionszeiten für Abfragen benötigen, sollten Sie eine Option wählen, die Echtzeitberichte unterstützt.

  • Müssen Sie eine große Anzahl von gleichzeitigen Benutzern und Verbindungen unterstützen? Die Unterstützung einer Reihe von gleichzeitigen Benutzern/Verbindungen hängt von mehreren Faktoren ab.

    • Informieren Sie sich für Azure SQL-Datenbank über die dokumentierten Ressourcenlimits für Ihre Dienstebene.

    • Bei SQL Server sind maximal 32.767 Benutzerverbindungen zulässig. Bei Ausführung auf einem virtuellen Computer hängt die Leistung von der Größe des virtuellen Computers sowie von anderen Faktoren ab.

    • Bei Azure Synapse ist die Anzahl gleichzeitiger Abfragen und gleichzeitiger Verbindungen beschränkt. Weitere Informationen finden Sie unter Parallelitäts- und Workloadverwaltung in Azure Synapse. Die Einschränkungen von Azure Synapse lassen sich bei Bedarf mit zusätzlichen Diensten wie Azure Analysis Services kompensieren.

  • Welche Art von Workload verwenden Sie? Im Allgemeinen eignen sich MPP-basierte Warehouse-Lösungen am besten für analytische, batchorientierte Workloads. Wenn es sich bei Ihrer Workload um eine Transaktionsworkload mit zahlreichen kleinen Lese-/Schreibvorgängen oder mehreren zeilenweisen Vorgängen handelt, empfiehlt sich die Verwendung einer SMP-Option. Hiervon ausgenommen sind Szenarien, in denen eine Streamverarbeitung für einen HDInsight-Cluster (beispielsweise Spark Streaming) verwendet wird und die Daten in einer Hive-Tabelle gespeichert werden.

Funktionsmatrix

In den folgenden Tabellen sind die Hauptunterschiede der Funktionen zusammengefasst:

Allgemeine Funktionen

Funktion Azure SQL-Datenbank SQL Server (VM) Azure Synapse Apache Hive in HDInsight Hive LLAP in HDInsight
Verwalteter Dienst Ja Nein Ja Ja1 Ja1
Erfordert Datenorchestrierung (Speicherung von Datenkopie/historischen Daten) Nein Nein Ja Ja Ja
Einfache Integration mehrerer Datenquellen Nein Nein Ja Ja Ja
Unterstützung des Anhaltens von Computevorgängen Nein Nein Ja Nein2 Nein2
Relationaler Datenspeicher Ja Ja Ja Nein Nein
Echtzeitberichte Ja Ja Nein Nein Ja
Flexible Sicherungswiederherstellungspunkte Ja Ja Nein3 Ja 4 Ja 4
SMP/MPP SMP SMP MPP MPP MPP

[1] Manuelle Konfiguration und Skalierung.

[2] Nicht benötigte HDInsight-Cluster können gelöscht und später erneut erstellt werden. Fügen Sie an Ihren Cluster einen externen Datenspeicher an, damit Ihre Daten beim Löschen des Clusters erhalten bleiben. Zur Automatisierung des Clusterlebenszyklus können Sie mithilfe von Azure Data Factory einen bedarfsgesteuerten HDInsight-Cluster für die Verarbeitung Ihrer Workload erstellen und ihn nach Abschluss der Verarbeitung wieder löschen.

[3] Mit Azure Synapse können Sie für eine Datenbank jeden verfügbaren Wiederherstellungspunkt innerhalb der letzten sieben Tage wiederherstellen. Momentaufnahmen werden alle vier bis acht Stunden gestartet und sind sieben Tage lang verfügbar. Wenn eine Momentaufnahme älter als sieben Tage ist, läuft sie ab, und ihr Wiederherstellungspunkt ist nicht mehr verfügbar.

[4] Verwenden Sie ggf. einen externen Hive-Metastore, der nach Bedarf gesichert und wiederhergestellt werden kann. Für die Daten können die standardmäßigen Sicherungs- und Wiederherstellungsoptionen für Blob Storage oder Data Lake Storage verwendet werden. Wenn Sie mehr Flexibilität und Komfort benötigen, können Sie aber auch HDInsight-Sicherungs- und Wiederherstellungslösungen von Drittanbietern (beispielsweise Imanis Data) verwenden.

Skalierbarkeitsfunktionen

Funktion Azure SQL-Datenbank SQL Server (VM) Azure Synapse Apache Hive in HDInsight Hive LLAP in HDInsight
Redundante regionale Server für Hochverfügbarkeit Ja Ja Ja Nein Nein
Unterstützung des Aufskalierens für Abfragen (verteilte Abfragen) Nein Nein Ja Ja Ja
Dynamische Skalierbarkeit Ja Nein Ja1 Nein Nein
Unterstützung der speicherinternen Zwischenspeicherung von Daten Ja Ja Ja Ja Ja

[1] Azure Synapse ermöglicht Hoch- und Herunterskalieren durch Anpassung der Anzahl von Data Warehouse-Einheiten (Data Warehouse Units, DWUs). Weitere Informationen finden Sie unter Verwalten von Computeleistung in Azure Synapse.

Sicherheitsfunktionen

Funktion Azure SQL-Datenbank SQL Server auf einem virtuellen Computer Azure Synapse Apache Hive in HDInsight Hive LLAP in HDInsight
Authentifizierung SQL/Azure Active Directory (Azure AD) SQL/Azure AD/Active Directory SQL/Azure AD Lokal/Azure AD 1 Lokal/Azure AD 1
Authorization Ja Ja Ja Ja Ja1
Überwachung Ja Ja Ja Ja Ja1
Datenverschlüsselung ruhender Daten Ja2 Ja2 Ja2 Ja2 Ja1
Sicherheit auf Zeilenebene Ja Ja Ja Nein Ja1
Unterstützung von Firewalls Ja Ja Ja Ja Ja3
Dynamische Datenmaskierung Ja Ja Ja Nein Ja1

[1] Erfordert die Verwendung eines in die Domäne eingebundenen HDInsight-Clusters.

[2] Erfordert die Verwendung von Transparent Data Encryption (TDE) zum Verschlüsseln und Entschlüsseln ruhender Daten.

[3] Unterstützt bei Verwendung in einem virtuellen Azure-Netzwerk

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Weitere Informationen zum Schutz Ihres Data Warehouse finden Sie hier: