In diesem Artikel wird beschrieben, wie Sie Daten aus einem lokalen Data Warehouse in eine Cloudumgebung übertragen und dann ein Business Intelligence (BI)-Modell verwenden, um die Daten zu verarbeiten. Sie können diesen Ansatz als Endziel oder einen ersten Schritt zur vollständigen Modernisierung mit cloudbasierten Komponenten verwenden.
Diese Anleitung basiert auf dem End-to-End-Szenario von Azure Synapse Analytics. Dieser Prozess verwendet Azure Synapse Analytics-Pipelines zum Aufnehmen von Daten aus einer SQL-Datenbank in SQL-Pools. Anschließend führt sie die Datentransformation für die Analyse aus. Dieser Artikel konzentriert sich auf Azure Synapse Analytics-Pipelines, Sie können aber auch Azure Data Factory-Pipelines oder Fabric Data Factory-Pipelines verwenden, um diese Aufgaben auszuführen.
Wann diese Architektur verwendet werden soll
Sie können verschiedene Methoden verwenden, um geschäftliche Anforderungen für Enterprise BI zu erfüllen. Verschiedene Aspekte definieren geschäftsspezifische Anforderungen, z. B. aktuelle Technologieinvestitionen, menschliche Fähigkeiten, die Zeitachse für modernisierung, zukünftige Ziele und ob Sie die Plattform als Service (PaaS) oder Software as a Service (SaaS) bevorzugen.
Berücksichtigen Sie die folgenden Entwurfsansätze:
Fabric und Azure Databricks für Kunden mit bestehenden Investitionen in Azure Databricks und Power BI und möchten mit Fabric modernisieren
Enterprise BI für kleine und mittlere Unternehmen, die ein Azure SQL-Ökosystem und Fabric-
Data Warehouse vollständig auf Fabric für Kunden, die SaaS bevorzugen
Bei der Architektur in diesem Artikel wird davon ausgegangen, dass Sie Azure Synapse Analytics Data Warehouse als persistente Ebene des Unternehmenssemantikmodells verwenden und Power BI für Business Intelligence verwenden. Dieser PaaS-Ansatz bietet die Flexibilität, verschiedene Geschäftliche Anforderungen und Vorlieben zu erfüllen.
Architektur
Laden Sie eine Visio-Datei dieser Architektur herunter.
Workflow
Datenquelle
- Eine SQL Server-Datenbank in Azure enthält die Quelldaten. Um die lokale Umgebung zu simulieren, konfigurieren Bereitstellungsskripts für dieses Szenario eine Azure SQL-Datenbank. Als Quelldatenschema und Beispieldaten wird die AdventureWorks-Beispieldatenbank verwendet. Weitere Informationen finden Sie unter Kopieren und Transformieren von Daten in und aus SQL Server-.
Erfassung und Datenspeicherung
Azure Data Lake Storage ist ein temporärer Stagingbereich während der Datenaufnahme. Sie können PolyBase verwenden, um Daten in einen dedizierten SQL-Pool von Azure Synapse Analyticszu kopieren.
Azure Synapse Analytics ist ein verteiltes System, das Analysen für große Daten durchführt. Es unterstützt eine massive parallele Verarbeitung, sodass sie Hochleistungsanalysen ausführen kann. Der dedizierte SQL-Pool von Azure Synapse Analytics ist ein Ziel für die kontinuierliche Aufnahme aus der lokalen Umgebung. Der SQL-Pool kann Daten Power BI über DirectQuery bereitstellen und eine weitere Verarbeitung durchführen.
Azure Synapse Analytics-Pipelines Koordinieren der Datenaufnahme und -transformation im Azure Synapse Analytics-Arbeitsbereich.
Analysen und Berichte
- Der Datenmodellierungsansatz in diesem Szenario kombiniert das Enterprise Model und das BI-Semantikmodell. Die dedizierten SQL-Pool azure Synapse Analytics enthält das Enterprise-Modell. Power BI Premium-Kapazität F64- enthält das BI-Semantikmodell. Power BI greift über DirectQuery auf die Daten zu.
Komponenten
Für dieses Szenario werden die folgenden Komponenten verwendet:
Azure SQL-Datenbank ist ein von Azure gehosteter PaaS SQL-Server. Diese Architektur verwendet SQL-Datenbank, um den Datenfluss für das Migrationsszenario zu veranschaulichen.
Data Lake Storage bietet flexiblen Cloudspeicher für unstrukturierte Daten, die für die dauerhaften Zwischenmigrationsergebnisse verwendet werden.
Azure Synapse Analytics ist ein Unternehmensanalysedienst für Data Warehouse- und Big Data-Systeme. Azure Synapse Analytics dient als haupt compute- und persistenter Speicher in der semantischen Modellierung und Wartung von Unternehmen.
Power BI Premium ist ein BI-Tool, das Daten in diesem Szenario darstellt und visualisiert.
Microsoft Entra ID ist eine Multicloud-Identitäts- und Netzwerklösungssuite, die den Authentifizierungs- und Autorisierungsfluss unterstützt.
Vereinfachte Architektur
Szenariodetails
In diesem Szenario verfügt eine Organisation über eine SQL-Datenbank, die ein großes lokales Data Warehouse enthält. Die Organisation möchte Azure Synapse Analytics verwenden, um Analysen durchzuführen und diese Erkenntnisse dann über Power BI an Benutzer und Analysen zu übermitteln.
Authentifizierung
Die Microsoft Entra-ID authentifiziert Benutzer, die eine Verbindung mit Power BI-Dashboards und -Apps herstellen. Einmaliges Anmelden verbindet Benutzer mit der Datenquelle in einem bereitgestellten Azure Synapse Analytics-Pool. Die Autorisierung erfolgt auf der Quelle.
Inkrementelles Laden
Wenn Sie einen automatisierten Extraktions-, Transformations-, Lade-, Lade-, Transformations- (ELT)-Prozess ausführen, sollten Sie nur die Daten laden, die sich seit der vorherigen Ausführung geändert haben. Dieser Prozess wird als inkrementelle Lastbezeichnet. Umgekehrt lädt eine vollständige Last alle Daten. Um eine inkrementelle Last durchzuführen, bestimmen Sie, wie die geänderten Daten identifiziert werden. Sie können ein High Water Mark Wertansatz verwenden, der den neuesten Wert einer Datum-Uhrzeit-Spalte oder einer eindeutigen ganzzahligen Spalte in der Quelltabelle nachverfolgt.
Sie können zeitlichen Tabellen in SQL Server verwenden. Zeitliche Tabellen sind systemversionsierte Tabellen, in denen der Datenänderungsverlauf gespeichert wird. Die Datenbank-Engine zeichnet den Verlauf aller Änderungen automatisch in einer separaten Verlaufstabelle auf. Um die Verlaufsdaten abzufragen, können Sie einer Abfrage eine FOR SYSTEM_TIME
Klausel hinzufügen. Intern fragt die Datenbank-Engine die Verlaufstabelle ab, aber diese Abfrage erfolgt transparent für die Anwendung.
Zeitliche Tabellen unterstützen Bemaßungsdaten, die sich im Laufe der Zeit ändern können. Faktentabellen stellen in der Regel eine unveränderliche Transaktion wie einen Verkauf dar, und in diesem Fall ist das Beibehalten des Systemversionsverlaufs nicht sinnvoll. Stattdessen verfügen Transaktionen in der Regel über eine Spalte, die das Transaktionsdatum darstellt. Die Spalte kann als Wasserzeichenwert verwendet werden. Beispielsweise weisen die SalesLT.*
Tabellen im AdventureWorks-Data Warehouse ein LastModified
Feld auf.
Dies ist der allgemeine Ablauf für die ELT-Pipeline:
Verfolgen Sie für jede Tabelle in der Quelldatenbank den Trennzeitpunkt der Ausführung des letzten ELT-Auftrags nach. Speichern Sie diese Informationen im Data Warehouse. Bei der Ersteinrichtung sind alle Zeiten auf
1-1-1900
festgelegt.Während des Datenexportschritts wird der Trennzeitpunkt als Parameter an einen Satz von gespeicherten Prozeduren in der Quelldatenbank übergeben. Diese gespeicherten Prozeduren abfragen alle Datensätze, die nach der Ablaufzeit geändert oder erstellt werden. Für alle Tabellen im Beispiel können Sie die Spalte
ModifiedDate
verwenden.Wenn die Datenmigration abgeschlossen ist, aktualisieren Sie die Tabelle, in der die Trennzeitpunkte gespeichert werden.
Datenpipeline
In diesem Szenario wird die AdventureWorks-Beispieldatenbank als Datenquelle verwendet. Das inkrementelle Datenlademuster stellt sicher, dass nur Daten, die nach dem Laden der letzten Pipelineausführung geändert oder hinzugefügt werden.
Tool zum metadatengesteuerten Kopieren
Das integrierte metadatengesteuerte Kopiertool in Azure Synapse Analytics-Pipelines lädt inkrementell alle Tabellen, die in der relationalen Datenbank enthalten sind.
Verwenden Sie eine Assistentenschnittstelle, um das Tool "Daten kopieren" mit der Quelldatenbank zu verbinden.
Konfigurieren Sie nach der Verbindung das inkrementelle Laden oder das vollständige Laden für jede Tabelle.
Das Tool "Daten kopieren" erstellt die Pipelines und SQL-Skripts, die zum Generieren der Steuerelementtabelle erforderlich sind. Diese Tabelle speichert Daten, z. B. den Hohen Wasserzeichenwert oder die Spalte für jede Tabelle, für den inkrementellen Ladevorgang.
Nachdem diese Skripts ausgeführt wurden, lädt die Pipeline alle Quelldatenlagertabellen in den dedizierten Azure Synapse Analytics-Pool.
Bevor das Tool die Daten lädt, erstellt es drei Pipelines, um die Tabellen in der Datenbank zu durchlaufen.
Die Pipelines führen die folgenden Aufgaben aus:
Zählen der Anzahl von Objekten (z. B. Tabellen), die bei der Pipelineausführung kopiert werden sollen
Durchlaufen Sie jedes objekt, das geladen oder kopiert werden soll.
Nachdem eine Pipeline jedes Objekts durchläuft, werden die folgenden Aufgaben ausgeführt:
Überprüft, ob eine Deltalast erforderlich ist. Andernfalls schließt die Pipeline eine normale volle Last ab.
Ruft den Wert für hohe Wasserzeichen aus der Steuerelementtabelle ab.
Kopiert Daten aus den Quelltabellen in das Stagingkonto in Data Lake Storage.
Lädt Daten über die ausgewählte Kopiermethode in den dedizierten SQL-Pool, z. B. den Befehl "PolyBase" oder "Kopieren".
Aktualisiert den Wert für hohe Wasserzeichen in der Steuerelementtabelle.
Laden von Daten in einen SQL-Pool von Azure Synapse Analytics
Die Kopieraktivität kopiert Daten aus der SQL-Datenbank in den SQL-Pool von Azure Synapse Analytics. Die SQL-Datenbank dieses Beispiels befindet sich in Azure, sodass die Azure-Integrationslaufzeit verwendet wird, um Daten aus der SQL-Datenbank zu lesen und die Daten in die angegebene Stagingumgebung zu schreiben.
Die Copy-Anweisung lädt dann Daten aus der Stagingumgebung in den dedizierten Azure Synapse Analytics-Pool.
Verwenden von Azure Synapse Analytics-Pipelines
Pipelines in Azure Synapse Analytics definieren einen sortierten Satz von Aktivitäten, um ein inkrementelles Lademuster abzuschließen. Manuelle oder automatische Trigger starten die Pipeline.
Transformieren der Daten
Die Beispieldatenbank in dieser Referenzarchitektur ist klein, sodass replizierte Tabellen ohne Partitionen erstellt werden. Für Produktionsworkloads können verteilte Tabellen die Abfrageleistung verbessern. Weitere Informationen finden Sie unter Anleitung zum Entwerfen verteilter Tabellen in Azure Synapse Analytics. Die Beispielskripts führen die Abfragen über eine statische Ressourcenklasseaus.
Erwägen Sie in einer Produktionsumgebung das Erstellen von Stagingtabellen mit Roundrobinverteilung. Transformieren und verschieben Sie dann die Daten in Produktionstabellen mit gruppierten Spaltenspeicherindizes, die die beste Gesamtleistung der Abfrage bieten. Columnstore-Indizes sind für Abfragen optimiert, die viele Datensätze überprüfen.
Columnstore-Indizes werden nicht optimal für Singleton-Nachschlagevorgänge oder nach einer einzelnen Zeile ausgeführt. Wenn Sie häufige Singleton-Nachschlagevorgänge durchführen müssen, können Sie einer Tabelle einen nicht gruppierten Index hinzufügen, wodurch die Geschwindigkeit erhöht wird. Singleton-Nachschlagevorgänge sind in Data Warehouse-Szenarien jedoch in der Regel weniger häufig als Arbeitslasten für die Onlinetransaktionsverarbeitung. Weitere Informationen finden Sie unter Indextabellen in Azure Synapse Analytics.
Hinweis
Gruppierte Columnstore-Tabellen bieten keine Unterstützung für die Datentypen varchar(max)
, nvarchar(max)
oder varbinary(max)
. Wenn Sie diese Datentypen verwenden, sollten Sie einen Heap oder einen gruppierten Index in Betracht ziehen. Sie können diese Spalten auch in eine separate Tabelle einfügen.
Verwenden von Power BI Premium für Zugriff, Modellierung und Visualisierung von Daten
Power BI Premium unterstützt mehrere Optionen zum Herstellen einer Verbindung mit Datenquellen in Azure. Sie können bereitgestellte Azure Synapse Analytics-Pools verwenden, um die folgenden Aufgaben auszuführen:
- Import: Die Daten werden in das Power BI-Modell importiert.
- DirectQuery: Daten werden direkt aus dem relationalen Speicher abgerufen.
- Zusammengesetztes Modell: Kombinieren Sie den Import für einige Tabellen mit dem DirectQuery-Ansatz für andere Tabellen.
In diesem Szenario wird das DirectQuery-Dashboard verwendet, da es eine kleine Menge an Daten und eine geringe Modellkomplexität aufweist. DirectQuery delegiert die Abfrage an das leistungsstarke Computemodul darunter und verwendet umfangreiche Sicherheitsfunktionen für die Quelle. DirectQuery stellt sicher, dass die Ergebnisse immer mit den neuesten Quelldaten konsistent sind.
Der Importmodus bietet die schnellste Abfrageantwortzeit. Erwägen Sie den Importmodus, wenn:
- Das Modell passt vollständig in den Speicher von Power BI.
- Die Datenlatenz zwischen Aktualisierungen ist akzeptabel.
- Sie benötigen komplexe Transformationen zwischen dem Quellsystem und dem endgültigen Modell.
In diesem Fall möchten die Endbenutzer vollzugriff auf die neuesten Daten ohne Verzögerungen bei der Power BI-Aktualisierung und möchten alle historischen Daten, die die Power BI-Datasetkapazität überschreiten. Ein Power BI-Dataset kann je nach Kapazitätsgröße 25-400 GB verarbeiten. Das Datenmodell im dedizierten SQL-Pool befindet sich bereits in einem Sternschema und erfordert keine Transformation, sodass DirectQuery eine geeignete Wahl ist.
Verwenden Sie Power BI Premium-, um große Modelle, paginierte Berichte und Bereitstellungspipelinen zu verwalten. Nutzen Sie den integrierten Azure Analysis Services-Endpunkt. Sie können auch dedizierte Kapazitäten verwenden, die ein besonderes Wertversprechen bieten.
Wenn das BI-Modell die Komplexität erhöht oder die Dashboardkomplexität zunimmt, können Sie zu zusammengesetzten Modellen wechseln und Teile von Nachschlagetabellen über Hybridtabellenimportieren und vorab aggregierte Daten importieren. Sie können Abfragezwischenspeicherung in Power BI für importierte Datasets aktivieren und dualen Tabellen für die Speichermoduseigenschaft verwenden.
Innerhalb des zusammengesetzten Modells dienen Datasets als virtuelle Pass-Through-Ebene. Wenn Benutzer mit Visualisierungen interagieren, generiert Power BI SQL-Abfragen in Azure Synapse Analytics SQL-Pools. Power BI bestimmt, ob speicherinterner oder DirectQuery-Speicher basierend auf Effizienz verwendet werden soll. Das Modul entscheidet, wann sie von In-Memory zu DirectQuery wechseln und die Logik an den AZURE Synapse Analytics SQL-Pool überträgt. Abhängig vom Kontext der Abfragetabellen können sie entweder als zwischengespeicherte (importierte) oder nicht zwischengespeicherte zusammengesetzte Modelle fungieren. Sie können auswählen, welche Tabelle im Arbeitsspeicher zwischengespeichert werden soll, Daten aus einer oder mehreren DirectQuery-Quellen kombinieren oder DirectQuery-Quelldaten und importierte Daten kombinieren.
Wenn Sie DirectQuery mit einem bereitgestellten Azure Synapse Analytics-Pool verwenden:
Verwenden Sie Azure Synapse Analytics zwischenspeichern, um Abfrageergebnisse in der Benutzerdatenbank zur wiederholten Verwendung zwischenzuspeichern. Dieser Ansatz verbessert die Abfrageleistung in Millisekunden und reduziert die Berechnung der Ressourcennutzung. Abfragen, die zwischengespeicherte Resultsets verwenden, verbrauchen keine Parallelitätsmodule in Azure Synapse Analytics, sodass sie nicht auf vorhandene Parallelitätsgrenzwerte zählen.
Verwenden Sie Azure Synapse Analytics materialisierte Ansichten, um Daten wie eine Tabelle vorzukompilieren, zu speichern und zu verwalten. Abfragen, die alle Daten oder eine Teilmenge der Daten in materialisierten Ansichten verwenden, können eine schnellere Leistung erzielen, ohne dass sie direkt auf die definierte materialisierte Ansicht verweisen müssen, um sie zu verwenden.
Überlegungen
Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Well-Architected Framework.
Sicherheit
Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für sicherheitsrelevante.
Bei der Cloud-Modernisierung werden Sicherheitsbedenken wie Datenschutzverletzungen, Schadsoftwareinfektionen und Schadcodeeinfügungen eingeführt. Sie benötigen einen Cloudanbieter oder eine Servicelösung, die Ihre Bedenken beheben kann, da unzureichende Sicherheitsmaßnahmen zu großen Problemen führen können.
In diesem Szenario werden die anspruchsvollsten Sicherheitsbedenken mithilfe einer Kombination von mehrstufigen Sicherheitskontrollen behandelt: Netzwerk-, Identitäts-, Datenschutz- und Autorisierungskontrollen. Ein bereitgestellter Azure Synapse Analytics-Pool speichert die meisten Daten. Power BI greift über DirectQuery über einmaliges Anmelden auf die Daten zu. Sie können Microsoft Entra ID für die Authentifizierung verwenden. Es gibt auch umfangreiche Sicherheitskontrollen für die Datenautorisierung innerhalb der bereitgestellten Pools.
Einige der häufig gestellten Sicherheitsfragen sind:
Definieren Sie, wer welche Daten sehen kann.
- Stellen Sie sicher, dass Ihre Daten den Richtlinien für Bundes-, Lokale und Unternehmensrichtlinien entsprechen, um Risiken für Datenschutzverletzungen zu mindern. Azure Synapse Analytics bietet mehrere Datenschutzfunktionen, um Compliance zu erreichen.
Bestimmen Sie, wie die Identität eines Benutzers überprüft werden soll.
- Verwenden Sie Azure Synapse Analytics, um zu steuern, wer über Zugriffssteuerung und Authentifizierungauf welche Daten zugreifen kann.
Wählen Sie eine Netzwerksicherheitstechnologie aus, um die Integrität, Vertraulichkeit und den Zugriff auf Ihre Netzwerke und Daten zu schützen.
- Schützen Sie Azure Synapse Analytics mithilfe Optionen für die Netzwerksicherheit.
Wählen Sie Tools aus, mit denen Sie Bedrohungen erkennen und benachrichtigen können.
- Verwenden Sie Azure Synapse Analytics Funktionen zur Bedrohungserkennung, z. B. SQL-Überwachung, SQL-Bedrohungserkennung und Sicherheitsrisikobewertung, um Datenbanken zu überwachen, zu schützen und zu überwachen.
Bestimmen Sie, wie Daten in Ihrem Speicherkonto geschützt werden.
- Verwenden Sie Azure Storage-Konten für Workloads, die schnelle und konsistente Reaktionszeiten erfordern oder eine hohe Anzahl von Eingabe-/Ausgabevorgängen (IOPs) pro Sekunde aufweisen. Speicherkonten können alle Datenobjekte speichern und mehrere Sicherheitsoptionen für Speicherkontenhaben.
Kostenoptimierung
Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Kostenoptimierung.
Dieser Abschnitt enthält Informationen zum Preis für verschiedene Dienste, die an dieser Lösung beteiligt sind, und erwähnt Entscheidungen, die für dieses Szenario mit einem Beispieldatensatz getroffen wurden. Verwenden Sie diese Startkonfiguration im Azure-Preisrechner, und passen Sie sie an Ihr Szenario an.
Azure Synapse Analytics
Azure Synapse Analytics ist eine serverlose Architektur, mit der Sie Ihre Compute- und Speicherebenen unabhängig voneinander skalieren können. Die Berechnung von Ressourcen verursacht Kosten basierend auf der Nutzung. Sie können diese Ressourcen nach Bedarf skalieren oder anhalten. Speicherressourcen verursachen Kosten pro Terabyte, sodass ihre Kosten beim Aufnehmen von Daten steigen.
Azure Synapse Analytics-Pipelines
Drei Hauptkomponenten beeinflussen den Preis einer Pipeline:
- Datenpipelineaktivitäten und Integration Runtime-Laufzeit (in Stunden)
- Größe und Implementierung von Datenflüssen
- Betriebskosten
Details zu den Preisen finden Sie auf der Registerkarte Datenintegration auf Azure Synapse Analytics-Preis.
Der Preis variiert je nach Komponenten oder Aktivitäten, Häufigkeit und Anzahl der Integrationslaufzeiteinheiten.
Für das Beispiel-Dataset, das die standardmäßige von Azure gehostete Integrationslaufzeit verwendet, dient Kopieren von Datenaktivitäten als Kern der Pipeline. Sie wird täglich für alle Entitäten (Tabellen) in der Quelldatenbank ausgeführt. Das Szenario enthält keine Datenflüsse. Und es entstehen keine Betriebskosten, da die Pipelines weniger als eine Million Vorgänge pro Monat ausführen.
Dedizierter Azure Synapse Analytics-Pool und -Speicher
Für das Beispiel-Dataset können Sie 500 Data Warehouse-Einheiten (DWUs) bereitstellen, um eine reibungslose Erfahrung für analytische Lasten zu bieten. Sie können die Berechnung während der Geschäftszeiten für Berichtszwecke verwalten. Wenn die Lösung in die Produktion wechselt, verwenden Sie reservierte Data Warehouse-Kapazität als kosteneffiziente Strategie. Verwenden Sie verschiedene Techniken, um Kosten- und Leistungsmetriken zu maximieren.
Preisdetails für einen dedizierten Azure Synapse Analytics-Pool finden Sie auf der Registerkarte Data Warehouse auf Azure Synapse Analytics-Preis. Im Rahmen des dedizierten Verbrauchsmodells entstehen Kunden kosten für jede bereitgestellte DWU pro Stunde Betriebszeit. Berücksichtigen Sie auch die Kosten für die Datenspeicherung, einschließlich der Größe Ihrer ruhenden Daten, Momentaufnahmen und Georedundanz.
Blob Storage
Erwägen Sie die Verwendung der reservierten Azure Storage-Kapazität, um die Speicherkosten zu reduzieren. Bei diesem Modell erhalten Sie einen Rabatt, wenn Sie eine feste Speicherkapazität für ein oder drei Jahre reservieren. Weitere Informationen finden Sie unter Optimieren der Kosten für Blob Storage mit reservierter Kapazität. In diesem Szenario wird kein beständiger Speicher verwendet.
Power BI Premium
In diesem Szenario werden Power BI Premium-Arbeitsbereiche mit integrierten Leistungsverbesserungen verwendet, um anspruchsvolle analytische Anforderungen zu erfüllen.
Weitere Informationen finden Sie unter Power BI-Preis.
Operative Exzellenz
Operational Excellence deckt die Betriebsprozesse ab, mit denen eine Anwendung bereitgestellt und in der Produktion ausgeführt wird. Weitere Informationen finden Sie unter Prüfliste für die Überprüfung von Operational Excellence.
Verwenden Sie eine Azure DevOps-Releasepipeline und GitHub-Aktionen, um die Bereitstellung eines Azure Synapse Analytics-Arbeitsbereichs in mehreren Umgebungen zu automatisieren. Weitere Informationen finden Sie unter kontinuierliche Integration und kontinuierliche Bereitstellung für einen Azure Synapse Analytics-Arbeitsbereich.
Platzieren Sie jede Workload in einer separaten Bereitstellungsvorlage, und speichern Sie die Ressourcen in Quellcodeverwaltungssystemen. Sie können die Vorlagen zusammen oder einzeln als Teil eines kontinuierlichen Integrations- und Kontinuierlichen Übermittlungsprozesses (CI/CD) bereitstellen. Dieser Ansatz vereinfacht den Automatisierungsprozess. Diese Architektur verfügt über vier Hauptarbeitslasten:
- Der Data Warehouse-Server und die zugehörigen Ressourcen
- Azure Synapse Analytics-Pipelines
- Power BI-Ressourcen, einschließlich Dashboards, Apps und Datasets
- Ein simuliertes Lokal-zu-Cloud-Szenario
Ziehen Sie ein Staging Ihrer Workloads in Betracht, wo dies sinnvoll ist. Stellen Sie Ihre Workload in verschiedenen Phasen bereit. Führen Sie Überprüfungen in jeder Phase aus, bevor Sie zur nächsten Phase wechseln. Bei diesem Ansatz werden Updates auf kontrollierte Weise an Ihre Produktionsumgebungen übertragen und unerwartete Bereitstellungsprobleme minimiert. Verwenden Sie blaugrüne Bereitstellung und Canary-Release Strategien zum Aktualisieren von Liveproduktionsumgebungen.
Verwenden Sie eine Rollbackstrategie, um fehlerhafte Bereitstellungen zu behandeln. Sie können beispielsweise automatisch eine frühere, erfolgreiche Bereitstellung aus Ihrem Bereitstellungsverlauf bereitstellen. Verwenden Sie das
--rollback-on-error
-Flag in der Azure CLI.Verwenden Sie Azure Monitor, um die Leistung Ihres Data Warehouse und die gesamte Azure-Analyseplattform für eine integrierte Überwachungserfahrung zu analysieren. Azure Synapse Analytics bietet eine Überwachungsfunktion im Azure-Portal, die Erkenntnisse zu Ihrer Data Warehouse-Workload liefert. Verwenden Sie das Azure-Portal, um Ihr Data Warehouse zu überwachen. Sie bietet konfigurierbare Aufbewahrungszeiträume, Warnungen, Empfehlungen und anpassbare Diagramme und Dashboards für Metriken und Protokolle.
Weitere Informationen finden Sie in den folgenden Ressourcen:
- Lernprogramm: Erste Schritte mit Azure Synapse Analytics
- Erstellen eines Azure Synapse Analytics-Arbeitsbereichs mithilfe der Azure CLI-
Leistungseffizienz
Die Leistungseffizienz bezieht sich auf die Fähigkeit Ihrer Workload, die Anforderungen der Benutzer effizient zu erfüllen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Leistungseffizienz.
Dieser Abschnitt enthält Details zur Größenanpassung für dieses Dataset.
Bereitgestellter Azure Synapse Analytics-Pool
Sie können verschiedene Data Warehouse-Konfigurationenverwenden.
DWUs | Anzahl der Computeknoten | Anzahl der Verteilungen pro Knoten |
---|---|---|
DW100c | 1 | 60 |
-- TO -- |
||
DW30000c | 60 | 1 |
Verwenden Sie mindestens ein 1-TB-Dataset, um die Leistungsvorteile der Skalierung anzuzeigen, insbesondere für größere DWUs. Um die beste Anzahl von DWUs für Ihren dedizierten SQL-Pool zu finden, versuchen Sie, die Skalierung nach oben und unten zu skalieren. Führen Sie Abfragen mit unterschiedlicher Anzahl von DWUs aus, nachdem Sie Ihre Daten geladen haben. Die Skalierung ist schnell, sodass Sie problemlos mit verschiedenen Leistungsstufen experimentieren können.
Ermitteln der besten Anzahl von DWUs
Wählen Sie für einen dedizierten SQL-Pool in der Entwicklung eine kleine Anzahl von DWUs als Ausgangspunkt aus, z. B. DW400c- oder DW200c-. Überwachen Sie die Anwendungsleistung für jede Anzahl von DWUs. Gehen Sie von einer linearen Skala aus, und bestimmen Sie, wie viel Sie zum Vergrößern oder Verkleinern der DWUs benötigen. Nehmen Sie weitere Anpassungen vor, bis Sie die optimale Leistungsstufe für Ihre geschäftlichen Anforderungen erreichen.
Skalieren eines SQL-Pools für Azure Synapse Analytics
Informationen zu Skalierbarkeits- und Leistungsoptimierungsfeatures von Pipelines in Azure Synapse Analytics und der von Ihnen verwendeten Kopieraktivität finden Sie in Leitfaden zur Kopieraktivität und Skalierbarkeit.
Weitere Informationen finden Sie in den folgenden Ressourcen:
- Skalierungsberechnung für einen SQL-Pool von Azure Synapse Analytics mit dem Azure-Portal
- Skalierungsberechnung für einen dedizierten SQL-Pool mit Azure PowerShell-
- Skalierungsberechnung für einen dedizierten SQL-Pool in Azure Synapse Analytics mithilfe von T-SQL-
- Verwalten der Berechnung für einen dedizierten SQL-Pool
Power BI Premium und Fabric
In diesem Artikel werden die Power BI Premium F64-Kapazität verwendet, um BI-Funktionen zu veranschaulichen. Dedizierte Power BI-Kapazitäten in Fabric reichen von F64 (8 vCores) bis F1024 (128 vCores).
So bestimmen Sie, wie viel Kapazität Sie benötigen:
- Bewerten der Last für Ihre Kapazität.
- Installieren Sie die Fabric -Kapazitätsmetriken-App für die fortlaufende Überwachung.
- Erwägen Sie die Verwendung von workloadbezogenen Kapazitätsoptimierungstechniken.
Beitragende
Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.
Hauptautoren:
- Galina Polyakova | Senior Cloud Solution Architect
- Noah Costar | Cloud Solution Architect
- George Stevens | Cloud Solution Architect
Andere Mitwirkende:
- Jim McLeod | Cloud Solution Architect
- Miguel Myers | Senior Program Manager
Um nichtöffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.
Nächste Schritte
- Was ist Power BI Premium?
- Was ist Microsoft Entra ID?
- zugreifen auf Data Lake Storage und Azure Blob Storage mit Azure Databricks
- Was ist Azure Synapse Analytics?
- Pipelines und Aktivitäten in Azure Data Factory und Azure Synapse Analytics
- Was ist Azure SQL?