Share via

Verstehen und Optimieren der Aktualisierung von Dataflows

  • Artikel

Mit Power BI Dataflows können Sie Daten für nachfolgende Analysen verbinden, transformieren, kombinieren und verteilen. Ein Schlüsselelement in Dataflows ist der Aktualisierungsvorgang, der die Transformationsschritte anwendet, welche Sie in den Dataflows erstellt haben, und die Daten in den Elementen selbst aktualisiert.

Zum Verstehen von Ausführungszeiten, Leistung, und um zu erfahren, ob Sie Ihren Dataflow optimal nutzen, können Sie nach dem Aktualisieren eines Dataflows den Aktualisierungsverlauf herunterladen.

Grundlegendes zu Aktualisierungen

Es gibt zwei Arten von Aktualisierungen, die auf Dataflows anwendbar sind:

  • Vollständig, wobei eine vollständige Leerung und erneutes Laden Ihrer Daten erfolgt.

  • Inkrementell (nur Premium) , wobei eine Teilmenge der Daten auf der Grundlage von zeitbasierten Regeln verarbeitet wird, die Sie konfigurieren. Der Filter für die Datumsspalte partitioniert die Daten im Power BI-Dienst dynamisch in Bereiche. Nachdem Sie die inkrementelle Aktualisierung konfiguriert haben, ändert der Dataflow Ihre Abfrage automatisch dahingehend, dass der Filter nach Datum eingeschlossen wird. Sie können die automatisch generierte Abfrage mithilfe des Erweiterter Editor in Power Query bearbeiten, um Ihre Aktualisierung zu optimieren oder anzupassen. Wenn Sie Ihren eigenen Azure Data Lake Storage mitbringen, können Sie auf der Grundlage der von Ihnen festgelegten Aktualisierungsrichtlinie Zeit-Slices Ihrer Daten sehen.

    Hinweis

    Weitere Informationen zur inkrementellen Aktualisierung und deren Funktionsweise finden Sie unter Verwenden der inkrementellen Aktualisierung mit Dataflows.

Die inkrementelle Aktualisierung bietet in Power BI für sehr große Dataflows die folgenden Vorteile:

  • Nach der ersten Aktualisierung werden Aktualisierungen aufgrund der folgenden Fakten schneller ausgeführt:

    • Power BI aktualisiert die letzten N Partitionen, die vom Benutzer angegeben wurden (wobei Partition „Tag/Woche/Monat“ usw. ist), oder:
    • Power BI aktualisiert nur die Daten, die aktualisiert werden müssen. Beispielsweise werden nur die letzten fünf Tage eines zehn Jahre alten Semantikmodells aktualisiert.
    • Power BI aktualisiert nur geänderte Daten, sofern Sie die Spalte angeben, die Sie auf Änderungen überprüfen möchten.

  • Zuverlässigere Aktualisierungen — es ist nicht mehr notwendig, Verbindungen mit langer Ausführungsdauer mit flüchtigen Quellsystemen herzustellen.

  • Reduzierter Ressourcenverbrauch — dank weniger zu aktualisierender Daten wird der Gesamtbedarf an Arbeitsspeicher und anderen Ressourcen reduziert.

  • Wenn möglich, verwendet Power BI die parallele Verarbeitung von Partitionen, was ebenfalls zu schnelleren Aktualisierungen führen kann.

In keinem dieser Aktualisierungsszenarien werden die Daten aktualisiert, wenn bei einer Aktualisierung ein Fehler auftritt. Bis zum Abschluss der letzten Aktualisierung sind Ihre Daten möglicherweise veraltet, oder Sie können sie manuell aktualisieren, und dann kann der Vorgang ohne Fehler abgeschlossen werden. Die Aktualisierung erfolgt für eine Partition oder Entität. Wenn eine inkrementelle Aktualisierung fehlschlägt oder eine Entität einen Fehler aufweist, wird die gesamte Aktualisierungstransaktion nicht durchgeführt. Anders gesagt: Bei einem Fehler einer Partition (inkrementelle Aktualisierungsrichtlinie) oder Entität für einen Dataflow schlägt der gesamte Aktualisierungsvorgang fehl, und es werden keine Daten aktualisiert.

Verstehen und Optimieren von Aktualisierungen

Damit Sie besser verstehen, wie ein Dataflow-Aktualisierungsvorgang durchgeführt wird, überprüfen Sie den Aktualisierungsverlauf für den Dataflow, indem Sie zu einem Ihrer Dataflows navigieren. Wählen Sie Weitere Optionen (...) für den Dataflow aus. Wählen Sie dann Einstellungen > Aktualisierungsverlauf aus. Sie können auch den Dataflow im Arbeitsbereich auswählen. Wählen Sie dann Weitere Optionen (...) > Aktualisierungsverlauf aus.

Screenshot of dataflows refresh history.

Der Aktualisierungsverlauf bietet einen Überblick über Aktualisierungen, einschließlich des Typs – Nach Bedarf oder geplant, der Dauer und des Ausführungszustands. Um Details in Form einer CSV-Datei anzuzeigen, wählen Sie das Download-Symbol ganz rechts in der Zeile der Aktualisierungsbeschreibung aus. Das heruntergeladene CSV enthält die in der folgenden Tabelle beschriebenen Attribute. Premium-Aktualisierungen bieten weitere Informationen, die auf den zusätzlichen Compute- und Dataflow-Funktionen basieren, im Vergleich zu Pro-basierten Dataflows, die sich in gemeinsam genutzter Kapazität befinden. Daher sind einige der folgenden Metriken nur in Premium verfügbar.

Element Beschreibung Pro Premium
Requested on (Angefordert am) Es wurde Zeitaktualisierung geplant, oder es wurde auf „Jetzt aktualisieren“ geklickt, in Ortszeit ✔ ✔
Name des Dataflow Name Ihres Dataflow. ✔ ✔
Aktualisierungszustand des Dataflow „Abgeschlossen“, „Fehlgeschlagen“ oder „Übersprungen“ (für eine Entität) sind mögliche Zustände. Anwendungsfälle wie verknüpfte Entitäten sind Gründe, warum „Übersprungen“ angezeigt werden kann. ✔ ✔
Name der Entität Tabellenname. ✔ ✔
Partitionsname Dieses Element hängt davon ab, ob es sich um einen Premium-Dataflow handelt und ob Pro als N/V angezeigt wird, da es keine inkrementellen Aktualisierungen unterstützt. Premium zeigt entweder „FullRefreshPolicyPartition“ oder „IncrementalRefreshPolicyPartition-[DateRange]“ an. ✔
Aktualisierungszustand Aktualisierungszustand der einzelnen Entität oder Partition, die den Status für diesen Zeit-Slice der zu aktualisierenden Daten bereitstellt. ✔ ✔
Startzeit In Premium ist dieses Element der Zeitpunkt, zu dem der Dataflow zur Verarbeitung für die Entität oder Partition in die Warteschlange eingereiht wurde. Diese Zeit kann abweichen, wenn Dataflows Abhängigkeiten aufweisen und warten müssen, bis die Verarbeitung des Resultsets eines vorhergehenden Dataflow begonnen hat. ✔ ✔
Endzeit Die Endzeit ist der Zeitpunkt, zu dem die Dataflow-Entität oder -Partition abgeschlossen wurde, falls zutreffend. ✔ ✔
Duration Insgesamt verstrichene Zeit für die Aktualisierung des Dataflow in HH:MM:SS. ✔ ✔
Verarbeitete Zeilen Für eine bestimmte Entität oder Partition die Anzahl der Zeilen, die von der Dataflow-Engine gescannt oder geschrieben wurden. Dieses Element enthält möglicherweise nicht immer Daten, die auf dem ausgeführten Vorgang basieren. Daten werden möglicherweise ausgelassen, wenn die Compute-Engine nicht verwendet wird oder Sie ein Gateway verwenden, da die Daten dort verarbeitet werden. ✔
Verarbeitete Byte Für eine bestimmte Entität oder Partition werden die von der Dataflow-Engine geschriebenen Daten in Byte ausgedrückt.

Beachten Sie, dass bei Verwendung eines Gateways für diesen bestimmten Dataflow diese Informationen nicht bereitgestellt werden.		 ✔
Max. Commit (KB) Der maximale Commit ist der Hauptzeit-Commit-Speicher, der für die Diagnose von Fehlern bei nicht genügend Arbeitsspeicher hilfreich ist, wenn die M-Abfrage nicht optimiert ist.

Beachten Sie, dass bei Verwendung eines Gateways für diesen bestimmten Dataflow diese Informationen nicht bereitgestellt werden.		 ✔
Prozessorzeit Für eine bestimmte Entität oder Partition wird die Zeit in HH:MM:SS ausgedrückt, welche die Datenflow-Engine für die Durchführung von Transformationen aufgewendet hat.

Beachten Sie, dass bei Verwendung eines Gateways für diesen bestimmten Dataflow diese Informationen nicht bereitgestellt werden.		 ✔
Wartezeit Für eine bestimmte Entität oder Partition die Zeit, die eine Entität für den Wartezustand aufgewendet hat, basierend auf der Workload der Premium-Kapazität. ✔
Compute-Engine Für eine bestimmte Entität oder Partition Details zur Verwendung der Compute-Engine beim Aktualisierungsvorgang. Die Werte sind:
- NA
- Gefaltet
- Zwischengespeichert
- Zwischengespeichert + gefaltet

Diese Elemente werden weiter unten in diesem Artikel ausführlicher beschrieben.		 ✔
Fehler Falls zutreffend, wird die ausführliche Fehlermeldung pro Entität oder Partition beschrieben. ✔ ✔

Leitfaden zur Dataflow-Aktualisierung

Die Aktualisierungsstatistik bietet wertvolle Informationen, die Sie verwenden können, um die Leistung Ihrer Dataflows zu optimieren und zu beschleunigen. In den folgenden Abschnitten werden einige Szenarien beschrieben, was Sie beobachten sollten und wie Sie anhand der bereitgestellten Informationen optimieren können.

Orchestrierung

Die Verwendung von Dataflows im gleichen Arbeitsbereich ermöglicht eine einfache Orchestrierung. Wenn Sie beispielsweise die Datenflüsse A, B und C in einem einzelnen Arbeitsbereich haben und eine Verkettung wie A > B > C, werden die nachfolgenden Entitäten ebenfalls aktualisiert, wenn Sie die Quelle (A) aktualisieren. Wenn Sie jedoch C aktualisieren, müssen Sie die anderen unabhängig aktualisieren. Wenn Sie Dataflow B eine neue Datenquelle hinzufügen (die nicht in A enthalten ist), werden diese Daten ebenfalls nicht im Rahmen der Orchestrierung aktualisiert.

Es kann sinnvoll sein, Elemente zu verketten, die nicht zur verwalteten Orchestrierung von Power BI passen. In diesen Szenarien können Sie die APIs und/oder Power Automate verwenden. Informationen zur programmgesteuerten Aktualisierung finden Sie in der API-Dokumentation und im PowerShell-Skript. Es gibt einen Power Automate-Connector, der diesen Vorgang ermöglicht, ohne dass Sie dazu Code schreiben müssten. Ausführliche Beispielemit speziellen exemplarischen Vorgehensweisen finden Sie unter sequenzielle Aktualisierungen.

Überwachung

Mithilfe der erweiterten Aktualisierungsstatistik, die weiter oben in diesem Artikel beschrieben wurde, können Sie detaillierte Informationen zu Datenflow-Aktualisierungen erhalten. Wenn Sie jedoch Datenflows mit einer Mandanten- oder Arbeitsbereichs-weiten Übersicht über Aktualisierungen sehen möchten, können Sie zum Erstellen eines Überwachungs-Dashboards die APIs oder PowerAutomate-Vorlagenverwenden. Entsprechend können Sie für Anwendungsfälle wie das Senden von einfachen oder komplexen Benachrichtigungen den PowerAutomate-Connector verwenden oder Ihre eigene benutzerdefinierte Anwendung mithilfe der APIs erstellen.

Timeoutfehler

Die Optimierung der Zeit, die zum Ausführen von Extraktions-, Transformations- und Ladeszenarien erforderlich ist, ist ideal. In Power BI gelten die folgenden Fälle:

  • Einige Konnectoren verfügen über explizite Timeouteinstellungen, die Sie konfigurieren können. Weitere Informationen finden Sie unter Connectors in Power Query.
  • Power BI-Dataflows mit Power BI Pro durchlaufen möglicherweise selbst auch Timeouts für Abfragen mit langer Laufzeit innerhalb einer Entität oder eines Datenflow. Diese Einschränkung ist in Power BI Premium-Arbeitsbereichen nicht vorhanden.

Timeout-Leitfaden

Dies sind die Timeout-Schwellenwerte für Power BI Pro-Dataflows:

  • Zwei Stunden für die Ebene der einzelnen Identitäten
  • Drei Stunden für die gesamte Dataflowebene

Bei einem Dataflow mit drei Tabellen kann beispielsweise keine einzelne Tabelle mehr als zwei Stunden in Anspruch nehmen, und für den gesamten Datenflow tritt ein Timeout auf, wenn die Dauer drei Stunden überschreitet.

Wenn Timeouts auftreten, sollten Sie die Optimierung der Dataflow-Abfragen und die Verwendung von Query Folding auf Ihren Quellsystemen in Erwägung ziehen.

Ziehen Sie unabhängig davon ein Upgrade auf die Premium-Einzelbenutzerlizenz in Erwägung, die diesen Timeouts nicht unterliegt und die aufgrund vieler Features der Power BI Premium-Einzelbenutzerlizenz eine bessere Leistung bietet.

Lange Dauer

Komplexe oder große Dataflows können für die Aktualisierung mehr Zeit in Anspruch nehmen, was auch auf unzureichend optimierte Datenflows zutrifft. In den folgenden Abschnitten wird erläutert, wie ein lange Aktualisierungsdauer verringert wird.

Leitfaden für lange Aktualisierungsdauer

Der erste Schritt zum Verbessern der langen Aktualisierungsdauer für Dataflows ist das Erstellen von Dataflows gemäß den bewährten Methoden. Zu den relevanten Mustern gehören:

Als nächstes können Sie auswerten, ob Sie die inkrementelle Aktualisierung verwenden können.

Die Verwendung einer inkrementellen Aktualisierung kann die Leistung verbessern. Es ist wichtig, dass die Partitionsfilter per Push an das Quellsystem übertragen werden, wenn Abfragen für Aktualisierungsvorgänge übermittelt werden. Das Filtern nach unten durchzusetzen bedeutet, dass die Datenquelle, die Abfragefaltung unterstützen sollte, oder Sie können Geschäftslogik über eine Funktion oder andere Mittel ausdrücken, die Power Query eliminieren und das Filtern von Dateien oder Ordnern unterstützen können. Die meisten Datenquellen, die SQL-Abfragen unterstützen, unterstützen das Falten von Abfragen, und einige OData-Feeds können auch das Filtern unterstützen.

Datenquellen wie Flatfiles, Blobs und APIs unterstützen das Filtern in der Regel nicht. In Fällen, in denen das Datenquellen-Back-End den Filter nicht unterstützt, kann er nicht nach unten verschoben werden. Diese Fälle werden von der Mashup-Engine ausgeglichen, die den Filter lokal anwendet. Es kann sein, dass dafür das komplette Semantikmodell von der Datenquelle abgerufen werden muss. Durch diesen Vorgang kann die inkrementelle Aktualisierung verlangsamt werden, und es kann sein, dass dem Prozess im Power BI-Dienst oder im lokalen Datengateway nicht ausreichend Ressourcen zur Verfügung stehen.

In Anbetracht des unterschiedlichen Maßes an Unterstützung für Query Folding für die einzelnen Datenquellen sollte eine Überprüfung durchgeführt werden, um sicherzustellen, dass die Filterlogik in die Quellabfragen eingeschlossen wurde. Um dies zu vereinfachen, versucht Power BI, diese Überprüfung für Sie durchzuführen, mit Schrittfaltungsindikatoren für Power Query Online. Viele dieser Optimierungen sind Entwurfszeit-Erfahrungen, aber nach einer Aktualisierung haben Sie die Möglichkeit, die Aktualisierungsleistung zu analysieren und zu optimieren.

Zum Schluss sollten Sie Ihre Umgebung optimieren. Sie können die Power BI-Umgebung optimieren, indem Sie Ihre Kapazität zentral hochskalieren, die Größe der Daten-Gateways anpassen und die Netzwerklatenz durch die folgenden Optimierungen verringern:

  • Wenn Sie Kapazitäten verwenden, die mit Power BI Premium oder Premium pro Benutzer zur Verfügung stehen, können Sie die Leistung steigern, indem Sie Ihre Premium-Instanz erhöhen oder den Inhalt einer anderen Kapazität zuweisen.

  • Ein Gateway ist immer dann erforderlich, wenn Power BI Zugriff auf Daten benötigt, die nicht direkt über das Internet zugänglich sind. Sie können das lokale Datengateway auf einem lokalen Server oder auf einem virtuellen Computer installieren.

    • Empfehlungen zu Gatewayworkloads und zur Festlegung der Größe finden Sie unter Festlegen der Größe des lokalen Datengateways.
    • Evaluieren Sie auch, ob Sie die Daten zunächst in einen Staging-Dataflow einbringen und sie mithilfe von verknüpften und berechneten Entitäten auf nachfolgende Bereiche verweisen.

  • Die Netzwerklatenz kann die Abfrageleistung beeinträchtigen, wenn es länger dauert, bis Anforderungen den Power BI-Dienst erreichen und Antworten übermittelt werden. Mandanten in Power BI werden einer bestimmten Region zugewiesen. Informationen dazu, wo sich Ihr Mandant befindet, finden Sie unter Bestimmen der Standardregion für Ihre Organisation. Wenn Benutzer von einem Mandanten aus auf den Power BI-Dienst zugreifen, werden ihre Anforderungen immer an diese Region weitergeleitet. Wenn die Anforderungen den Power BI-Dienst erreichen, sendet der Dienst möglicherweise zusätzliche Anforderungen (z. B. an die zugrunde liegende Datenquelle oder ein Datengateway), die ebenfalls der Netzwerklatenz unterliegen.

    • Tools wie Azure Speed Test bieten einen Überblick über die Netzwerklatenz zwischen dem Client und der Azure-Region. Im Allgemeinen sollten sich, um die Auswirkungen der Netzwerklatenz zu minimieren, Datenquellen, Gateways und der Power BI-Cluster in möglichst großer Nähe zueinander befinden. Vorzugsweise sollten sie sich in derselben Region befinden. Wenn die Netzwerklatenz ein Problem darstellt, versuchen Sie, Gateways und Datenquellen näher an Ihrem Power BI-Cluster anzuordnen, indem Sie sie auf in der Cloud gehosteten VMs platzieren.

Hohe Prozessorzeit

Wenn Sie eine hohe Prozessorzeit feststellen, nutzen Sie wahrscheinlich teure Transformationen, die nicht gefaltet werden. Die hohe Prozessorzeit liegt entweder an der Anzahl der angewendeten Schritte oder an der Art der Transformationen, die Sie vornehmen. Jede dieser Möglichkeiten kann zu längeren Aktualisierungszeiten führen.

Leitfaden für hohe Prozessorzeit

Es gibt zwei Optionen, um eine hohe Prozessorzeit zu optimieren.

Verwenden Sie zunächst Query Folding in der Datenquelle selbst, wodurch die Auslastung der Dataflow-Compute-Engine direkt reduziert werden sollte. Query Folding innerhalb der Datenquelle ermöglicht es dem Quellsystem, den größten Teil der Arbeit zu erledigen. Der Dataflow kann dann Abfragen in der nativen Sprache der Quelle durchlaufen, statt alle Berechnungen nach der ursprünglichen Abfrage im Arbeitsspeicher ausführen zu müssen.

Nicht alle Datenquellen können Query Folding ausführen, und auch wenn Query Folding dort möglich ist, können einzelne Dataflows bestimmte Transformationen durchführen, für die keine Faltung in der Quelle möglich ist. In solchen Fällen bietet sich die Erweiterte Compute-Engine an, eine von Power BI eingeführte Funktion, mit der die Leistung möglicherweise bis zu 25fach verbessert wird, speziell für Transformationen.

Verwenden der Compute-Engine zum Maximieren der Leistung

Zwar bietet Power Query für Query Folding Sichtbarkeit zur Entwurfszeit, trotzdem bietet die Spalte „Compute-Engine“ Details dazu, ob die eigentliche interne Engine verwendet wird. Die Compute-Engine ist nützlich, wenn Sie über einen komplexen Dataflow verfügen und Transformationen im Arbeitsspeicher ausführen. In dieser Situation kann die erweiterte Aktualisierungsstatistik hilfreich sein, da die Spalte „Compute-Engine“ Informationen dazu liefert, ob die Engine selbst verwendet wurde.

Die folgenden Abschnitte enthalten Anleitungen zur Verwendung der Compute-Engine und ihrer Statistiken.

Warnung

Zur Entwurfszeit zeigt der Faltungsindikator im Editor möglicherweise an, dass die Abfrage nicht gefaltet wird, wenn Daten aus einem anderen Dataflow genutzt werden. Prüfen Sie den Quelldataflow, wenn die erweiterte Compute-Engine aktiviert ist, um sicherzustellen, dass die Faltung des Quelldataflows aktiviert ist.

Leitfaden zu Compute-Engine-Zuständen

Das Aktivieren der erweiterten Compute-Engine und das Verständnis der verschiedenen Zustände sind nützlich. Intern verwendet die erweiterte Compute-Engine eine SQL-Datenbank, um Daten zu lesen und zu speichern. Es ist am besten, dass Ihre Transformationen an dieser Stelle für die Abfrage-Engine ausgeführt werden. In den folgenden Abschnitten werden verschiedene Situationen und Anleitungen zu den einzelnen Aktionen bereitgestellt.

N/V: Dieser Status bedeutet, dass die Compute-Engine nicht verwendet wurde, aus einem der folgenden Gründe:

  • Sie verwenden Power BI Pro-Dataflows
  • Sie haben die Compute-Engine explizit deaktiviert
  • Sie verwenden Query Folding in der Datenquelle
  • Sie führen komplexe Transformationen durch, die die SQL-Engine nicht zum Beschleunigen von Abfragen nutzen können.

Wenn Sie eine lange Dauer haben und weiterhin den Zustand N/V erhalten, vergewissern Sie sich, dass sie Eingeschaltet ist und nicht versehentlich ausgeschaltet wurde. Ein empfohlenes Muster besteht darin, die Daten zunächst mithilfe von Staging-Dataflows in den Power BI-Dienst zu übernehmen und dann Dataflows auf der Grundlage dieser Daten zu erstellen, nachdem sie sich in einem Staging-Dataflow befinden. Dieses Muster kann die Auslastung von Quellsystemen verringern und in Verbindung mit der Compute-Engine schnellere Transformationen und eine gesteigerte Leistung bieten.

Zwischengespeichert: Wenn der Status Zwischengespeichert angezeigt wird, wurden die Dataflow-Daten in der Compute-Engine gespeichert und können als Teil einer anderen Abfrage referenziert werden. Diese Situation ist ideal, wenn Sie sie als verknüpfte Entität verwenden, da die Compute-Engine diese Daten zur Verwendung im Downstream zwischenspeichert. Die zwischengespeicherten Daten müssen nicht mehrmals im selben Dataflow aktualisiert werden. Diese Situation ist potenziell ebenfalls ideal, wenn Sie sie für DirectQuery verwenden möchten.

Beim Zwischenspeichern zahlen sich die Auswirkungen auf die Leistung bei der anfänglichen Erfassung später in demselben Dataflow oder in einem anderen Dataflow im gleichen Arbeitsbereich aus.

Wenn Sie für die Entität eine lange Dauer haben, sollten Sie die Compute-Engine ausschalten. Zum Zwischenspeichern der Entität wird Sie von Power BI in den Speicher und in SQL geschrieben. Wenn es sich um eine nur ein Mal verwendete Entität handelt, lohnt sich der Leistungsvorteil für Benutzer angesichts der Beeinträchtigung aufgrund er doppelten Datenerfassung möglicherweise nicht.

Gefaltet: Gefaltet bedeutet, dass der Dataflow SQL-Compute zum Lesen von Daten verwenden konnte. Die berechnete Entität hat die Tabelle aus SQL verwendet, um Daten zu lesen, und die verwendete SQL-Datenbank bezieht sich auf die Konstrukte Ihrer Abfrage.

Der Status „Gefaltet“ wird angezeigt, wenn Sie bei der Verwendung von lokalen oder Cloud-Datenquellen zuerst Daten in einen Staging-Dataflow geladen haben und in diesem Datenfluss darauf verwiesen wird. Dieser Status gilt nur für Entitäten, die auf eine andere Entität verweisen. Es bedeutet, dass Ihre Abfragen auf der SQL-Engine ausgeführt werden und daher mit SQL Compute verbessert werden können. Um sicherzustellen, dass ihre Transformationen von der SQL-Engine verarbeitet werden, verwenden Sie Transformationen, die SQL Folding unterstützen, wie z. B. die Aktionen Merge (Zusammenführen), Gruppieren nach (Gruppierung) und Anfügen (Verknüpfung) im Query-Editor.

Zwischengespeichert und gefaltet: Wenn Zwischengespeichert und gefaltet angezeigt wird, ist es wahrscheinlich, dass die Datenaktualisierung optimiert wurde, da Sie über eine Entität verfügen, die zum einen auf eine andere Entität verweist und auf die zum anderen von einer anderen vorhergehenden Entität verwiesen wird. Dieser Vorgang wird auch auf der Grundlage von SQL ausgeführt und kann daher potenziell ebenfalls mit SQL-Compute verbessert werden. Um sicherzustellen, dass Sie die beste Leistung erzielen, verwenden Sie Transformationen, die SQL-Falten unterstützen, wie z. B. die Aktionen Mergen (Zusammenführen), Gruppieren nach (Gruppierung) und Anfügen (Verknüpfung) im Query-Editor.

Leitfaden zur Leistungsoptimierung der Compute-Engine

Mithilfe der folgenden Schritte können Workloads die Compute-Engine auslösen, wodurch sich immer eine verbesserte Leistung ergibt.

Berechnete und verknüpfte Entitäten im selben Arbeitsbereich:

Legen Sie den Fokus für die Datenerfassung darauf, die Daten schnellstmöglich in den Speicher zu laden. Verwenden Sie dazu nur dann Filter, wenn sie die Gesamtgröße des Semantikmodell reduzieren. Behalten Sie die von diesem Schritt getrennte Transformationslogik bei. Trennen Sie als Nächstes Ihre Transformations- und Geschäftslogik in einen separaten Dataflow im selben Arbeitsbereich. Verwenden Sie verknüpfte oder berechnete Entitäten. Dadurch kann die Engine Ihre Berechnungen aktivieren und beschleunigen. Als einfache Analogie kann das mit der Lebensmittelvorbereitung in der Küche verglichen werden: Bei der Essensvorbereitung handelt es sich in der Regel um einen eigenen Schritt, der nach dem Zusammensammeln der rohen Zutaten erfolgt. Außerdem ist sie eine Voraussetzung dafür, die Lebensmittel in den Ofen schieben zu können. Analog dazu müssen Sie Ihre Logik separat vorbereiten, damit sie die Vorteile der Compute-Engine nutzen kann.

Sorgen Sie dafür, dass die Vorgänge, für die ein Folding durchgeführt wird, ausgeführt werden, z. B. Merge-Vorgänge, Joins, Konvertierungen und andere.

Bei diesem Schritt werden Dataflows innerhalb von veröffentlichten Richtlinien und Einschränkungen erstellt.

Die Compute-Engine ist eingeschaltet, aber die Leistung ist schwach:

Führen Sie die folgenden Schritte aus, wenn Sie Szenarien untersuchen, in denen die Compute-Engine aktiviert ist, die Leistung jedoch schwach ist:

  • Beschränken Sie berechnete und verknüpfte Entitäten, die Arbeitsbereich-übergreifend vorhanden sind.
  • Wenn Sie zuerst einen Aktualisierungsvorgang mit aktivierter Compute-Engine durchführen, werden die Daten in den Data Lake und in den Cache geschrieben. Dieser doppelte Schreibvorgang führt dazu, dass Aktualisierungen langsamer werden.
  • Wenn ein Dataflow mit mehreren Dataflows verknüpft ist, sollten Sie dafür sorgen, dass Sie Aktualisierungen für die Quelldataflows so planen, dass die Aktualisierungen nicht alle zur selben Zeit durchgeführt werden.

Überlegungen und Einschränkungen

Für eine Power BI Pro-Lizenz gilt ein Grenzwert für Dataflowaktualisierungen von 8 Aktualisierungen pro Tag.

Zugehöriger Inhalt