Teilen über

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 (mithilfe von DirectQuery oder Live Connection) gehostet, und in Power BI werden sie als semantische Modelle bezeichnet. 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 Speichermodi für semantische Modelltabellen: Import, DirectQuery und Composite. Weitere Informationen finden Sie unter Semantische Modelle im Power BI-Dienst und Modi von semantischen Modellen im Power BI-Dienst.

Anleitungen für den Speichermodus für semantische Modelltabellen finden Sie unter:

Optimieren für Berichtsautoren und Modellkunden

Das semantische Modell ist die Grundlage aller Berichte in Power BI. Consumer des Semantikmodells können Power BI-Berichte in Power BI Desktop erstellen, indem sie eine Verbindung mit einem veröffentlichten Semantikmodell herstellen oder eine Verbindung mit Daten herstellen und ein lokales Semantikmodell erstellen. Das semantische Modell kann auch verwendet werden, um Power BI-Berichte im Browser zu erstellen, Power BI-Erkundungen zu erstellen, paginierte Berichte zu erstellen, DAX-Abfragen zu erstellen und Berichte in Excel mit Analyse in Excel zu erstellen, eine Verbindung mit Power BI in Excel herzustellen oder Daten aus einer berichtsvisualen Darstellung sowie viele andere Berichterstellungstools zu exportieren. Ein Autor eines Semantikmodells kann benutzern des Semantikmodells helfen, das semantische Modell mit ihrer Erstellung zu verstehen und zu nutzen.

  • Namen: Tabellen, Spalten und Measures im semantischen Modell mit beschreibenden Namen. Beispielsweise ist "Store Sales" als Tabellenname intuitiver als "Tabelle1".
  • Beschreibungen: Tabellen, Spalten und Measures im Modell können ihnen Beschreibungen hinzugefügt haben, um mehr Details bereitzustellen, als in den Namen passen können. Erläutern Sie nicht nur, was sie enthalten, sondern wie sie verwendet werden sollen.
  • Ausblenden: Sie können Tabellen, Spalten und Measures im Modell ausblenden, um nur das anzuzeigen, was sie in einem Bericht verwenden sollen. Beispielsweise können Beziehungsspalten eine ID sein, die für die Berichterstellung nicht erforderlich ist und ausgeblendet werden kann, da sie nicht in einem Bericht verwendet werden soll, oder Datenspalten, die ein Measure zum Aggregieren der Spalte aufweisen, ausgeblendet werden können, um stattdessen die Verwendung des Measures zu fördern. Ausgeblendete Objekte können später vom Modellanwender immer eingeblendet werden, sodass sie weiterhin verfügbar sind, aber das Ausblenden kann den Fokus bieten.
  • Hierarchien: Sie können Hierarchien erstellen, um die Hierarchie über mehrere Spalten hinweg zu vermitteln. Eine Kalenderhierarchie kann z. B. Jahres-, Monats-, Tagesspalten und eine Produkthierarchie Kategorie, Unterkategorie, Produktspalten enthalten. Klicken Sie mit der rechten Maustaste auf eine Spalte, um eine Hierarchie zu erstellen.
  • Measures: Sie können Measures verwenden, um Datenspalten im semantischen Modell zu aggregieren, um Konsistenz über Berichte hinweg bereitzustellen. Measures können von der SUMME einer Spalte bis hin zu einem Integritätsindex reichen, der mehrere Aggregationen auf eine bestimmte Weise kombiniert oder Aggregationen über Zeiträume hinweg vergleicht, z. B. der tägliche Durchschnitt in diesem Monat im Vergleich zum täglichen Durchschnitt desselben Monats im letzten Jahr. Measures können auch in der Power BI-Suche und anderen Features wie Metriken und Scorecards angezeigt werden.
  • Formate: Sie können angeben, wie eine Spalte oder ein Measure standardmäßig in einem visuellen Element angezeigt wird. Werte in visuellen Elementen können weiter im visuellen Bereich angepasst werden. Zu den Formatoptionen gehören ein Tausenderkomma, wie viele Dezimalstellen, wie viele Dezimalstellen angezeigt werden, wie ein Datum angezeigt wird usw. Sie können auch benutzerdefinierte oder dynamische Formate anwenden.
  • Datenkategorie: Sie können eine Spaltendatenkategorie angeben, z. B. wenn es sich um ein Land oder eine Web-URL handelt.

Dies sind allgemeine Features des Power BI-Semantikmodells, die genutzt werden können, um Ihren Berichtsautoren und Modellkunden zu helfen. Es gibt viele andere, z . B. Berechnungsgruppen, Feldparameter, was wäre, wenn Parameter, Gruppierungs- und Binningspalten, die ausgewertet werden sollten, um festzustellen, ob sie Ihre spezifischen Berichtsanforderungen anwenden.

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 Microsoft Fabric-Kapazitätslizenzen und Verwalten von Premium-Kapazitäten.

Wichtig

Manchmal bezieht sich dieser Artikel auf Power BI Premium oder seine Kapazitätsabonnements (P-SKUs). Beachten Sie, dass Microsoft derzeit Kaufoptionen konsolidiert und die SKUs von Power BI Premium pro Kapazität einstellt. Neue und vorhandene Kunden sollten stattdessen den Kauf von Fabric-Kapazitätsabonnements (F-SKUs) in Betracht ziehen.

Weitere Informationen finden Sie unter Wichtige Updates zur Power BI Premium-Lizenzierung und Häufig gestellte Fragen zu Power BI Premium.

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: