Enterprise Business Intelligence

Azure Active Directory
Blob Storage
Analysis Services
Data Factory
Synapse Analytics

Diese Referenzarchitektur implementiert eine ELT-Pipeline (Extrahieren, Laden und Transformieren), die Daten aus einer lokalen SQL Server-Datenbank in Azure Synapse verschiebt und die Daten für die Analyse transformiert.

GitHub-Logo Eine Referenzimplementierung dieser Architektur ist auf GitHub verfügbar.

Architekturdiagramm für Enterprise BI in Azure mit Azure Synapse

Szenario: Ein großes OLTP-Dataset einer Organisation ist lokal in einer SQL Server-Datenbank gespeichert. Die Organisation möchte mittels Azure Synapse eine Analyse mit Power BI ausführen.

Diese Referenzarchitektur ist für einmalige oder bedarfsgesteuerte Aufträge bestimmt. Wenn Sie fortlaufend (stündlich oder täglich) Daten verschieben müssen, sollten Sie mit Azure Data Factory einen automatisierten Workflow definieren. Eine Referenzarchitektur, die Data Factory verwendet, finden Sie unter Automatisierte Enterprise BI-Instanz mit Azure Synapse und Azure Data Factory.

Aufbau

Die Architektur umfasst die folgenden Komponenten.

Datenquelle

SQL Server. Die Quelldaten befinden sich in einer lokalen SQL Server-Datenbank. Um die lokale Umgebung zu simulieren, stellen die Bereitstellungsskripts für diese Architektur einen virtuellen Computer in Azure bereit, auf dem SQL Server installiert ist. Die OLTP-Beispieldatenbank von Wide World Importers wird als Datenquelle verwendet.

Erfassung und Datenspeicherung

Blobspeicher. Blobspeicher wird als Stagingbereich zum Kopieren der Daten vor dem Laden in Azure Synapse verwendet.

Azure Synapse: Azure Synapse ist ein verteiltes System für die Analyse großer Datenmengen. Es unterstützt massive Parallelverarbeitung (Massive Parallel Processing, MPP), die die Ausführung von Hochleistungsanalysen ermöglicht.

Analysen und Berichte

Azure Analysis Services: Analysis Services ist ein vollständig verwalteter Dienst, der Datenmodellierungsfunktionen ermöglicht. Verwenden Sie Analysis Services zum Erstellen eines semantischen Modells, das Benutzer abfragen können. Analysis Services ist in einem Szenario mit BI-Dashboard besonders nützlich. In dieser Architektur liest Analysis Services Daten aus dem Data Warehouse, um das semantische Modell zu verarbeiten, und bedient Dashboardabfragen effizient. Darüber hinaus unterstützt der Dienst auch die elastische Parallelität durch zentrales Hochskalieren von Replikaten zur schnelleren Abfragenverarbeitung.

Zurzeit unterstützt Azure Analysis Services tabellarische Modelle, aber keine mehrdimensionalen Modelle. Tabellarische Modelle verwenden relationale Modellierungskonstrukte (Tabellen und Spalten), wohingegen mehrdimensionale Modelle OLAP-Modellierungskonstrukte (Cubes, Dimensionen und Measures) verwenden. Wenn Sie mehrdimensionale Modelle benötigen, verwenden Sie SQL Server Analysis Services (SSAS). Weitere Informationen finden Sie unter Vergleichen von tabellarischen und mehrdimensionalen Lösungen.

Power BI: Power BI ist eine Suite aus Business Analytics-Tools zum Analysieren von Daten für Einblicke in Geschäftsvorgänge. In dieser Architektur dient sie zum Abfragen des in Analysis Services gespeicherten semantischen Modells.

Authentifizierung

Azure Active Directory (Azure AD) authentifiziert Benutzer, die über Power BI eine Verbindung mit dem Analysis Services-Server herstellen.

Datenpipeline

Diese Referenzarchitektur verwendet die Beispieldatenbank WorldWideImporters als Datenquelle. Die Phasen der Datenpipeline sind:

  1. Exportieren der Daten aus SQL Server in Flatfiles (BCP-Hilfsprogramm).
  2. Kopieren der Flatfiles in Azure Blob Storage (AzCopy).
  3. Laden der Daten in Azure Synapse (PolyBase).
  4. Transformieren der Daten in ein Sternschema (T-SQL).
  5. Laden eines Semantikmodells in Analysis Services (SQL Server Data Tools).

Diagramm der Enterprise BI-Pipeline

Hinweis

Erwägen Sie für die Schritte 1 – 3 die Verwendung von Redgate Data Platform Studio. Data Platform Studio wendet optimal abgestimmte Kompatibilitätspatches und Optimierungen an und ermöglicht so den schnellsten Einstieg in die Verwendung von Azure Synapse. Weitere Informationen finden Sie unter Laden von Daten mit Redgate Data Platform Studio.

In den folgenden Abschnitten werden diese Phasen ausführlicher beschrieben.

Exportieren von Daten aus SQL Server

Das Hilfsprogramm BCP (Bulk Copy Program) ist eine schnelle Möglichkeit zum Erstellen von Textflatfiles aus SQL-Tabellen. In diesem Schritt wählen Sie die Spalten, die Sie exportieren möchten, jedoch nicht die zu transformierenden Daten. Alle Datentransformationen sollten in Azure Synapse erfolgen.

Empfehlungen:

Planen Sie die Datenextrahierung nach Möglichkeit außerhalb der Spitzenzeiten, um Ressourcenkonflikte in der Produktionsumgebung zu minimieren.

Führen Sie BCP nicht auf dem Datenbankserver aus. Führen Sie BCP stattdessen auf einem anderen Computer aus. Schreiben Sie die Dateien auf ein lokales Laufwerk. Stellen Sie sicher, dass genügend E/A-Ressourcen für gleichzeitige Schreibvorgänge bereitstehen. Um die Leistung zu optimieren, exportieren Sie die Dateien auf dedizierte schnelle Speicherlaufwerke.

Sie können die Netzwerkübertragung beschleunigen, indem Sie die exportierten Daten im komprimierten Gzip-Format speichern. Allerdings ist das Laden komprimierter Dateien in Warehouse langsamer als das Laden dekomprimierter Dateien, sodass ein Kompromiss zwischen schneller Netzwerkübertragung und schnellerem Laden getroffen werden muss. Wenn Sie die Gzip-Komprimierung verwenden möchten, erstellen Sie keine einzelne Gzip-Datei. Teilen Sie die Daten stattdessen auf mehrere komprimierte Dateien auf.

Kopieren von Flatfiles in Blobspeicher

Das Hilfsprogramm AzCopy ist für das Hochleistungskopieren von Daten in den Azure-Blobspeicher bestimmt.

Empfehlungen:

Erstellen Sie das Speicherkonto in einer Region, die sich in der Nähe des Quelldatenspeicherorts befindet. Stellen Sie das Speicherkonto und die Azure Synapse-Instanz in derselben Region bereit.

Führen Sie AzCopy und Ihre Produktionsworkloads nicht auf dem gleichen Computer aus, da CPU- und E/A-Verbrauch die Produktionsworkloads beeinträchtigen können.

Testen Sie den Upload zuerst, um die Uploadgeschwindigkeit zu ermitteln. Sie können in AzCopy mit der Option „/NC“ die Anzahl der gleichzeitigen Kopiervorgänge angeben. Beginnen Sie mit dem Standardwert, und experimentieren Sie mit dieser Einstellung, um die Leistung zu optimieren. In einer Umgebung mit geringer Bandbreite können zu viele gleichzeitige Vorgänge die Netzwerkverbindung überlasten, sodass die Vorgänge nicht erfolgreich abgeschlossen werden können.

AZCopy verschiebt Daten über das öffentliche Internet in den Speicher. Wenn dies nicht schnell genug ist, sollten Sie die Einrichtung einer ExpressRoute-Verbindung erwägen. ExpressRoute ist ein Dienst, der Ihre Daten über eine dedizierte private Verbindung zu Azure weiterleitet. Wenn Ihre Netzwerkverbindung zu langsam ist, können Sie die Daten auch physisch auf einem Datenträger an ein Azure-Rechenzentrum senden. Weitere Informationen finden Sie unter Übertragen von Daten in und aus Azure.

Während eines Kopiervorgangs erstellt AzCopy eine temporäre Journaldatei, mit der AzCopy den Vorgang bei einer Unterbrechung (z.B. aufgrund eines Netzwerkfehlers) neu starten kann. Stellen Sie sicher, dass auf dem Datenträger genügend Speicherplatz zum Speichern der Journaldateien vorhanden ist. Mit der Option „/Z“ können Sie angeben, wohin die Journaldateien geschrieben werden.

Laden von Daten in Azure Synapse

Laden Sie die Dateien mit PolyBase aus dem Blobspeicher in das Data Warehouse. PolyBase ist dafür ausgelegt, die MPP-Architektur (Massively Parallel Processing) von Azure Synapse zu nutzen, und ist somit die schnellste Möglichkeit, Daten in Azure Synapse zu laden.

Das Laden der Daten ist ein zweistufiger Prozess:

  1. Erstellen eines Satzes externer Tabellen für die Daten. Eine externe Tabelle ist eine Tabellendefinition, die auf außerhalb des Warehouse gespeicherte Daten zeigt — in diesem Fall die Flatfiles im Blobspeicher. Dieser Schritt verschiebt keine Daten in das Warehouse.
  2. Erstellen von Stagingtabellen und Laden der Daten in die Stagingtabellen. Dieser Schritt kopiert die Daten in das Warehouse.

Empfehlungen:

Sie sollten Azure Synapse verwenden, wenn Sie große Datenmengen (mehr als 1 TB) nutzen und eine Analyseworkload ausführen, die von Parallelität profitiert. Azure Synapse ist nicht ideal für OLTP-Workloads oder kleinere Datasets (kleiner als 250 GB) geeignet. Verwenden Sie für Datasets unter 250 GB Azure SQL-Datenbank oder SQL Server. Weitere Informationen finden Sie unter Data Warehousing und Data Marts.

Erstellen Sie die Stagingtabellen als Heaptabellen, die nicht indiziert werden. Die Abfragen, die die Produktionstabellen erstellen, resultieren in einem vollständigen Tabellenscan, sodass die Stagingtabellen nicht Indiziert werden müssen.

PolyBase nutzt automatisch die Vorteile der Parallelität im Warehouse. Die Ladeleistung wird skaliert, indem Sie die DWUs heraufsetzen. Die beste Leistung erzielen Sie mit einem einzelnen Ladevorgang. Die Aufteilung der Eingabedaten in Blöcke und das Ausführen mehrerer paralleler Ladevorgänge bringt keinen Leistungsvorteil.

PolyBase kann mit GZip komprimierte Dateien lesen. Allerdings wird nur ein einziger Leser pro komprimierter Datei verwendet, weil das Dekomprimieren der Datei ein Singlethread-Vorgang ist. Vermeiden Sie daher, eine einzelne große komprimierte Datei zu laden. Teilen Sie die Daten stattdessen in mehrere komprimierte Dateien auf, um den Vorteil der Parallelität zu nutzen.

Bedenken Sie dabei folgende Einschränkungen:

  • PolyBase unterstützt eine maximale Spaltengröße von varchar(8000), nvarchar(4000) oder varbinary(8000). Wenn Ihre Daten diese Grenzen überschreiten, können Sie die Daten in Blöcke unterteilen, wenn Sie sie exportieren, und die Blöcke nach dem Import wieder zusammensetzen.

  • PolyBase verwendet das feste Zeilenabschlusszeichen „\n“ oder einen Zeilenvorschub. Dies kann Probleme verursachen, wenn das Zeilenumbruchzeichen in den Quelldaten vorkommt.

  • Es kann sein, dass Ihr Quelldatenschema Datentypen enthält, die in Azure Synapse nicht unterstützt werden.

Um diese Einschränkungen zu umgehen, können Sie eine gespeicherte Prozedur erstellen, die die erforderlichen Konvertierungen ausführt. Verweisen Sie auf diese gespeicherte Prozedur, wenn Sie BCP ausführen. Alternativ führt Redgate Data Platform Studio für Datentypen, die in Azure Synapse nicht unterstützt werden, automatisch eine Konvertierung durch.

Weitere Informationen finden Sie in den folgenden Artikeln:

Transformieren der Daten

Transformieren Sie die Daten, und verschieben Sie sie in Produktionstabellen. In diesem Schritt werden die Daten in ein Sternschema mit Dimensions- und Faktentabellen umgewandelt, sodass sie für die semantische Modellierung geeignet sind.

Erstellen Sie die Produktionstabellen mit gruppierten Columnstore-Indizes, die beste Abfragegesamtleistung bieten. Columnstore-Indizes sind für Abfragen optimiert, die viele Datensätze überprüfen. Columnstore-Indizes sind nicht für Singleton-Suchvorgänge (d.h. Suchen in einer einzelnen Zeile) geeignet. Wenn Sie häufig Singleton-Suchvorgänge ausführen müssen, können Sie einen nicht gruppierten Index einer Tabelle hinzufügen. Singleton-Suchvorgänge können mit einem nicht gruppierten Index erheblich schneller ausgeführt werden. Jedoch sind Singleton-Suchvorgänge in der Regel in Data Warehouse-Szenarien weniger gebräuchlich als OLTP-Workloads. Weitere Informationen finden Sie unter Indizieren von Tabellen in Azure Synapse.

Hinweis

Gruppierte Columnstore-Tabellen unterstützen nicht die Datentypen varchar(max), nvarchar(max) oder varbinary(max). Ziehen Sie in diesem Fall einen Heap- oder gruppierten Index in Erwägung. Sie können diese Spalten in eine separate Tabelle einfügen.

Da die Beispieldatenbank nicht sehr groß ist, haben wir replizierte Tabellen ohne Partitionen erstellt. Bei Produktionsworkloads verbessert die Verwendung von verteilten Tabellen wahrscheinlich die Abfrageleistung. Weitere Informationen finden Sie im Leitfaden für das Entwerfen verteilter Tabellen in Azure Synapse. Unsere Beispielskripts führen die Abfragen mithilfe einer statischen Ressourcenklasse aus.

Laden des semantischen Modells

Laden Sie die Daten in ein tabellarisches Modell in Azure Analysis Services. In diesem Schritt erstellen Sie ein semantisches Datenmodell mithilfe von SQL Server Data Tools (SSDT). Sie können auch ein Modell erstellen, indem Sie es aus einer Power BI Desktop-Datei importieren. Da Azure Synapse keine Fremdschlüssel unterstützt, müssen Sie dem Semantikmodell die Beziehungen hinzufügen, damit Sie eine tabellenübergreifende Verknüpfung durchführen können.

Verwenden von Power BI zum Visualisieren von Daten

Power BI unterstützt zwei Optionen zum Herstellen einer Verbindung mit Azure Analysis Services:

  • Importieren. Die Daten werden in das Power BI-Modell importiert.
  • Liveverbindung. Daten werden direkt per Pull aus Analysis Services abgerufen.

Verwenden Sie die Liveverbindung, da sie kein Kopieren von Daten in das Power BI-Modell erfordert. Auch stellt die Verwendung von DirectQuery sicher, dass die Ergebnisse immer mit den neuesten Quelldaten konsistent sind. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit Power BI.

Empfehlungen:

Vermeiden Sie, BI-Dashboardabfragen direkt im Data Warehouse auszuführen. BI-Dashboards erfordern sehr kurze Antwortzeiten, die direkte Warehouse-Abfragen möglicherweise nicht leisten können. Darüber hinaus schränkt das Aktualisieren des Dashboards die Anzahl gleichzeitiger Abfragen ein, was sich auf die Leistung auswirken könnte.

Azure Analysis Services dient zum Behandeln der Abfrageanforderungen eines BI-Dashboards, daher ist die empfohlene Vorgehensweise die Abfrage von Analysis Services über Power BI.

Überlegungen zur Skalierbarkeit

Azure Synapse

Sie können mit Azure Synapse Computeressourcen bedarfsabhängig aufskalieren. Das Abfragemodul optimiert Abfragen für die parallele Verarbeitung basierend auf der Anzahl von Serverknoten und verschiebt Daten nach Bedarf zwischen Knoten. Weitere Informationen finden Sie unter Verwalten von Computeressourcen in Azure Synapse.

Analysis Services

Bei Produktionsworkloads sollten Sie den Standard-Tarif für Azure Analysis Services nutzen, da er Partitionierung und DirectQuery unterstützt. Innerhalb eines Tarifs bestimmt die Größe der Instanz Arbeitsspeicher und Verarbeitungsleistung. Die Verarbeitungsleistung wird in Query Processing Units (QPUs) gemessen. Beobachten Sie Ihre QPU-Nutzung, um die geeignete Größe auszuwählen. Weitere Informationen finden Sie unter Überwachen von Servermetriken.

Bei hoher Last kann die Abfrageleistung durch parallele Abfragen beeinträchtigt werden. Sie können Analysis Services aufskalieren, indem Sie einen Pool von Replikaten zum Verarbeiten von Abfragen erstellen, sodass mehrere Abfragen gleichzeitig ausgeführt werden können. Die Verarbeitung des Datenmodells erfolgt immer auf dem primären Server. Standardmäßig behandelt der primäre Server auch Abfragen. Optional können Sie den primären Server ausschließlich zum Ausführen der Verarbeitung festlegen, sodass der Abfragepool alle Abfragen verarbeitet. Wenn Sie hohe Anforderungen an die Verarbeitung stellen, sollten Sie die Verarbeitung vom Abfragepool trennen. Bei hohen Abfragelasten und relativ unaufwändiger Verarbeitung können Sie den primären Server in den Abfragepool einschließen. Weitere Informationen finden Sie unter Horizontales Hochskalieren von Azure Analysis Services.

Um unnötigen Verarbeitungsaufwand zu verringern, sollten Sie das tabellarische Modell mit Partitionen in logische Bereiche unterteilen. Jede Partition kann separat verarbeitet werden. Weitere Informationen finden Sie unter Partitionen.

Sicherheitshinweise

Liste zugelassener IP-Adressen der Analysis Services-Clients

Ziehen Sie die Verwendung der Firewallfunktion von Analysis Services in Betracht, um Listen von Client-IP-Adressen zuzulassen. Bei Aktivierung blockiert die Firewall alle Clientverbindungen, die nicht in den Firewallregeln angegeben sind. Die Standardregeln erlauben das Auflisten des Power BI-Diensts, aber Sie können diese Regel falls gewünscht deaktivieren. Weitere Informationen finden Sie unter Härtung von Azure Analysis Services mit der neuen Firewallfunktion.

Authorization

Azure Analysis Services authentifiziert mit Azure Active Directory (Azure AD) Benutzer, die eine Verbindung mit dem Analysis Services-Server herstellen. Sie können einschränken, welche Daten ein bestimmter Benutzer anzeigen kann, indem Sie Rollen erstellen und dann Azure AD-Benutzer oder Gruppen diesen Rollen zuweisen. Für jede Rolle können Sie:

  • Tabellen oder einzelne Spalten schützen.
  • Einzelne Zeilen basierend auf Filterausdrücken schützen.

Weitere Informationen finden Sie unter Verwalten von Datenbankrollen und Benutzern.

Überlegungen zu DevOps

  • Erstellen Sie separate Ressourcengruppen für Produktions-, Entwicklungs- und Testumgebungen. Separate Ressourcengruppen erleichtern das Verwalten von Bereitstellungen, das Löschen von Testbereitstellungen und das Zuweisen von Zugriffsrechten.

  • Verwenden Sie die in dieser Architektur bereitgestellten Vorlage für Azure-Bausteine, oder erstellen Sie die Azure Resource Manager-Vorlage, um die Azure-Ressourcen gemäß dem IaC-Prozess (Infrastructure-as-Code) bereitzustellen. Vorlagen erleichtern das Automatisieren von Bereitstellungen mit Azure DevOps Services und anderen CI/CD-Lösungen.

  • Platzieren Sie jede Workload in einer separaten Bereitstellungsvorlage, und speichern Sie die Ressourcen in Quellcodeverwaltungssystemen. Sie können die Vorlagen zusammen oder einzeln im Rahmen eines CI/CD-Prozesses bereitstellen. Dies erleichtert den Automatisierungsprozess.

    In dieser Architektur sind drei grundlegende Workloads vorhanden:

    • der Data Warehouse Server, Analysis Services und zugehörige Ressourcen.
    • Azure Data Factory
    • Ein Szenario mit Lokal-zu-Cloud-Simulation.

    Jede Workload verfügt über eine eigene Bereitstellungsvorlage.

    Der Data Warehouse-Server wird mit Befehlen der Azure-Befehlszeilenschnittstelle eingerichtet und konfiguriert, wobei der imperative Ansatz der IaC-Praktiken verfolgt wird. Erwägen Sie, Bereitstellungsskripts zu verwenden und diese in den Automatisierungsprozess zu integrieren.

  • Erwägen Sie ein Staging Ihrer Workloads. Nehmen Sie die Bereitstellung in verschiedenen Stages vor, und führen Sie auf jeder Stage Überprüfungen durch, bevor Sie zur nächsten Stage wechseln. Auf diese Weise können Sie mit umfassender Kontrolle Aktualisierungen in Ihre Produktionsumgebungen pushen, und Sie minimieren unerwartete Bereitstellungsprobleme. Verwenden Sie die Strategien der Blaugrün-Bereitstellung und Canary-Releases, um Liveproduktionsumgebungen zu aktualisieren.

    Sorgen Sie für eine gute Rollbackstrategie für die Behandlung fehlerhafter Bereitstellungen. Sie können beispielsweise automatisch eine frühere, erfolgreiche Bereitstellung aus Ihrem Bereitstellungsverlauf bereitstellen. Siehe --rollback-on-error-Flag-Parameter in der Azure-Befehlszeilenschnittstelle.

  • Azure Monitor ist die empfohlene Option zum Analysieren der Leistung Ihres Data Warehouse und der gesamten Azure Analytics-Plattform; hiermit verfügen Sie über eine integrierte Überwachungsumgebung. Azure Synapse Analytics bietet Überwachungsfunktionen im Azure-Portal, mit denen Sie Erkenntnisse zu Ihrer Data Warehouse-Workload gewinnen können. Das Azure-Portal ist das empfohlene Tool zum Überwachen Ihrer Data Warehouse-Instanz, weil es eine konfigurierbare Aufbewahrungsdauer, Warnungen, Empfehlungen und anpassbare Diagramme und Dashboards für Metriken und Protokolle bietet.

Weitere Informationen finden Sie im Microsoft Azure Well-Architected Framework unter Übersicht über die DevOps-Säule.

Azure Synapse

  • Wählen Sie Optimiert für Compute Gen1 für häufige Skalierungsvorgänge aus. Diese Option wird basierend auf dem Verbrauch von Data Warehouse-Einheiten (Data Warehouse Units, DWU) nutzungsbasiert berechnet.

  • Wählen Sie Optimiert für Compute Gen2 für intensive Workloads mit höherer Abfrageleistung und Computeskalierbarkeitsanforderungen aus. Sie können das Modell mit nutzungsbasierter Bezahlung wählen oder reservierte Pläne mit einer Laufzeit von einem Jahr (37 Prozent Ersparnis) oder drei Jahren (65 Prozent Ersparnis) nutzen.

Datenspeicher wird separat abgerechnet. Andere Dienste wie die Notfallwiederherstellung und die Bedrohungserkennung werden ebenfalls separat abgerechnet.

Weitere Informationen finden Sie unter Preise für Azure Synapse.

Azure Analysis Services

Die Preise für Azure Analysis Services sind abhängig von der Dienstebene. In der Referenzimplementierung dieser Architektur wird die Dienstebene Entwickler verwendet, die für Auswertungs-, Entwicklungs- und Testszenarien empfohlen wird. Zu den anderen Dienstebenen gehören die Dienstebene Basic, die für kleine Produktionsumgebungen empfohlen wird, und die Dienstebene Standard für unternehmenskritische Produktionsanwendungen. Weitere Informationen finden Sie unter Immer der richtige Tarif.

Wenn Sie Ihre Instanz anhalten, fallen keine Gebühren an.

Weitere Informationen finden Sie unter Azure Analysis Services – Preise.

Blob Storage

Verwenden Sie ggf. die Funktion für reservierte Kapazität von Azure Storage, um die Speicherkosten zu senken. Mit diesem Modell erhalten Sie einen Rabatt, wenn Sie für ein oder drei Jahre eine Reservierung für eine feste Speicherkapazität vornehmen. Weitere Informationen finden Sie unter Optimieren der Kosten für Blobspeicher mit reservierter Kapazität.

Power BI Embedded

Power BI Embedded ist eine PaaS-Lösung (Platform-as-a-Service), die eine Reihe von APIs für die Integration von Power BI-Inhalten in benutzerdefinierte Apps und Websites bietet. Benutzer, die BI-Inhalte veröffentlichen, benötigen eine Lizenz für Power BI Pro. Informationen zu Preisen finden Sie unter Power BI Embedded – Preise.

Weitere Informationen finden Sie im Microsoft Azure Well-Architected Framework unter Grundsätze der Kostenoptimierung.

Bereitstellen der Lösung

Führen Sie zum Bereitstellen und Ausführen der Referenzimplementierung die Schritte aus der GitHub-Infodatei aus. Die folgenden Ressourcen werden bereitgestellt:

  • Eine Windows-VM, um einen lokalen Datenbankserver zu simulieren. Sie enthält SQL Server 2017 und zugehörige Tools zusammen mit Power BI Desktop.
  • Ein Azure Storage-Konto, das Blobspeicher zum Speichern von Daten bereitstellt, die aus SQL Server-Datenbank exportiert wurden.
  • Eine Azure Synapse-Instanz.
  • Eine Azure Analysis Services-Instanz.

Nächste Schritte

Es wird empfohlen, sich das folgende Azure-Beispielszenario anzusehen. Darin wird veranschaulicht, wie einige dieser Technologien in spezifischen Lösungen verwendet werden: