Power BI-Verwendungsszenarien: Erweiterte Datenaufbereitung

Hinweis

Dieser Artikel ist Teil der Artikelreihe zur Power BI-Implementierungsplanung. Diese Reihe konzentriert sich hauptsächlich auf den Power BI-Workload innerhalb von Microsoft Fabric. Eine Einführung in die Artikelreihe finden Sie unter Power BI-Implementierungsplanung.

Die Aktivitäten im Rahmen der Datenaufbereitung (manchmal als ETL bezeichnet, ein Akronym für Extrahieren, Transformieren und Laden) sind häufig mit einem großen Aufwand verbunden. Zeit, Qualifikation und Aufwand für Erfassung, Bereinigung, Zusammensetzung und Anreicherung von Daten hängen von der Qualität und Struktur der Quelldaten ab.

Zeit und Aufwand für eine zentrale Datenaufbereitung bieten folgende Vorteile:

• Verbessern der Wiederverwendbarkeit und maximaler Nutzen aus den Datenaufbereitungsbemühungen.
• Verbessern der Möglichkeit, konsistente Daten für mehrere Teams bereitzustellen.
• Verringern des Aufwands, der von anderen Inhaltsautoren benötigt wird.
• Sicherstellen von Skalierung und Leistung.

Das Verwendungsszenario Erweiterte Datenaufbereitung ergänzt das Szenario Self-Service-Datenaufbereitung. Die erweiterte Datenaufbereitung ermöglicht die Wiederverwendung von Dataflows durch mehrere Benutzer in verschiedenen Teams und für verschiedene Anwendungsfälle.

Separate Arbeitsbereiche für die jeweiligen Dataflowzielsetzungen sind hilfreich, wenn die Dataflowausgabe mehreren Semantikmodellersteller*innen (früher als Dataset bezeichnet) zur Verfügung gestellt wird, insbesondere wenn sie sich in verschiedenen Teams in der Organisation befinden. Separate Arbeitsbereiche sind auch hilfreich für die Verwaltung von Sicherheitsrollen, wenn die Personen, die Dataflows erstellen und verwalten, nicht mit den Verbrauchern identisch sind.

Hinweis

Das Szenario für die erweiterte Datenaufbereitung ist das zweite der Datenaufbereitungsszenarien. Dieses Szenario baut auf den Möglichkeiten zentraler Dataflows auf (siehe Beschreibung im Szenario Self-Service-Datenaufbereitung).

Das Szenario für die erweiterte Datenaufbereitung ist eines der Self-Service-BI-Szenarien. Ein Mitglied des zentralen Teams kann die Techniken jedoch ähnlich wie im Szenario Verwaltete Self-Service-BI verwenden. Eine vollständige Liste der Self-Service-Szenarien finden Sie im Artikel zu Power BI-Verwendungsszenarien.

Einige Aspekte, die in den Szenarios für die inhaltsorientierte Zusammenarbeit und Übermittlung von Inhalten beschrieben sind, werden der Kürze halber in diesem Artikel nicht behandelt. Lesen Sie für vollständige Informationen zuerst diese Artikel.

Szenariodiagramm

Tipp

Es wird empfohlen, das Verwendungsszenario Self-Service-Datenaufbereitung durchzulesen (sofern noch nicht geschehen). Das Szenario für die erweiterte Self-Service-Datenaufbereitung baut auf diesem Szenario auf.

Der Schwerpunkt der Szenarien für die erweiterte Datenaufbereitung liegt auf folgenden Aspekten:

• Verwendung separater Dataflows abhängig vom Zweck: Stagingdataflow, Transformationsdataflow oder endgültiger Dataflow. Es wird die Verwendung von zusammensetzbaren Bausteinen empfohlen, die verschieden kombiniert werden können, um eine größere Wiederverwendung zu ermöglichen und bestimmte Benutzeranforderungen zu unterstützen. Zusammensetzbare Bausteine werden weiter unten in diesem Artikel beschrieben.
• Verwendung von separaten Arbeitsbereichen, die Ersteller oder Verbraucher von Dataflows unterstützen. Datenmodellierer, die Dataflows nutzen, können sich in verschiedenen Teams befinden und/oder unterschiedliche Anwendungsfälle haben.
• Verwendung verknüpfter Tabellen (auch als verknüpfte Entitäten bezeichnet), berechneten Tabellen (auch als berechnete Entitäten bezeichnet) und der erweiterten Compute-Engine.

Hinweis

Manchmal werden die Begriffe Semantikmodell und Datenmodell synonym verwendet. Aus Sicht des Power BI-Diensts wird der Begriff Semantikmodell verwendet. Aus Entwicklungsperspektive wird Datenmodell (oder kurz Modell) verwendet. In diesem Artikel haben beide Begriffe dieselbe Bedeutung. Ebenso haben Semantikmodellersteller*innen und Datenmodellierer*innen dieselbe Bedeutung.

Das folgende Diagramm enthält eine allgemeine Übersicht über die am häufigsten verwendeten Benutzeraktionen und Power BI-Komponenten, die das Szenario für die erweiterte Datenaufbereitung unterstützen.

Tipp

Wir empfehlen Ihnen, das Szenariodiagramm herunterzuladen, wenn Sie es in Ihre Präsentation, Dokumentation oder Ihren Blogbeitrag einbinden oder als Wandposter ausdrucken möchten. Da es sich um ein SVG-Bild (Scalable Vector Graphics) handeln kann, können Sie es ohne Qualitätsverlust nach oben oder unten skalieren.

Das Szenariodiagramm veranschaulicht die folgenden Benutzeraktionen, Tools und Features:

Element	Beschreibung
	Der Dataflowersteller entwickelt mehrere Tabellen in einem Dataflow. Für einen Dataflow, der für die Wiederverwendung vorgesehen ist, gehört der Ersteller üblicherweise (aber nicht notwendigerweise) zu einem zentralen Team, das Benutzer über Organisationsgrenzen hinweg unterstützt (z. B. IT, Unternehmens-BI oder Center of Excellence).
	Der Dataflow stellt eine Verbindung zu Daten in mindestens einer Datenquelle her.
	Für einige Datenquellen ist möglicherweise ein lokales Datengateway oder ein VNet-Gateway für die Datenaktualisierung erforderlich, z. B. solche, die sich in einem privaten Organisationsnetzwerk befinden. Diese Gateways werden sowohl zum Erstellen des Datenflusses in Power Query Online als auch zum Aktualisieren des Datenflusses verwendet.
	Alle beteiligten Arbeitsbereiche haben ihren Lizenzmodus auf Fabric-Kapazität, Premium-Kapazität, Premium pro Benutzer oder Eingebettet festgelegt. Diese Lizenzmodi ermöglichen die Verwendung verknüpfter Tabellen und berechneter Tabellen über Arbeitsbereiche hinweg, was in diesem Szenario erforderlich ist.
	Dataflowersteller entwickeln Dataflows mit Power Query Online, eine webbasierte Version von Power Query.
	Ein Stagingdataflow wird in einem dedizierten Arbeitsbereich für die zentrale Verwaltung von Dataflows erstellt. Ein Stagingdataflow kopiert die Rohdaten von der Quelle. Es werden nur wenige Transformationen angewendet (wenn überhaupt).
	Ein Transformationsdataflow (auch als bereinigter Dataflow bezeichnet) wird im gleichen Arbeitsbereich erstellt. Es generiert Daten mithilfe verknüpfter Tabellen zum Stagingdataflow. Berechnete Tabelle(n) enthalten Transformationsschritte, die die Daten aufbereiten, bereinigen und umgestalten.
	Dataflowersteller haben Zugriff auf die Verwaltung von Inhalten im dedizierten Arbeitsbereich für die zentrale Verwaltung von Dataflows.
	Es gibt mindestens einen anderen Arbeitsbereich, der Zugriff auf den endgültigen Dataflow ermöglichen soll, der produktionsgeeignete Daten für Datenmodelle bereitstellt.
	Der endgültige Dataflow wird in einem Arbeitsbereich erstellt, der Datenmodellierern zur Verfügung steht. Es generiert Daten mithilfe verknüpfter Tabellen zum Transformationsdataflow. Berechnete Tabellen stellen die aufbereitete Ausgabe dar, die für Datenmodellierer mit einer Arbeitsbereichsrolle als anzeigender Benutzer sichtbar ist.
	Semantikmodellersteller*innen (die die Dataflowausgabe verwenden) verfügen über Viewerzugriff auf den Arbeitsbereich, der die endgültige Dataflowausgabe enthält. Dataflowersteller verfügen ebenfalls über Zugriff auf die Verwaltung und Veröffentlichung von Inhalten im Arbeitsbereich (nicht im Szenariodiagramm dargestellt).
	Semantikmodellersteller*innen verwenden den endgültigen Dataflow als Datenquelle bei der Entwicklung eines Datenmodells in Power BI Desktop. Nachdem dies erledigt ist, veröffentlichen Semantikmodellersteller*innen die Power BI Desktop-Datei (PBIX), die das Datenmodell enthält, im Power BI-Dienst (nicht im Szenariodiagramm dargestellt).
	Fabric-Administratoren verwalten Einstellungen im Verwaltungsportal.
	Im Verwaltungsportal können Power BI-Administratoren Azure-Verbindungen so einrichten, dass Dataflowdaten in ihrem Azure Data Lake Storage Gen2 (ADLS Gen2)-Konto gespeichert werden. Die Einstellungen umfassen das Zuweisen eines Speicherkontos auf Mandantenebene und das Aktivieren von Speicherberechtigungen auf Arbeitsbereichsebene.
	Standardmäßig speichern Dataflows Daten im internen Speicher, der vom Power BI-Dienst verwaltet wird. Optional kann die Datenausgabe des Dataflows im ADLS Gen2-Konto der Organisation gespeichert werden.
	Fabric-Administratoren überwachen und überwachen Aktivitäten im Fabric-Portal.

Wesentliche Punkte

Nachstehend sind einige wichtige Punkte aufgeführt, auf die im Szenario für die erweitere Datenaufbereitung besonders hingewiesen werden muss.

Dataflows

Ein Dataflow umfasst mehrere Tabellen (auch als Entitäten bezeichnet). Jede Tabelle wird durch eine Abfrage definiert, die die erforderlichen Datenaufbereitungsschritte zum Laden der Tabelle mit Daten enthält. Alle Arbeiten zum Erstellen eines Dataflows werden in Power Query Online ausgeführt. Sie können einen Dataflow in mehreren Produkten erstellen, z. B. Power Apps, Dynamics 365 Customer Insights und Power BI.

Hinweis

Sie können keine Dataflows in einem persönlichen Arbeitsbereich im Power BI-Dienst erstellen.

Dataflowtypen

Die Verwendung von zusammensetzbaren Bausteinen ist ein Designprinzip, mit dem Sie Systemkomponenten verwalten, bereitstellen und sichern sowie anschließend in verschiedenen Kombinationen verwenden können. Das Erstellen von modularen, eigenständigen Dataflows für einen bestimmten Zweck ist eine bewährte Methode, um Wiederverwendung von Daten und Skalierung im Unternehmen zu erreichen. Modulare Dataflows sind außerdem einfacher zu verwalten und zu testen.

Im Szenariodiagramm werden drei Datentypen veranschaulicht: Stagingdataflow, Transformationsdataflow und endgültiger Dataflow.

Stagingdataflow

Ein Stagingdataflow (manchmal als Datenextraktionsdataflow bezeichnet) kopiert Rohdaten unverändert aus der Quelle. Dadurch, dass die Rohdaten mit minimaler Transformation extrahiert werden, können nachgelagerte Transformationsdataflows (als Nächstes beschrieben) den Stagingdataflow als Quelle verwenden. Diese Modularität ist in folgenden Fällen nützlich:

• Der Zugriff auf eine Datenquelle ist auf enge Zeitfenster und/oder auf wenige Benutzer begrenzt.
• Damit alle nachgelagerten Dataflows (und zugehörige Semantikmodelle) Daten liefern, die gleichzeitig aus der Datenquelle extrahiert wurden, ist eine zeitliche Konsistenz erwünscht.
• Aufgrund von Beschränkungen des Quellsystem oder dessen Fähigkeit zur Unterstützung analytischer Abfragen ist eine Reduzierung der Anzahl von Abfragen erforderlich, die an die Datenquelle übermittelt werden.
• Für Abgleichprozesse und Datenqualitätsüberprüfungen ist eine Kopie der Quelldaten von Nutzen.

Transformationsdataflow

Ein Transformationsdataflow (manchmal als bereinigter Dataflow bezeichnet) bezieht seine Daten aus verknüpften Tabellen, mit dem Stagingdataflow verbunden sind. Es hat sich bewährt, Transformationen vom Datenextraktionsprozess zu trennen.

Ein Transformationsdataflow umfasst alle Transformationsschritte, die zum Aufbereiten und Umstrukturieren der Daten erforderlich sind. Der Schwerpunkt liegt auf dieser Ebene jedoch weiterhin auf der Wiederverwendbarkeit, damit der Datenfluss für mehrere Anwendungsfälle und Zwecke geeignet ist.

Endgültiger Dataflow

Ein endgültiger Datenfluss stellt die aufbereitete Ausgabe dar. Abhängig von Anwendungsfall und Zweck können einige zusätzliche Transformationen stattfinden. Für Analysen wird die Gestaltung des endgültigen Dataflows als Tabelle mit Sternschema (Dimension oder Fakt) bevorzugt.

Berechnete Tabellen sind für Datenmodellierer mit einer Arbeitsbereichsrolle als anzeigender Benutzer sichtbar. Dieser Tabellentyp wird in weiter unten im Abschnitt Arten von Dataflowtabellen beschrieben.

Hinweis

Data Lakes verfügen oft über Zonen wie Bronze, Silber und Gold. Die drei Dataflowtypen stellen ein ähnliches Entwurfsmuster dar. Um die bestmöglichen Datenarchitekturentscheidungen zu treffen, muss berücksichtigt werden, wer die Daten verwaltet, wie die Daten voraussichtlich genutzt werden und welche Qualifikation Personen benötigen, die auf die Daten zugreifen.

Arbeitsbereiche für Dataflows

Wenn Sie alle Dataflows in einem einzelnen Arbeitsbereich erstellen würden, würde die Wiederverwendbarkeit dadurch erheblich eingeschränkt. Die Verwendung eines einzelnen Arbeitsbereichs beschränkt auch die verfügbaren Sicherheitsoptionen, wenn mehrere Arten von Benutzern in Teams und/oder für unterschiedliche Anwendungsfälle unterstützt werden müssen. Es wird empfohlen, mehrere Arbeitsbereiche zu verwenden. Sie bieten eine mehr Flexibilität, wenn Self-Service-Ersteller aus verschiedenen Bereichen der Organisation unterstützt werden müssen.

Das Szenariodiagramm enthält die beiden folgenden Arbeitsbereichstypen:

• Arbeitsbereich 1: Dieser speichert zentral verwaltete Dataflows (manchmal auch als Back-End-Arbeitsbereich bezeichnet). Er enthält sowohl die Staging- als auch die Transformationsdataflows, da sie von den gleichen Personen verwaltet werden. Dataflowersteller sind häufig Mitglieder eines zentralen Teams, z. B. IT, BI oder Center of Excellence. Ihnen sollte eine Rolle als Administrator, Mitglied oder Mitwirkender für den Arbeitsbereich zugewiesen werden.
• Arbeitsbereich 2: Dieser speichert und liefert die endgültige Dataflowausgabe an die Verbraucher der Daten (manchmal auch als Benutzerarbeitsbereich bezeichnet). Semantikmodellersteller*innen sind häufig Self-Service-Analyst*innen, Hauptbenutzer*innen oder zivile Datentechniker*innen. Ihnen sollten eine Rolle als anzeigender Benutzer für den Arbeitsbereich zugewiesen werden, da sie nur die Ausgabe des endgültigen Dataflows nutzen müssen. Um Semantikmodellersteller*innen aus verschiedenen Bereichen der Organisation zu unterstützen, können Sie abhängig von Anwendungsfällen und Sicherheitsanforderungen mehrere Arbeitsbereiche wie diesen erstellen.

Tipp

Es wird empfohlen, Möglichkeiten zur Unterstützung von Semantikmodellersteller*innen zu überprüfen wie im Szenario Self-Service-Datenaufbereitung beschrieben. Es ist wichtig zu wissen, dass Semantikmodellersteller*innen weiterhin alle Funktionen von Power Query in Power BI Desktop verwenden können. Sie können Abfrageschritte hinzufügen, um die Dataflowdaten weiter zu transformieren oder die Dataflowausgabe mit anderen Quellen zusammenzuführen.

Arten von Dataflowtabellen

Im Szenariodiagramm sind drei Arten von Dataflowtabellen (auch als Entitäten bezeichnet) dargestellt.

• Standardtabelle: Fragt eine externe Datenquelle ab, z. B. eine Datenbank. Im Szenariodiagramm sind Standardtabellen im Stagingdataflow dargestellt.
• Verknüpfte Tabelle: Verweist auf eine Tabelle in einem anderen Dataflow. Eine verknüpfte Tabelle dupliziert keine Daten. Sie ermöglicht stattdessen die mehrmalige Wiederverwendung einer Standardtabelle für mehrere Zielsetzungen. Verknüpfte Tabellen sind für anzeigende Benutzer von Arbeitsbereichen nicht sichtbar, da sie Berechtigungen vom ursprünglichen Dataflow erben. Im Szenariodiagramm sind verknüpfte Tabellen zweimal dargestellt:
  • Im Transformationsdataflow für den Zugriff auf die Daten im Stagingdataflow.
  • Im endgültigen Dataflow für den Zugriff auf die Daten im Transformationsdataflow.
• Berechnete Tabelle: Führt zusätzliche Berechnungen unter Verwendung eines anderen Dataflows als Quelle aus. Berechnete Tabellen ermöglichen eine bedarfsorientierte Anpassung der Ausgabe für individuelle Anwendungsfälle. Im Szenariodiagramm sind berechnete Tabellen zweimal dargestellt:
  • Im Transformationsdataflow zum Ausführen allgemeiner Transformationen.
  • Im endgültigen Dataflow zum Bereitstellen der Ausgabe an Semantikmodellersteller*innen. Da berechnete Tabellen die Daten wiederum beibehalten (nach der Dataflowaktualisierung), können Datenmodellierer im endgültigen Dataflow auf die berechneten Tabellen zugreifen. In diesem Fall sollte den Datenmodellierern die Rolle als anzeigender Benutzer für den Zugriff auf den Arbeitsbereich gewährt werden.

Hinweis

Es gibt viele Entwurfstechniken, Muster und bewährte Methoden für Dataflows, die vom Self-Service bis hin zu unternehmensweiten Lösungen reichen. Dataflows in einem Arbeitsbereich, dessen Lizenzmodus auf Premium-Einzelbenutzer oder Premium-Kapazität festgelegt ist, können darüber hinaus von erweiterten Features profitieren. Verknüpfte Tabellen und berechnete Tabellen (auch als Entitäten bezeichnet) sind zwei erweiterte Features, die für die Verbesserung der Wiederverwendbarkeit von Datenflüssen unerlässlich sind.

erweiterte Compute-Engine

Die erweiterte Compute-Engine ist ein erweitertes Feature, das mit Power BI Premium verfügbar ist. Die erweiterte Compute-Engine verbessert die Leistung verknüpfter Tabellen (im selben Arbeitsbereich), die auf den Dataflow verweisen (damit verknüpft sind). So profitieren Sie optimal von der erweiterten Compute-Engine:

• Teilen Sie Staging- und Transformationsdataflows auf.
• Verwenden Sie denselben Arbeitsbereich zum Speichern von Staging- und Transformationsdataflows.
• Wenden Sie komplexe Vorgänge, die Query Folding bewirken können, frühzeitig in den Abfrageschritten an. Die Priorisierung von Foldingvorgängen kann dazu beitragen, optimale Aktualisierungsleistung zu erzielen.
• Verwenden Sie inkrementelle Aktualisierung, um Aktualisierungsdauer und Ressourcenverbrauch zu verringern.
• Führen Sie Tests frühzeitig und häufig in der Entwicklungsphase aus.

Aktualisieren von Dataflow und Semantikmodell

Ein Dataflow ist eine Datenquelle für Semantikmodell. In den meisten Fällen sind mehrere Datenaktualisierungszeitpläne beteiligt: einer für die einzelnen Dataflows und einer für die einzelnen Semantikmodelle. Alternativ ist es möglich, DirectQuery vom Semantikmodell zum Dataflow zu verwenden. Dafür sind Power BI Premium und die erweiterte Compute-Engine erforderlich (nicht im Szenariodiagramm dargestellt).

Azure Data Lake Storage Gen2

Ein ADLS Gen2-Konto ist ein bestimmter Azure Storage-Kontotyp, für den der hierarchische Namespace aktiviert ist. ADLS Gen2 verfügt über Leistungs-, Verwaltungs- und Sicherheitsvorteile für die Verarbeitung analytischer Workloads. Standardmäßig verwenden Power BI-Dataflows internen Speicher, d. h. ein integriertes Data Lake-Konto, das vom Power BI-Dienst verwaltet wird. Optional können Organisationen ihren eigenen Data Lake verwenden, indem sie eine Verbindung zu einem ADLS Gen2-Konto in ihrer Organisation herstellen.

Einige Vorteile der Verwendung eines eigenen Data Lakes sind:

• Benutzer (oder Prozesse) können direkt auf die Dataflowdaten zugreifen, die im Data Lake gespeichert sind. Das ist hilfreich, wenn der Dataflow über Power BI hinaus wiederverwendet wird. Beispielsweise kann Azure Data Factory auf die Dataflowdaten zugreifen.
• Andere Tools oder Systeme können die Daten im Data Lake verwalten. In diesem Fall kann Power BI die Daten nutzen, aber nicht verwalten (nicht im Szenariodiagramm dargestellt).

Achten Sie bei Verwendung verknüpfter Tabellen oder berechneter Tabellen darauf, dass jeder Arbeitsbereich demselben ADLS Gen2-Speicherkonto zugewiesen ist.

Hinweis

Dataflowdaten in ADLS Gen2 werden in einem Power BI-spezifischen Container gespeichert. Dieser Container wird im Diagramm des Verwendungsszenarios Self-Service-Datenaufbereitung behandelt.

Einstellungen im Verwaltungsportal

Es gibt zwei wichtige Einstellungen für die Verwaltung im Verwaltungsportal:

• Azure-Verbindungen:Der Abschnitt Azure-Verbindungen des Verwaltungsportals enthält eine Einstellung zum Einrichten einer Verbindung zu einem ADLS Gen2-Konto. Diese Einstellung ermöglicht es einem Power BI-Administrator, eigene Data Lakes in Dataflows zu verwenden. Nach der Konfiguration können Arbeitsbereiche dieses Data Lake-Konto als Speicher verwenden.
• Speicherung auf Arbeitsbereichsebene: Ein Power BI-Administrator kann Speicherberechtigungen auf Arbeitsbereichsebene festlegen. Wenn diese Einstellung aktiviert ist, können Arbeitsbereichsadministratoren ein anderes Speicherkonto verwenden als das Speicherkonto, das auf Mandantenebene festgelegt wurde. Die Aktivierung dieser Einstellung ist hilfreich für dezentrale Geschäftseinheiten, die einen eigenen Data Lake in Azure verwalten.

Gatewaysetup

Zum Herstellen einer Verbindung zu Datenquellen, die sich in einem privaten Organisationsnetzwerk oder in einem virtuellen Netzwerk befinden, ist normalerweise ein lokales Datengateway erforderlich.

Ein Datengateway ist in folgenden Fällen erforderlich:

• Erstellen eines Dataflows in Power Query Online, der eine Verbindung zu privaten Organisationsdaten herstellt.
• Aktualisieren eines Dataflows, der eine Verbindung zu privaten Organisationsdaten herstellt.

Tipp

Dataflows benötigen ein zentrales Datengateway im Standardmodus. Ein Gateway im persönlichen Modus wird bei der Verwendung von Dataflows nicht unterstützt.

Systemüberwachung

Das Aktivitätsprotokoll erfasst Benutzeraktivitäten, die im Power BI-Dienst stattfinden. Power BI-Administratoren können die erfassten Aktivitätsprotokolldaten für Auditzwecke verwenden, um Nutzungsmuster und Akzeptanz zu verstehen. Das Aktivitätsprotokoll ist auch für die Unterstützung von Governancebemühungen, Sicherheitsüberprüfungen und Complianceanforderungen von Nutzen. Im Szenario für die erweiterte Datenaufbereitung sind die Aktivitätsprotokolldaten hilfreich, um die Verwaltung und Verwendung von Dataflows nachzuverfolgen.

Zugehöriger Inhalt

Weitere nützliche Szenarios, die Ihnen bei Entscheidungen zur Power BI-Implementierung helfen können, finden Sie im Artikel Power BI-Verwendungsszenarios.