DAX Performance: Langsame Measures in Power BI beheben

Um ein langsames Measure zu beheben, finden Sie es zuerst mit dem Performance Analyzer in Power BI Desktop und sehen dann in DAX Studio, wo es seine Zeit verbringt. Die üblichen Ursachen sind ein Iterator, der bei jeder Zeile einer großen Tabelle ein Measure aufruft, FILTER über eine ganze Tabelle innerhalb von CALCULATE, derselbe Ausdruck mehrfach berechnet und ein Modell, das kein sauberes Sternschema ist. Beheben Sie zuerst das Modell, wenn es die Ursache ist, denn kein Umschreiben eines Measures gleicht es aus.

Dieser Beitrag behandelt langsames DAX. Ist der ganze Report langsam, auch bei Visuals mit einfachen Measures, beginnen Sie mit dem Leitfaden zur Fehlersuche bei langsamen Reports oder dem Power-BI-Performance-Leitfaden.

Warum DAX-Measures langsam werden

Eine DAX-Abfrage in einem Import-Modell wird von zwei Engines beantwortet:

• Die Storage Engine (VertiPaq) scannt komprimierte Spalten. Sie ist schnell und kann parallel laufen.

• Die Formula Engine übernimmt alles, was die Storage Engine nicht kann, etwa komplexe Logik und zeilenweise Auswertung. Sie läuft in einem einzigen Thread und ist langsamer.

Ein Measure ist langsam, wenn es viel Arbeit in die Formula Engine verlagert oder wenn die Storage Engine viele einzelne Scans ausführen muss. Häufige Ursachen:

• Iteratoren, die für jede Zeile einer großen Tabelle ein Measure aufrufen

• FILTER über eine ganze Tabelle als CALCULATE-Filter

• Derselbe Ausdruck wird mehrfach berechnet

• Bidirektionale oder lange Ketten von Beziehungen

• Spalten mit hoher Kardinalität in Filtern und Beziehungen

Schritt 1: Das langsame Measure finden (Performance Analyzer)

Messen Sie, bevor Sie etwas ändern.

1. Öffnen Sie in Power BI Desktop das Menüband Optimize und wählen Sie Performance Analyzer.

2. Wählen Sie Start recording, dann Refresh visuals.

3. Klappen Sie das langsamste Visual auf. Vergleichen Sie die Zeit für DAX query mit Visual display und Other.

4. Dominiert die Zeit für DAX query, wählen Sie Copy query oder Run in DAX query view, um die Abfrage zu sehen, die das Visual sendet.

Dominiert Visual display oder Other, ist das Measure nicht das Problem. Schauen Sie stattdessen auf die Anzahl der Visuals auf der Seite. Nutzen Sie Export, um die Ergebnisse als JSON-Datei zu speichern und nach jeder Änderung zu vergleichen.

Schritt 2: Iteratoren reduzieren (SUMX, FILTER, AVERAGEX)

Ein Iterator ist nicht von vornherein langsam. Ein einfacher Ausdruck über Spalten einer Tabelle wird von der Storage Engine berechnet:

Total Sales = SUMX ( Sales, Sales[Quantity] * Sales[Price] )

Dieses Measure ist in Ordnung, und eine berechnete Spalte als Ersatz ist nicht nötig. Der Beitrag SUM vs. SUMX erklärt, warum es auch die richtige Art ist, Umsatz zu berechnen.

Langsames Muster

Das teure Muster ist ein Iterator, der für jede Zeile einer großen Tabelle ein Measure aufruft:

Total Margin Slow =
SUMX ( Sales, [Margin] )

Jede Zeile wird durch Kontexttransition zu einem Filter, und [Margin] wird einmal pro Zeile ausgewertet. Bei einer Verkaufstabelle mit Millionen Zeilen sind das Millionen Auswertungen.

Schnellerer Ansatz

Iterieren Sie über die kleinste Tabelle, die die Frage beantwortet, oder schreiben Sie den Zeilenausdruck mit Spalten:

Total Margin =
SUMX ( Sales, Sales[Quantity] * ( Sales[Price] - Sales[Unit Cost] ) )

Braucht die Logik wirklich ein Measure pro Element, iterieren Sie über die Dimension statt über die Faktentabelle:

Total Margin by Customer =
SUMX ( VALUES ( Customer[CustomerKey] ), [Margin] )

Regel: Halten Sie Zeilenausdrücke bei Spaltenarithmetik und iterieren Sie über möglichst wenige Zeilen.

Schritt 3: Wiederholte Berechnungen vermeiden (Variablen nutzen)

Steht ein Ausdruck zweimal in einer Formel, kann er zweimal berechnet werden.

Langsames Measure

Sales YoY % =
DIVIDE (
    [Total Sales] - CALCULATE ( [Total Sales], SAMEPERIODLASTYEAR ( 'Date'[Date] ) ),
    CALCULATE ( [Total Sales], SAMEPERIODLASTYEAR ( 'Date'[Date] ) )
)

Das CALCULATE für das Vorjahr steht sowohl im Zähler als auch im Nenner.

Optimierte Version

Sales YoY % =
VAR CurrentSales = [Total Sales]
VAR PriorYearSales =
    CALCULATE ( [Total Sales], SAMEPERIODLASTYEAR ( 'Date'[Date] ) )
RETURN
    DIVIDE ( CurrentSales - PriorYearSales, PriorYearSales )

Variablen verhindern, dass dieselbe Berechnung zweimal läuft, weil DAX eine Variable einmal auswertet und das Ergebnis wiederverwendet. Benennen Sie Variablen sorgfältig: VAR Sales = ... scheitert in jedem Modell, das eine Tabelle namens Sales enthält. Der Leitfaden zu DAX-Variablen behandelt die Regeln.

Schritt 4: FILTER() in CALCULATE() minimieren

Langsames Muster

West Sales =
CALCULATE (
    [Total Sales],
    FILTER ( Sales, Sales[Region] = "West" )
)

FILTER geht jede Zeile der Tabelle Sales durch und liefert eine Tabelle, die CALCULATE dann als Filter anwendet.

Schnellere Alternative

West Sales =
CALCULATE (
    [Total Sales],
    KEEPFILTERS ( Sales[Region] = "West" )
)

Ein Boolescher Filter auf einer Spalte ist genau das, wofür die Storage Engine gebaut ist. KEEPFILTERS behält eine vorhandene Auswahl bei Region bei, so wie es die FILTER-Variante tat. Lassen Sie es weg, wenn das Measure unabhängig vom Slicer immer West zeigen soll.

FILTER wird weiterhin gebraucht, wenn die Bedingung ein Measure nutzt, zum Beispiel FILTER ( VALUES ( 'Date'[Month] ), [Profit] > 0 ). Filtern Sie eine kleine Spalte wie diese, nicht die Faktentabelle.

Schritt 5: Datenmodell optimieren (am wichtigsten)

Viele langsame Measures sind wegen des Modells darunter langsam. Ein sauberes Sternschema hilft oft mehr als das Umschreiben von DAX.

• Nutzen Sie ein Sternschema: Faktentabellen, die mit Dimensionstabellen in Beziehung stehen. Der Beitrag Star vs. Snowflake Schema vergleicht beide.

• Vermeiden Sie bidirektionale Beziehungen, solange eine Berechnung sie nicht braucht.

• Halten Sie Beziehungsketten kurz.

• Entfernen Sie Spalten, die kein Report nutzt.

• Verknüpfen Sie Tabellen über Integer-Schlüssel statt über lange Textschlüssel.

Schritt 6: Kardinalität reduzieren

Eine Spalte mit vielen verschiedenen Werten lässt sich schlechter komprimieren und kostet mehr beim Filtern und Verknüpfen. Typische Beispiele:

• Transaktions-IDs

• GUIDs

• Datum-Uhrzeit-Spalten mit Sekunden

So reduzieren Sie sie:

• Teilen Sie eine Datum-Uhrzeit-Spalte in eine Datumsspalte und eine Uhrzeitspalte.

• Entfernen Sie eindeutige ID-Spalten, die kein Report nutzt.

• Runden oder aggregieren Sie Werte vorgelagert, wenn das Detail nicht gebraucht wird.

Der Beitrag Beziehungen und Kardinalität geht speziell auf die Kardinalität von Beziehungen ein.

Schritt 7: Komplexe verschachtelte CALCULATE() vermeiden

Ein CALCULATE in einem CALCULATE ist an sich nicht teuer. Die Kosten entstehen, wenn CALCULATE einmal pro Zeile läuft. Das passiert immer, wenn ein Measure innerhalb eines Iterators referenziert wird, weil jede Measure-Referenz in ein implizites CALCULATE gehüllt ist:

High Value Customers =
COUNTROWS (
    FILTER ( Customer, [Total Sales] > 10000 )
)

Das wertet [Total Sales] einmal pro Kunde aus. Bei einigen tausend Kunden ist das in Ordnung. Bei Millionen Zeilen ist es das nicht.

So bleibt es schnell:

• Iterieren Sie über Dimensionstabellen oder über VALUES einer Schlüsselspalte, nicht über Faktentabellen.

• Verschieben Sie gemeinsame Ergebnisse in Variablen, bevor der Iterator startet.

• Fassen Sie mehrere Filter in einem CALCULATE zusammen, statt sie zu schichten.

Schritt 8: Measures statt berechneter Spalten nutzen (wenn passend)

Berechnete Spalten:

• Werden für jede Zeile gespeichert und belegen dauerhaft Speicher

• Verlängern jede Aktualisierung

Measures:

• Werden zur Abfragezeit berechnet

• Vergrößern das Modell nicht

Eine berechnete Spalte ist ihren Speicher wert, wenn Sie danach schneiden, filtern, gruppieren oder verknüpfen. Für Arithmetik, die Sie nur aggregieren, ist ein Measure meist die bessere Wahl. Der Beitrag Measures vs. berechnete Spalten bietet den vollständigen Vergleich.

Schritt 9: Auswirkung von ALL vs. ALLSELECTED auf die Performance verstehen

Innerhalb von CALCULATE entfernen ALL und REMOVEFILTERS dieselben Filter, der Wechsel zwischen beiden ändert also die Lesbarkeit, nicht die Geschwindigkeit. Entscheidend ist, wie viel Sie entfernen:

• ALL ( Sales ) auf einer Faktentabelle entfernt Filter auf jeder verknüpften Dimension. Die Engine aggregiert dann möglicherweise weit mehr Zeilen.

• REMOVEFILTERS ( 'Product'[Category] ) entfernt eine Spalte und lässt alles andere unverändert.

Entfernen Sie Filter von den schmalsten Spalten, die das richtige Ergebnis liefern. ALLSELECTED ist innerhalb von Iteratoren schwerer nachzuvollziehen, testen Sie Measures damit also einzeln, bevor Sie sie kombinieren. Der Beitrag ALLSELECTED vs. ALL erklärt den Unterschied in den Ergebnissen.

Schritt 10: Mit DAX Studio testen (fortgeschrittene Optimierung)

DAX Studio ist ein kostenloses Tool, das eine Abfrage gegen Ihr Modell ausführt und zeigt, wohin die Zeit geht. Fügen Sie die Abfrage aus dem Performance Analyzer ein, aktivieren Sie Server Timings, leeren Sie den Cache und führen Sie sie aus.

Achten Sie auf:

• Gesamtzeit, aufgeteilt in Storage Engine und Formula Engine

• Die Anzahl der Storage-Engine-Abfragen

• Ob eine Storage-Engine-Abfrage einen Callback zur Formula Engine enthält

Ein gutes Ergebnis ist überwiegend Storage-Engine-Zeit aus wenigen Abfragen. Hohe Formula-Engine-Zeit oder Dutzende Storage-Engine-Abfragen für ein einzelnes Visual deuten auf die Muster aus Schritt 2, 4 und 7. Ändern Sie jeweils nur eine Sache und führen Sie dieselbe Abfrage erneut aus, um zu vergleichen.

Checkliste zur DAX-Performance-Optimierung

Prüfen Sie vor dem Veröffentlichen eines Reports:

• Das Modell ist ein Sternschema

• Kein Iterator ruft ein Measure über einer Faktentabelle auf

• CALCULATE-Filter sind wo möglich Boolesch

• Wiederholte Ausdrücke sind in Variablen gespeichert

• Spalten mit hoher Kardinalität sind reduziert oder entfernt

• Langsame Visuals wurden im Performance Analyzer geprüft

FAQs

Warum ist mein Power-BI-Report auch bei einfachen Visuals langsam?

Prüfen Sie zuerst den Performance Analyzer. Ist die Zeit für DAX query hoch, liegt die Ursache bei einem Measure oder beim Modell, oft bei einem Measure, das eine große Tabelle iteriert, oder bei einer bidirektionalen Beziehung. Ist die Zeit für Visual display oder Other hoch, hat die Seite zu viele Visuals oder die Visuals warten aufeinander.

Sind Iterator-Funktionen immer schlecht?

Nein. SUMX über Spaltenarithmetik auf einer Tabelle verarbeitet die Storage Engine effizient. Iteratoren werden langsam, wenn sie bei jeder Zeile einer großen Tabelle ein Measure aufrufen oder komplexe Logik ausführen.

Was bringt in Power BI die größte Performance-Verbesserung?

Ein sauberes Sternschema mit Beziehungen in einer Richtung und ohne ungenutzte Spalten mit hoher Kardinalität. Danach bringt das Entfernen von Measure-Aufrufen pro Zeile aus Iteratoren auf Faktentabellen in DAX meist den größten Gewinn.

Quellen

• Use Performance Analyzer to examine report performance - Microsoft Learn

• Avoid using FILTER as a filter argument in DAX - Microsoft Learn

• Use variables to improve your DAX formulas - Microsoft Learn

• CALCULATE function (DAX) - Microsoft Learn