Leitfaden für die Optimierung von Power BI

  • Artikel

Dieser Artikel enthält Anweisungen, mit denen Entwickler und Administratoren optimierte Power BI-Lösungen erstellen und verwalten können. Sie können Ihre Lösung auf verschiedenen Architekturebenen optimieren. Dazu zählen:

  • Die Datenquelle(n)
  • Das Datenmodell
  • Visualisierungen, einschließlich Dashboards, Power BI-Berichte und paginierte Power BI-Berichte
  • Die Umgebung, einschließlich Kapazitäten, Datengateways und Netzwerk

Optimieren des Datenmodells

Das Datenmodell unterstützt das gesamte Visualisierungserlebnis. Datenmodelle werden entweder im Power BI-Ökosystem oder extern (über DirectQuery oder Live Connection) gehostet. In Power BI werden sie als semantische Modelle bezeichnet – zuvor als Datensätze bekannt. Sie sollten mit den verfügbaren Optionen vertraut sein und den geeigneten Typ des semantischen Modells für Ihre Lösung auswählen. Es gibt drei Modi für semantische Modelle: „Import“, „DirectQuery“ und „Zusammengesetzt“. Weitere Informationen finden Sie unter Semantische Modelle im Power BI-Dienst und Modi von semantischen Modellen im Power BI-Dienst.

Spezielle Anleitungen zum Modus des semantischen Modells finden Sie unter:

Optimieren von Visualisierungen

Bei Power BI-Visualisierungen kann es sich um Dashboards, Power BI-Berichte oder paginierte Power BI-Berichte handeln. Da jede dieser Visualisierungen über eine eigene Architektur verfügt, gelten jeweils individuelle Anweisungen.

Dashboards

Power BI verfügt über einen Cache für Ihre Dashboardkacheln (mit Ausnahme von Liveberichtskacheln und Streamingkacheln). Wenn Ihr semantisches Modell eine dynamische Sicherheit auf Zeilenebene (Row-Level Security, RLS) erzwingt, sollten Sie mit den Auswirkungen auf die Leistung vertraut sein, da Kacheln pro Benutzer zwischengespeichert werden.

Wenn Sie Liveberichtskacheln im Dashboard anheften, werden sie nicht aus dem Abfragecache bereitgestellt. Stattdessen entspricht das Verhalten dem regulären Berichtsverhalten, sodass Abfragen nach Bedarf an V-Kerne erfolgen.

Wie der Name bereits vermuten lässt, bietet das Abrufen der Daten aus dem Abfragecache eine bessere und konsistentere Leistung als das Verwenden der Datenquelle. Eine Möglichkeit zum Nutzen dieser Funktionalität besteht darin, Dashboards als erste Landing Page für die Benutzer anzuzeigen. Heften Sie häufig verwendete und stark nachgefragte Visuals an die Dashboards an. Auf diese Weise werden Dashboards eine wertvolle „erste Abwehrlinie“ und bieten eine konsistente Leistung bei geringerer Beanspruchung der Kapazität. Die Benutzer können immer noch durch den Bericht klicken, um die Details zu analysieren.

Bei den semantischen Modellen DirectQuery und Live-Verbindung wird der Cache in regelmäßigen Abständen durch Abfrage der Datenquelle aktualisiert. Standardmäßig geschieht dies stündlich, aber Sie können in den Einstellungen des semantischen Modells eine andere Häufigkeit festlegen. Bei jeder Aktualisierung des Caches werden Abfragen an die zugrunde liegende Datenquelle gesendet, um den Cache zu aktualisieren. Die Anzahl der generierten Abfragen ist abhängig von der Anzahl der an Dashboards angehefteten Visuals, die diese Datenquelle benötigen. Beachten Sie, dass bei Aktivieren der Sicherheit auf Zeilenebene für jeden einzelnen Sicherheitskontext Abfragen generiert werden. Angenommen, Ihre Benutzer werden mithilfe von zwei Rollen kategorisiert, und es gibt zwei unterschiedliche Ansichten der Daten. Bei der Aktualisierung des Abfragecaches generiert Power BI zwei Sätze von Abfragen.

Power BI-Berichte

Für die Optimierung von Power BI-Berichtsentwürfen sind eine Reihe von Empfehlungen verfügbar.

Hinweis

Wenn Berichte auf einem semantischen Modell von DirectQuery basieren, finden Sie unter Leitfaden für das DirectQuery-Model in Power BI Desktop (Optimieren von Berichtsentwürfen) weitere Optimierungen für Berichtsentwürfe.

Anwenden der restriktivsten Filter

Je mehr Daten in einem Visual angezeigt werden müssen, umso länger dauert das Laden des Visuals. Auch wenn dieses Prinzip offensichtlich erscheint, gerät es leicht in Vergessenheit. Beispiel: Angenommen, Sie haben ein großes semantisches Modell. Basierend auf diesem semantischen Modell erstellen Sie einen Bericht mit einer Tabelle. Die Endbenutzer verwenden Slicer auf der Seite, um die gewünschten Zeilen abzurufen – in der Regel sind sie nur an wenigen Dutzend Zeilen interessiert.

Ein häufiger Fehler besteht darin, dass die Standardansicht der Tabelle nicht gefiltert ist und alle Zeilen zeigt, in diesem Fall über 100 Millionen. Die Daten für diese Zeilen werden in den Arbeitsspeicher geladen und bei jeder Aktualisierung dekomprimiert. Diese Art der Verarbeitung geht mit hohen Arbeitsspeicheranforderungen einher. Die Lösung: Verwenden Sie den Filter „Top N“, um die maximale Anzahl von Elementen zu verringern, die in der Tabelle angezeigt werden. Sie können die maximale Anzahl von Elementen auf einen deutlich höheren Wert festlegen als die Menge, die Benutzer benötigen, z. B. 10.000. Das Ergebnis hiervon ist, dass sich die Benutzeroberfläche für Endbenutzer nicht ändert, die Speicherauslastung aber bedeutend sinkt. Außerdem wird die Leistung verbessert.

Ein ähnlicher Ansatz wird für alle visuellen Elemente in Ihrem Bericht empfohlen. Fragen Sie sich, ob wirklich alle Daten in einem Visual benötigt werden. Gibt es Möglichkeiten, die Menge der angezeigten Daten im Visual zu filten, ohne dass sich für den Endbenutzer viel ändert? Bedenken Sie, dass insbesondere Tabellen äußerst ressourcenintensiv sein können.

Einschränken von Visuals auf Berichtsseiten

Das oben genannte Prinzip gilt genauso für die Anzahl von visuellen Elementen, die zu einer Berichtsseite hinzugefügt werden. Es wird dringend empfohlen, die Anzahl von visuellen Elementen auf einer Berichtsseite auf die wirklich benötigten Elemente zu beschränken. Drillthroughseiten und QuickInfos zur Berichtsseite sind eine hervorragende Möglichkeit, um zusätzliche Informationen bereitzustellen, ohne dem Bericht weitere visuelle Elemente hinzuzufügen.

Auswerten der Leistung von benutzerdefinierten visuellen Elementen

Achten Sie darauf, jedes benutzerdefinierte Visual zu analysieren, um eine hohe Leistung sicherzustellen. Schlecht optimierte Power BI-Visuals können sich negativ auf die Leistung des gesamten Berichts auswirken.

Paginierte Power BI-Berichte

Paginierte Power BI-Berichtsentwürfe können optimiert werden, indem Sie bewährte Methoden für den Datenabruf des Berichts anwenden. Weitere Informationen finden Sie unter Leitfaden zum Datenabruf von paginierten Berichten.

Stellen Sie außerdem sicher, dass im Rahmen Ihrer Kapazität genügend Arbeitsspeicher für die Workload paginierter Berichte zugeordnet ist.

Optimieren der Umgebung

Sie können die Power BI-Umgebung optimieren, indem Sie Kapazitätseinstellungen konfigurieren, Datengateways anpassen und die Netzwerklatenz verringern.

Kapazitätseinstellungen

Bei Verwendung von Kapazitäten – verfügbar mit Power BI Premium (P SKUs), Premium Per User (PPU)-Lizenzen oder Power BI Embedded (A SKUs, A4-A6) – können Sie die Kapazitätseinstellungen verwalten. Weitere Informationen finden Sie unter Verwalten von Premium-Kapazitäten.

Festlegen der Gatewaygröße

Ein Gateway ist immer dann erforderlich, wenn Power BI Zugriff auf Daten benötigt, die nicht direkt über das Internet zugänglich sind. Sie können das lokale Datengateway entweder auf einem lokalen Server oder in einem VM-gehosteten IaaS-Dienst (Infrastructure-as-a-Service) installieren.

Empfehlungen zu Gatewayworkloads und zur Festlegung der Größe finden Sie unter Festlegen der Größe des lokalen Datengateways.

Netzwerklatenz

Die Netzwerklatenz kann die Leistung eines Berichts beeinträchtigen, wenn es länger dauert, bis Anforderungen den Power BI-Dienst erreichen und Antworten übermittelt werden. Mandanten in Power BI werden einer bestimmten Region zugewiesen.

Tipp

Im Artikel Wo befindet sich mein Power BI-Mandant? erfahren Sie, wie Sie ermitteln, in welcher Region sich Ihr Mandant befindet.

Wenn Benutzer von einem Mandanten aus auf den Power BI-Dienst zugreifen, werden ihre Anforderungen immer an diese Region weitergeleitet. Wenn die Anforderungen den Power BI-Dienst erreichen, kann der Dienst zusätzliche Anforderungen senden (z.B. an die zugrunde liegende Datenquelle oder das Gateway), die ebenfalls der Netzwerklatenz unterliegen.

Tools wie Azure Speed Test bieten einen Überblick über die Netzwerklatenz zwischen dem Client und der Azure-Region. Generell sollten Datenquellen, Gateways und die Power BI-Kapazität möglichst nah beieinander liegen, um die Auswirkungen der Netzwerklatenz zu minimieren. Idealerweise befinden sie sich innerhalb derselben Region. Wenn die Netzwerklatenz ein Problem darstellt, versuchen Sie, Gateways und Datenquellen näher an Ihrer Power BI-Kapazität zu platzieren, indem Sie sie auf in der Cloud gehosteten virtuellen Computern platzieren.

Leistungsüberwachung

Sie können die Leistung überwachen, um Engpässe zu ermitteln. Ein Schwerpunkt der kontinuierlichen Optimierung sollten langsame Abfragen oder langsame visuelle Berichtselemente sein. Die Überwachung kann zur Entwurfszeit in Power BI Desktop oder auf Produktionsworkloads in Power BI Premium-Kapazitäten erfolgen. Weitere Informationen finden Sie unter Überwachen der Berichtsleistung in Power BI.

Zugehöriger Inhalt

Weitere Informationen zu diesem Artikel finden Sie in den folgenden Ressourcen: