Freigeben über

Verwenden von Microsoft Fabric zum Entwerfen einer Enterprise BI-Lösung

Microsoft Fabric
Azure Blob Storage
Microsoft Entra ID
Power BI

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 als ersten Schritt zur vollständigen Modernisierung mit cloudbasierten Komponenten verwenden.

Diese Anleitung basiert auf dem End-to-End-Szenario von Microsoft Fabric. Es gibt mehrere Optionen, um Daten von einem lokalen SQL-Server zu extrahieren, wie Fabric Data Factory-Pipelines, Spiegelung, Kopierauftrag und Fabric-Ereignisstreams in Echtzeit zur Änderungsdatenerfassung (CDC) für SQL. Nach der Extraktion werden die Daten für die Analyse transformiert.

Architektur

Diagramm, das die Unternehmens BI-Architektur mit Fabric zeigt.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Arbeitsablauf

Der folgende Workflow entspricht dem vorherigen Diagramm.

Datenquelle

Erfassung und Datenspeicherung

  • Fabric OneLake ist ein einzelner, einheitlicher, logischer Datensee für Ihre gesamte Organisation. Dieser SaaS bietet verschiedene Datenspeicheroptionen wie Fabric Lakehouse für Data Engineering Lakehouse-Workloads, Fabric Warehouse für Data Warehouse-Workloads und Fabric Eventhouse für Zeitreihen und Log-Datasets mit hohem Volumen.

  • Fabric Data Factory-Pipelines ermöglichen ihnen das Erstellen komplexer Extrakt-, Transformations-, Last- (ETL)- und Data Factory-Workflows, die viele verschiedene Aufgaben im großen Maßstab ausführen können. Steuerungsflussfunktionen sind in Datenpipelinen integriert, mit denen Sie Workflowlogik erstellen können, die Schleifen und Bedingungen bereitstellt. In dieser Architektur ermöglichen metadatengesteuerte Frameworks die inkrementelle Erfassung und Verarbeitung mehrerer Tabellen in großem Maßstab.

  • Fabric Data Factory-Spiegelung ermöglicht es Ihnen, komplexe ETL-Prozesse zu vermeiden und Ihren vorhandenen SQL Server-Bestand mit den übrigen Daten von Fabric zu integrieren. Sie können Ihre vorhandenen SQL Server-Datenbanken kontinuierlich direkt in Fabric OneLake replizieren. Der Fabric Data Factory-Kopierauftrag erleichtert das Verschieben von Daten aus Ihrer Quelle auf Ihr Ziel, ohne Dass Pipelines erforderlich sind. Datenübertragungen können über integrierte Muster für Batch- und inkrementelle Kopie mit Unterstützung für skalierbare Leistung konfiguriert werden.

  • Fabric-Ereignisstreams bieten einen hohen Durchsatz und Echtzeit-Datenaufnahme einer SQL Server-Datenbank, die auf einem virtuellen Computer (VM) gehostet und mithilfe der CDC-Extraktion verarbeitet wird. Dieses Muster eignet sich für Anwendungsfälle, die Echtzeit-Dashboards und Warnungen erfordern.

Analysen und Berichte

Komponenten

  • Azure SQL-Datenbank ist ein von Azure gehosteter PaaS SQL-Server. In dieser Architektur stellt DIE SQL-Datenbank die Quelldaten bereit und veranschaulicht den Datenfluss für das Migrationsszenario.

  • OneLake ist ein einheitlicher, cloudbasierter Datensee zum Speichern von strukturierten und unstrukturierten Daten in der gesamten Organisation. In dieser Architektur dient OneLake als zentrale Speicherebene. Es verwendet Artefakte wie Fabric Lakehouse, Fabric Warehouse, Fabric Eventhouse und gespiegelte Datenbanken, um verschiedene Datentypen für Analysen und Berichte zu speichern und zu organisieren.

  • Fabric Data Warehouse ist ein SaaS-Angebot, das Data Warehouse-Workloads für große Datasets hostet. In dieser Architektur dient Fabric Data Warehouse als endgültiger Speicher für dimensionale Datasets und unterstützt Analysen und Berichte.

  • Power BI ist ein Business Intelligence-Tool, das auf Fabric-Compute gehostet wird. Es stellt Daten in diesem Szenario dar und visualisiert sie, sodass Geschäftsbenutzer basierend auf Daten aus Fabric Data Warehouse und anderen Quellen mit Dashboards und Berichten interagieren können.

  • Microsoft Entra ID ist eine Multicloud-Identitäts- und Netzwerklösungssuite, die den Authentifizierungs- und Autorisierungsfluss unterstützt. In dieser Architektur bietet Microsoft Entra ID sicheren Zugriff für Benutzer, die eine Verbindung mit Power BI- und Fabric-Ressourcen herstellen.

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 Fabric verwenden, um die Daten aufzunehmen und zu analysieren und Analyseeinblicke für Benutzer über Power BI bereitzustellen.

Wann diese Architektur verwendet werden soll

Sie können verschiedene Methoden verwenden, um geschäftsanforderungen für Enterprise Business Intelligence zu erfüllen. Verschiedene Aspekte definieren Geschäftsanforderungen, z. B. aktuelle Technologieinvestitionen, menschliche Fähigkeiten, die Zeitachse für modernisierung, zukünftige Ziele und ob Sie plattform as a Service (PaaS) oder Software as a Service (SaaS) bevorzugen.

Berücksichtigen Sie die folgenden Entwurfsansätze:

Bei der Architektur in diesem Artikel wird davon ausgegangen, dass Sie ein Fabric Lakehouse oder Fabric Warehouse als persistente Ebene des Enterprise-Semantikmodells verwenden und Power BI für Business Intelligence verwenden. Dieser SaaS-Ansatz bietet die Flexibilität, verschiedene Geschäftliche Anforderungen und Vorlieben zu erfüllen.

Authentifizierung

Die Microsoft Entra-ID authentifiziert Benutzer, die eine Verbindung mit Power BI-Dashboards und -Apps herstellen. Single Sign-On (SSO) verbindet Benutzer mit den Daten im Fabric Warehouse- und Power BI-Semantikmodell. Die Autorisierung erfolgt an der Quelle.

Inkrementelles Laden

Wenn Sie einen automatisierten ETL- oder 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 Last bezeichnet. Im Gegensatz dazu lädt eine vollständige Datenlast 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 unveränderliche Transaktionen dar, z. B. ein Verkauf, bei dem das Beibehalten des Systemversionsverlaufs nicht sinnvoll ist. 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.

Die folgenden Schritte beschreiben den allgemeinen Fluss der ELT-Pipeline:

  1. 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.

  2. 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.

  3. 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.

Metadatengesteuertes Ingestions-Framework

Das metadatengesteuerte Ingestionsframework in den Pipelines der Fabric Data Factory lädt schrittweise alle in der relationalen Datenbank enthaltenen Tabellen. Der Artikel bezieht sich auf ein Data Warehouse als Quelle, kann aber durch eine Azure SQL-Datenbank als Quelle ersetzt werden.

  1. Wählen Sie eine Wasserzeichenspalte aus. Wählen Sie eine Spalte in der Quelltabelle aus, die beim Nachverfolgen neuer oder geänderter Datensätze hilft. Diese Spalte enthält in der Regel Werte, die sich erhöhen, wenn Zeilen hinzugefügt oder aktualisiert werden (z. B. ein Zeitstempel oder eine ID). Verwenden Sie den höchsten Wert in dieser Spalte als Referenzwert, um zu wissen, wo Sie aufgehört haben.

  2. Richten Sie eine Tabelle ein, um Den letzten Wasserzeichenwert zu speichern.

  3. Erstellen Sie eine Pipeline, die die folgenden Aktivitäten enthält:

    • Zwei Nachschlageaktivitäten. Die erste Aktivität ruft den letzten Wasserzeichenwert ab (wo wir das letzte Mal aufgehört haben). Die zweite Aktivität ruft den neuen Wasserzeichenwert ab (wo wir dieses Mal aufhören). Beide Werte werden an die Kopieraktivität übergeben.

    • Eine Kopieraktivität, die Zeilen findet, in denen der Wert der Wasserzeichenspalte zwischen den alten und neuen Wasserzeichen liegt. Anschließend werden diese Daten aus Ihrem Data Warehouse als neue Datei in Ihr Lakehouse kopiert.

    • Eine gespeicherte Prozeduraktivität, die den neuen Wasserzeichenwert speichert, um den Ausgangspunkt für die nächste Pipelineausführung zu bestimmen.

    Das Diagramm zeigt ein Flussdiagramm von Aktivitäten zum Abrufen, Verwenden und Aktualisieren von Wasserzeichenwerten.

Die folgende Abbildung zeigt eine abgeschlossene Pipeline. Weitere Informationen finden Sie unter inkrementelle Aufnahme.

Der Screenshot zeigt eine Medienaufnahmepipeline mit Nachschlageaktivitäten zum Abrufen von Wasserzeichenwerten, eine Kopieraktivität für neue Daten und eine gespeicherte Prozedur zum Aktualisieren des Wasserzeichens.

Laden von Daten in ein Fabric-Data Warehouse

Die Kopieraktivität kopiert Daten aus der SQL-Datenbank in das Fabric-Data Warehouse. Die SQL-Datenbank dieses Beispiels befindet sich in Azure, daher wird eine Im Fabric-Portal unter "Verbindung und Gateways verwalten" eingerichtete Verbindung verwendet.

Verwenden von Fabric Data Factory-Pipelines

Pipelines in Fabric Data Factory definieren einen sortierten Satz von Aktivitäten, um ein inkrementelles Lademuster abzuschließen. Manuelle oder automatische Trigger starten die Pipeline.

Transformieren der Daten

Wenn eine Transformation erforderlich ist, verwenden Sie Fabric-Datenflüsse, um Low-Code, AI-gestützte ETL-Transformationen zu entwerfen, die die Daten neu gestalten. Fabric-Datenflüsse basieren auf dem Power Query-Modul, um diese Transformationen anzuwenden und die Ergebnisse in Fabric Data Warehouse zu schreiben.

Verwenden Sie in einer Produktionsumgebung Fabric-Notizbücher , um ETL-Transformationen zu implementieren, die gut für große Datasets über ein verteiltes Computing-Framework funktionieren, das von Apache Spark gesteuert wird.

Hinweis

Verwenden Sie das systemeigene Ausführungsmodul , um Daten engineering- oder ETL-Workloads auszuführen.

Verwenden von Power BI mit Fabric-Kapazitäten zum Zugreifen auf, Modellieren und Visualisieren von Daten

Fabric-Kapazitäten in Power BI unterstützen mehrere Speichermodi zum Herstellen einer Verbindung mit Azure-Datenquellen:

  • Importieren: Lädt Daten in das Power BI-Semantikmodell für die In-Memory-Abfrage.

  • DirectQuery: Führt Abfragen direkt gegen relationalen Speicher aus, ohne Daten in den Arbeitsspeicher zu laden.

  • Zusammengesetztes Modell: Kombiniert den Importmodus für einige Tabellen mit DirectQuery für andere Tabellen im selben Dataset.

  • Direct Lake: Abfragen von Deltatabellen, die in OneLake gespeichert sind, über ein Fabric-Arbeitsbereichs-Semantikmodell. Es ist für die interaktive Analyse großer Tabellen optimiert, indem Daten nach Bedarf in den Arbeitsspeicher geladen werden.

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 zugrunde liegende Computemodul und verwendet Sicherheitsfunktionen für die Quelle. DirectQuery stellt sicher, dass die Ergebnisse immer mit den neuesten Quelldaten konsistent sind.

Der Importmodus kann die niedrigste Abfragelatenz bereitstellen. Berücksichtigen Sie den Importmodus, wenn die folgenden Faktoren zutreffen:

  • 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 Benutzer vollständigen Zugriff auf die aktuellsten 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 Gigabyte (GB) auf 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.

Der Screenshot zeigt ein Power BI-Dashboard mit Umsatzmetriken, Trenddiagrammen, Filtern und einer detaillierten Datentabelle.

Verwenden Sie Power BI , um große Modelle, paginierte Berichte und Bereitstellungspipelinen zu verwalten. Nutzen Sie den integrierten Azure Analysis Services-Endpunkt. Sie können auch eine dedizierte Kapazität mit einem einzigartigen Wertversprechen haben.

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 Fabric Data Warehouse. Power BI bestimmt, ob speicherinterner oder DirectQuery-Speicher basierend auf Effizienz verwendet werden soll. Die Engine entscheidet, wann von In-Memory auf DirectQuery umgeschaltet wird und überträgt die Logik an das Fabric-Datenlager. Je nach Kontext der Abfragetabellen können sie entweder als zwischengespeicherte (importierte) oder nicht zwischengespeicherte zusammengesetzte Modelle dienen. 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 Fabric Data Warehouse oder Lakehouse verwenden, führen Sie die folgenden Aktionen aus:

  • Verwenden Sie Fabric Z-Order und V-Order , um die Abfrageleistung zu verbessern, indem Sie die Speicherung zugrunde liegender Tabellendaten in Delta-Formatdateien optimieren.

  • Verwenden Sie fabric lakehouse 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.

Zuverlässigkeit

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Zuverlässigkeit.

Der Artikel Zuverlässigkeit erläutert, wie Fabric Zuverlässigkeit unterstützt, einschließlich regionaler Resilienz über Verfügbarkeitszonen sowie regionsübergreifende Wiederherstellung und Geschäftskontinuität. Auf der Fabric-Seite „Kapazitätseinstellungen“ ist die Option „Notfallwiederherstellung“ vorhanden. Es ist verfügbar, wo Azure regionale Paarungen mit der Präsenz des Fabric-Dienstes übereinstimmen. Wenn die Kapazitätseinstellung für die Notfallwiederherstellung aktiviert ist, wird die regionsübergreifende Replikation als Notfallwiederherstellungsfunktion für OneLake-Daten aktiviert.

Sicherheit

Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Sicherheit.

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.

Dieses Szenario befasst sich mit den anspruchsvollsten Sicherheitsbedenken mithilfe einer Kombination von mehrstufigen Sicherheitskontrollen, einschließlich Netzwerk-, Identitäts-, Datenschutz- und Autorisierungskontrollen. Ein Fabric-Data Warehouse speichert die meisten Daten. Power BI greift über DirectQuery über SSO auf die Daten zu. Verwenden Sie die Microsoft Entra-ID für die Authentifizierung. Es gibt auch umfangreiche Sicherheitskontrollen für die Datenautorisierung innerhalb der bereitgestellten Pools.

Berücksichtigen Sie die folgenden allgemeinen Sicherheitsbedenken:

  • 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. Fabric bietet umfassende Datenschutzfunktionen zur Unterstützung der Sicherheit und zur Förderung der Compliance.

    • Die OneLake-Sicherheit steuert den gesamten Zugriff auf OneLake-Daten mit unterschiedlichen Berechtigungen, die von den Berechtigungen des übergeordneten Elements oder Arbeitsbereichs geerbt wurden.

      • Ein Arbeitsbereich ist eine kollaborative Umgebung zum Erstellen und Verwalten von Elementen. Arbeitsbereichsrollen können auf dieser Ebene verwaltet werden.

      • Ein Element ist eine Reihe von Funktionen, die in einer einzelnen Komponente gebündelt sind. Ein Datenelement ist ein Untertyp von Element, mit dem Daten mithilfe von OneLake darin gespeichert werden können. Elemente erben Berechtigungen von den Arbeitsbereichsrollen, können aber auch über zusätzliche Berechtigungen verfügen. Ordner innerhalb eines Elements werden zum Speichern und Verwalten von Daten verwendet, z. B. Tables/ oder Files/.

  • Bestimmen Sie, wie die Identität eines Benutzers überprüft werden soll.

  • Wählen Sie eine Netzwerksicherheitstechnologie aus, um die Integrität, Vertraulichkeit und den Zugriff auf Ihre Netzwerke und Daten zu schützen.

  • Wählen Sie Tools aus, mit denen Sie Bedrohungen erkennen und benachrichtigen können.

  • Bestimmen Sie, wie Daten in Fabric OneLake geschützt werden.

    • Schützen Sie Daten auf Fabric mithilfe von Vertraulichkeitsbezeichnungen von Microsoft Purview Information Protection. Bezeichnungen wie "Allgemein", "Vertraulich" und "Streng vertraulich" werden in Microsoft Office-Apps wie Word, PowerPoint und Excel häufig verwendet, um vertrauliche Informationen zu schützen. Sie folgen den Daten automatisch von Element zu Element, während sie über Fabric fließt, und zwar von datenquelle zu Geschäftsbenutzern.

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.

In diesem Abschnitt werden die Preisdetails für die verschiedenen Dienste, die in der Lösung verwendet werden, beschrieben, und die Entscheidungen, die für dieses Szenario mithilfe eines Beispieldatensatzes getroffen wurden, erläutert. Verwenden Sie die Startkonfiguration im Azure-Preisrechner , und passen Sie sie an Ihr Szenario an. Weitere Informationen zu Fabric-SKUs finden Sie in der Fabric-Preisübersicht. Weitere Informationen zum Generieren einer Schätzung des Gesamtverbrauchs von Fabric finden Sie in der Fabric-Kapazitätsschätzung.

Skalierbare Fabric-Architektur

Fabric ist eine serverlose Architektur für die meisten Workloads, mit denen 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 GB, sodass ihre Kosten beim Aufnehmen von Daten steigen.

Fabric Factory-Pipelines

Drei Hauptkomponenten beeinflussen den Preis einer Pipeline:

  • Datenpipelineaktivitäten für die Orchestrierung: Um die Kosten zu optimieren, reduzieren Sie die gesamt Orchestrierungszeit, indem Sie parallele Abläufe implementieren.

  • Dataflow Gen2 zur Berechnung: Um die Kosten zu optimieren, vereinfachen Sie ETL-Pipelines, indem Sie unnötige Daten filtern und die inkrementelle Extraktion verarbeiten.

  • Datenverschiebung für Kopierauftrag oder Kopieraktivität: Um die Kosten zu optimieren, konfigurieren Sie den Kopierauftrag mit inkrementeller Extraktion, und passen Sie den Durchsatz für die Kopieraktivität an.

Weitere Informationen finden Sie unter der Registerkarte „Preismessungen für Data Factory“ auf „Data Factory-Preise“.

Der Preis variiert je nach Komponenten oder Aktivitäten, Häufigkeit und der Gesamtberechnung, die mit der Orchestrierung verbunden ist. Jede Datenverschiebung, die aus Pipelineaktivitäten oder einem Kopierauftrag resultiert, verursacht Kosten. Die Berechnung, die mit der Datenverschiebung über Fabric-Spiegelung verknüpft ist, ist jedoch kostenlos, und die Speicherkosten für gespiegelte Daten sind bis zur Kapazitätsgröße frei. Wenn Sie z. B. eine F64-Kapazität erwerben, erhalten Sie 64 kostenlose Terabyte (TB) Speicher, der ausschließlich für die Spiegelung verwendet wird. OneLake-Speicher wird in Rechnung gestellt, wenn der freie Spiegelungsspeichergrenzwert überschritten wird oder wenn die Kapazität angehalten wird.

Entscheidungshandbuch zur Gewebe-Arbeitslast

Verwenden Sie dieses Entscheidungshandbuch , um einen Datenspeicher für Ihre Fabric-Workloads auszuwählen. Alle Optionen sind im einheitlichen Speicher in OneLake verfügbar.

Der SQL-Endpunkt für Fabric Lakehouse oder Fabric Warehouse bietet die Möglichkeit, Ad-hoc-Abfragen für die Analyse auszuführen. Außerdem können Power BI-Semantikmodelle die Daten importieren oder direkt abfragen. Die Kosten, die einem Seehaus oder Lager zugeordnet sind, entsprechen dem CUs-Verbrauch für SQL-Abfragen für den SQL-Endpunkt. Um die Kosten zu optimieren, implementieren Sie Z-Order und V-Order in Fabric Lakehouse, um die Abfrageleistung zu verbessern. Optimieren Sie für Data Warehouse Abfragen, um kleinere Batches zu lesen.

OneLake-Speicher

Für den OneLake-Speicher erfolgt die Abrechnung nach einem nutzungsabhängigen Modell pro GB der verwendeten Daten, und es werden keine Kapazitätseinheiten (CUs) von Fabric verbraucht. Fabric-Elemente wie Lakehouses und Warehouses verbrauchen OneLake Storage. Weitere Informationen finden Sie unter Fabric-Preise.

Um OneLake-Kosten zu optimieren, konzentrieren Sie sich auf die Verwaltung des Speichervolumes, indem Sie regelmäßig nicht verwendete Daten löschen, einschließlich Daten im Vorläufigen Löschen und Optimieren von Lese-/Schreibvorgängen. OneLake-Speicher wird separat von der Berechnung abgerechnet, daher ist es wichtig, die Nutzung mit der Fabric-Kapazitätsmetrik-App zu überwachen. Um die Speicherkosten zu reduzieren, die basierend auf der durchschnittlichen täglichen Nutzung im Monat berechnet werden, sollten Sie die Menge der gespeicherten Daten minimieren.

Power BI

In diesem Szenario werden Power BI-Arbeitsbereiche mit integrierten Leistungsverbesserungen verwendet, um anspruchsvolle analytische Anforderungen zu erfüllen. Um die Kosten zu optimieren, implementieren Sie die inkrementelle Aktualisierung für die Importmodusextraktion. Implementieren Sie den Direct Lake-Modus für die Berichterstellung für größere Datasets, wenn möglich, um die Gesamtlast der Fabric-Kapazitäten zu reduzieren.

Weitere Informationen finden Sie unter Power BI-Preis.

Operative Exzellenz

„Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Checkliste für die Designüberprüfung zur betrieblichen Exzellenz.

  • Verwenden Sie eine Azure DevOps-Releasepipeline und GitHub-Aktionen, um die Bereitstellung eines Fabric-Arbeitsbereichsartefaktes in mehreren Umgebungen zu automatisieren. Weitere Informationen finden Sie unter Fortlaufende Integration und kontinuierliche Bereitstellung für einen Fabric-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:

    • Das Data Warehouse und die zugehörigen Ressourcen
    • Data Factory-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 die Fabric-Kapazitätsmetriken-App , um die umfassende Überwachung des Fabric-Kapazitätsverbrauchs zu ermöglichen. Verwenden Sie die Arbeitsbereichsüberwachung, um die Telemetrieprotokolle von Fabric-Arbeitsbereichen detailliert zu überwachen.

  • Verwenden Sie die Fabric-Kapazitätsschätzung , um Ihre Fabric-Kapazitätsanforderungen zu schätzen.

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.

In diesem Artikel wird die Fabric F64-Kapazität verwendet, um BI-Funktionen zu veranschaulichen. Dedizierte Power BI-Kapazitäten in Fabric reichen von F64 bis zur maximalen SKU-Größe. Weitere Informationen finden Sie unter Fabric-Preise.

Führen Sie die folgenden Aktionen aus, um zu bestimmen, wie viel Kapazität Sie benötigen:

Beitragende

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

Hauptautor:

Andere Mitwirkende:

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

Nächste Schritte