Power BI-Leistungsoptimierung: DAX, Modelle und Abfragen

Ein Power BI-Bericht, dessen Laden 15 Sekunden dauert, ist ein Bericht, den Benutzer nicht mehr verwenden. Leistung ist keine technische Feinheit – sie ist der Unterschied zwischen BI-Einführung und BI-Abbruch. Jede Sekunde der Berichtsladezeit reduziert die Benutzerinteraktion messbar. Untersuchungen zeigen durchweg, dass interaktive Dashboards (mit einer Ladezeit von weniger als 3 Sekunden) vier- bis fünfmal mehr Aufrufe erhalten als langsame (über 10 Sekunden) und dass Benutzer, die eine anhaltende Langsamkeit feststellen, innerhalb von 30 Tagen zu manuellen Prozessen zurückkehren.

Die gute Nachricht ist, dass Power BI-Leistungsprobleme fast immer lösbar sind. Nach unserer Erfahrung bei der Optimierung Hunderter Power BI-Umgebungen sind 90 % der Leistungsprobleme auf eine von fünf Grundursachen zurückzuführen: ineffiziente DAX-Maßnahmen, übergroße Datenmodelle, schlechtes Beziehungsdesign, ungeeignete Verwendung von DirectQuery oder unzureichende Kapazität für die Arbeitslast. Dieser Leitfaden bietet einen systematischen Ansatz zur Diagnose und Lösung jedes dieser Probleme.

Wenn in Ihrer Power BI-Umgebung Leistungsprobleme auftreten, die Ihr Team nicht intern lösen kann, bieten unsere [Power BI-Leistungsoptimierungsdienste] (/services/powerbi/performance-optimization) praktische Analysen und Behebung.

Wichtige Erkenntnisse

– Der Leistungsanalysator in Power BI Desktop identifiziert, welche Visuals und Abfragen langsam sind – beginnen Sie immer hier, bevor Sie mit der Optimierung beginnen – DAX Studio zeigt an, ob langsame Abfragen einen Engpass in der Storage Engine (Datenscan) oder der Formula Engine (Berechnung) verursachen – die Lösung unterscheidet sich erheblich – Die häufigsten DAX-Leistungsfehler sind unnötige CALCULATE-Verschachtelung, die Verwendung von Iteratoren, wo Aggregatoren ausreichen, und die Materialisierung großer Zwischentabellen – Die Modellgröße wirkt sich direkt auf die Leistung aus: Durch das Entfernen nicht verwendeter Spalten, die Reduzierung der Kardinalität und die Optimierung von Datentypen können Modelle um 40–70 % verkleinert werden. – Aggregationstabellen bieten 10- bis 100-fache Verbesserungen der Abfrageleistung für große Datenmengen durch Vorberechnung von Zusammenfassungsdaten – DirectQuery ist 10–100 Mal langsamer als der Importmodus für interaktive Berichte – verwenden Sie ihn nur, wenn die Anforderungen an die Datenaktualität dies wirklich erfordern

• Vorher/Nachher-Benchmarking mit dokumentierten Metriken ist für den Nachweis der Optimierungsauswirkungen und die Verhinderung von Regressionen unerlässlich

---

Diagnosetools und -methodik

Leistungsanalysator

Performance Analyzer ist das integrierte Diagnosetool von Power BI Desktop. Es zeichnet die Ausführungszeit für jede von jedem Visual auf einer Berichtsseite generierte Abfrage auf und unterteilt die Zeit in drei Komponenten:

So verwenden Sie den Leistungsanalysator:

1. Öffnen Sie Ihren Bericht in Power BI Desktop.
2. Gehen Sie zu Ansicht > Leistungsanalysator.
3. Klicken Sie auf „Aufzeichnung starten“.
4. Interagieren Sie mit dem Bericht (Filter ändern, Seiten navigieren, Slicer anwenden).
5. Klicken Sie auf „Stopp“.
6. Überprüfen Sie die Ergebnisse, sortiert nach Gesamtdauer.

Ergebnisse interpretieren:

– Wenn die DAX-Abfragezeit dominiert, liegt das Problem in Ihren Kennzahlen oder Ihrem Modell. Verwenden Sie DAX Studio für eine tiefergehende Analyse.

• Wenn die visuelle Anzeigezeit dominiert, liegt das Problem in der visuellen Konfiguration (zu viele Datenpunkte, komplexe bedingte Formatierung oder ein benutzerdefiniertes Visual mit schlechter Leistung).
• Wenn „Sonstige“ Zeit dominiert, liegt das Problem in der Infrastruktur (Netzwerklatenz für DirectQuery, Gateway-Engpässe oder Kapazitätsdrosselung).

Der entscheidende Schritt, den die meisten Leute überspringen: Kopieren Sie die DAX-Abfrage aus Performance Analyzer (Rechtsklick > „Abfrage kopieren“) und fügen Sie sie in DAX Studio ein. Performance Analyzer sagt Ihnen, welches Visual langsam ist. DAX Studio sagt Ihnen warum.

DAX Studio

DAX Studio ist ein kostenloses Open-Source-Tool, das umfassende Diagnosefunktionen für die Analysis Services-Engine bietet, die Power BI zugrunde liegt. Es ist das wichtigste Werkzeug im Toolkit eines jeden Power BI-Leistungsingenieurs.

Wichtige DAX Studio-Funktionen:

Server-Timings: Zeigt die Aufschlüsselung zwischen der Abfragezeit der Storage Engine (SE) und der Formula Engine (FE) an.

• Storage Engine (SE)-Abfragen sind Datenscans, die für den Spaltenspeicher (VertiPaq-Engine) ausgeführt werden. Sie sind hochgradig parallelisiert und schnell. SE-Abfragen erscheinen als xmSQL-Anweisungen im Trace.
• Formula Engine (FE)-Operationen sind Single-Threaded-Berechnungen, die auf den Ergebnissen von SE-Abfragen durchgeführt werden. FE-Operationen sind der Hauptengpass bei den meisten langsamen DAX-Kennzahlen.

Das Optimierungsziel besteht darin, so viel Arbeit wie möglich in die Storage Engine zu verlagern und die Vorgänge der Formula Engine zu minimieren.

Abfragepläne: DAX Studio kann logische und physische Abfragepläne anzeigen und genau zeigen, wie die Engine Ihre Kennzahl verarbeitet. Für fortgeschrittene Benutzer offenbaren Abfragepläne Optimierungsmöglichkeiten, die allein in den Timing-Daten nicht sichtbar sind.

VertiPaq-Analysator: Scannt das gesamte Datenmodell und meldet Spaltengröße, Kardinalität, Kodierungstyp und Wörterbuchgröße für jede Spalte in jeder Tabelle. So erkennen Sie übergroße Spalten und Tabellen, die Ihr Modell aufblähen.

Systematische Optimierungsmethodik

1. Grundlage: Erfassen Sie die Ladezeiten für jede Seite mit Performance Analyzer. Größe des Dokumentmodells (Datei > Informationen > Dateigröße reduzieren > Analysieren). Zeichnen Sie Kapazitätsmetriken auf, wenn Sie Premium/Fabric verwenden.

2. Identifizieren: Sortieren Sie die Ergebnisse des Leistungsanalysators nach Gesamtdauer. Konzentrieren Sie sich auf die fünf langsamsten visuellen Elemente – diese erzielen bei Optimierung die größte Wirkung.

3. Diagnose: Kopieren Sie jede langsame Abfrage in DAX Studio. Analysieren Sie die SE- und FE-Zeit. Identifizieren Sie spezifische DAX-Muster, die FE-Engpässe verursachen.

4. Optimieren: Wenden Sie gezielte Korrekturen an (siehe unten). Testen Sie jede Änderung einzeln, um ihre Auswirkungen zu messen.

5. Validieren: Führen Sie den Leistungsanalysator erneut aus und vergleichen Sie ihn mit dem Ausgangswert. Dokumentieren Sie die Verbesserung für jede Optimierung.

6. Überwachen: Richten Sie eine fortlaufende Leistungsüberwachung ein (Kapazitätsmetriken, vom Benutzer gemeldete Probleme, regelmäßige Performance-Analysator-Prüfungen), um eine Regression zu verhindern.

---

Langsame DAX-Muster und Korrekturen

Muster 1: Unnötige CALCULATE-Verschachtelung

Das Problem:

Bad Measure =
CALCULATE(
    CALCULATE(
        SUM(Sales[Amount]),
        FILTER(ALL(Products), Products[Category] = "Electronics")
    ),
    Date[Year] = 2025
)

Verschachtelte CALCULATE-Anweisungen erhöhen die Leistung nicht – sie sorgen für Verwirrung und manchmal auch für mehr Leistung. Bei jedem CALCULATE wird ein neuer Filterkontext erstellt, und ihre Verschachtelung kann zu unerwarteten Ergebnissen führen und die Formel-Engine dazu zwingen, redundante Kontextübergänge durchzuführen.

Die Lösung:

Good Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics",
    Date[Year] = 2025
)

Kombinieren Sie Filterargumente in einem einzigen CALCULATE. Mehrere Filterargumente werden gleichzeitig angewendet (Schnittpunkt). Dies führt zum gleichen Ergebnis bei saubererer Ausführung.

Muster 2: FILTER mit ALLEN statt direkten Spaltenfiltern

Das Problem:

Slow Measure =
CALCULATE(
    SUM(Sales[Amount]),
    FILTER(ALL(Products), Products[Category] = "Electronics")
)

FILTER(ALL(Produkte), ...) zwingt die Engine, die gesamte Produkttabelle in der Formel-Engine zu materialisieren und dann jede Zeile zu durchlaufen, um den Filter anzuwenden. Für eine Tabelle mit Millionen Zeilen ist das außerordentlich langsam.

Die Lösung:

Fast Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics"
)

Direkte Spaltenfilter in CALCULATE werden in der Storage Engine aufgelöst, was um Größenordnungen schneller ist. Verwenden Sie FILTER nur, wenn Sie eine komplexe Bedingung anwenden müssen, die nicht als einfacher Spaltenvergleich ausgedrückt werden kann (z. B. Filtern nach einem Messwert oder einer Bedingung mit mehreren Spalten).

Faustregel: Wenn Ihre FILTER-Bedingung mit einem einfachen Vergleich auf eine einzelne Spalte verweist, ersetzen Sie diese durch ein direktes CALCULATE-Filterargument. Reservieren Sie FILTER für wirklich komplexe Bedingungen.

Muster 3: Iteratoren, bei denen Aggregatoren ausreichen

Das Problem:

Slow Total = SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])

SUMX durchläuft jede Zeile der Sales-Tabelle und wertet den Ausdruck für jede Zeile in der Formel-Engine aus. Für eine Sales-Tabelle mit 10 Millionen Zeilen bedeutet dies 10 Millionen FE-Operationen.

Die Lösung:

Wenn es sich bei der Berechnung um eine einfache Multiplikation zweier Spalten handelt, berechnen Sie sie vorab als berechnete Spalte:

-- Add calculated column: Sales[LineTotal] = Sales[Quantity] * Sales[UnitPrice]
-- Then use aggregator:
Fast Total = SUM(Sales[LineTotal])

SUM arbeitet in der Storage Engine, die Spaltendaten in hochoptimierten Stapeln verarbeitet. Die berechnete Spalte erhöht die Modellgröße, verkürzt jedoch die Abfragezeit erheblich.

Wann sollte SUMX beibehalten werden: Verwenden Sie SUMX, wenn Sie bedingte Logik auf Zeilenebene benötigen (z. B. SUMX(Sales, IF(Sales[Type] = "Return", -Sales[Amount], Sales[Amount]))) oder wenn Sie über eine kleine Tabelle iterieren (Dimensionstabellen mit Tausenden, nicht Millionen Zeilen).

Muster 4: Große Zwischentabellen

Das Problem:

Slow Measure =
SUMX(
    SUMMARIZE(Sales, Products[Category], Date[Month]),
    [Complex Calculation]
)

SUMMARIZE erstellt eine Zwischentabelle in der Formel-Engine. Wenn die Kombination aus Kategorie und Monat 10.000 Zeilen ergibt und [Komplexe Berechnung] zusätzliche SE-Abfragen für jede Zeile auslöst, sind das Ergebnis mehr als 10.000 Abfragen – ein katastrophales Leistungsmuster, das als „SE-Abfragestürme“ bekannt ist.

Die Lösung:

Fast Measure =
VAR SalesTable =
    ADDCOLUMNS(
        SUMMARIZE(Sales, Products[Category], Date[Month]),
        "@SubTotal", CALCULATE(SUM(Sales[Amount]))
    )
RETURN
    SUMX(SalesTable, [@SubTotal] * [SomeMultiplier])

Durch die Materialisierung der Zwischensumme innerhalb von ADDCOLUMNS (wodurch der Kontextübergang effizient genutzt wird) lösen nachfolgende Verweise auf @SubTotal keine zusätzlichen SE-Abfragen aus. Variablen (VAR) stellen außerdem sicher, dass die Tabelle nur einmal ausgewertet wird, auch wenn mehrfach darauf verwiesen wird.

Muster 5: Auswirkungen auf die Sicherheitsleistung auf Zeilenebene

Das Problem:

RLS mit komplexen DAX-Ausdrücken führt für jede Abfrage eine Auswertung durch, wodurch ein Overhead entsteht, der sich auf alle visuellen Elemente auswirkt. Eine schlecht geschriebene RLS-Regel kann die Ladezeiten von Berichten verdoppeln oder verdreifachen.

Häufige RLS-Leistungskiller:

• LOOKUPVALUE in RLS-Filtern (erzwingt FE-Auswertung pro Zeile)
• CONTAINS- oder IN-Operatoren für große Tabellen
• RLS-Regeln, die auf Kennzahlen verweisen, anstelle einfacher Spaltenfilter
• Mehrtabellen-RLS mit Kreuzfilterrichtungsproblemen

Die Lösung:

• Verwenden Sie einfache Spaltenvergleiche: [TenantId] = USERNAME() oder [Region] IN VALUES(SecurityTable[Region])
• Berechnen Sie Sicherheitszuordnungen in einer dedizierten Dimensionstabelle mit direkten Beziehungen vorab – Vermeiden Sie Maßnahmen in RLS-Regeln – verwenden Sie nur Filter auf Spaltenebene
• Testen Sie die RLS-Leistung mit DAX Studio, indem Sie Abfragezeiten mit und ohne aktives RLS vergleichen

---

Reduzierung der Modellgröße

Warum die Modellgröße wichtig ist

Der Power BI-Importmodus speichert Daten in einem stark komprimierten Spaltenformat (VertiPaq-Engine). Die Modellgröße wirkt sich direkt auf Folgendes aus:

• Speicherverbrauch: Das gesamte Modell muss in den Speicher passen. Bei Premium/Fabric verbrauchen größere Modelle mehr Kapazität und können eine Drosselung des Speicherdrucks auslösen.
• Aktualisierungsdauer: Die Aktualisierung größerer Modelle dauert länger, da mehr Daten verarbeitet, komprimiert und geladen werden müssen.
• Abfrageleistung: Größere Modelle erzeugen größere Scans, was die Abfragezeit selbst bei gut optimiertem DAX erhöht.
• Dateigröße: PBIX-Dateien mit großen Modellen lassen sich nur langsam speichern, veröffentlichen und herunterladen.

Identifizieren von Mitwirkenden an der Modellgröße

Verwenden Sie den VertiPaq Analyzer von DAX Studio (Erweitert > Metriken anzeigen), um die größten Tabellen und Spalten zu identifizieren:

Optimierungstechniken

Nicht verwendete Spalten entfernen:

Die einzige Optimierung mit der größten Wirkung. Jede Spalte in Ihrem Modell verbraucht Speicher, unabhängig davon, ob sie verwendet wird oder nicht. Überprüfen Sie Ihr Modell und entfernen Sie alle Spalten, auf die nicht in einer visuellen, Kennzahl-, Beziehungs- oder RLS-Regel verwiesen wird.

Typische Auswirkung: Reduzierung der Modellgröße um 20–40 %.

Kardinalität der Textspalte reduzieren:

Textspalten mit vielen eindeutigen Werten (Beschreibungen, Adressen, Notizen) lassen sich schlecht komprimieren. Wenn die Spalte nur zur Anzeige (nicht zum Filtern oder Gruppieren) benötigt wird, sollten Sie erwägen, sie in eine reine Detailtabelle zu verschieben oder lange Werte abzuschneiden.

Erwägen Sie bei Spalten, die beim Gruppieren/Filtern verwendet werden, die Einteilung in Buckets: Gruppieren Sie statt 50.000 eindeutiger Produktnamen in 500 Produktkategorien mit einer separaten Nachschlagetabelle für einzelne Produktdetails.

Datentypen optimieren:

• Verwenden Sie eine Ganzzahl anstelle einer Dezimalzahl, wenn es sich bei den Werten um ganze Zahlen handelt (spart 50 % pro Spalte).
• Verwenden Sie Date anstelle von DateTime, wenn keine Zeit benötigt wird (reduziert die Kardinalität)
• Vermeiden Sie das Speichern numerischer Werte als Text (Text lässt sich weitaus schlechter komprimieren als Zahlen).
• Verwenden Sie Boolesche Werte anstelle von Text für Ja/Nein- oder Wahr/Falsch-Spalten

Typische Auswirkung: Reduzierung der Modellgröße um 10–20 %.

Große Tische aufteilen:

Eine Faktentabelle mit 100 Millionen Zeilen kann in aktive Daten (aktuelles Jahr, bei jeder Aktualisierung geladen) und historische Daten (vorherige Jahre, seltener geladen oder als Aggregationen gespeichert) aufgeteilt werden. Dadurch werden sowohl die Modellgröße als auch die Aktualisierungsdauer reduziert.

Aggregationstabellen (im Detail weiter unten behandelt):

Bei großen Faktentabellen bieten Aggregationstabellen die größte Leistungsverbesserung, indem sie zusammenfassende Daten mit häufig abgefragten Granularitäten vorab berechnen.

---

Aggregationstabellen

Was Aggregationstabellen sind

Aggregationstabellen sind vorberechnete Übersichtstabellen, die Power BI abfragt, anstatt die vollständige Detailtabelle zu scannen. Wenn ein Benutzer ein Diagramm mit den monatlichen Einnahmen nach Region anzeigt, fragt Power BI die Aggregationstabelle (die möglicherweise 120 Zeilen enthält: 10 Regionen x 12 Monate) anstelle der Detailtabelle (die möglicherweise 50 Millionen Transaktionszeilen enthält) ab.

Der Vorteil von Aggregationstabellen besteht darin, dass sie für Berichtskonsumenten transparent sind. Benutzer interagieren mit denselben visuellen Elementen und Maßnahmen. Power BI leitet Abfragen automatisch an die Aggregationstabelle weiter, wenn die Abfragegranularität übereinstimmt, und leitet sie für Drilldown- oder Detailabfragen an die Detailtabelle weiter.

Entwerfen von Aggregationstabellen

Schritt 1: Aggregationsgranularität identifizieren.

Analysieren Sie Ihre Berichte, um die häufigsten Abfragegranularitäten zu ermitteln. Für ein Vertriebs-Dashboard:

– Die meisten visuellen Abfragen für Führungskräfte erfolgen auf der Ebene „Monat“, „Region“ und „Produktkategorie“.

• Manager-Visuals-Abfrage auf Woche-, Filial- und Produktebene
• Abfrage von Detailtabellen auf der Ebene einzelner Transaktionen

Entwerfen Sie eine oder zwei Aggregationstabellen mit den am häufigsten abgefragten Granularitäten.

Schritt 2: Erstellen Sie die Aggregationstabelle.

Erstellen Sie in Power Query eine neue Tabelle, die Ihre Faktentabelle nach der Aggregationsgranularität gruppiert:

Schritt 3: Aggregationszuordnungen konfigurieren.

Wählen Sie in Power BI Desktop die Aggregationstabelle aus, gehen Sie zu Eigenschaften > Aggregationen verwalten und ordnen Sie jede Aggregationsspalte der entsprechenden Detailtabellenspalte und Funktion zu:

Schritt 4: Aggregationstabelle ausblenden.

Benutzer sollten nicht direkt mit der Aggregationstabelle interagieren. Blenden Sie es aus der Berichtsansicht aus. Power BI nutzt es automatisch und transparent.

Auswirkungen auf die Aggregationsleistung

Diese Verbesserungen wirken sich auf alle Berichtsseiten aus. Eine Seite mit 10 Visuals, die jeweils die Aggregationstabelle statt der Detailtabelle abfragen, kann in 1 Sekunde statt in 30 Sekunden geladen werden.

Wartung der Aggregationstabelle

• Aktualisieren Sie Aggregationstabellen nach demselben Zeitplan wie Detailtabellen, um die Konsistenz zu gewährleisten
• Überwachen Sie die Trefferquoten der Aggregation mit DAX Studio (Trace-Ereignisse zeigen an, ob Abfragen die Aggregation treffen oder durchfallen).
• Fügen Sie neue Aggregationstabellen hinzu, wenn Sie weitere gängige Abfragemuster identifizieren
• Entfernen Sie Aggregationstabellen, deren Trefferquote unter 50 % fällt (sie verbrauchen Platz ohne ausreichenden Nutzen).

---

DirectQuery-Optimierung

Wenn DirectQuery erforderlich ist

DirectQuery fragt die Quelldatenbank in Echtzeit ab, anstatt Daten in die In-Memory-Engine von Power BI zu importieren. Es ist notwendig, wenn:

• Anforderungen an die Datenaktualität erfordern eine Latenzzeit von weniger als einer Minute (Aktienhandel, IoT-Überwachung, Betrugserkennung) – Der Datensatz überschreitet die Modellgrößenbeschränkungen von Power BI (10 GB auf Premium P1, 25 GB auf P2 usw.)
• Compliance oder Sicherheit erfordern, dass Daten niemals das Quellsystem verlassen – Die Quelldatenbank verfügt bereits über umfangreiche materialisierte Ansichten und Aggregationsinfrastruktur

Für alle anderen Szenarien wird der Importmodus dringend empfohlen. Der Importmodus ist bei interaktiven Abfragen 10–100 Mal schneller und bietet ein besseres Benutzererlebnis.

DirectQuery-Leistungsstrategien

Reduzieren Sie die Anzahl der Bilder pro Seite.

Jedes Visual im DirectQuery-Modus generiert eine separate Abfrage an die Quelldatenbank. Eine Seite mit 20 visuellen Elementen generiert beim Laden der Seite 20 gleichzeitige Abfragen sowie zusätzliche Abfragen, wenn sich Filter ändern. Begrenzen Sie DirectQuery-Seiten auf maximal 8–10 visuelle Elemente.

Optimieren Sie die Quelldatenbank.

Power BI sendet SQL-Abfragen (oder native Abfragen für Nicht-SQL-Quellen) an die Quelle. Die Leistung der Quelldatenbank bestimmt direkt die Berichtsleistung. Stellen Sie sicher:

• Für alle in Filtern, Beziehungen und Kennzahlen verwendeten Spalten sind Indizes vorhanden
• Die Statistiken der abgefragten Tabellen sind aktuell – Der Datenbankserver verfügt über ausreichend CPU und Speicher für gleichzeitige Analyseabfragen neben betrieblichen Arbeitslasten – Erwägen Sie die Erstellung materialisierter Ansichten oder indizierter Ansichten für gängige Abfragemuster

Optionen zur Abfragereduzierung aktivieren.

Aktivieren Sie in Power BI Desktop > Optionen > Abfragereduzierung:

• „Reduzieren Sie die Anzahl der gesendeten Abfragen, indem Sie keine Querhervorhebungsabfragen senden“: Verhindert, dass durch die Kreuzfilterung zwischen Visuals zusätzliche Abfragen generiert werden
• „Fügen Sie jedem Slicer eine Schaltfläche „Anwenden“ hinzu“: Benutzer passen mehrere Slicer an, bevor Abfragen ausgeführt werden, wodurch das gesamte Abfragevolumen reduziert wird
• „Schaltfläche „Anwenden“ zum Filterbereich hinzufügen“: Gleiches Prinzip für den Filterbereich

Verwenden Sie den Dual-Storage-Modus strategisch.

Tabellen können auf den „Dual“-Modus eingestellt werden, der Daten sowohl im Importmodus (für schnelle lokale Abfragen) speichert als auch eine DirectQuery-Verbindung aufrechterhält (für Beziehungen mit DirectQuery-Tabellen). Stellen Sie Dimensionstabellen (Produkte, Kunden, Daten) auf den Dual-Modus ein und behalten Sie gleichzeitig große Faktentabellen in DirectQuery bei. Dadurch wird die Filter- und Slicer-Leistung erheblich verbessert, ohne dass die Aktualität der Daten in den Faktentabellen beeinträchtigt wird.

Abfrage-Caching implementieren.

Aktivieren Sie „Abfrage-Caching“ in den Dataset-Einstellungen des Power BI-Diensts. Dadurch werden Abfrageergebnisse für einen konfigurierbaren Zeitraum zwischengespeichert und zwischengespeicherte Ergebnisse für identische Abfragen bereitgestellt. Das Abfrage-Caching ist besonders effektiv für Dashboards, die von vielen Benutzern mit denselben Filtern angezeigt werden (z. B. ein Executive-Dashboard, das unternehmensweite Kennzahlen anzeigt).

---

Überwachung der Kapazitätsleistung

Wichtige Kapazitätsmetriken

Für Unternehmen mit Premium- oder Fabric-Kapazität ist die Infrastrukturleistung ebenso wichtig wie das Berichtsdesign. Eine Kapazitätsdrosselung kann dazu führen, dass selbst gut optimierte Berichte eine schlechte Leistung erbringen.

Zu überwachende Metriken:

Die Microsoft Fabric-Kapazitätsmetrik-App

Microsoft stellt im Power BI Service eine dedizierte App zur Kapazitätsüberwachung bereit. Installieren Sie es von AppSource und verbinden Sie es mit Ihrer Kapazität. Es bietet:

• Echtzeit- und historische CPU-Auslastung mit Aufschlüsselung nach Workload-Typ
• Interaktive Drosselungsanalyse, die zeigt, welche Vorgänge die Drosselung ausgelöst haben
• Speicherverbrauch nach Datensatz mit Räumungsverlauf
• Leistungstrends aktualisieren
• Leistungsperzentile abfragen

Überprüfen Sie diese App wöchentlich während der Optimierungsphasen und monatlich im stabilen Zustand.

Richtige Kapazitätsdimensionierung

Eine unzureichend bereitgestellte Kapazität führt zu Drosselung und schlechter Benutzererfahrung. Übermäßig bereitgestellte Kapazität verschwendet Geld. Um die richtige Dimensionierung zu erreichen, müssen Sie Ihr Arbeitslastmuster verstehen:

• Spitzennutzungszeiten: Die meisten Unternehmen verzeichnen während der Geschäftszeiten eine zwei- bis dreimal höhere Auslastung als über Nacht. Wenn Sie die Größe für Spitzenzeiten wählen und Stoff-F-SKUs haben, sollten Sie eine Pause über Nacht oder eine Reduzierung außerhalb der Geschäftszeiten in Betracht ziehen.
• Aktualisierung vs. interaktiver Konflikt: Datenaktualisierungen und interaktive Abfragen konkurrieren um die gleichen Kapazitätsressourcen. Planen Sie umfangreiche Aktualisierungen außerhalb der Hauptinteraktionszeiten. Wenn dies nicht möglich ist, ziehen Sie separate Kapazitäten für Aktualisierungs- und interaktive Workloads in Betracht.
• Wachstumsprognose: Planen Sie ein Wachstum von 6–12 Monaten ein. Modellgröße, Benutzerzahl und Abfragekomplexität nehmen mit der Zeit tendenziell zu. Bauen Sie 30–50 % Spielraum bei der Kapazitätsdimensionierung ein.

---

Vorher/Nachher Benchmarking

Warum Benchmarking wichtig ist

Optimierung ohne Messung ist eine Vermutung. Vorher/Nachher-Benchmarking beweist, dass Änderungen die Leistung verbessern, quantifiziert die Verbesserung für Stakeholder und schafft eine Grundlage für die Erkennung zukünftiger Regressionen.

Benchmarking-Methodik

Schritt 1: Metriken definieren.

Schritt 2: Basislinie aufzeichnen.

Notieren Sie alle Kennzahlen, bevor Sie Änderungen vornehmen. Führen Sie den Leistungsanalysator zehnmal aus, um die Cache-Erwärmung und -Variabilität zu berücksichtigen. Notieren Sie den Median (P50) und das 95. Perzentil (P95) für jede Metrik.

Schritt 3: Änderungen schrittweise implementieren.

Führen Sie jeweils eine Optimierung durch und messen Sie nach jeder Änderung erneut. Dadurch wird ermittelt, welche Optimierungen die größte Wirkung erzielt haben, und es wird verhindert, dass ein Rückschritt durch eine Verbesserung an anderer Stelle verschleiert wird.

Schritt 4: Post-Optimierungsmetriken aufzeichnen.

Erfassen Sie nach allen Optimierungen dieselben Metriken mit derselben Methodik. Ergebnisse in einer Vergleichstabelle darstellen:

Schritt 5: Planen Sie eine laufende Überwachung.

Die Leistung lässt mit der Zeit nach, wenn die Daten wachsen, neue Kennzahlen hinzugefügt und neue visuelle Darstellungen erstellt werden. Planen Sie vierteljährliche Leistungsüberprüfungen mit derselben Methodik, um Rückschritte frühzeitig zu erkennen.

Für Unternehmen, die eine systematische Leistungsoptimierung mit dokumentierten Vorher-/Nachher-Metriken benötigen, bietet ECOSIRE [umfassende Power BI-Leistungsdienste] (/services/powerbi/performance-optimization), einschließlich DAX Studio-Analyse, Modelloptimierung und Kapazitätsoptimierung.

---

Erweiterte Optimierungstechniken

Berechnungsgruppen

Berechnungsgruppen ersetzen sich wiederholende Maßvarianten durch wiederverwendbare Berechnungslogik. Anstatt für jede Basiskennzahl separate Kennzahlen für MTD, QTD, YTD, Vorjahres- und Jahreswachstum zu erstellen, wendet eine Berechnungsgruppe diese Transformationen dynamisch an.

Leistungsvorteil: Weniger Kennzahlen im Modell bedeuten einen kleineren Metadaten-Footprint und ein schnelleres Laden des Modells. Noch wichtiger ist, dass Berechnungsgruppen einfachere Basismaße fördern, die tendenziell eine bessere Leistung erbringen als komplexe Gesamtmaße.

Zusammengesetzte Modelle

Zusammengesetzte Modelle kombinieren den Importmodus und DirectQuery-Tabellen in einem einzigen Modell. Verwenden Sie den Importmodus für Dimensionstabellen und häufig abgefragte Faktentabellen, DirectQuery für sehr große Tabellen, die sich für den Import zu häufig ändern.

Leistungsvorteil: Dimensionssuchen und Filtervorgänge werden mit Importgeschwindigkeit (Mikrosekunden) ausgeführt, während Faktentabellenabfragen mit DirectQuery-Geschwindigkeit (Hunderte Millisekunden bis Sekunden) ausgeführt werden. Das Nettoergebnis ist deutlich besser als reines DirectQuery.

Inkrementelle Aktualisierung

Bei der inkrementellen Aktualisierung werden während der Aktualisierung nur neue und geänderte Daten geladen, anstatt den gesamten Datensatz neu zu laden. Bei einer Tabelle mit 100 Millionen Zeilen, in der sich täglich nur 100.000 Zeilen ändern, reduziert die inkrementelle Aktualisierung die Aktualisierungszeit um 99 %.

Konfiguration: Definieren Sie einen RangeStart- und RangeEnd-Parameter in Power Query. Konfigurieren Sie die inkrementelle Aktualisierungsrichtlinie, um anzugeben, wie viele Tage/Monate der Daten aktualisiert werden sollen und wie viele historische Daten aufbewahrt werden sollen. Power BI partitioniert das Dataset automatisch und aktualisiert nur die aktiven Partitionen.

Leistungsvorteil: Drastische Reduzierung der Aktualisierungsdauer und des Kapazitätsverbrauchs während der Aktualisierung. Ermöglicht außerdem die Aktualisierung in Echtzeit mit DirectQuery-Partitionen auf Fabric-Kapazität.

Abfragefaltung

Die Abfragefaltung verschiebt Power Query-Transformationen zurück in die Quelldatenbank und führt sie als natives SQL statt in der Power Query-Engine aus. Gefaltete Abfragen werden viel schneller ausgeführt, da die Datenbank-Engine sie nativ optimiert und ausführt.

So überprüfen Sie: Klicken Sie mit der rechten Maustaste auf einen beliebigen Schritt im Power Query-Editor und prüfen Sie, ob „Native Abfrage anzeigen“ verfügbar ist. Wenn dies der Fall ist, wird die Abfrage zu diesem Schritt weitergeleitet. Wenn es ausgegraut ist, ist die Faltung bei einem vorherigen Schritt fehlgeschlagen.

Häufige Faltunterbrecher: Benutzerdefinierte Spalten mit M-Ausdrücken, Zusammenführen von Tabellen aus verschiedenen Quellen, bestimmte Transformationen (Pivotierung, komplexe Typkonvertierungen). Wenn die Faltung unterbrochen wird, werden alle nachfolgenden Transformationen in der Power Query-Engine ausgeführt, die bei großen Datensätzen deutlich langsamer ist.

---

FAQ

Was ist ein gutes Ziel für die Ladezeit von Power BI-Berichten?

Zielen Sie auf weniger als 3 Sekunden für häufig verwendete Dashboards und auf weniger als 5 Sekunden für detaillierte Analyseberichte. Diese Ziele entsprechen den Erwartungen der Benutzer an Webanwendungen und sorgen für ein hohes Engagement. Berichte, die dauerhaft länger als 10 Sekunden sind, sollten zur Optimierung priorisiert werden. Messen Sie die Ladezeit aus Benutzersicht (einschließlich Netzwerk und Rendering), nicht nur die DAX-Abfragezeit. Die DAX-Abfragezeit des Performance Analyzers plus visuelle Renderingzeit sollte für jedes Visual weniger als 2 Sekunden betragen, um einen Seitenladevorgang von 3 Sekunden mit 8–10 Visuals zu erreichen.

Sollte ich den Importmodus immer dem DirectQuery vorziehen?

Für interaktive Berichte, die von Geschäftsanwendern verwendet werden, ja --- Der Importmodus ist fast immer die bessere Wahl. Der Importmodus ist für Abfragen 10–100-mal schneller, hängt bei der Berichtsanzeige nicht von der Leistung der Quelldatenbank ab und unterstützt die gesamte Palette der DAX-Funktionen und KI-Funktionen. Verwenden Sie DirectQuery nur, wenn Sie eine echte Anforderung an die Aktualität der Daten in Sekundenschnelle haben, wenn Ihr Datensatz die Importgrößenbeschränkungen überschreitet oder wenn die Compliance erfordert, dass die Daten im Quellsystem verbleiben. Betrachten Sie zusammengesetzte Modelle als Mittelweg: Importieren Sie die Dimensionen und häufig abgefragten Fakten, DirectQuery nur die Tabellen, die wirklich Echtzeit-Aktualität benötigen.

Wie oft sollte ich Leistungsprüfungen für meine Power BI-Berichte durchführen?

Führen Sie vierteljährlich eine umfassende Leistungsprüfung für Produktionsberichte durch. Überwachen Sie zwischen den Audits wöchentlich die Kapazitätsmetriken und untersuchen Sie umgehend jede vom Benutzer gemeldete Langsamkeit. Zu den wichtigsten Ereignissen, die eine sofortige Prüfung auslösen sollten, gehören: erhebliches Datenvolumenwachstum (mehr als 25 % Anstieg), Hinzufügung neuer Berichtsseiten oder komplexer DAX-Maßnahmen, Änderungen in der Benutzergleichzeitigkeit (Benutzerwachstum nach dem Start) und Kapazitätsänderungen (Upgrade, Downgrade oder Migration).

Kann ich die Power BI-Leistung optimieren, ohne meine Berichte zu ändern?

Ja, bis zu einem gewissen Grad. Zu den Optimierungen auf Infrastrukturebene gehören: Upgrade der Kapazitäts-SKU, Aktivieren des Abfrage-Cachings in den Diensteinstellungen, Planen umfangreicher Aktualisierungen außerhalb der Spitzenzeiten, Konfigurieren von Gateway-Clustering für besseren Durchsatz und Optimieren der Quelldatenbank (Indizes, Statistiken, materialisierte Ansichten). Diese Änderungen verbessern die Leistung, ohne die Berichtsdateien zu beeinträchtigen. Die wirkungsvollsten Optimierungen umfassen jedoch in der Regel Änderungen auf Berichtsebene: Umschreiben von DAX-Kennzahlen, Reduzierung der Modellgröße, Aggregationstabellen und Reduzierung der visuellen Anzahl. Durch die Optimierung der Infrastruktur werden Kapazitätsengpässe behoben. Die Berichtsoptimierung zielt auf Effizienz ab.

Was führt dazu, dass Power BI-Berichte mit der Zeit langsamer werden?

Fünf häufige Ursachen: (1) Wachstum des Datenvolumens – dieselben Abfragen dauern länger, wenn die Tabellen von 1 Million auf 10 Millionen Zeilen anwachsen. (2) Kennzahlakkumulation: Neue Kennzahlen werden hinzugefügt, ohne bestehende zu optimieren, und Wechselwirkungen zwischen Kennzahlen führen zu zunehmender Komplexität. (3) Visuelle Ausbreitung – Benutzer fügen pro Seite mehr visuelle Elemente hinzu, die jeweils zusätzliche Abfragen generieren. (4) Modellaufblähung --- Neue Spalten und Tabellen werden hinzugefügt, ohne nicht verwendete zu entfernen. (5) Wachstum gleichzeitiger Benutzer – mehr Benutzer konkurrieren um die gleichen Kapazitätsressourcen. Beheben Sie diese Probleme mit vierteljährlichen Leistungsprüfungen, Governance-Richtlinien, die die visuelle Anzahl begrenzen und die Komplexität messen, sowie proaktiver Kapazitätsüberwachung.