Power BI Performance optimieren: Schritt für Schritt

Power BI Performance zu optimieren heißt, einen Report schneller zu laden, zu filtern und zu aktualisieren. Dafür beheben Sie vier Ebenen in fester Reihenfolge: wie Daten abgerufen werden, wie das Modell aufgebaut ist, wie Measures geschrieben sind und wie Report-Seiten gebaut sind. Die meisten langsamen Reports lassen sich in den ersten beiden Ebenen beheben, indem Sie Query Folding erhalten und ein Sternschema bauen. Messen Sie das Problem, bevor Sie etwas ändern, und arbeiten Sie die Ebenen in der Reihenfolge unten ab.

Was Power BI Performance-Optimierung wirklich bedeutet

Optimierung senkt fünf Größen:

• Die Ausführungszeit von Abfragen, wenn ein Visual lädt oder ein Slicer wechselt.

• Den Speicher, den das Modell belegt.

• Die Komplexität des Modells, die beide Größen oben treibt.

• Die Dauer der Aktualisierung.

• Die Zeit zum Rendern der Visuals.

Sie verteilen sich auf vier Ebenen:

Eine Ebene allein löst das Problem selten ganz.

Warum Ihr Power BI Report langsam ist

Finden Sie vor der Optimierung heraus, welche Ebene langsam ist. Die meisten Ursachen fallen in vier Gruppen:

1. Datenabruf. Query Folding bricht ab, ungenutzte Spalten werden geladen, oder DirectQuery durchsucht große Quelltabellen.

2. Datenmodellierung. n:m-Beziehungen, Snowflake-Dimensionen oder Spalten mit hoher Kardinalität, etwa Zeitstempel mit Sekunden.

3. DAX. Iteratoren über große Tabellen, wiederholte Teilausdrücke oder FILTER über eine ganze Tabelle innerhalb von CALCULATE.

4. Report-Design. Zu viele Visuals pro Seite, schwere benutzerdefinierte Visuals oder jedes Visual, das jedes andere kreuzfiltert.

Unser Leitfaden zur Fehlersuche bei langsamen Reports zeigt, wie Sie jede davon diagnostizieren.

Query Folding in Power BI erklärt

Query Folding bedeutet, dass Power Query Ihre Schritte in eine einzige Abfrage übersetzt, die die Quelle ausführt, etwa eine SQL-Anweisung. Funktioniert das, filtert und aggregiert die Quelle, es wandern weniger Daten, und die Aktualisierung geht schneller. Lässt sich ein Schritt nicht falten, laufen dieser Schritt und alle folgenden in Power BI, über alle Zeilen, die die Quelle geliefert hat.

Typische Auslöser, die das Folding brechen:

• Eine Indexspalte hinzufügen.

• Benutzerdefinierte Spalten mit Funktionen, für die die Quelle keine Entsprechung hat.

• Abfragen aus zwei verschiedenen Quellen zusammenführen.

Setzen Sie faltbare Schritte an den Anfang. In dieser Abfrage werden die Spaltenauswahl und der Datumsfilter in SQL gefaltet, und die Indexspalte kommt zuletzt, wo sie frühere Schritte nicht mehr am Falten hindern kann:

let
    Source = Sql.Database("myserver.database.windows.net", "SalesDW"),
    Sales = Source{[Schema = "dbo", Item = "FactSales"]}[Data],
    KeptColumns = Table.SelectColumns(Sales, {"OrderDate", "ProductKey", "CustomerKey", "SalesAmount"}),
    RecentRows = Table.SelectRows(KeptColumns, each [OrderDate] >= #date(2024, 1, 1)),
    AddedIndex = Table.AddIndexColumn(RecentRows, "Index", 1, 1, Int64.Type)
in
    AddedIndex

Das setzt voraus, dass OrderDate eine Datumsspalte ist. Ob gefaltet wird, prüfen Sie so: Klicken Sie unter Angewendete Schritte mit der rechten Maustaste auf einen Schritt. Ist Native Abfrage anzeigen verfügbar, wird der Schritt gefaltet.

Weitere Maßnahmen beim Laden der Daten:

• Entfernen Sie Spalten, die Sie nicht im Report brauchen, schon im Quellschritt.

• Filtern Sie Zeilen an der Quelle, nicht erst nach einer Zusammenführung.

• Verlagern Sie aufwendige Transformationen nach oben in eine SQL-View oder eine Warehouse-Tabelle.

• Nutzen Sie inkrementelle Aktualisierung für große Faktentabellen.

Optimierung des Datenmodells

Die Form des Modells entscheidet über die Performance, noch bevor eine Zeile DAX geschrieben ist.

Sternschema (empfohlen)

• Faktentabellen enthalten Ereignisse und Zahlen.

• Dimensionstabellen enthalten beschreibende Spalten.

• Jede Dimension steht über eine 1:n-Beziehung direkt mit den Faktentabellen in Verbindung.

Filter nehmen den kürzesten Weg, Spalten lassen sich gut komprimieren, und DAX bleibt einfach.

Snowflake-Schema

• Dimensionen sind in Ketten aufgeteilt, etwa Produkt, dann Unterkategorie, dann Kategorie.

• Filter laufen über mehr Beziehungen.

• Das Modell hat mehr Tabellen und mehr Schlüsselspalten.

Microsoft empfiehlt, in Power BI meist eine einzelne denormalisierte Dimensionstabelle einer Snowflake-Dimension vorzuziehen. Den Vergleich und wie Sie eine Dimension abflachen, zeigt Sternschema vs. Snowflake-Schema in Power BI.

Beziehungen und Kardinalität in Power BI optimieren

Beziehungen bestimmen, wie Filter wandern, und damit, wie Abfragen laufen:

• Bevorzugen Sie 1:n-Beziehungen.

• Vermeiden Sie n:m-Beziehungen, wo eine Brückentabelle oder eine saubere Dimension genügt.

• Verbinden Sie über ganzzahlige Schlüssel statt über lange Textschlüssel.

• Filtern Sie standardmäßig in eine Richtung. Wann „Beide“ gerechtfertigt ist, steht unter Kreuzfilterrichtung.

Die Kardinalität, also die Anzahl unterschiedlicher Werte in einer Spalte, treibt den Speicherbedarf. Eine Datetime-Spalte mit Sekunden hat weit mehr unterschiedliche Werte als eine Datumsspalte. Teilen Sie sie in eine Datums- und eine Zeitspalte auf oder runden Sie sie, wenn Sie die Genauigkeit nicht brauchen.

Die ausführliche Erklärung: Beziehungen und Kardinalität in Power BI.

DAX-Performance optimieren: langsame Measures beheben

Nach dem Modell ist DAX die nächste Ebene. Zwei Muster decken viele langsame Measures ab.

Filtern Sie eine Spalte, nicht eine Tabelle. Das erste Measure unten iteriert über jede Zeile von Sales. Das zweite filtert eine Spalte von Product, was die Engine deutlich günstiger verarbeitet. Beide liefern den Umsatz roter Produkte innerhalb der aktuellen Filter:

Red Sales Slow =
CALCULATE (
    [Sales Amount],
    FILTER ( Sales, RELATED ( 'Product'[Color] ) = "Red" )
)

Red Sales =
CALCULATE (
    [Sales Amount],
    KEEPFILTERS ( 'Product'[Color] = "Red" )
)

Berechnen Sie einen Wert nur einmal. Variablen speichern ein Ergebnis, damit das Measure es nicht zweimal auswertet:

Sales Growth % =
VAR CurrentSales = [Sales Amount]
VAR PriorSales =
    CALCULATE ( [Sales Amount], SAMEPERIODLASTYEAR ( 'Date'[Date] ) )
RETURN
    DIVIDE ( CurrentSales - PriorSales, PriorSales )

Ausführlicher Leitfaden: DAX-Performance optimieren.

Das Vorgehen zur Power BI Performance-Optimierung

Arbeiten Sie in dieser Reihenfolge:

1. Query Folding prüfen. Die Quelle soll filtern und formen.

2. Modell korrigieren. Bauen Sie ein Sternschema mit sauberen 1:n-Beziehungen.

3. Kardinalität senken. Entfernen Sie ungenutzte Spalten und teilen oder runden Sie Spalten mit hoher Kardinalität.

4. DAX optimieren. Schreiben Sie die langsamsten Measures um, die Sie mit dem Performance Analyzer finden.

5. Report-Design verbessern. Kürzen Sie Visuals und Interaktionen auf den langsamsten Seiten.

Die Reihenfolge zählt. DAX auf einem schlecht geformten Modell zu optimieren, hält selten, denn das nächste Measure stößt auf dasselbe Problem.

Fortgeschrittene Techniken und neuere Speicheroptionen

• Aggregationstabellen. Eine kleine, vorab zusammengefasste Tabelle beantwortet die meisten Abfragen, und die Detailtabelle wird nur abgefragt, wenn ein Visual das Detail braucht.

• Hybridtabellen. Eine Richtlinie für inkrementelle Aktualisierung kann über den importierten Verlauf eine DirectQuery-Partition für die neuesten Daten legen. Das erfordert Premium, Premium Per User oder Embedded.

• Kompositmodelle. Mischen Sie Import- und DirectQuery-Tabellen, etwa indem Sie Dimensionen importieren und eine sehr große Faktentabelle in DirectQuery lassen. Siehe Import vs. DirectQuery.

• Direct Lake. In Microsoft Fabric kann ein Semantic Model Delta-Tabellen in OneLake direkt lesen, mit derselben In-Memory-Engine wie beim Import, ohne die Daten in einer geplanten Import-Aktualisierung zu kopieren.

Jede davon bringt zusätzliche bewegliche Teile mit. Setzen Sie sie ein, wenn die Grundlagen oben stehen, nicht an deren Stelle.

Optimierung von Umgebung und Infrastruktur

Ein gut gebautes Modell kann trotzdem langsam sein, wenn die Umgebung darum nicht passend dimensioniert ist:

• Kapazität. Auf einer Premium- oder Fabric-Kapazität teilen sich aufwendige Aktualisierungen und intensive Report-Nutzung dieselben Ressourcen. Legen Sie große Aktualisierungen abseits der Zeiten mit viel Nutzung.

• Gateways. Ein lokales Datengateway braucht genug CPU und Arbeitsspeicher für gleichzeitige Aktualisierungen und sollte im Netzwerk nah an der Quelle stehen.

• Netzwerklatenz. DirectQuery sendet pro Visual eine Abfrage, deshalb verlängert die Entfernung zwischen Power BI und der Quelle jedes Laden einer Seite.

• Speichermodus. Import ist beim Abfragen am schnellsten. DirectQuery ist nur so schnell wie die Quelldatenbank.

Performance messen und überwachen

Messen Sie vor und nach jeder Änderung:

• Der Performance Analyzer in Power BI Desktop, im Menüband Optimieren, zeichnet auf, wie lange jedes Visual für seine DAX-Abfrage, fürs Rendern und für sonstige Arbeit braucht.

• DAX Studio, ein kostenloses externes Tool, führt die aus dem Performance Analyzer kopierte Abfrage aus und zeigt Server-Timings.

• Der Aktualisierungsverlauf in den Einstellungen des Semantic Models zeigt Dauer und Fehler der Aktualisierungen über die Zeit.

• Die Microsoft Fabric Capacity Metrics App zeigt Kapazitätsauslastung und Drosselung auf Premium- und Fabric-Kapazitäten.

Verfolgen Sie Ladezeit der Visuals, Abfragedauer, Aktualisierungszeit und Modellgröße. Eine Verschlechterung lässt sich viel leichter beheben, wenn sie in derselben Woche auffällt.

Optimierung von Report und Visualisierung

Jedes Visual auf einer Seite sendet eine eigene Abfrage. Eine Seite mit vielen Visuals sendet bei jedem Slicer-Wechsel viele Abfragen.

• Zeigen Sie pro Seite nur die Visuals, die der Leser braucht, und verlagern Sie Details auf Drillthrough-Seiten.

• Entfernen Sie Slicer, die niemand nutzt.

• Schalten Sie Visual-Interaktionen aus, die nichts bringen, unter Format > Interaktionen bearbeiten.

• Setzen Sie Standardfilter, die Daten begrenzen, etwa das aktuelle Jahr.

• Testen Sie benutzerdefinierte Visuals im Performance Analyzer, bevor Sie sie behalten.

Governance und Best Practices

Die Performance sinkt, wenn mehr Menschen auf einem Modell aufbauen. Standards verhindern das Abdriften:

• Modellierungsregeln: Sternschema, ganzzahlige Schlüssel, Beziehungen mit einer Filterrichtung.

• Namensstandards für Tabellen und Measures.

• Ein Vermerk, warum jede Ausnahme gemacht wurde, etwa eine bidirektionale Beziehung.

• Ein benannter Verantwortlicher für jedes gemeinsam genutzte Semantic Model.

• Ein einheitlicher Bereitstellungsprozess zwischen Entwicklung, Test und Produktion.

Auch Row-Level-Security-Regeln laufen bei jeder Abfrage mit. Halten Sie sie einfach und filtern Sie nach Möglichkeit Dimensionstabellen statt großer Faktentabellen.

Verbreitete Mythen zur Performance

„Power BI ist bei großen Datensätzen langsam“

Die Zeilenzahl allein entscheidet selten über die Geschwindigkeit. Eine große Faktentabelle in einem sauberen Sternschema mit Spalten niedriger Kardinalität kann schnell antworten, während ein kleines Modell mit n:m-Beziehungen langsam sein kann.

„Wir brauchen nur bessere Hardware“

Eine größere Kapazität hilft, wenn die Kapazität überlastet ist. Sie behebt keine Abfrage, die wegen einer fehlerhaften Beziehung oder eines FILTER auf Tabellenebene jede Zeile durchsucht.

„DAX ist das Hauptproblem“

An DAX zeigt sich oft nur das Symptom. Die Ursache liegt häufig im darunterliegenden Modell, das das Measure zu zusätzlicher Arbeit zwingt.

Checkliste zur Performance-Optimierung

• Query Folding hält über die Filterschritte hinweg.

• Das Modell ist ein Sternschema.

• Beziehungen sind 1:n mit einer Filterrichtung, Ausnahmen sind dokumentiert.

• Spalten mit hoher Kardinalität sind entfernt, geteilt oder gerundet.

• Measures nutzen Variablen und Spaltenfilter.

• Ungenutzte Spalten sind entfernt.

• Jede Seite zeigt nur die Visuals, die ihr Leser braucht.

Fallen mehrere Punkte durch, beginnen Sie mit dem ersten, der durchfällt.

Wie CaseWhen Organisationen hilft, langsame Power BI Reports zu beheben

CaseWhen diagnostiziert langsame Power BI Reports Ebene für Ebene und behebt die Ursache, ob in den Quellabfragen, im Modell oder in den Measures. Wir gestalten auch Modelle und Kapazitäts-Setups neu für Teams, deren Nutzung die ursprüngliche Lösung überholt hat.

FAQs

Warum ist mein Power BI Report langsam?

Die häufigsten Ursachen sind ein Modell ohne Sternschema, Query Folding, das früh abbricht, DAX, das große Tabellen iteriert, und Seiten mit zu vielen Visuals. Öffnen Sie den Performance Analyzer in Power BI Desktop, um zu sehen, ob die Zeit in DAX-Abfragen oder im Rendern steckt, und gehen Sie von dort aus weiter.

Was verbessert die Power BI Performance am meisten?

Meist das Modell. Der Wechsel zu einem Sternschema mit 1:n-Beziehungen in eine Filterrichtung und das Entfernen von Spalten mit hoher Kardinalität hilft in der Regel jedem Visual auf einmal. Query Folding wirkt am stärksten auf die Aktualisierungszeit.

Soll ich zuerst das Modell oder das DAX optimieren?

Das Modell. Wie schnell ein Measure läuft, hängt stark vom Modell darunter ab: Ein Sternschema, weniger und schmalere Spalten und Beziehungen mit einer Filterrichtung beschleunigen alle Measures auf einmal. Ist das Modell sauber, finden Sie mit dem Performance Analyzer die langsamsten Measures und optimieren diese.

Quellen

• Use Performance Analyzer to examine report element performance - Microsoft Learn

• Understand star schema and the importance for Power BI - Microsoft Learn

• Optimization guide for Power BI - Microsoft Learn

• Query folding basics - Microsoft Learn