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. Durch das Importieren von Daten in Power BI, was den einfachsten Weg darstellt, Daten abzurufen 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 Optionen für die Power BI-Datenkonnektivität.
• Anleitungen dazu, wann DirectQuery anstelle des Imports verwendet werden sollte.
• Einschränkungen und Auswirkungen der Verwendung von DirectQuery.
• Empfehlungen für die erfolgreiche Verwendung von DirectQuery.
• Wie Sie DirectQuery-Leistungsprobleme diagnostizieren.

Der Artikel konzentriert sich auf den DirectQuery-Workflow beim Erstellen eines Berichts in Power BI Desktop, behandelt aber auch die Verbindung über DirectQuery im Power BI-Dienst.

Power BI-Konnektivitätsmodi

Power BI stellt eine Verbindung zu einer großen Anzahl verschiedener Datenquellen her, wie 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 in Power BI-Datenquellen. DirectQuery-fähige Quellen sind in erster Linie Quellen, die eine gute interaktive Abfrageleistung bieten können.

Importieren Sie Dateien in Power BI, wann immer dies möglich ist. Das Importieren nutzt die leistungsstarke Abfrage-Engine von Power BI, und Sie erhalten eine hoch interaktive und vollständig ausgestattete Erfahrung.

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, sollten Sie DirectQuery verwenden. Die Verwendung von DirectQuery ist jedoch nur möglich, wenn die zugrunde liegende Datenquelle interaktive Abfragen (weniger als fünf Sekunden für die typische Aggregatabfrage) bereitstellen und die generierte Abfragelast verarbeiten kann. Berücksichtigen Sie sorgfältig die Einschränkungen und Auswirkungen der Verwendung von DirectQuery.

Die Power BI-Import- und DirectQuery-Funktionen entwickeln sich mit der Zeit weiter. Änderungen, die mehr Flexibilität bei der Verwendung importierter Daten bieten, ermöglichen es Ihnen, häufiger zu importieren und einige der Nachteile der Verwendung von DirectQuery zu beseitigen. Unabhängig von den Verbesserungen bleibt die Leistung der zugrunde liegenden Datenquelle bei Verwendung von DirectQuery immer ein wichtiger Gesichtspunkt. Wenn die zugrunde liegende Datenquelle langsam ist, kann DirectQuery für diese Quelle nicht verwendet werden.

Die folgenden Abschnitte behandeln diese drei Optionen für die Verbindung zu Daten: Import, DirectQuery und Live-Verbindung. 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, sind die folgenden Konnektivitätsbedingungen vorhanden:

• Wenn Sie zunächst Daten abrufen verwenden, definiert jeder von Ihnen 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 verbinden.

• Nach dem Laden werden alle durch diese 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, da alle Änderungen am Visual sofort wiedergegeben 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 Semantikmodell, das die importierten Daten enthält, erstellt und hochgeladen. Sie können dann die Datenaktualisierung planen, um die Daten beispielsweise täglich neu zu importieren. Abhängig vom Speicherort der ursprünglichen Datenquelle ist es möglicherweise erforderlich, ein lokales Datengateway zu konfigurieren.

• Wenn Sie einen bestehenden Bericht öffnen oder einen neuen Bericht im Power BI-Dienst verfassen, werden die importierten Daten erneut abgefragt, so dass die Interaktivität gewährleistet ist.

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

DirectQuery-Verbindungen

Wenn Sie DirectQuery verwenden, um eine Verbindung mit einer Datenquelle in Power BI Desktop herzustellen, sind die folgenden Datenkonnektivitätsbedingungen vorhanden:

• Sie verwenden Daten abrufen, um die Quelle auszuwählen. Für relationale Datenquellen wird ein Satz von Tabellen ausgewählt, und jede Tabelle definiert weiterhin eine Abfrage, die logisch einen Satz von Daten zurückgibt. Für mehrdimensionale Quellen wie SAP Business Warehouse (SAP BW) wählen Sie nur die Quelle aus.

• Beim Laden werden jedoch keine Daten in den Power BI-Speicher importiert. Wenn Sie ein Visual in Power BI Desktop erstellen, werden Abfragen zum Abrufen der erforderlichen Daten an die zugrunde liegende Quelle gesendet. 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 jedem vorhandenen visuellen Element wiedergegeben. Eine Aktualisierung ist trotzdem erforderlich. Power BI Desktop die erforderlichen Abfragen für jedes Visual erneut senden und das Visual nach Bedarf aktualisiert.

• Durch die Veröffentlichung des Berichts im Power BI-Dienst wird ein Semantikmodell erstellt und hochgeladen, das mit dem Import identisch ist. Dieses Semantikmodell enthält jedoch keine Daten.

• Beim Öffnen eines vorhandenen Bericht oder beim Erstellen eines neuen im Power BI-Dienst wird die zugrunde liegende Datenquelle erneut abgefragt, um die benötigten Daten abzurufen. Je nachdem, wo sich die ursprüngliche Datenquelle befindet, kann es erforderlich sein, ein lokales Daten-Gateway zu konfigurieren, um die Daten zu erhalten.

• Sie können Visuals oder ganze Berichtsseiten als Dashboardkacheln anheften. Um sicherzustellen, dass das Öffnen eines Dashboards schnell ausgeführt wird, werden die Kacheln nach einem Zeitplan automatisch aktualisiert, z. B. einmal pro Stunde. 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.

• Die Kacheln geben beim Öffnen eines Dashboards die Daten zum Zeitpunkt der letzten Aktualisierung wider und nicht unbedingt die neuesten Änderungen, die an der zugrunde liegenden Quelle vorgenommen wurden. Sie können ein geöffnetes Dashboard aktualisieren, um sicherzustellen, dass es aktuell ist.

Liveverbindungen

Beim Herstellen einer Verbindung mit SQL Server Analysis Services können Sie auswählen, die Daten zu importieren oder eine Liveverbindung zu nutzen. Die Verwendung einer Liveverbindung ist ähnlich wie DirectQuery. Es werden keine Daten importiert und die zugrunde liegende Datenquelle wird abgefragt, um ein visuelles Element 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 Felderliste angezeigt.

Diese Situation gilt auch, wenn Sie eine Verbindung mit den folgenden Quellen herstellen, außer es gibt keine Möglichkeit zum Importieren der Daten:

• Power BI-Semantikmodelle, z. B. beim Herstellen einer Verbindung mit einem Power BI-Semantikmodell, das bereits im Dienst veröffentlicht wurde, 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:

• Beim Öffnen eines vorhandenen Berichts im Power BI-Dienst oder beim Schreiben eines neuen Berichts wird die zugrunde liegende SQL Server Analysis Services-Quelle abgefragt, wobei möglicherweise ein lokales Datengateway erforderlich ist.

• Dashboardkacheln werden automatisch nach einem Zeitplan aktualisiert, z. B. einmal pro Stunde.

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

DirectQuery-Anwendungsfälle

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

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

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

Die Daten ändern sich häufig, und Sie benötigen eine Berichterstellung nahezu in Echtzeit.

Modelle mit importierten Daten können höchstens einmal pro Stunde aktualisiert werden; oder häufigere Aktualisierungen sind mit einem Power BI Pro- oder Power BI Premium-Abonnement möglich. Wenn sich die Daten kontinuierlich ändern und Berichte die neuesten Daten zeigen müssen, ist die Verwendung des Imports mit geplanter Aktualisierung womöglich nicht für Anforderungen dieser Art geeignet. Sie können Daten direkt in Power BI streamen. Es gibt jedoch Grenzwerte für die unterstützten Datenvolumes.

Wenn Sie im Gegensatz dazu DirectQuery verwenden, bedeutet dies, dass beim Öffnen oder Aktualisieren eines Berichts oder Dashboards immer die neuesten Daten in der Datenquelle angezeigt werden. Darüber hinaus können die Dashboardkacheln häufiger aktualisiert werden, bis hin zu 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 im Gegensatz dazu keinen großen Datentransfer, da die Abfrage direkt durchgeführt wird. Große Daten können jedoch auch dazu führen, dass die Leistung von Abfragen gegen diese zugrunde liegende Quelle zu langsam wird.

Sie müssen nicht immer die vollständigen Detaildaten importieren. Mit dem Power Abfrage-Editor können Sie während des Imports leicht die vorab erforderliche Aggregation durchführen. Technisch ist es möglich, genau die aggregierten Daten zu importieren, die Sie für jedes visuelle Element benötigen. Während DirectQuery der einfachste Ansatz für große Daten ist, kann der Import von aggregierten Daten eine Lösung sein, wenn die zugrunde liegende Datenquelle für DirectQuery zu langsam ist.

Diese Details beziehen sich auf die alleinige Verwendung von Power BI. Weitere Informationen zum Verwenden von großen Modellen in Power BI finden Sie unter Große Semantikmodelle 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 zur Datenquelle her, indem es die Power BI Desktop-Anmeldeinformationen des aktuellen Benutzers oder die Anmeldeinformationen verwendet, die für die geplante Aktualisierung durch den Power BI-Dienst konfiguriert wurden. Bei der Veröffentlichung und Freigabe von Berichten mit importierten Daten müssen Sie darauf achten, dass die Freigabe nur für Benutzer*innen erfolgt, die die Daten sehen dürfen, oder Sie müssen die Sicherheit auf Zeilenebene als Teil des Semantikmodells definieren.

DirectQuery ermöglicht es, die Anmeldeinformationen eines Berichts-Viewers an die zugrunde liegende Quelle zu übergeben, 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 in der Übersicht über das einmalige Anmelden (SSO) für lokale Datengateways 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. Im Gegensatz dazu verbleiben Daten mit DirectQuery in der zugrunde liegenden Quelle. Sogar mit DirectQuery werden einige Caches von Daten auf der visuellen Ebene im Power BI-Dienst aufgrund einer geplanten Aktualisierung von Kacheln beibehalten.

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 sie von der Abfrage definiert wird. Ein Visual, das Daten in einem Aggregat auf höherer Ebene anfragt, z. B . TotalSales nach Jahr, aggregiert den Aggregatwert weiter. Für additive Measures wie Sum und Min ist diese Aggregation kein Problem. Für nicht additive Measure, z. B. Average, DistinctCount, kann dies ein Problem darstellen.

Das einfache Abrufen der richtigen aggregierten Daten, die für ein Visual direkt aus der Quelle benötigt werden, erfordert das Senden von Abfragen pro Visual, wie in DirectQuery. Wenn Sie eine Verbindung zum SAP BW herstellen, ermöglicht die Auswahl von DirectQuery diese Behandlung von Kennzahlen. Weitere Informationen finden Sie unter DirectQuery und SAP BW.

Allerdings wird die Datenquelle derzeit von DirectQuery via SAP HANA genauso wie eine relationale Quelle behandelt, was sich beim Verhalten für den Import widerspiegelt. 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 von der genauen Quelle, die Sie verwenden. In den folgenden Abschnitten werden allgemeine 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. Hinsichtlich der Verwendung von Caches gibt es keine Garantie, dass das visuelle Element immer die neuesten Daten anzeigt. Ein visuelles Element kann möglicherweise die Transaktionen des letzten Tags anzeigen. Eine Datenschnittänderung kann das Visual aktualisieren, um Transaktionen für die letzten zwei Tage anzuzeigen, einschließlich der letzten, neu eingetroffenen Transaktionen. Die Umwandlung des Slicers in seinen ursprünglichen Wert würde dazu führen, dass wieder die zuvor abgerufenen zwischengespeicherten Werte angezeigt werden. Wenn Sie Aktualisieren auswählen, werden sämtliche Caches geleert, und alle visuellen Elemente auf der Seite werden aktualisiert, damit sie die neuesten Daten anzeigen.

• Wenn Daten geändert werden, besteht keine Garantie der Konsistenz zwischen visuellen Elementen. Andere Visuals, egal ob auf derselben Seite oder auf verschiedenen Seiten, werden möglicherweise zu unterschiedlichen Zeiten aktualisiert. Wenn die Daten in der zugrunde liegenden Quelle geändert werden, kann nicht garantiert werden, dass jedes visuelle Elemente die Daten zu exakt demselben Zeitpunkt anzeigt.

  Wenn tatsächlich davon ausgegangen wird, dass manchmal mehr als eine Abfrage für ein einzelnes visuelles Element benötigt wird, z. B. um die Details und Gesamtwerte abzurufen, kann die Konsistenz auch für ein einzelnes visuelles Element nicht garantiert werden. Damit diese Konsistenz gewährleistet werden kann, ist sobald ein visuelles Element aktualisiert wird, der Aktualisierungsaufwand aller visuellen Elemente erforderlich, zusammen mit dem Gebrauch der zahlungspflichtigen Funktionen wie der Momentaufnahmeisolation in der zugrunde liegenden Quelle.

  Dieses Problem kann weitgehend minimiert werden, indem Sie erneut Aktualisieren auswählen, wodurch alle visuellen Elemente auf der Seite aktualisiert werden. Auch im Importmodus gibt es ein ähnliches Problem, nämlich die Wahrung der Konsistenz, wenn Sie Daten aus mehr als einer Tabelle importieren.

• Sie müssen in Power BI Desktop aktualisieren, um Schemaänderungen widerzuspiegeln. Nachdem ein Bericht veröffentlicht wurde, aktualisiert Aktualisieren im Power BI-Dienst die Visuals im Bericht. 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 Datenquelle entfernt wurden, kann es dazu kommen, dass die Abfrage bei der Aktualisierung fehlschlägt. Um die Felder im Modell zu aktualisieren, damit sie die Änderungen widerspiegeln, müssen Sie den Bericht in Power BI Desktop öffnen und Aktualisieren wählen.

• Für jede Abfrage kann ein Grenzwert von 1 Million Zeilen zurückgegeben werden. Für die Anzahl von Zeilen, die in einer einzelnen Abfrage an die zugrunde liegende Quelle zurückgegeben werden, gibt es eine festgelegte maximale Anzahl von einer Million Zeilen. Diese Beschränkung hat in der Regel keine praktische Auswirkung, und visuelle Elemente werden selbst nicht so viele Punkte anzeigen. Allerdings kann die Begrenzung in Fällen auftreten, in denen Power BI die gesendeten Abfragen nicht vollständig optimiert und Zwischenergebnisse angefragt werden, die diese Begrenzung übersteigen.

  Sie kann auch während der Erstellung eines visuellen Elements auf dem Pfad zu einem akzeptableren Endzustand auftreten. Beispielsweise würde das Einschließen von Customer und TotalSalesQuantity diese Begrenzung erreichen, falls es mehr als eine Million Kunden gibt, bis einige Filter angewendet werden. Fehlerbeschreibung: „Das Resultset einer Abfrage einer externen Datenquelle hat die maximal zulässige Größe von '1000000' 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 umwandeln. 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 zum DirectQuery-Modus zu wechseln, vor allem aufgrund des Featuresatzes, den der DirectQuery-Modus nicht unterstützt. Bei multidimensionalen Quellen wie SAP BW können Sie aufgrund der unterschiedlichen Behandlung externer Kennzahlen auch nicht vom DirectQuery- in den Importmodus wechseln.

Auswirkungen auf Leistung und Auslastung

Bei Verwendung von DirectQuery hängt die allgemeine Erfahrung sehr 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 die Benutzeroberfläche angemessen, obwohl sich dies im Vergleich zur unmittelbaren Antwort mit importierten Daten möglicherweise schleppend anfühlt. Wenn die Langsamkeit der Quelle dazu führt, dass einzelne visuelle Elemente länger als zehn Sekunden dauern, wird die Erfahrung äußerst schlecht. Abfragen können sogar ein Timeout bewirken.

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. Dies erfordert, dass die Quelle solch eine Abfragelast verarbeiten kann, während sie gleichzeitig eine akzeptable Leistung beibehält.

Folgen für die Sicherheit

Sofern die zugrunde liegende Datenquelle einmaliges Anmelden nicht verwendet, verwendet ein DirectQuery-Bericht immer dieselben festen Anmeldeinformationen, um eine Verbindung mit der Quelle herzustellen, sobald er 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 konfigurieren, würde das Öffnen des Berichts über den Power BI-Dienst zu einem Fehler führen.

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

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

• Außerdem werden „alternative Anmeldeinformationen“ nicht unterstützt, wenn in Power BI Desktop DirectQuery-Verbindungen zu SQL Server hergestellt werden. 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 zu verstehen, wie Daten zwischen den zugrunde liegenden Datenquellen ausgetauscht werden und welche Auswirkungen auf die Sicherheit daraus resultieren.

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. Beispielsweise können Sie JSON-Dokumente analysieren oder Daten aus einer Spalte in ein Zeilenformular pivotieren. Diese Transformationen sind in DirectQuery beschrä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 ist es noch immer möglich, mehrere Transformationen pro Abfrage zu bestimmen. Diese Transformationen sind jedoch 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 Transformation verwenden, die zu komplex ist, erhalten Sie einen Fehler, der angibt, dass sie entweder gelöscht oder das Verbindungsmodell in den Importmodus versetzt 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. Die im Power Abfrage-Editor definierte Abfrage muss in diesem Kontext gültig sein. Es ist insbesondere weder möglich, eine Abfrage mithilfe von allgemeinen Tabellenausdrücken zu verwenden, noch eine Abfrage, die gespeicherte Prozeduren aufruft.

Modellierungseinschränkungen

Der Begriff Modellierung bezeichnet in diesem Kontext den Vorgang zum Verfeinern und Anreichern der Rohdaten im Rahmen der Erstellung von Berichten, in denen sie verwendet werden. Beispiele für die Modellierung sind:

• Definieren von Beziehungen zwischen Tabellen
• Hinzufügen von neuen Berechnungen (berechnete Spalten und Measures)
• Umbenennen und Ausblenden von Spalten und Measures
• Definieren von Hierarchien
• Definieren der Formatierung, Standardzusammenfassung und Sortierreihenfolge für eine Spalte
• Gruppierungs- oder Clusterwerte

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. Allerdings sind einige Modellierungsfunktionen nicht verfügbar oder bei der Verwendung von DirectQuery eingeschränkt. Im Allgemeinen werden Einschränkungen 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: Wenn Sie Daten importieren, erhält jede date/datetime-Spalte eine integrierte Datumshierarchie, die standardmäßig verfügbar ist. Wenn Sie z. B. eine Tabelle mit Verkaufsaufträgen importieren, die eine Spalte OrderDate enthält, und OrderDate in einem visuellen Element verwenden, können Sie die entsprechende Datumsebene auswählen, z. B. Jahr, Monat oder Tag. Diese integrierte Datumshierarchie ist nicht verfügbar, wenn Sie DirectQuery verwenden. Wenn in der zugrundeliegenden Quelle eine Datumstabelle vorhanden ist, wie es in vielen Data Warehouses üblich ist, können Sie wie gewohnt die Zeiterkennungsfunktionen von Data Analysis Expressions (DAX) verwenden.

• Unterstützung für Datum/Uhrzeit nur auf Sekundenebene: Für Semantikmodelle, 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 sind darauf beschränkt, dass sie zeilenintern sind. Das bedeutet, dass sie sich nur auf Werte anderer Spalten derselben Tabelle beziehen können, ohne Aggregatfunktionen zu benutzen. Zusätzlich sind die erlaubten DAX-Skalarfunktionen, z. B. LEFT(), auf die Funktionen beschränkt, die per Push an die zugrunde liegende Quelle gesendet werden können. Die Funktionen variieren je nach den genauen Möglichkeiten der Quelle. Nicht unterstützte Funktionen werden nicht in AutoVervollständigen aufgelistet, wenn DAX für eine berechnete Tabelle erstellt wird, und würden bei Benutzung einen Fehler auslösen.

• Keine Unterstützung für über- und untergeordnete DAX-Funktionen: Wenn Sie sich im DirectQuery-Modell befinden, ist die Verwendung der DAX PATH()-Funktionsfamilie nicht möglich, die normalerweise die Strukturen der über- und untergeordneten Funktionen behandeln (etwa als Kontenplan 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. Daher ist es möglich, solange die zugrunde liegenden Datenquelle ein geeignetes Maß an Leistung bietet, den gleichen Satz von Visualisierungen zu verwenden.

Eine allgemeine Einschränkung besteht darin, dass die maximale Länge der Daten in einer Textspalte für DirectQuery-Semantikmodelle 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: Visuelle Elemente, die Measures (oder Aggregate von Spalten) enthalten, können Filter in diesen Measures enthalten. Das visuelle Element unten zeigt z. B. SalesAmount nach Category an, aber nur einschließlich dieser Kategorien mit mehr als 20M Verkäufen.

  

  Dieser Ansatz führt dazu, dass zwei Abfragen an die zugrunde liegende Datenquelle gesendet werden:

  • Die erste Abfrage ruft die Kategorien ab, die die Bedingung erfüllen (SalesAmount größer als 20 Millionen).
  • Die zweite Abfrage ruft die notwendigen Daten für das visuelle Element ab, einschließlich der Kategorien, die die Bedingung in der WHERE-Klausel erfüllen.

  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: Erweiterte Filter können so definiert werden, dass nur die oberen oder unteren N Werte gefiltert werden, die nach einem bestimmten Measure geordnet sind. So können die Filter z. B. die zehn obersten Kategorien einbeziehen. Dieser Ansatz führt dazu, dass zwei Abfragen an die zugrunde liegende Datenquelle gesendet werden: Allerdings gibt die erste Abfrage alle Kategorien der zugrunde liegenden Quelle zurück, dann werden die TopN basierend auf den zurückgegebenen Ergebnissen bestimmt. Je nach Kardinalität der betreffenden Spalte kann dieser Ansatz zu Leistungsproblemen oder Abfragefehlern führen, da die Abfrageergebnisse auf eine Million Zeilen begrenzt sind.

• Median: Im Allgemeinen wird jede Aggregation wie Sum oder Count Distinct per Push an die zugrunde liegende Quelle gesendet. In der Regel wird das median-Aggregat jedoch von der zugrunde liegenden Quelle nicht unterstützt. Für median werden die Detaildaten aus der zugrunde liegenden Quelle abgerufen und der Median wird aus den zurückgegebenen Ergebnissen berechnet. Dieser Ansatz ist sinnvoll, wenn der Median über eine relativ kleine Anzahl von Ergebnissen berechnet werden soll.

  Bei großer Kardinalität kommt es zu Leistungsproblemen oder Abfrageausfällen aufgrund des Zeilengrenzwerts von einer Million. Den Median der Bevölkerungszahl eines Landes/einer Region zu ermitteln, kann sinnvoll sein, nicht jedoch die Ermittlung des Medians von Verkaufspreisen.

• Erweiterte Textfilter wie „contains": Die erweiterte Filterung für eine Textspalte ermöglicht Filter wie contains und begins with. Diese Filter können sicherlich zu Leistungseinbußen bei einigen Datenquellen führen. Verwenden Sie insbesondere nicht den Standardfilter contains , wenn Sie eine genaue Übereinstimmung benötigen. Obwohl das Ergebnis möglicherweise identisch ist, kann sich abhängig von den tatsächlichen Daten die Leistung aufgrund der Verwendung von Indizes erheblich unterscheiden.

• Datenschnitte mit Mehrfachauswahl: Standardmäßig erlauben Datenschnitte nur eine einzige Auswahl. Das Zulassen der Mehrfachauswahl in Datenschnitten und Filtern kann zu Leistungsproblemen führen. Wenn der Benutzer z. B. die für ihn interessanten zehn 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 auf den Tabellen-Visuals: Standardmäßig werden Summen und Teilsummen in Tabellen und Matrizen angezeigt. In vielen Fällen erfordert das Abrufen der Werte für solche Summen das Senden separater Abfragen an die zugrunde liegende Quelle. Dies gilt immer, wenn die Aggregation DistinctCount verwendet wird oder wenn 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.

Leistung der Back-End-Datenquelle

Überprüfen Sie, ob einfache visuelle Elemente innerhalb von fünf Sekunden aktualisiert werden, um eine angemessene interaktive Oberfläche zu bieten. Wenn die Aktualisierung von visuellen Elementen 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 Abfragen, die an die zugrunde liegende Quelle gesendet werden, und den Grund für die Abfrageleistung. Weitere Informationen finden Sie unter Leistungsdiagnosen.

In diesem Artikel wird die breite Palette der bewährten Methoden zur Datenbankoptimierung für die gesamten potenziellen zugrunde liegenden Quellen nicht behandelt. Ziehen Sie die folgenden Standardvorgehensweisen für Datenbanken in Betracht, die in den meisten Fällen passen:

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

• Erstellen Sie die entsprechenden Ordner. Indexerstellung bedeutet im Allgemeinen die Verwendung von Columnstore-Indizes in den 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. Zumindest am Anfang wird empfohlen, Measures auf einfache Aggregate zu beschränken. 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 am meisten verwendete Problemumgehung ist, die Spalten mithilfe einer berechneten Spalte zu verknüpfen und dann den Join auf Basis dieser Spalte zu basieren.

  Während diese Problemumgehung für importierte Daten sinnvoll ist, führt sie bei DirectQuery zu einem Join für einen Ausdruck. Dieses Ergebnis verhindert in der Regel die Verwendung von Indizes und führt zu einer schlechten Leistung. Die einzige Problemumgehung ist tatsächlich, die vielen Spalten in eine einzige Spalte in der zugrunde liegenden Datenbank zu materialisieren.

• Vermeiden Sie Beziehungen zwischen „uniqueidentifier“-Spalten. Power BI verfügt nicht über die native Unterstützung für den Datentyp uniqueidentifier. Die Definition einer Beziehung zwischen Spalten vom Typ uniqueidentifier-Spalte führt zu einer Abfrage mit einem Join, der eine Umwandlung umfasst. Auch dieser Ansatz führt häufig zu schlechter Leistung. Die einzige Abhilfe besteht darin, Spalten eines anderen Typs in der zugrunde liegenden Datenquelle zu materialisieren.

• Blenden Sie die „to“-Spalte für Beziehungen aus. Die to-Spalte für Beziehungen ist üblicherweise 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 von Bedeutung ist, führen Sie eine berechnete sichtbare Spalte ein, die über einen einfachen Ausdruck verfügt, wonach sie mit dem Primärschlüssel gleich ist.

      ProductKey_PK   (Destination of a relationship, hidden)
      ProductKey (= [ProductKey_PK],   visible)
      ProductName
      ...
  

• Überprüfen Sie alle Vorkommen von berechneten Spalten und Änderungen des Datentyps. Sie können berechnete Tabellen verwenden, wenn Sie DirectQuery mit zusammengesetzten Modellen verwenden. Diese Funktionen sind nicht unbedingt schädlich, aber sie führen zu Abfragen, die Ausdrücke anstelle einfacher Verweise auf Spalten enthalten. Das wiederum kann dazu führen, dass Indizes nicht verwendet werden.

• Vermeiden Sie bidirektionale Kreuzfilterung für Beziehungen. Die Verwendung des bidirektionalen Kreuzfilterns 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 Papier 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 voraussetzen für Beziehungen lässt zu, dass Abfragen INNER JOIN-Anweisungen und nicht OUTER JOIN-Anweisungen verwenden. Diese Anleitung verbessert im Allgemeinen die Abfrageleistung, obwohl dies nicht von den Eigenheiten der Datenquelle abhängt.

• Verwenden Sie nicht die relative Datenfilterung im Power Abfrage-Editor. Es ist möglich, die relative Datenfilterung im Power Abfrage-Editor zu definieren. Ein Beispiel dafür ist es, nach Zeilen zu filtern, in denen das Datum im Zeitraum der letzten 14 Tage liegt.

  

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

  

  Dies ist vermutlich nicht das gewünschte Ergebnis. Um sicherzustellen, dass der Filter basierend auf dem Datum angewendet wird, an dem der Bericht ausgeführt wird, wenden Sie stattdessen den Filter im Bericht als Berichtsfilter an. Sie können eine berechnete Spalte erstellen, die die Anzahl der Tage vor berechnet, indem Sie die DAX DATE() -Funktion verwenden, und diese berechnete Spalte im Filter verwenden.

Berichtsentwurf

Wenn Sie einen Bericht erstellen, der eine DirectQuery-Verbindung verwendet, befolgen Sie diese Anleitung:

• Überlegungen für das Verwenden von Optionen zur Verringerung von Abfragen: Power BI stellt Optionen im Bericht bereit, mit denen weniger Abfragen gesendet und bestimmte Interaktionen deaktiviert werden, die bei langer Ausführung der resultierenden Abfragen zu Leistungseinbußen führen würden. Diese Optionen gelten für Ihren Bericht, während Sie mit Power BI Desktop interagieren, und wenn Ihre Benutzer den Bericht im Power BI-Dienst verwenden.

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

  

  Mithilfe der Auswahl auf dem Bildschirm Abfragereduzierung können Sie die Schaltfläche Anwenden für Slicer oder Filterauswahlen anzeigen. Es werden keine Abfragen gesendet, bis Sie die Schaltfläche Anwenden für den 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. Wenden Sie z. B. den Filter Jahr zu Beginn an, anstatt sich im TotalSalesAmount und ProductName zu bewegen und dann nach einem bestimmten Jahr zu filtern.

  Jeder Schritt beim Erstellen eines visuellen Elements sendet eine Abfrage. Obwohl es möglich ist, Änderungen durchzuführen, bevor die erste Abfrage abgeschlossen ist, hinterlässt dieser Ansatz dennoch unnötige Last auf der zugrunde liegenden Quelle. Wenn Filter früh angewendet werden, werden diese zwischenzeitlichen Abfragen generell günstiger. Darüber hinaus kann es dazu führen, dass die Begrenzung von eine Million Zeilen erreicht wird, wenn die Filter nicht frühzeitig angewendet werden.

• Begrenzen Sie die Anzahl von visuellen Elementen auf einer Seite: Wenn Sie eine Seite öffnen oder einen Slicer oder Filter auf Seitenebene ändern, werden alle visuellen Elemente auf einer 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. Aus diesem Grund wird empfohlen, die Anzahl von visuellen Elementen auf einer Seite zu begrenzen, und stattdessen mehr einfachere Seiten zu haben.

• Überlegen Sie, die Interaktion zwischen visuellen Elementen 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 z. B. 1999 auf dem Kreisdiagramm ausgewählt ist, wird das Säulendiagramm übergreifend hervorgehoben, um die Verkäufe nach Kategorie für 1999 anzuzeigen.

  

  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 benötigt wird, um auf die Auswahl der Benutzer zu reagieren, unangemessen lang ist.

  Sie können die Einstellungen für die Abfragereduzierung verwenden, um die Kreuzheraufhebung 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>Optionen, und wählen Sie im Abschnitt Aktuelle Datei im linken Bereich DirectQuery aus.

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

Die Erhöhung der Option Maximale Verbindungsanzahl pro Datenquelle stellt sicher, dass mehr Abfragen bis zu der angegebenen maximalen Anzahl an die zugrunde liegende Datenquelle gesendet werden können. 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 Erhöhen dieses Grenzwerts führt zu mehr Last auf der zugrunde liegenden Quelle. Daher ist nicht garantiert, dass durch die Einstellung 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 in der Zielumgebung festgelegt sind, in der der Bericht veröffentlicht wird. Power BI, Power BI Premium und Power BI Report Server legen unterschiedliche Grenzen fest. 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.

Umgebung	Obergrenze pro Datenquelle
Power BI Pro	10 aktive Verbindungen
Power BI Premium	Hängt von der SKU-Einschränkung des Semantikmodells ab.
Power BI-Berichtsserver	10 aktive Verbindungen

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. Beispielsweise ist es möglich, dass ein Geschäftsbenutzer Power BI zum Herstellen einer Verbindung mit den Daten in Salesforce verwendet und sofort ohne die Verwendung von Power BI Desktop ein Dashboard abrufen kann.

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

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

Auch 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 bei der weiteren Verbesserung des resultierenden Berichts. Es ist dann z. B. nicht möglich, Berechnungen zu erstellen oder viele analytische Features zu verwenden oder sogar die Metadaten zu aktualisieren, um Änderungen des zugrunde liegenden Schemas 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.

Verhalten im Power BI-Dienst

Wenn Sie einen Bericht im Power BI-Dienst öffnen, werden alle Visuals auf der derzeit sichtbaren Seite aktualisiert. Jedes visuelle Element erfordert in der Regel mindestens eine Abfrage für die zugrunde liegenden Datenquelle. Einige visuelle Elemente erfordern möglicherweise mehr als eine Abfrage. Ein visuelles Element kann z. B. aggregierte Werte aus zwei verschiedenen Faktentabellen anzeigen oder ein komplexeres Measure oder die Summe eines nicht additiven Measure 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. Dasselbe gilt für das Klicken auf ein visuelles Element, um andere visuelle Elemente hervorzuheben oder einen Filter zu ändern. In ähnlicher Weise erfordert die Bearbeitung eines neuen Berichts das Senden von Abfragen für jeden Schritt auf dem Weg zur Erstellung des endgültigen visuellen Elements.

Es erfolgt eine Zwischenspeicherung der Ergebnisse. Die Aktualisierung eines visuellen Elements erfolgt augenblicklich, wenn vor kurzem genau dieselben Ergebnisse erzielt wurden. Wenn keine Sicherheit auf Zeilenebene definiert ist, werden solche Caches nicht von den Benutzern gemeinsam genutzt.

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 durchsuchen schnell verschiedene Teilmengen des Semantikmodells unter Verwendung eines hoch entwickelten Algorithmus, um potenziell interessante Erkenntnisse zu gewinnen. Da Quick Insights hochleistungsfähige Abfragen erfordern, ist dieses Feature für Semantikmodelle, die DirectQuery verwenden, nicht verfügbar.

• Die Verwendung von Explore in Excel beeinträchtigt die Leistung: Sie können ein Semantikmodell 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 Semantikmodelle unterstützt, die DirectQuery verwenden, aber die Leistung ist langsamer als beim Erstellen von visuellen Elementen 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-Semantikmodellen, die DirectQuery verwenden, definiert sind.

Dashboard-Aktualisierung

Im Power BI-Dienst können Sie einzelne visuelle Elemente oder ganze Seiten als Kacheln an Dashboards anheften. Kacheln, die auf DirectQuery-Semantikmodellen basieren, werden automatisch aktualisiert, indem Abfragen nach einem Zeitplan an die zugrunde liegenden Datenquellen gesendet werden. Standardmäßig werden Semantikmodelle einmal pro Stunde aktualisiert, Sie können jedoch in den Semantikmodelleinstellungen die Intervalle für Aktualisierungen für einen Zeitraum zwischen „Wöchentlich“ oder „Alle 15 Minuten“ festlegen.

Wenn keine Sicherheit auf Zeilenebene im Modell 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.

Andernfalls kann sich ein großer Multiplikatoreffekt ergeben. Ein Dashboard mit 10 Kacheln, das von 100 Benutzer*innenn gemeinsam genutzt wird und auf einem Semantikmodell mit DirectQuery mit Sicherheit auf Zeilenebene erstellt wurde, führt dazu, dass bei jeder Aktualisierung mindestens 1,000 Abfragen an die zugrunde liegende Datenquelle gesendet werden. Achten Sie sorgfältig auf die Verwendung der Sicherheit auf Zeilenebene und die Konfiguration des Aktualisierungszeitplans.

Zeitüberschreitungen bei Abfragen

Ein Timeout von vier Minuten wird für einzelne Abfragen für den Power BI-Dienst angewendet. Abfragen, die länger als vier Minuten dauern, schlagen fehl. Diese Einschränkung soll verhindern, dass Probleme durch zu lange Ausführungszeiten entstehen. Sie sollten DirectQuery nur für Quellen verwenden, die interaktive Abfrageleistung bieten können.

Leistungsdiagnose

Dieser Abschnitt beschreibt, wie Sie Leistungsprobleme diagnostizieren oder weitere Informationen darüber erhalten können, wie Berichte optimiert werden.

Es wird empfohlen, die Diagnose von Leistungsproblemen im Power BI Desktop und nicht im Power BI-Dienst zu starten. Leistungsprobleme basieren oft auf der Leistung der zugrunde liegenden Quelle. In der stärker isolierten Umgebung von Power BI Desktop können Sie Probleme leichter identifizieren und diagnostizieren.

Dieser Ansatz verzichtet anfänglich auf bestimmte Komponenten wie das Power BI-Gateway. Wenn die Leistungsprobleme im Power BI Desktop nicht vorhanden sind, untersuchen Sie die Einzelheiten des Berichts im Power BI-Dienst.

Das Power BI Desktop Performance Analyzer ist ein nützliches Tool zum Identifizieren von Problemen. Versuchen Sie, alle Probleme auf ein einziges visuelles Element zu beschränken, anstatt viele visuelle Elemente auf einer Seite zu verwenden. 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 dieses Protokoll alle Abfragen, die an die zugrunde liegende Datenquelle gesendet wurden. 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.

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

1. Wählen Sie zum Abrufen dieses Ordners in Power BI Desktop Datei>Optionen und Einstellungen>Optionen und dann Diagnose aus.

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

   

   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 entsprechende Arbeitsbereichsordner wird gelöscht, wenn die zugehörige 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. Wählen Sie in SQL Server Profiler Datei>Öffnen>Ablaufverfolgungsdatei 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 Gruppe verfügt über folgende Ereignisse:

• 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 Ereignissen für DirectQuery Begin und DirectQuery End stellen eine an die zugrunde liegende Datenquelle gesendete Abfrage als Teil der Auswertung der DAX-Abfrage dar.

Mehrere DAX-Abfragen können parallel ausgeführt werden, damit sich Ereignisse aus verschiedenen Gruppen überlappen können. Der Wert der ActivityID kann verwendet werden, um zu bestimmen, welche Ereignisse zur selben Gruppe gehören.

Die folgenden Spalten sind ebenfalls von Interesse:

• TextData: Die Textdetails des Ereignisses. Bei Query Begin und Query End-Ereignissen ist das Detail die DAX-Abfrage. Bei DirectQuery Begin und DirectQuery End-Ereignissen 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.
• Duration (Dauer): Die Dauer in Millisekunden, die zur Ausführung der DAX- oder SQL-Abfrage benötigt wird.
• Fehler: Gibt an, ob ein Fehler aufgetreten ist. In diesem Fall wird das Ergebnis 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. Schließen Sie einige zusätzliche Aktionen mit ein, um sicherzustellen, dass die interessanten Ereignisse in die Ablaufverfolgungsdatei geleert werden.

3. Öffnen Sie den 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 Subselect-Abfragen. Nehmen wir z.B. an, dass die folgenden TPC-DS-Tabellen in SQL Server vorhanden sind:

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:

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.

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.

Zugehöriger Inhalt

Weitere Informationen zu DirectQuery finden Sie unter DirectQuery in Power BI.

• Verwenden von DirectQuery in Power BI Desktop

Dieser Artikel beschreibt Aspekte von DirectQuery, die für alle Datenquellen üblich sind. Informationen finden Sie in den folgenden Artikeln, die bestimmte Quellen abdecken:

• DirectQuery und SAP HANA
• DirectQuery und SAP BW
• Verwenden von DirectQuery für Power BI-Semantikmodelle und Analysis Services