DirectQuery in Power BI

In Power BI Desktop oder dem Power BI-Dienst können Sie auf unterschiedliche Weise eine Verbindung mit vielen verschiedenen Datenquellen herstellen. Sie können Daten in Power BI importieren , was die am häufigsten verwendete Methode zum Abrufen von Daten ist. Sie können auch eine direkte Verbindung mit einigen Daten im ursprünglichen Quellrepository herstellen, das als DirectQuery bezeichnet wird. In diesem Artikel werden in erster Linie DirectQuery-Funktionen erläutert.

Dieser Artikel beschreibt Folgendes:

  • Die verschiedenen Power BI-Datenkonnektivitätsoptionen.
  • Anleitungen zur Verwendung von DirectQuery anstelle des Imports.
  • Einschränkungen und Auswirkungen der Verwendung von DirectQuery.
  • Empfehlungen für die erfolgreiche Verwendung von DirectQuery.
  • Diagnostizieren von DirectQuery-Leistungsproblemen

Der Artikel konzentriert sich auf den DirectQuery-Workflow, wenn Sie einen Bericht in Power BI Desktop erstellen, aber auch die Verbindung über DirectQuery im Power BI-Dienst.

Hinweis

DirectQuery ist auch ein Feature von SQL Server Analysis Services. Dieses Feature teilt viele Details mit Direct Query in Power BI, aber es gibt auch wichtige Unterschiede. In diesem Artikel wird in erster Linie DirectQuery mit Power BI behandelt, nicht SQL Server Analysis Services.

Weitere Informationen zur Verwendung von DirectQuery mit SQL Server Analysis Services finden Sie unter Verwenden von DirectQuery für Power BI-Datasets und Analysis Services (Vorschau). Sie können die PDF DirectQuery auch in SQL Server 2016 Analysis Services herunterladen.

Power BI-Datenkonnektivitätsmodi

Power BI stellt eine Verbindung mit einer großen Anzahl unterschiedlicher Datenquellen bereit, z. B.:

  • Onlinedienste wie Salesforce und Dynamics 365.
  • Datenbanken wie SQL Server, Access und Amazon Redshift.
  • Einfache Dateien in Excel, JSON und anderen Formaten.
  • Andere Datenquellen wie Spark, Websites und Microsoft Exchange.

Sie können Daten aus diesen Quellen in Power BI importieren. Für einige Quellen können Sie auch eine Verbindung mit DirectQuery herstellen. Eine Zusammenfassung der Quellen, die DirectQuery unterstützen, finden Sie unter Von DirectQuery unterstützte Datenquellen. DirectQuery-fähige Quellen sind in erster Linie Quellen, die eine gute interaktive Abfrageleistung liefern können.

Sie sollten Daten nach Möglichkeit in Power BI importieren. Der Import nutzt die leistungsstarke Abfrage-Engine von Power BI und bietet eine hochgradig interaktive, voll ausgestattete Oberfläche.

Wenn Sie Ihre Ziele nicht erreichen können, indem Sie Daten importieren, z. B. wenn sich die Daten häufig ändern und Berichte die neuesten Daten widerspiegeln müssen, erwägen Sie die Verwendung von DirectQuery. DirectQuery ist nur möglich, wenn die zugrunde liegende Datenquelle interaktive Abfrageergebnisse in weniger als fünf Sekunden für eine typische Aggregatabfrage bereitstellen und die generierte Abfragelast verarbeiten kann. Berücksichtigen Sie sorgfältig die Einschränkungen und Auswirkungen der Verwendung von DirectQuery.

Power BI-Import- und DirectQuery-Funktionen werden im Laufe der Zeit weiterentwickelt. Änderungen, die mehr Flexibilität bei der Verwendung importierter Daten bieten, ermöglichen das Importieren häufiger und beseitigen einige der Nachteile der Verwendung von DirectQuery. Unabhängig von Verbesserungen ist die Leistung der zugrunde liegenden Datenquelle ein wichtiger Aspekt bei der Verwendung von DirectQuery. Wenn eine zugrunde liegende Datenquelle langsam ist, bleibt die Verwendung von DirectQuery für diese Quelle nicht durchführbar.

In den folgenden Abschnitten werden die drei Optionen zum Herstellen einer Verbindung mit Daten behandelt: Import, DirectQuery und Liveverbindung. Der rest des Artikels konzentriert sich auf DirectQuery.

Importieren von Verbindungen

Wenn Sie eine Verbindung mit einer Datenquelle wie SQL Server herstellen und Daten in Power BI Desktop importieren, treten die folgenden Ergebnisse auf:

  • Beim anfänglichen Abrufen von Daten definiert jeder ausgewählte Tabellensatz eine Abfrage, die einen Satz von Daten zurückgibt. Sie können diese Abfragen vor dem Laden der Daten bearbeiten, z. B. um Filter anzuwenden, die Daten zu aggregieren oder verschiedene Tabellen zu verknüpfen.

  • Beim Laden werden alle durch die Abfragen definierten Daten in den Power BI-Cache importiert.

  • Beim Erstellen eines Visuals in Power BI Desktop werden die zwischengespeicherten Daten abgefragt. Der Power BI-Speicher stellt sicher, dass die Abfrage schnell ist und dass alle Änderungen am Visual sofort widerspiegelt werden.

  • Visuals spiegeln keine Änderungen an den zugrunde liegenden Daten im Datenspeicher wider. Sie müssen erneut importieren, um die Daten zu aktualisieren.

  • Beim Veröffentlichen des Berichts im Power BI-Dienst als PBIX-Datei wird ein Dataset erstellt und hochgeladen, das die importierten Daten enthält. Sie können dann die Datenaktualisierung planen, z. B. die Daten täglich erneut importieren. Abhängig vom Speicherort der ursprünglichen Datenquelle kann es erforderlich sein, ein lokales Datengateway für die Aktualisierung zu konfigurieren.

  • Beim Öffnen eines vorhandenen Berichts oder beim Erstellen eines neuen Berichts im Power BI-Dienst werden die importierten Daten erneut abfragt, um die Interaktivität zu gewährleisten.

  • Sie können Visuals oder ganze Berichtsseiten als Dashboardkacheln im Power BI-Dienst anheften. Die Kacheln werden automatisch aktualisiert, sobald das zugrunde liegende Dataset aktualisiert wird.

DirectQuery-Verbindungen

Wenn Sie DirectQuery verwenden, um eine Verbindung mit einer Datenquelle in Power BI Desktop herzustellen, treten die folgenden Ergebnisse auf:

  • Sie verwenden Daten abrufen , um die Quelle auszuwählen. Für relationale Quellen können Sie weiterhin eine Gruppe von Tabellen auswählen, die eine Abfrage definieren, die einen Satz von Daten logisch zurückgibt. Für mehrdimensionale Quellen wie SAP Business Warehouse (SAP BW) wählen Sie nur die Quelle aus.

  • Beim Laden werden keine Daten in den Power BI-Speicher importiert. Wenn Sie stattdessen ein Visual erstellen, sendet Power BI Desktop Abfragen an die zugrunde liegende Datenquelle, um die erforderlichen Daten abzurufen. Die zum Aktualisieren des Visuals benötigte Zeit hängt von der Leistung der zugrunde liegenden Datenquelle ab.

  • Alle Änderungen an den zugrunde liegenden Daten werden nicht sofort in vorhandenen Visuals widerzuspiegeln. Eine Aktualisierung ist trotzdem erforderlich. Power BI Desktop die erforderlichen Abfragen für jedes Visual erneut senden und das Visual nach Bedarf aktualisiert.

  • Beim Veröffentlichen des Berichts im Power BI-Dienst wird ein Dataset erstellt und hochgeladen, wie beim Import. Dieses Dataset enthält jedoch keine Daten.

  • Beim Öffnen eines vorhandenen Berichts oder beim Erstellen eines neuen Berichts im Power BI-Dienst wird die zugrunde liegende Datenquelle abgefragt, um die erforderlichen Daten abzurufen. Abhängig vom Speicherort der ursprünglichen Datenquelle kann es erforderlich sein, ein lokales Datengateway zu konfigurieren, um die Daten abzurufen.

  • Sie können Visuals oder ganze Berichtsseiten als Dashboardkacheln anheften. Um sicherzustellen, dass das Öffnen eines Dashboards schnell erfolgt, werden die Kacheln automatisch nach einem Zeitplan aktualisiert, z. B. stündlich. Sie können die Aktualisierungshäufigkeit abhängig davon steuern, wie häufig sich die Daten ändern und wie wichtig es ist, die neuesten Daten anzuzeigen.

  • Wenn Sie ein Dashboard öffnen, spiegeln die Kacheln die Daten zum Zeitpunkt der letzten Aktualisierung wider, nicht unbedingt die letzten Änderungen, die an der zugrunde liegenden Quelle vorgenommen wurden. Sie können ein geöffnetes Dashboard aktualisieren, um sicherzustellen, dass es aktuell ist.

Liveverbindungen

Wenn Sie eine Verbindung mit SQL Server Analysis Services herstellen, können Sie die Daten importieren oder eine Liveverbindung mit dem ausgewählten Datenmodell verwenden. Die Verwendung einer Liveverbindung ist ähnlich wie DirectQuery. Es werden keine Daten importiert, und die zugrunde liegende Datenquelle wird abgefragt, um Visuals zu aktualisieren.

Wenn Sie beispielsweise import verwenden, um eine Verbindung mit SQL Server Analysis Services herzustellen, definieren Sie eine Abfrage für die externe SQL Server Analysis Services Quelle und importieren die Daten. Wenn Sie eine Liveverbindung herstellen, definieren Sie keine Abfrage, und das gesamte externe Modell wird in der Feldliste angezeigt.

Diese Situation gilt auch, wenn Sie eine Verbindung mit den folgenden Quellen herstellen, es sei denn, es gibt keine Option zum Importieren der Daten:

  • Power BI-Datasets, z. B. eine Verbindung mit einem Bereits im Dienst veröffentlichten Power BI-Dataset, um einen neuen Bericht darüber zu erstellen.

  • Microsoft Dataverse

Wenn Sie SQL Server Analysis Services Berichte veröffentlichen, die Liveverbindungen verwenden, ähnelt das Verhalten in der Power BI-Dienst den DirectQuery-Berichten auf folgende Weise:

  • Wenn Sie einen vorhandenen Bericht öffnen oder einen neuen Bericht im Power BI-Dienst erstellen, wird die zugrunde liegende SQL Server Analysis Services Quelle abgefragt, sodass möglicherweise ein lokales Datengateway erforderlich ist.

  • Dashboardkacheln werden automatisch nach einem Zeitplan aktualisiert, z. B. stündlich.

Eine Liveverbindung unterscheidet sich auch in verschiedener Hinsicht von DirectQuery. Beispielsweise übergeben Liveverbindungen immer die Identität des Benutzers, der den Bericht öffnet, an die zugrunde liegende SQL Server Analysis Services Quelle.

DirectQuery-Anwendungsfälle

Das Herstellen einer Verbindung mit DirectQuery kann in den folgenden Szenarien hilfreich sein. In einigen dieser Fälle ist es erforderlich oder vorteilhaft, die Daten an ihrem ursprünglichen Quellspeicherort zu belassen.

DirectQuery in Power BI bietet in den folgenden Szenarien die größten Vorteile:

  • Die Daten ändern sich häufig, und Sie benötigen eine Berichterstellung nahezu in Echtzeit.
  • Sie müssen große Daten verarbeiten, ohne vorab aggregieren zu müssen.
  • Die zugrunde liegende Quelle definiert und wendet Sicherheitsregeln an.
  • Einschränkungen der Datensouveränität gelten.
  • Die Quelle ist eine multidimensionale Quelle mit Measures, z. B. SAP BW.

Daten werden häufig geändert, und Sie benötigen eine Berichterstellung nahezu in Echtzeit.

Sie können Modelle mit importierten Daten höchstens einmal pro Stunde aktualisieren, häufiger mit Power BI Pro oder Power BI Premium Abonnements. Wenn sich die Daten ständig ändern und Berichte die neuesten Daten anzeigen müssen, erfüllt die Verwendung von Import mit geplanter Aktualisierung möglicherweise nicht Ihre Anforderungen. Sie können Daten direkt in Power BI streamen, obwohl für diesen Fall Grenzwerte für die unterstützten Datenvolumes gelten.

Die Verwendung von DirectQuery bedeutet, dass beim Öffnen oder Aktualisieren eines Berichts oder Dashboards immer die neuesten Daten in der Quelle angezeigt werden. Die Dashboardkacheln können auch häufiger aktualisiert werden, so oft wie alle 15 Minuten.

Die Datenmenge ist sehr groß

Wenn die Daten sehr groß sind, ist es nicht möglich, alle daten zu importieren. DirectQuery erfordert keine große Übertragung von Daten, da daten direkt abfragt werden. Große Daten können jedoch auch die Leistung von Abfragen für diese zugrunde liegende Quelle zu langsam machen.

Sie müssen nicht immer vollständige Detaildaten importieren. Die Power Query-Editor erleichtert das Vorabaggregieren von Daten während des Imports. Technisch gesehen ist es möglich, genau die aggregierten Daten zu importieren, die Sie für jedes Visual benötigen. Obwohl DirectQuery der einfachste Ansatz für große Daten ist, kann das Importieren von aggregierten Daten eine Lösung bieten, wenn die zugrunde liegende Datenquelle für DirectQuery zu langsam ist.

Diese Details beziehen sich auf die Verwendung von Power BI allein. Weitere Informationen zum Verwenden von großen Modellen in Power BI finden Sie unter Große Datasets in Power BI Premium. Es gibt keine Einschränkung, wie oft die Daten aktualisiert werden können.

Die zugrunde liegende Quelle definiert Sicherheitsregeln.

Wenn Sie Daten importieren, stellt Power BI eine Verbindung mit der Datenquelle her, indem die anmeldeinformationen des aktuellen Benutzers Power BI Desktop oder die Anmeldeinformationen verwendet werden, die für die geplante Aktualisierung aus dem Power BI-Dienst konfiguriert sind. Beim Veröffentlichen und Freigeben von Berichten mit importierten Daten müssen Sie darauf achten, nur für Benutzer freizugeben, die die Daten anzeigen dürfen, oder Sie müssen die Sicherheit auf Zeilenebene als Teil des Datasets definieren.

DirectQuery ermöglicht die Übergabe der Anmeldeinformationen eines Berichts-Viewers an die zugrunde liegende Quelle, die Sicherheitsregeln anwendet. DirectQuery unterstützt einmaliges Anmelden (Single Sign-On, SSO) zum Azure SQL Datenquellen und über ein Datengateway zu lokalen SQL-Servern. Weitere Informationen finden Sie unter Übersicht über einmaliges Anmelden (Single Sign-On, SSO) für Gateways in Power BI.

Einschränkungen der Datensouveränität gelten

Einige Organisationen verfügen über Richtlinien zur Datensouveränität, d. h., dass Daten die Organisation nicht verlassen können. Diese Daten stellen Probleme für Lösungen dar, die auf dem Datenimport basieren. Mit DirectQuery verbleiben die Daten am zugrunde liegenden Quellspeicherort. Aber auch bei DirectQuery behält die Power BI-Dienst aufgrund der geplanten Aktualisierung von Kacheln einige Datencaches auf visueller Ebene bei.

Die zugrunde liegende Datenquelle verwendet Measures.

Eine zugrunde liegende Datenquelle wie SAP HANA oder SAP BW enthält Measures. Measures bedeuten, dass importierte Daten bereits auf einer bestimmten Aggregationsebene liegen, wie in der Abfrage definiert. Ein Visual, das Daten in einem Aggregat auf höherer Ebene anfragt, z. B . TotalSales nach Jahr, aggregiert den Aggregatwert weiter. Diese Aggregation ist für additive Measures wie Sum und Min in Ordnung, kann aber für nicht additive Measures wie Average und DistinctCount ein Problem sein.

Das einfache Abrufen der richtigen Aggregatdaten, die für ein Visual direkt aus der Quelle erforderlich sind, erfordert das Senden von Abfragen pro Visual, wie in DirectQuery. Wenn Sie eine Verbindung mit SAP BW herstellen, ermöglicht die Auswahl von DirectQuery diese Behandlung von Measures. Weitere Informationen finden Sie unter DirectQuery und SAP BW.

Derzeit behandelt DirectQuery über SAP HANA Daten genauso wie eine relationale Quelle und erzeugt ein ähnliches Verhalten wie beim Importieren. Weitere Informationen finden Sie unter DirectQuery und SAP HANA.

DirectQuery-Einschränkungen

Die Verwendung von DirectQuery hat potenziell negative Auswirkungen. Einige dieser Einschränkungen unterscheiden sich geringfügig, je nachdem, welche Quelle Sie genau verwenden. In den folgenden Abschnitten werden die allgemeinen Auswirkungen der Verwendung von DirectQuery sowie Einschränkungen in Bezug auf Leistung, Sicherheit, Transformationen, Modellierung und Berichterstellung aufgeführt.

Allgemeine Auswirkungen

Es folgen einige allgemeine Auswirkungen und Einschränkungen der Verwendung von DirectQuery:

  • Wenn sich Daten ändern, müssen Sie aktualisieren, um die neuesten Daten anzuzeigen. Angesichts der Verwendung von Caches gibt es keine Garantie, dass Visuals immer die neuesten Daten anzeigen. Ein Visual kann z. B. Transaktionen des letzten Tages anzeigen. Eine Datenschnittänderung kann das Visual aktualisieren, um Transaktionen der letzten zwei Tage anzuzeigen, einschließlich der letzten, neu eingetroffenen Transaktionen. Die Rückgabe des Datenschnitts auf den ursprünglichen Wert kann jedoch dazu führen, dass der vorherige zwischengespeicherte Wert erneut angezeigt wird. Wählen Sie Aktualisieren aus, um alle Caches zu löschen und alle Visuals auf der Seite zu aktualisieren, um die neuesten Daten anzuzeigen.

  • Wenn sich Daten ändern, gibt es keine Garantie für die Konsistenz zwischen Visuals. Andere Visuals, egal ob auf derselben Seite oder auf verschiedenen Seiten, werden möglicherweise zu unterschiedlichen Zeiten aktualisiert. Wenn sich die Daten in der zugrunde liegenden Quelle ändern, gibt es keine Garantie, dass jedes Visual die Daten zum gleichen Zeitpunkt anzeigt.

    Angesichts der Tatsache, dass mehrere Abfragen für ein einzelnes Visual erforderlich sein können, z. B. zum Abrufen der Details und der Summen, ist selbst die Konsistenz innerhalb eines einzelnen Visuals nicht garantiert. Um diese Konsistenz zu gewährleisten, würde der Mehraufwand für das Aktualisieren aller Visuals bei jeder Aktualisierung eines Visuals sowie die Verwendung kostspieliger Features wie Momentaufnahmeisolation in der zugrunde liegenden Datenquelle erforderlich sein.

    Sie können dieses Problem weitgehend beheben, indem Sie Aktualisieren auswählen, um alle Visuals auf der Seite zu aktualisieren. Auch im Importmodus gibt es ein ähnliches Problem bei der Aufrechterhaltung der Konsistenz, wenn Sie Daten aus mehreren Tabellen importieren.

  • Sie müssen in Power BI Desktop aktualisieren, um Schemaänderungen widerzuspiegeln. Nachdem ein Bericht veröffentlicht wurde, werden die Visuals im Bericht durch Aktualisieren im Power BI-Dienst aktualisiert. Wenn sich jedoch das zugrunde liegende Quellschema ändert, aktualisiert der Power BI-Dienst nicht automatisch die Liste der verfügbaren Felder. Wenn Tabellen oder Spalten aus der zugrunde liegenden Quelle entfernt werden, kann dies bei der Aktualisierung zu einem Abfragefehler führen. Um die Felder im Modell entsprechend den Änderungen zu aktualisieren, müssen Sie den Bericht in Power BI Desktop öffnen und Aktualisieren auswählen.

  • Für jede Abfrage kann ein Grenzwert von 1 Million Zeilen zurückgegeben werden. Es gibt einen festen Grenzwert von 1 Million Zeilen, die in jeder einzelnen Abfrage an die zugrunde liegende Quelle zurückgegeben werden können. Dieser Grenzwert hat im Allgemeinen keine praktischen Auswirkungen, und Visuals zeigen nicht so viele Punkte an. Der Grenzwert kann jedoch in Fällen auftreten, in denen Power BI die gesendeten Abfragen nicht vollständig optimiert und ein Zwischenergebnis anfordert, das den Grenzwert überschreitet.

    Der Grenzwert kann auch beim Erstellen eines Visuals auf dem Pfad zu einem vernünftigeren Endzustand auftreten. Beispielsweise könnte das Einschließen von Customer und TotalSalesQuantity diesen Grenzwert erreichen, wenn mehr als 1 Million Kunden vorhanden sind, bis Sie einen Filter anwenden. Der zurückgegebene Fehler lautet: Das Resultset einer Abfrage an eine externe Datenquelle hat die maximal zulässige Größe von "10000000"-Zeilen überschritten.

    Hinweis

    Mit Premium-Kapazitäten können Sie den Grenzwert von einer Million Zeilen überschreiten. Weitere Informationen finden Sie unter Maximale Anzahl von Ergebniszeilen.

  • Sie können ein Modell nicht vom Import in den DirectQuery-Modus ändern. Sie können ein Modell vom DirectQuery-Modus in den Importmodus wechseln, wenn Sie alle erforderlichen Daten importieren. Es ist nicht möglich, zurück in den DirectQuery-Modus zu wechseln, hauptsächlich aufgrund des Featuresatzes, der vom DirectQuery-Modus nicht unterstützt wird. Bei mehrdimensionalen Quellen wie SAP BW können Sie aufgrund der unterschiedlichen Behandlung externer Measures auch nicht vom DirectQuery-Modus zum Importmodus wechseln.

Auswirkungen auf Leistung und Last

Wenn Sie DirectQuery verwenden, hängt die Gesamterfahrung von der Leistung der zugrunde liegenden Datenquelle ab. Wenn das Aktualisieren jedes Visuals, z. B. nach dem Ändern eines Datenschnittwerts, weniger als fünf Sekunden dauert, ist dies sinnvoll, obwohl sich dies im Vergleich zur unmittelbaren Antwort mit importierten Daten träge anfühlen kann. Wenn die Langsamkeit der Quelle dazu führt, dass die Aktualisierung einzelner Visuals länger als zehn Sekunden dauert, wird die Erfahrung unangemessen schlecht. Bei Abfragen kann sogar ein Timeout auftreten.

Zusammen mit der Leistung der zugrunde liegenden Quelle wirkt sich die Last auf die Quelle auch auf die Leistung aus. Jeder Benutzer, der einen gemeinsamen Bericht öffnet, und jede Dashboardkachel, die aktualisiert wird, sendet mindestens eine Abfrage pro visuellem Element an die zugrunde liegende Quelle. Die Quelle muss in der Lage sein, eine solche Abfragelast zu verarbeiten und gleichzeitig eine angemessene Leistung zu gewährleisten.

Folgen für die Sicherheit

Es sei denn, die zugrunde liegende Datenquelle verwendet SSO, ein DirectQuery-Bericht verwendet immer dieselben festen Anmeldeinformationen, um eine Verbindung mit der Quelle herzustellen, sobald sie im Power BI-Dienst veröffentlicht wurde. Unmittelbar nach der Veröffentlichung eines DirectQuery-Berichts müssen Sie die zu verwendenden Anmeldeinformationen des Benutzers konfigurieren. Bis Sie die Anmeldeinformationen konfiguriert haben, führt der Versuch, den Bericht im Power BI-Dienst zu öffnen, zu einem Fehler.

Nachdem Sie die Benutzeranmeldeinformationen angegeben haben, verwendet Power BI diese Anmeldeinformationen für den Benutzer, der den Bericht öffnet, genau wie für importierte Daten. Jeder Benutzer sieht dieselben Daten, es sei denn, die Sicherheit auf Zeilenebene ist als Teil des Berichts definiert. Sie müssen die gleiche Aufmerksamkeit auf die Freigabe des Berichts wie für importierte Daten richten, auch wenn in der zugrunde liegenden Quelle Sicherheitsregeln definiert sind.

  • Beim Herstellen einer Verbindung mit Power BI-Datasets und Analysis Services im DirectQuery-Modus wird immer einmaliges Anmelden verwendet, sodass die Sicherheit den Liveverbindungen mit Analysis Services ähnelt.

  • Alternative Anmeldeinformationen werden beim Herstellen von DirectQuery-Verbindungen mit SQL Server von Power BI Desktop nicht unterstützt. Sie können Ihre aktuellen Windows-Anmeldeinformationen oder Datenbankanmeldeinformationen verwenden.

  • Sie können mehrere Datenquellen in einem DirectQuery-Modell verwenden, indem Sie zusammengesetzte Modelle verwenden. Wenn Sie mehrere Datenquellen verwenden, ist es wichtig, die Sicherheitsauswirkungen der Hin- und Herverschiebung von Daten zwischen den zugrunde liegenden Datenquellen zu verstehen.

Einschränkungen der Datentransformation

DirectQuery schränkt die Datentransformationen ein, die Sie innerhalb Power Query-Editor anwenden können. Mit importierten Daten können Sie problemlos einen komplexen Satz von Transformationen anwenden, um die Daten zu bereinigen und umzugestalten, bevor Sie sie zum Erstellen von Visuals verwenden. Sie können beispielsweise JSON-Dokumente analysieren oder Daten aus einer Spalte in ein Zeilenformular pivotieren. Diese Transformationen sind in DirectQuery eingeschränkter.

Wenn Sie eine Verbindung mit einer OLAP-Quelle (Online Analytical Processing) wie SAP BW herstellen, können Sie keine Transformationen definieren, und das gesamte externe Modell wird von der Quelle übernommen. Für relationale Quellen wie SQL Server können Sie weiterhin eine Reihe von Transformationen pro Abfrage definieren, aber diese Transformationen sind aus Leistungsgründen eingeschränkt.

Alle Transformationen müssen auf jede Abfrage auf die zugrunde liegende Quelle angewendet werden und nicht nur einmal bei der Datenaktualisierung. Transformationen müssen vernünftigerweise in eine einzelne native Abfrage übersetzt werden können. Wenn Sie eine zu komplexe Transformation verwenden, erhalten Sie die Fehlermeldung, dass sie entweder gelöscht oder das Verbindungsmodell in den Import gewechselt werden muss.

Darüber hinaus verwenden Sie im Dialogfeld Daten abrufen oder Power Query-Editor Unterauswahlen in den Abfragen verwenden, die sie generieren und senden, um Daten für ein Visual abzurufen. In Power Query-Editor definierte Abfragen müssen in diesem Kontext gültig sein. Insbesondere ist es nicht möglich, eine Abfrage mit allgemeinen Tabellenausdrücken zu verwenden, noch eine Abfrage, die gespeicherte Prozeduren aufruft.

Modellierungseinschränkungen

Der Begriff Modellierung bedeutet in diesem Kontext das Verfeinern und Anreichern von Rohdaten im Rahmen der Erstellung eines Berichts mithilfe der Daten. Beispiele für die Modellierung sind:

  • Definieren von Beziehungen zwischen Tabellen.
  • Hinzufügen neuer Berechnungen, z. B. berechneter Spalten und Measures.
  • Umbenennen und Ausblenden von Spalten und Measures.
  • Definieren von Hierarchien.
  • Definieren von Spaltenformatierung, Standardzusammenfassung und Sortierreihenfolge.
  • Gruppierung oder Clustering von Werten.

Sie können weiterhin viele dieser Modellanreicherungen vornehmen, wenn Sie DirectQuery verwenden, und das Prinzip der Anreicherung der Rohdaten verwenden, um die spätere Nutzung zu verbessern. Einige Modellierungsfunktionen sind jedoch nicht verfügbar oder mit DirectQuery eingeschränkt. Die Einschränkungen werden angewendet, um Leistungsprobleme zu vermeiden.

Die folgenden Einschränkungen gelten für alle DirectQuery-Quellen. Weitere Einschränkungen können für einzelne Quellen gelten.

  • Keine integrierte Datumshierarchie: Bei importierten Daten verfügt jede date/datetime-Spalte standardmäßig auch über eine integrierte Datumshierarchie. Wenn Sie z. B. eine Tabelle mit Verkaufsaufträgen importieren, die eine Spalte OrderDate enthält, und OrderDate in einem Visual verwenden, können Sie die entsprechende Datumsebene auswählen, z. B. Jahr, Monat oder Tag. Diese integrierte Datumshierarchie ist mit DirectQuery nicht verfügbar. Wenn in der zugrunde liegenden Quelle eine Date-Tabelle verfügbar ist, wie in vielen Data Warehouses üblich, können Sie die DAX-Zeitintelligenzfunktionen (Data Analysis Expressions) wie gewohnt verwenden.

  • Unterstützung für Datum/Uhrzeit nur auf Sekundenebene: Für Datasets, die Zeitspalten verwenden, stellt Power BI Abfragen an die zugrunde liegende DirectQuery-Quelle nur bis zur Detailebene von Sekunden und nicht in Millisekunden aus. Entfernen Sie Millisekundendaten aus Ihren Quellspalten.

  • Einschränkungen in berechneten Spalten: Berechnete Spalten können nur zeilenintern sein, d. h. sie können nur auf Werte anderer Spalten derselben Tabelle verweisen, ohne Aggregatfunktionen zu verwenden. Außerdem sind die zulässigen DAX-Skalarfunktionen, z LEFT(). B. , auf die Funktionen beschränkt, die an die zugrunde liegende Quelle gepusht werden können. Die Funktionen variieren je nach den genauen Möglichkeiten der Quelle. Funktionen, die nicht unterstützt werden, werden beim Erstellen der DAX-Abfrage für eine berechnete Spalte nicht in autovervollständigen aufgeführt und führen bei Verwendung zu einem Fehler.

  • Keine Unterstützung für DAX-Funktionen über- und untergeordneter Elemente: Im DirectQuery-Modus ist es nicht möglich, die Familie von DAX PATH() Funktionen zu verwenden, die normalerweise über- und untergeordnete Strukturen behandeln, z. B. Kontendiagramme oder Mitarbeiterhierarchien.

  • Kein Clustering: Wenn Sie DirectQuery verwenden, können Sie die Clusteringfunktion nicht verwenden, um Gruppen automatisch zu finden.

Einschränkungen bei der Berichterstattung

Fast alle Berichtsfunktionen werden für DirectQuery-Modelle unterstützt. Solange die zugrunde liegende Quelle ein geeignetes Leistungsniveau bietet, können Sie denselben Satz von Visualisierungen wie für importierte Daten verwenden.

Eine allgemeine Einschränkung besteht darin, dass die maximale Länge der Daten in einer Textspalte für DirectQuery-Datasets 32.764 Zeichen beträgt. Die Berichterstattung über längere Texte führt zu einem Fehler.

Die folgenden Power BI-Berichterstellungsfunktionen können Leistungsprobleme in DirectQuery-basierten Berichten verursachen:

  • Measurefilter: Visuals, die Measures oder Aggregate von Spalten verwenden, können Filter in diesen Measures enthalten. Die folgende Abbildung zeigt beispielsweise SalesAmount nach Kategorie, aber nur für Kategorien mit mehr als 20 Mio . Umsatz.

    Screenshot: Measures, die Filter enthalten

    Dieser Ansatz bewirkt, dass zwei Abfragen an die zugrunde liegende Quelle gesendet werden:

    • Die erste Abfrage ruft die Kategorien ab, die die Bedingung SalesAmount größer als 20 Millionen erfüllen.
    • Die zweite Abfrage ruft die erforderlichen Daten für das Visual ab, einschließlich der Kategorien, die die WHERE Bedingung erfüllt haben.

    Dieser Ansatz funktioniert in der Regel gut, wenn es Hunderte oder Tausende von Kategorien gibt, wie in diesem Beispiel. Die Leistung kann sich verschlechtern, wenn die Anzahl der Kategorien viel größer ist. Die Abfrage schlägt fehl, wenn mehr als eine Million Kategorien vorhanden sind.

  • TopN-Filter: Sie können erweiterte Filter definieren, um nur nach den nach einem Measure sortierten oberen oder unteren N Werten zu filtern. Filter können beispielsweise die 10 obersten Kategorien enthalten. Dieser Ansatz sendet erneut zwei Abfragen an die zugrunde liegende Quelle. Die erste Abfrage gibt jedoch alle Kategorien aus der zugrunde liegenden Quelle zurück, und dann werden die TopN basierend auf den zurückgegebenen Ergebnissen bestimmt. Abhängig von der Kardinalität der beteiligten Spalte kann dieser Ansatz aufgrund des Zeilenlimits von einer Million für Abfrageergebnisse zu Leistungsproblemen oder Abfragefehlern führen.

  • Median: Jede Aggregation, z Sum . B. oder Count Distinct, wird an die zugrunde liegende Quelle gepusht. In der Regel wird das median Aggregat jedoch von der zugrunde liegenden Quelle nicht unterstützt. Für medianwerden die Detaildaten aus der zugrunde liegenden Quelle abgerufen, und der Median wird aus den zurückgegebenen Ergebnissen berechnet. Dieser Ansatz ist sinnvoll, um den Median über eine relativ kleine Anzahl von Ergebnissen zu berechnen.

    Leistungsprobleme oder Abfragefehler können auftreten, wenn die Kardinalität aufgrund des Grenzwerts von einer Million Zeilen groß ist. Beispielsweise kann die Abfrage der medianen Landes-/Regionsbevölkerung sinnvoll sein, aber der Median-Verkaufspreis ist möglicherweise nicht angemessen.

  • Erweiterte Textfilter wie "contains": Die erweiterte Filterung für eine Textspalte ermöglicht Filter wie contains und begins with. Diese Filter können zu leistungseinbußen für einige Datenquellen führen. Verwenden Sie insbesondere nicht den Standardfilter contains , wenn Sie eine genaue Übereinstimmung benötigen. Obwohl die Ergebnisse abhängig von den tatsächlichen Daten identisch sein können, kann die Leistung aufgrund von Indizes drastisch abweichen.

  • Slicer mit mehrfacher Auswahl: Standardmäßig lassen Slicer nur eine einzelne Auswahl zu. Das Zulassen der Mehrfachauswahl in Filtern kann zu Leistungsproblemen führen. Wenn der Benutzer beispielsweise 10 interessante Produkte auswählt, führt jede neue Auswahl dazu, dass Abfragen an die Quelle gesendet werden. Obwohl der Benutzer das nächste Element auswählen kann, bevor die Abfrage abgeschlossen ist, führt dieser Ansatz zu einer zusätzlichen Last für die zugrunde liegende Quelle.

  • Summen für Tabellenvisuals: Standardmäßig werden in Tabellen und Matrizen Summen und Teilergebnisse angezeigt. In vielen Fällen erfordert das Abrufen der Werte für solche Summen das Senden separater Abfragen an die zugrunde liegende Quelle. Diese Anforderung gilt, wenn Sie Aggregation verwenden DistinctCount , oder in allen Fällen, in denen DirectQuery über SAP BW oder SAP HANA verwendet wird. Sie können diese Summen über den Bereich Format deaktivieren.

DirectQuery-Empfehlungen

Dieser Abschnitt enthält allgemeine Anleitungen zur erfolgreichen Verwendung von DirectQuery angesichts der Auswirkungen.

Zugrunde liegende Datenquellenleistung

Überprüfen Sie, ob einfache Visuals innerhalb von fünf Sekunden aktualisiert werden, um eine angemessene interaktive Oberfläche zu bieten. Wenn die Aktualisierung von Visuals länger als 30 Sekunden dauert, ist es wahrscheinlich, dass die Lösung aufgrund weiterer Probleme nach der Veröffentlichung des Berichts nicht mehr funktioniert.

Wenn Abfragen langsam sind, untersuchen Sie die an die zugrunde liegende Quelle gesendeten Abfragen und den Grund für die langsame Leistung. Weitere Informationen finden Sie unter Leistungsdiagnose.

In diesem Artikel wird nicht die breite Palette der Empfehlungen zur Datenbankoptimierung in allen möglichen zugrunde liegenden Quellen behandelt. Die folgenden Standardmethoden für Datenbank gelten für die meisten Situationen:

  • Um die Leistung zu verbessern, basieren Sie auf Ganzzahlspalten, anstatt Spalten anderer Datentypen zu verknüpfen.

  • Erstellen Sie die entsprechenden Indizes. Indexerstellung bedeutet im Allgemeinen die Verwendung von Spaltenspeicherindizes in Quellen, die diese unterstützen, z. B. SQL Server.

  • Aktualisieren Sie alle erforderlichen Statistiken in der Quelle.

Modellentwurf

Wenn Sie das Modell definieren, befolgen Sie diese Anleitung:

  • Vermeiden Sie komplexe Abfragen im Power Abfrage-Editor. Der Power Abfrage-Editor übersetzt eine komplexe Abfrage in eine einzelne SQL-Abfrage. Die einzelne Abfrage wird bei jeder an diese Tabelle gesendeten Abfrage in der Unterauswahl angezeigt. Wenn diese Abfrage komplex ist, kann es zu Leistungsproblemen bei jeder gesendeten Abfrage kommen. Sie können die eigentliche SQL-Abfrage für eine Reihe von Schritten abrufen, indem Sie unter Angewendete Schritte in Power Query-Editor mit der rechten Maustaste auf den letzten Schritt klicken und native Abfrage anzeigen auswählen.

  • Halten Sie Measures einfach. Beschränken Sie Measures zumindest anfänglich auf einfache Aggregate. Wenn die Measures zufriedenstellend funktionieren, können Sie komplexere Measures definieren, aber auf die Leistung achten.

  • Vermeiden Sie Beziehungen in berechneten Spalten. In Datenbanken, in denen Sie verknüpfungen mit mehreren Spalten durchführen müssen, erlaubt Power BI nicht, beziehungen auf mehreren Spalten als Primärschlüssel oder Fremdschlüssel zu basieren. Die gängige Problemumgehung besteht darin, die Spalten mithilfe einer berechneten Spalte zu verketten und die Verknüpfung auf dieser Spalte zu basieren.

    Diese Problemumgehung ist für importierte Daten sinnvoll, führt aber für DirectQuery zu einer Verknüpfung für einen Ausdruck. Dieses Ergebnis verhindert in der Regel die Verwendung von Indizes und führt zu einer schlechten Leistung. Die einzige Problemumgehung besteht darin, die einzelnen Spalten tatsächlich in einer einzelnen Spalte in der zugrunde liegenden Datenquelle zu materialisieren.

  • Vermeiden Sie Beziehungen zu "uniqueidentifier"-Spalten. Power BI unterstützt einen uniqueidentifier Datentyp nicht nativ. Das Definieren einer Beziehung zwischen uniqueidentifier Spalten führt zu einer Abfrage mit einer Verknüpfung, die eine Umwandlung beinhaltet. Auch dieser Ansatz führt häufig zu schlechter Leistung. Die einzige Problemumgehung besteht darin, Spalten eines alternativen Typs in der zugrunde liegenden Datenquelle zu materialisieren.

  • Blenden Sie die Spalte "to" für Beziehungen aus. Die to Spalte für Beziehungen ist in der Regel der Primärschlüssel in der to Tabelle. Diese Spalte sollte ausgeblendet sein, aber wenn sie ausgeblendet ist, wird sie nicht in der Feldliste angezeigt und kann nicht in Visuals verwendet werden. Häufig sind die Spalten, auf denen Beziehungen basieren , tatsächlich Systemspalten, z. B. Ersatzschlüssel in einem Data Warehouse. Es ist immer noch am besten, solche Spalten auszublenden.

    Wenn die Spalte eine Bedeutung hat, führen Sie eine berechnete Spalte ein, die sichtbar ist und mit einem einfachen Ausdruck gleich dem Primärschlüssel ist, z. B.:

        ProductKey_PK   (Destination of a relationship, hidden)
        ProductKey (= [ProductKey_PK],   visible)
        ProductName
        ...
    
  • Untersuchen Sie alle berechneten Spalten und Datentypänderungen. Sie können berechnete Tabellen verwenden, wenn Sie DirectQuery mit zusammengesetzten Modellen verwenden. Diese Funktionen sind nicht unbedingt schädlich, führen aber zu Abfragen, die Ausdrücke anstelle einfacher Verweise auf Spalten enthalten. Diese Abfragen können dazu führen, dass Indizes nicht verwendet werden.

  • Vermeiden Sie bidirektionale Kreuzfilterung für Beziehungen. Die Bidirektionale Kreuzfilterung kann zu Abfrageanweisungen führen, die nicht gut funktionieren. Weitere Informationen zur bidirektionalen Kreuzfilterung finden Sie unter Aktivieren der bidirektionalen Kreuzfilterung für DirectQuery in Power BI Desktop, oder laden Sie das Whitepaper Bidirektionale Kreuzfilterung herunter. Die Beispiele in diesem Artikel beziehen sich auf SQL Server Analysis Services, aber die grundlegenden Punkte gelten auch für Power BI.

  • Experimentieren Sie mit der Einstellung Referenzielle Integrität voraussetzen. Die Einstellung Referenzielle Integrität für Beziehungen annehmen ermöglicht die Verwendung von INNER JOIN Abfragen anstelle von OUTER JOIN Anweisungen. Diese Anleitung verbessert im Allgemeinen die Abfrageleistung, hängt jedoch von den Besonderheiten der Datenquelle ab.

  • Verwenden Sie nicht die relative Datenfilterung im Power Abfrage-Editor. Es ist möglich, die relative Datenfilterung im Power Abfrage-Editor zu definieren. Sie können beispielsweise nach den Zeilen filtern, in denen sich das Datum in den letzten 14 Tagen befindet.

    Screenshot: Filtern von Zeilen für die letzten 14 Tage

    Dieser Filter wird jedoch basierend auf einem festen Datum in einen Filter übersetzt, z. B. der Zeit, zu der die Abfrage erstellt wurde, wie Sie in der nativen Abfrage sehen können.

    Screenshot: Filtern von Zeilen in einer nativen SQL-Abfrage

    Diese Daten sind wahrscheinlich nicht das, was Sie möchten. Um sicherzustellen, dass der Filter basierend auf dem Datum zum Zeitpunkt der Ausführung des Berichts angewendet wird, wenden Sie den Datumsfilter im Bericht an. Sie können mithilfe der -Funktion eine berechnete Spalte erstellen, die DAX DATE() die Anzahl der Tage vor berechnet, und diese berechnete Spalte im Filter verwenden.

Berichtsentwurf

Wenn Sie einen Bericht erstellen, der eine DirectQuery-Verbindung verwendet, befolgen Sie die folgenden Anleitungen:

  • Erwägen Sie die Verwendung von Abfragereduzierungsoptionen: Power BI bietet Berichtsoptionen, um weniger Abfragen zu senden und bestimmte Interaktionen zu deaktivieren, die eine schlechte Erfahrung verursachen, wenn die ausführung der resultierenden Abfragen lange dauert. Diese Optionen gelten, wenn Sie mit Ihrem Bericht in Power BI Desktop interagieren, und gelten auch dann, wenn Benutzer den Bericht im Power BI-Dienst nutzen.

    Navigieren Sie in Power BI Desktop zu Datei>Optionen und Einstellungen>Optionen, und wählen Sie Abfrageverringerung aus, um auf diese Optionen zuzugreifen.

    Screenshot: Optionen zur Abfragereduzierung

    Mit der Auswahl auf dem Bildschirm Abfragereduzierung können Sie die Schaltfläche Anwenden für Datenschnitte oder Filterauswahlen anzeigen. Es werden keine Abfragen gesendet, bis Sie die Schaltfläche Anwenden im Filter oder Slicer auswählen. Die Abfragen verwenden dann Ihre Auswahl, um die Daten zu filtern. Mit dieser Schaltfläche können Sie mehrere Slicer- und Filterauswahlen vornehmen, bevor Sie sie anwenden.

  • Wenden Sie zuerst Filter an: Wenden Sie anwendbare Filter immer zu Beginn der Erstellung eines Visuals an. Anstatt beispielsweise totalSalesAmount und ProductName zu ziehen und dann auf ein bestimmtes Jahr zu filtern, wenden Sie den Filter zu Beginn auf Year an.

    Jeder Schritt beim Erstellen eines visuellen Elements sendet eine Abfrage. Obwohl es möglich ist, eine weitere Änderung vorzunehmen, bevor die erste Abfrage abgeschlossen ist, bleibt bei diesem Ansatz eine unnötige Last für die zugrunde liegende Quelle. Das frühe Anwenden von Filtern macht diese Zwischenabfragen im Allgemeinen kostengünstiger. Wenn Filter nicht frühzeitig angewendet werden, kann dies zum Erreichen des Grenzwerts von einer Million Zeilen führen.

  • Beschränken Sie die Anzahl von Visuals auf einer Seite: Wenn Sie eine Seite öffnen oder einen Datenschnitt auf Seitenebene ändern, werden alle Visuals auf der Seite aktualisiert. Die Anzahl paralleler Abfragen ist begrenzt. Wenn die Anzahl der Visuals zunimmt, werden einige Visuals seriell aktualisiert, was die Zeit zum Aktualisieren der Seite erhöht. Daher ist es am besten, die Anzahl der Visuals auf einer einzelnen Seite zu begrenzen und stattdessen mehr, einfachere Seiten zu haben.

  • Erwägen Sie, die Interaktion zwischen Visuals zu deaktivieren: Standardmäßig können Visualisierungen auf einer Berichtsseite für die Kreuzfilterung und -hervorhebung der anderen Visualisierungen auf der Seite verwendet werden. Wenn Sie beispielsweise 1999 im Kreisdiagramm auswählen, wird das Säulendiagramm kreuz hervorgehoben, um die Verkäufe nach Kategorie für 1999 anzuzeigen.

    Screenshot: Mehrere Visuals mit Kreuzfilterung und Kreuzmarkierung

    Die Kreuzfilterung und die übergreifende Hervorhebung in DirectQuery erfordern das Übermitteln von Abfragen an die zugrunde liegende Quelle. Sie sollten diese Interaktion deaktivieren, wenn die Zeit, die zum Reagieren auf die Auswahl der Benutzer benötigt wird, unangemessen lang ist.

    Sie können die Einstellungen für die Abfragereduzierung verwenden, um die Kreuzmarkierung im gesamten Bericht oder von Fall zu Fall zu deaktivieren. Weitere Informationen finden Sie unter Gegenseitige Kreuzfilterung von Visuals in einem Power BI-Bericht.

Maximale Anzahl von Verbindungen

Sie können einstellen, wie viele Verbindungen für jede zugrunde liegende Datenquelle von DirectQuery maximal geöffnet werden können, wodurch gesteuert wird, wie viele Abfragen gleichzeitig an jede Datenquelle gesendet werden.

DirectQuery öffnet standardmäßig eine maximale Anzahl von zehn gleichzeitigen Verbindungen. Um die maximale Anzahl für die aktuelle Datei in Power BI Desktop zu ändern, wechseln Sie zu Dateioptionen>und Einstellungen>, und wählen Sie im linken Bereich im Abschnitt Aktuelle DateidirectQuery aus.

Screenshot: Festlegen der maximalen DirectQuery-Verbindungen

Die Einstellung ist nur aktiviert, wenn im aktuellen Bericht mindestens eine DirectQuery-Quelle vorhanden ist. Der Wert gilt für alle DirectQuery-Quellen und für alle neuen DirectQuery-Quellen, die diesem Bericht hinzugefügt wurden.

Das Erhöhen der maximalen Verbindungen pro Datenquelle ermöglicht das Senden weiterer Abfragen bis zur angegebenen maximalen Anzahl an die zugrunde liegende Datenquelle. Dieser Ansatz ist nützlich, wenn sich viele visuelle Elemente auf einer einzelnen Seite befinden oder viele Benutzer gleichzeitig auf einen Bericht zugreifen. Sobald die maximale Anzahl von Verbindungen erreicht ist, werden weitere Abfragen in die Warteschlange gestellt, bis eine Verbindung verfügbar wird. Ein höherer Grenzwert führt zu mehr Last für die zugrunde liegende Quelle, sodass die Einstellung nicht garantiert ist, dass die Gesamtleistung verbessert wird.

Nachdem Sie einen Bericht im Power BI-Dienst veröffentlicht haben, hängt die maximale Anzahl gleichzeitiger Abfragen auch von festen Grenzwerten ab, die für die Zielumgebung festgelegt sind, in der der Bericht veröffentlicht wird. Power BI, Power BI Premium und Power BI-Berichtsserver unterschiedliche Grenzwerte festlegen. In der folgenden Tabelle werden die Obergrenzen für aktive Verbindungen pro Datenquelle für die verschiedenen Power BI-Umgebungen aufgeführt. Diese Grenzwerte gelten für Clouddatenquellen und lokale Datenquellen wie SQL Server, Oracle und Teradata.

Environment Obergrenze pro Datenquelle
Power BI Pro 10 aktive Verbindungen
Power BI Premium 30 aktive Verbindungen
Power BI-Berichtsserver 10 aktive Verbindungen

Hinweis

Die Einstellung für die maximale Anzahl von DirectQuery-Verbindungen gilt für alle DirectQuery-Quellen, wenn Sie erweiterte Metadaten aktivieren. Dies ist die Standardeinstellung für alle Modelle, die in Power BI Desktop erstellt wurden.

DirectQuery im Power BI-Dienst

Alle DirectQuery-Datenquellen werden von Power BI Desktop unterstützt, und einige Quellen sind auch direkt aus dem Power BI-Dienst verfügbar. Ein Geschäftsbenutzer kann beispielsweise Power BI verwenden, um eine Verbindung mit seinen Daten in Salesforce herzustellen und sofort ein Dashboard abzurufen, ohne Power BI Desktop zu verwenden.

Nur die folgenden beiden DirectQuery-fähigen Quellen sind direkt im Power BI-Dienst verfügbar:

  • Spark
  • Azure Synapse Analytics (ehemals SQL Data Warehouse)

Selbst für diese beiden Quellen ist es immer noch am besten, die DirectQuery-Verwendung in Power BI Desktop zu starten. Während es einfach ist, die Verbindung zunächst im Power BI-Dienst herzustellen, gibt es Einschränkungen für die weitere Verbesserung des resultierenden Berichts. Beispielsweise ist es im Dienst nicht möglich, Berechnungen zu erstellen oder viele Analysefeatures zu verwenden oder die Metadaten zu aktualisieren, um Änderungen am zugrunde liegenden Schema widerzuspiegeln.

Die Leistung eines DirectQuery-Berichts im Power BI-Dienst hängt vom Lastgrad der zugrunde liegenden Datenquelle ab. Die Last hängt von folgenden Faktoren ab:

  • Die Anzahl der Benutzer, die den Bericht und das Dashboard gemeinsam nutzen.
  • Die Komplexität des Berichts.
  • Gibt an, ob der Bericht sicherheit auf Zeilenebene definiert.

Berichtsverhalten im Power BI-Dienst

Wenn Sie einen Bericht im Power BI-Dienst öffnen, werden alle Visuals auf der aktuell sichtbaren Seite aktualisiert. Jedes Visual erfordert mindestens eine Abfrage für die zugrunde liegende Datenquelle. Einige visuelle Elemente erfordern möglicherweise mehr als eine Abfrage. Ein Visual kann beispielsweise Aggregatwerte aus zwei verschiedenen Faktentabellen oder ein komplexeres Measure enthalten oder Summen eines nicht additiven Measures wie Count Distinct enthalten. Wenn Sie auf eine neue Seite wechseln, werden diese visuellen Elemente aktualisiert. Bei der Aktualisierung wird ein neuer Satz von Abfragen an die zugrunde liegende Quelle gesendet.

Jedes Eingreifen des Benutzers in den Bericht führt möglicherweise dazu, dass visuelle Elemente aktualisiert werden. Wenn Sie z. B. einen anderen Wert auf einem Datenschnitt auswählen, müssen Sie eine neue Reihe von Abfragen senden, um alle betroffenen visuellen Elemente zu aktualisieren. Das gleiche gilt für die Auswahl eines Visuals zum Kreuzmarkieren anderer Visuals oder für das Ändern eines Filters. Ebenso erfordert das Erstellen oder Bearbeiten eines Berichts Abfragen für jeden Schritt im Pfad, um das endgültige Visual zu erstellen.

Es erfolgt eine Zwischenspeicherung der Ergebnisse. Die Aktualisierung eines Visuals erfolgt sofort, wenn die gleichen Ergebnisse kürzlich erzielt wurden. Wenn Sicherheit auf Zeilenebene definiert ist, werden diese Caches nicht für Benutzer freigegeben.

Die Verwendung von DirectQuery erzwingt einige wichtige Einschränkungen in einigen der Funktionen, die der Power BI-Dienst für veröffentlichte Berichte bietet:

  • Quick Insights werden nicht unterstützt: Power BI Quick Insights durchsucht verschiedene Teilmengen Ihres Datasets und wendet gleichzeitig eine Reihe von anspruchsvollen Algorithmen an, um potenziell interessante Erkenntnisse zu gewinnen. Da schnelle Erkenntnisse hochleistungsfähige Abfragen erfordern, ist dieses Feature nicht für Datasets verfügbar, die DirectQuery verwenden.

  • Die Verwendung von Explore in Excel führt zu einer schlechten Leistung: Sie können ein Dataset untersuchen, indem Sie die Funktion In Excel durchsuchen verwenden, mit der Sie Pivottabellen und Pivotdiagramme in Excel erstellen können. Diese Funktion wird für Datasets unterstützt, die DirectQuery verwenden, aber die Leistung ist langsamer als das Erstellen von Visuals in Power BI. Wenn die Verwendung von Excel für Ihre Szenarien wichtig ist, berücksichtigen Sie dieses Problem bei der Entscheidung, ob DirectQuery verwendet werden soll.

  • Excel zeigt keine Hierarchien an: Wenn Sie beispielsweise Analysieren in Excel verwenden, zeigt Excel keine Hierarchien an, die in Azure Analysis Services Modellen oder Power BI-Datasets definiert sind, die DirectQuery verwenden.

Dashboard-Aktualisierung

Im Power BI-Dienst können Sie einzelne Visuals oder ganze Seiten als Kacheln an Dashboards anheften. Kacheln, die auf DirectQuery-Datasets basieren, werden automatisch aktualisiert, indem Abfragen nach einem Zeitplan an die zugrunde liegenden Datenquellen gesendet werden. Datasets werden standardmäßig stündlich aktualisiert. Sie können die Aktualisierung jedoch zwischen wöchentlich und alle 15 Minuten als Teil der Dataseteinstellungen konfigurieren.

Wenn im Modell keine Sicherheit auf Zeilenebene definiert ist, wird jede Kachel einmal aktualisiert, und die Ergebnisse werden für alle Benutzer freigegeben. Wenn Sie Sicherheit auf Zeilenebene verwenden, müssen für jede Kachel separate Abfragen pro Benutzer an die zugrunde liegende Quelle gesendet werden.

Es kann einen großen Multiplikatoreffekt geben. Ein Dashboard mit 10 Kacheln, die für 100 Benutzer freigegeben werden und für ein Dataset mit DirectQuery mit Sicherheit auf Zeilenebene erstellt wurden, führt dazu, dass bei jeder Aktualisierung mindestens 1000 Abfragen an die zugrunde liegende Datenquelle gesendet werden. Berücksichtigen Sie sorgfältig die Verwendung der Sicherheit auf Zeilenebene und die Konfiguration des Aktualisierungszeitplans.

Zeitüberschreitungen bei Abfragen

Für einzelne Abfragen im Power BI-Dienst gilt ein Timeout von vier Minuten. Abfragen, die länger als vier Minuten dauern, schlagen fehl. Dieser Grenzwert soll Probleme verhindern, die durch zu lange Ausführungszeiten verursacht werden. Sie sollten DirectQuery nur für Quellen verwenden, die interaktive Abfrageleistung bieten können.

Leistungsdiagnose

In diesem Abschnitt wird beschrieben, wie Sie Leistungsprobleme diagnostizieren oder ausführlichere Informationen erhalten, um Ihre Berichte zu optimieren.

Beginnen Sie mit der Diagnose von Leistungsproblemen in Power BI Desktop und nicht in der Power BI-Dienst. Leistungsprobleme basieren oft auf der Leistung der zugrunde liegenden Quelle. Sie können Probleme einfacher in der isolierteren Power BI Desktop Umgebung identifizieren und diagnostizieren.

Dieser Ansatz verzichtet anfänglich auf bestimmte Komponenten wie das Power BI-Gateway. Wenn die Leistungsprobleme in Power BI Desktop nicht auftreten, können Sie die Besonderheiten des Berichts im Power BI-Dienst untersuchen.

Das Power BI Desktop Performance Analyzer ist ein nützliches Tool zum Identifizieren von Problemen. Versuchen Sie, alle Probleme auf ein Visual zu isolieren und nicht viele Visuals auf einer Seite. Wenn ein einzelnes Visual auf einer Power BI Desktop Seite träge ist, verwenden Sie die Leistungsanalyse, um die Abfragen zu analysieren, die Power BI Desktop an die zugrunde liegende Quelle sendet.

Sie können auch Ablaufverfolgungen und Diagnoseinformationen anzeigen, die von einigen zugrunde liegenden Datenquellen ausgegeben werden. Selbst wenn keine Ablaufverfolgungen von der Quelle vorhanden sind, enthält die Ablaufverfolgungsdatei möglicherweise nützliche Details dazu, wie eine Abfrage ausgeführt wird und wie Sie sie verbessern können. Sie können den folgenden Prozess verwenden, um die von Power BI gesendeten Abfragen und deren Ausführungszeiten anzuzeigen.

Verwenden von SQL Server Profiler zum Anzeigen von Abfragen

Standardmäßig protokolliert Power BI Desktop während einer gegebenen Sitzung Ereignisse in einer Ablaufverfolgungsdatei mit dem Namen FlightRecorderCurrent.trc. Die Ablaufverfolgungsdatei befindet sich im Ordner Power BI Desktop für den aktuellen Benutzer in einem Ordner namens AnalysisServicesWorkspaces.

Bei einigen DirectQuery-Quellen enthält diese Ablaufverfolgungsdatei alle Abfragen, die an die zugrunde liegende Datenquelle gesendet werden. Die folgenden Datenquellen senden Abfragen an das Protokoll:

  • SQL Server
  • Azure SQL-Datenbank
  • Azure Synapse Analytics (ehemals SQL Data Warehouse)
  • Oracle
  • Teradata
  • SAP HANA

Sie können die Ablaufverfolgungsdateien lesen, indem Sie die SQL Server Profiler verwenden, die teil der kostenlosen Download-SQL Server Management Studio.

Screenshot: SQL Server Profiler

So öffnen Sie die Ablaufverfolgungsdatei für die aktuelle Sitzung:

  1. Wählen Sie während einer Power BI Desktop Sitzung Dateioptionen>und Einstellungen>Optionen und dann Diagnose aus.

  2. Wählen Sie unter Absturzabbildsammlung die Option Absturzabbild/Ablaufverfolgungsordner öffnen aus.

    Screenshot: Link zum Öffnen des Ordners

    Der Ordner Power BI Desktop\Traces wird geöffnet.

  3. Navigieren Sie zum übergeordneten Ordner und dann zum Ordner AnalysisServicesWorkspaces, der einen Arbeitsbereichsordner für jede geöffnete Instanz von Power BI Desktop enthält. Diese Ordner werden mit einem Integersuffix bezeichnet, z. B. AnalysisServicesWorkspace2058279583. Der Arbeitsbereichsordner wird gelöscht, wenn die zugeordnete Power BI Desktop Sitzung endet.

    Im Arbeitsbereichsordner für die aktuelle Power BI-Sitzung enthält der Ordner \Data die Ablaufverfolgungsdatei FlightRecorderCurrent.trc . Notieren Sie sich den Speicherort.

  4. Öffnen Sie SQL Server Profiler, und wählen Sie DateiAblaufverfolgungsdatei>öffnen> aus.

  5. Navigieren Sie zu oder geben Sie den Pfad zur Ablaufverfolgungsdatei für die aktuelle Power BI-Sitzung ein, und öffnen Sie FlightRecorderCurrent.trc.

SQL Server Profiler zeigt alle Ereignisse aus der aktuellen Sitzung an. Der folgende Screenshot zeigt eine Gruppe von Ereignissen für eine Abfrage. Jede Abfragegruppe weist die folgenden Ereignisse auf:

  • Ein Query Begin - und Query End -Ereignis, das den Anfang und das Ende einer DAX-Abfrage darstellt, die durch Ändern eines Visuals oder Filters in der Power BI-Benutzeroberfläche oder durch Das Filtern oder Transformieren von Daten in der Power Query-Editor generiert wird.

  • Ein oder mehrere Paare von DirectQuery Begin und DirectQuery End -Ereignissen, die Abfragen darstellen, die im Rahmen der Auswertung der DAX-Abfrage an die zugrunde liegende Datenquelle gesendet werden.

Screenshot: SQL Server Profiler mit Den Ereignissen

Mehrere DAX-Abfragen können parallel ausgeführt werden, damit sich Ereignisse aus verschiedenen Gruppen überlappen können. Sie können den ActivityID Wert verwenden, um zu bestimmen, welche Ereignisse zu derselben Gruppe gehören.

Die folgenden Spalten sind ebenfalls von Interesse:

  • TextData: Die Textdetails des Ereignisses. Für Query Begin Ereignisse und Query End ist das Detail die DAX-Abfrage. Für DirectQuery Begin Ereignisse und DirectQuery End ist das Detail die SQL-Abfrage, die an die zugrunde liegende Quelle gesendet wird. TextData für das aktuell ausgewählte Ereignis wird auch im Bereich am unteren Bildschirmrand angezeigt.
  • EndTime: Die Zeit, zu der das Ereignis beendet wurde.
  • Dauer: Die Dauer in Millisekunden, die zum Ausführen der DAX- oder SQL-Abfrage benötigt wurde.
  • Fehler: Ob ein Fehler aufgetreten ist, in diesem Fall wird das Ereignis auch rot angezeigt.

So erfassen Sie eine Ablaufverfolgung, um ein potenzielles Leistungsproblem zu diagnostizieren:

  1. Öffnen Sie eine einzelne Power BI Desktop-Sitzung zur Vermeidung von Verwechslungen von mehreren Arbeitsbereichsordnern.

  2. Führen Sie die interessanten Aktionen in Power BI Desktop aus. Fügen Sie einige weitere Aktionen ein, um sicherzustellen, dass die relevanten Ereignisse in die Ablaufverfolgungsdatei geleert werden.

  3. Öffnen Sie SQL Server Profiler, und untersuchen Sie die Ablaufverfolgung. Denken Sie daran, dass beim Schließen von Power BI Desktop die Ablaufverfolgungsdatei gelöscht wird. Auch weitere Aktionen in Power BI Desktop werden nicht sofort angezeigt. Sie müssen die Ablaufverfolgungsdatei schließen und erneut öffnen, um neue Ereignisse anzuzeigen.

Halten Sie einzelne Sitzungen relativ klein, vielleicht zehn Sekunden mit Aktionen, nicht Hunderte Sekunden. Dieser Ansatz erleichtert die Interpretation der Ablaufverfolgungsdatei. Es gibt auch einen Grenzwert für die Größe der Ablaufverfolgungsdatei. Bei langen Sitzungen besteht die Möglichkeit, dass die frühen Ereignisse gelöscht werden.

Grundlegendes zum Format von Abfragen

Das allgemeine Format von Power BI Desktop Abfragen verwendet Unterauswahlen für jede Tabelle, auf die sie verweisen. Die Power Query-Editor Abfrage definiert die Unterauswahlabfragen. Angenommen, Sie verfügen über die folgenden TPC-DS-Tabellen in SQL Server:

Screenshot: TPC-DS-Tabellen in SQL Server

Ausführen der folgenden Abfrage:

SalesAmount (SUMX(Web_Sales, [ws_sales_price]*[ws_quantity]))
by Item[i_category]
for Date_dim[d_year] = 2000

Führt zu dem folgenden Visual in Power BI:

Screenshot: Visuelles Ergebnis einer Abfrage

Das Aktualisieren dieses Visuals erzeugt die SQL-Abfrage in der folgenden Abbildung. Es gibt drei Unterauswahlabfragen für Web_Sales, Itemund Date_dim, die jeweils alle Spalten der jeweiligen Tabelle zurückgeben, obwohl das Visual nur auf vier Spalten verweist.

Screenshot der sql-Abfrage, die wie angegeben verwendet wird.

Power Query-Editor definiert die genauen Unterauswahlabfragen. Diese Verwendung von Unterauswahlabfragen wirkt sich nicht auf die Leistung für die von DirectQuery unterstützten Datenquellen aus. Datenquellen wie SQL Server optimieren die Verweise auf die anderen Spalten.

Power BI verwendet dieses Muster, da der Analyst die SQL-Abfrage direkt bereitstellt. Power BI verwendet die Abfrage wie angegeben, ohne dass versucht wird, sie neu zu schreiben.

Nächste Schritte

Weitere Informationen zu DirectQuery in Power BI finden Sie unter:

In diesem Artikel wurden Aspekte von DirectQuery beschrieben, die für alle Datenquellen gelten. Ausführliche Informationen zu bestimmten Quellen finden Sie in den folgenden Artikeln: