Power BI Update Februar 2026

Power BI Performance Deep Dive #2: Die VertiPaq Engine

Die Anpassungen, die von uns im Power BI Performance Deep Dive #1 empfohlen werden, zielen darauf ab, die VertiPaq Engine möglichst effizient arbeiten zu lassen. Die VertiPaq Engine wird auf verschiedenen Plattformen verwendet und nicht nur in Power BI, sondern auch in Excel (mittels PowerPivot), Analysis Services und Microsoft Fabric.

Bei der VertiPaq Engine handelt es sich um eine spaltenbasierete In-Memory-Engine, die Daten stark komprimiert im Arbeitsspeicher hält. Das ermöglicht extreme Kompression, sehr schnelle Scans und parallele Verarbeitung. Sie ist von entscheidender Bedeutung für die Performance von Abfragen in PowerBI.

Verarbeitung einer DAX-Abfrage

Wenn wir ein Measure in Power BI schreiben, und dieses in einem Report auswerten (z.B. einen Filter anwenden oder ein Visual aktualisieren), generiert das Frontend eine DAX-Abfrage, die an die Analysis Services-Engine (lokal in Power BI Desktop oder in der Cloud/am Server) gesendet wird. 

Diese wird an zwei Engines weitergeleitet, die Formula Engine (FE) empfängt die DAX-Abfrage, interpretiert sie und zerlegt sie in logische Schritte. Sie erstellt einen detaillierten Abfrageplan, der festlegt, welche Daten benötigt werden und wie sie verarbeitet werden müssen, um das gewünschte Ergebnis zu erzielen. Die FE ist für die Ausführung der komplexeren DAX-Logik zuständig. 

Die FE kann selbst keine Daten aus dem Datenmodell abrufen, sondern sendet Anfragen an die Storage Engine (SE), um die im Abfrageplan spezifizierten Daten zu erhalten. Die SE ist für die effiziente Datenkomprimierung und -speicherung verantwortlich. 

Die SE ruft in weiterer Folge die angeforderten Daten ab. Die Art und Weise, wie dies geschieht, hängt vom Speichermodus ab: 

• Import-Modus (VertiPaq): Die SE greift auf den komprimierten, spaltenbasierten In-Memory-Cache zu. Sie nutzt Multi-Threading (mehrere CPU-Kerne), um Daten schnell zu scannen, zu filtern und einfache Aggregationen durchzuführen, bevor sie als Daten-Cache an die FE zurückgesendet werden.
• DirectQuery-Modus: Die SE generiert eine entsprechende SQL-Abfrage und sendet diese direkt an die externe Datenquelle (z.B. eine Datenbank), um die benötigten Daten in Echtzeit abzurufen. Durch die Konvertierung in eine SQL-Abfrage ist bei der Verwendung des DirectQuery-Modus DAX nur eingeschränkt nutzbar, da manche DAX-Funktionen nicht in SQL übersetzt werden können.

Der Import Modus ist hierbei zu bevorzugen, da der DirectQuery-Modus das Vorsystem belastet. Bei großen Datenmodellen oder Datenmodellen, die sehr oft aktualisiert werden müssen, kann es aber nötig sein, den DirectQuery-Modus zu verwenden.

Sobald die FE den Daten-Cache von der SE erhalten hat, wendet sie die restlichen DAX-Ausdrücke und komplexeren Berechnungen (unter Berücksichtigung des Zeilenkontexts und Filterkontexts) darauf an. Die FE ist zwar vielseitig, aber verwendet nur einen CPU-Kern. 

Das endgültige, berechnete Ergebnis wird dann strukturiert und an das Power BI-Visual im Bericht zurückgesendet, wo es angezeigt wird. 

Dieser gesamte Prozess - obwohl komplex - findet in der Regel so schnell statt, dass er für den/die Benutzer:in nahezu augenblicklich erscheint. Diesen Prozess kann man mithilfe externer Tools wie DAX Studio analysieren und die Leistung optimieren. 

Dafür wenden wir zuerst die Leistungsanalyse in Power BI an. Diese ist unter “Optimieren” zu finden.

Nach dem Wählen einer Reportseite können wir „Visuals aktualisieren“ anklicken und damit Bottlenecks identifizieren.

Durch Klicken auf “Abfrage kopieren” können wir diese Abfrage in DAX Studio verwenden. Nach Installation können wir dieses direkt unter “Externe Tools” in Power BI aufrufen:

Nach Kopieren der Abfrage können wir diese genau ansehen und gegebenenfalls optimieren.

Dem Optimieren von Abfragen in DAX widmen wir uns im nächsten Blogbeitrag.