VertiPaq Engine in Power BI

Haben Sie sich schon mal gefragt, was Power BI so stark macht, wenn es um das Thema Performanz geht? So stark, dass komplexe Kalkulationen über Millionen von Zeilen in kürzester Zeit durchgeführt werden können.
In diesem Artikel werfen wir einen Blick darauf, was sich “unter der Haube” von Power BI versteckt, wie Ihre Daten gespeichert, komprimiert, abgefragt und letztendlich auf Ihre Report-Oberfläche projiziert werden.

Formel Engine & Speicher Engine

Dazu schauen wir uns die VertiPaq Engine an. Sie dient nicht nur Power BI als “Gehirn und Muskeln”, sondern auch in den Analysis Services (Tabellarisch) und in Excel Power Pivot. Genau genommen repräsentiert die VertiPaq Engine jedoch nur einen Teil der Speicher Engine innerhalb des tabellarischen Modells.

Aber Schritt für Schritt…:
Senden wir eine Abfrage um Daten für unseren Power BI Report abzurufen, passiert folgendes:

• Formel Engine / Formula Engine (FE) nimmt den Request an, prozessiert ihn, erstellt einen Abfrageplan und führt diesen im Anschluss aus.

• Speicher Engine / Storage Engine (SE) zieht die Daten aus dem tabellarischen Modell, um den von der FE ausgelösten Request zu beantworten.

Die Speicher Engine arbeitet auf zwei verschiedene Wege, um die angeforderten Daten aus der Datenquelle zu bekommen. VertiPaq hält einen Abzug der Daten im Arbeitsspeicher. Dieser Abzug kann von Zeit zu Zeit aktualisiert werden, indem erneut Daten von der eigentlichen Datenquelle abgefragt werden.

Im Gegensatz dazu speichert DirectQuery keine Daten. Die erstellte Abfrage wird für jeden einzelnen Request direkt an die eigentliche Datenquelle weitergeleitet.

Formel Engine

Wie bereits gesagt, besteht die Aufgabe der Formel Engine darin, die Abfrage entgegenzunehmen; und da sie DAX (und MDX, was hier jedoch nicht weiter betrachtet wird) interpretieren kann, übersetzt sie diesen Code in einen spezifischen Abfrageplan. Dieser Plan beinhaltet physische Operationen, die ausgeführt werden müssen, um letztendlich ein Ergebnis zu erhalten.

Diese physischen Operationen können beispielsweise Joins zwischen mehreren Tabellen, Filterungen oder auch Aggregationen sein. Dabei arbeitet die Formel Engine immer in einem Single-Thread-Verfahren, das heißt, dass die Anfragen an die Speicher Engine immer sequentiell gesendet werden.

Speicher Engine

Sobald der Abfrageplan von der Formel Engine generiert und weitergeleitet wurde, kommt die Speicher Engine ins Spiel. Sie geht entweder physisch durch die im Tabellenmodell (VertiPaq) gespeicherten Daten oder leitet die Abfrage direkt an die darunterliegende Datenquelle (z.B. SQL Server) weiter, sofern die DirectQuery Verbindung gewählt wurde.

Bei der Angabe der Speicher Engine für eine Tabelle gibt es drei mögliche Optionen, zwischen denen Sie wählen können:

• Import Modus - basierend auf VertiPaq. Die Tabelleninhalte werden aus der zugrundeliegenden Datenquelle abgefragt und als Snapshot im Arbeitsspeicher abgelegt. Die Daten können in regelmäßigen Abständen aktualisiert werden

• DirectQuery - die Daten werden zum Zeitpunkt der Abfrage (also beim Aufruf des Reports durch den Anwender) aus der Datenquelle abgerufen. Die Daten befinden sich vor, während und nach der Ausführung der Abfrage immer in ihrer ursprünglichen Datenquelle.

• Dualer Modus - Kombination der ersten beiden Optionen. Daten können sowohl im Speicher gehalten als auch per Direktabfrage aus der Datenquelle gezogen werden. Insbesondere bei der Anbindung mehrerer unterschiedlicher Datenquellen kann diese Option sehr hilfreich sein. Im Gegensatz zur Formel Engine, die keine Parallelität unterstützt, kann die Speicher Engine asynchron arbeiten.

VertiPaq Speicher Engine

An dieser Stelle wollen wir nun einen genaueren Blick auf die VertiPaq Speicher Engine werfen um zu erfahren, wie sie im Hintergrund arbeitet um die Performanz unserer Power BI Reports zu verbessern.

Wenn wir den Import Modus für unsere Tabellen auswählen, werden folgende Aktionen von der VertiPaq Engine durchgeführt:

• Lesen der Datenquelle, Transformation in eine Struktur aus mehreren Spalten, Kodierung und Komprimierung der Daten in der Spalte
• Erstellung von Indizes für die einzelnen Spalten
• Vorbereitung und Aufbau von Beziehungen
• Berechnung aller berechneten Spalten und berechneten Tabellen, anschließende Komprimierung

VertiPaq hat also zwei Haupt-Charakteristiken

1. VertiPaq ist eine spaltenbasierte Speichermethode
2. VertiPaq ist eine In-Memory Speichermethode

Wie Sie in der obigen Abbildung sehen können, speichern und komprimieren spaltenbasierte Datenbanken Daten auf eine andere Weise als herkömmliche zeilenbasierte Speicher. Spaltenbasierte Datenbanken sind für das vertikale Scannen von Daten optimiert, was bedeutet, dass jede Spalte auf ihre eigene Weise strukturiert und physisch von anderen Spalten getrennt ist.

Beispiel aus dem Buch “The Definitive guide to Dax” von Marco Russo und Alberto Ferrari

Ohne an dieser Stelle näher auf Vor- und Nachteile von zeilen- und spaltenbasierten Datenbanken einzugehen, da hierfür eine eigene Artikelserie notwendig wäre, möchten wir hier nur einige wichtige Unterschiede in Bezug auf die Leistung aufzeigen.

Bei spaltenorientierten Datenbanken ist der Zugriff auf eine einzelne Spalte schnell und effektiv. Sobald die Berechnung mehrere Spalten umfasst, werden die Dinge komplexer, da die Ergebnisse von Zwischenschritten auf irgendeine Weise zwischengespeichert werden müssen.

Vereinfach gesagt, sind spaltenbasierte Datenbanken CPU-lastiger, während zeilenbasierte Datenbanken aufgrund der vielen Scans nutzloser Daten mehr I/O erfordern.

Codierung

Wir haben gelernt, dass spaltenbasierte Datenbanken die einzelnen Spalten physisch voneinander getrennt speichern und individuell strukturieren können. Das hat den Vorteil, dass die VertiPaq Engine verschiedene Typen an Komprimierungs-Algorithmen je nach Inhalt der einzelnen Spalten anwenden kann.

Die Komprimierung wird erreicht, indem die Werte innerhalb der Spalte codiert werden. Im Hintergrund arbeitet hierbei ein tabellarisches Modell, wie wir es auch aus den Analysis Services und Excel Power Pivot kennen. Sehen wir uns im nächsten Schritt verschiedene Codierungs-Algorithmen an.

Wert-Codierung

Dieser Codierungstyp arbeitet ausschließlich mit ganzen Zahlen und benötigt daher weniger Speicher als zum Beispiel das Arbeiten im Textwerten.

Schauen wir uns hierzu ein Beispiel an. Nehmen wir an, wir haben eine Spalte mit der Anzahl an Telefonaufrufen pro Tag, wobei der Wert dieser Spalte zwischen 4000 und 5000 schwankt. Die VertiPaq Engine würde als Ausgangspunkt den niedrigsten Wert in diesem Bereich (also 4000) ermitteln, dann die Differenz zwischen diesem Wert und allen anderen Werten in der Spalte berechnen und diese Differenz als neuen Wert speichern.

Auf den ersten Blick mögen 3 Bits pro Wert nicht nach einer großen Einsparung aussehen, aber multipliziert man diese Einsparung mit Millionen von Zeilen, dann werden Sie die Menge des eingesparten Speichers zu schätzen wissen.

Hash-Codierung

Dies ist vermutlich der am häufigsten von VertiPaq genutzte Codierungstyp. VertiPaq erzeugt eine Art Lexikon an eindeutigen Werten welche innerhalb einer Spalte vorkommen und ersetzt diese im Anschluss mit den Index-Werten des Lexikons.

Eindeutige Werte innerhalb der Spalte “Angebotsstatus” wurden also erkennt, in einem Lexikon zusammengefasst und mit Index-Werten versehen. Diese Indexwerte wurden als Zeiger auf die echten Werte dann wiederum gespeichert. Der Vorteil ergibt sich dadurch, dass diese Integer-Werte wesentlich weniger Speicherplatz benötigen als die zuvor gespeicherten Textwerte.

Dabei ist es egal, ob die Spalte vom Datentyp Text, Bigint oder Float ist, VertiPaq kann für alle diese Spalten ein Lexikon erstellen, was wiederum bedeutet, dass alle diese Datentypen sowohl im Bezug auf Geschwindigkeit als auch auf den belegten Speicherplatz die gleiche Leistung haben!

Es ist also ein Mythos, dass der Datentyp einer Spalte ihre Größe innerhalb des Datenmodells beeinflusst. Im Gegenteil, die Anzahl der eindeutigen Werte innerhalb der Spalte, die als Kardinalität bezeichnet wird, hat den größten Einfluss auf den Speicherverbrauch der Spalte.

Lauflängencodierung

Die Lauflängencodierung (Run-Length-Encoding; kurz RLE) ist ein einfacher, verlustfreier Kompressionsalgorithmus der sich dazu eignet, längere Wiederholungen von Symbolen zu komprimieren. Die Grundidee des Algorithmus ist, jede Sequenz von identischen Symbolen durch deren Anzahl und ggf. das Symbol zu ersetzen. Das heißt, es werden nur die Stellen markiert, an denen sich das Symbol in der Nachricht ändert.

In der Praxis speichert VertiPaq jedoch keine Startwerte, da es den Beginn des nächsten Knotens schnell berechnen kann, indem es die vorherigen Count-Werte summiert.

So leistungsfähig dieser Algorithmus auf den ersten Blick auch sein mag, RLE ist stark von der Reihenfolge der einzelnen Werte innerhalb der Spalte abhängig. Wenn die Daten so gespeichert sind, wie im obigen Beispiel zu sehen, funktioniert der Algorithmus hervorragend. Wenn die Datenbereiche jedoch kleiner sind und häufiger rotieren, wäre RLE keine optimale Lösung.

Ein weiterer Hinweis zu RLE: In Wirklichkeit speichert VertiPaq die Daten nicht so, wie sie in der obigen Abbildung dargestellt sind. Zuerst wird eine Hash-Codierung durchgeführt und ein Lexikon erstellt, dann wird der RLE-Algorithmus darauf angewendet.

Also wird RLE nicht an Stelle, sondern zusätzlich zur Hash-Codierung verwendet, nämlich immer dann wenn VertiPaq davon ausgeht, dass es Sinn macht, die Daten zusätzlich zu komprimieren.

Neu-Codierung

Egal wie “intelligent” VertiPaq ist, es können durchaus auch falsche Entscheidungen getroffen werden, die auf fehlerhaften Annahmen beruhen. Bevor wir allerdings darauf eingehen, wie die Neu-Codierung funktioniert, betrachten wir kurz den Prozess der Datenkomprimierung für eine Spalte.

• VertiPaq scannt eine Stichprobe von Zeilen aus der betrachteten Spalte
• Wenn der Datentyp keine ganze Zahl ist, sucht es nicht weiter und verwendet die Hash-Codierung
• Wenn die Spalte vom Typ Integer ist, werden einige zusätzliche Parameter ausgewertet: Wenn die Zahlen in der Stichprobe linear ansteigen, geht VertiPaq davon aus, dass es sich wahrscheinlich um einen Primärschlüssel handelt und wählt die Wert-Codierung.
• Wenn die Zahlen in der Spalte relativ nah beieinander liegen (der Zahlenbereich ist nicht sehr groß, wie in unserem obigen Beispiel mit 4.000 - 5.000 Telefonanrufen pro Tag), verwendet Vertipaq die Wert-Codierung. Wenn die Werte innerhalb des Zahlenbereichs stark schwanken (z.B. 1.000 und 1.000.000), ist die Wert-Codierung nicht sinnvoll und VertiPaq wendet den Hash-Algorithmus an.

Es kann jedoch auch vorkommen, dass VertiPaq auf der Grundlage der Beispieldaten eine Entscheidung über den zu verwendenden Algorithmus trifft, dann aber ein Ausreißer im Datenset auftaucht und die Spalte von Grund auf neu codiert werden muss.

Nehmen wir unser obiges Beispiel für die Anzahl der Telefonaufrufe: VertiPaq scannt die Stichprobe und entscheidet sich für die Wertcodierung. Nach der Verarbeitung von 10 Millionen Zeilen wird plötzlich der Wert 50.000 gefunden. Dabei kann es sich auch um einen Fehler im Datenset handeln. Jetzt bewertet VertiPaq die Entscheidung neu und kann beschließen, die Spalte stattdessen mit dem Hash-Algorithmus neu zu codieren. Dies würde sich dann natürlich auf den gesamten Prozess und insbesondere auf die für die erneute Verarbeitung benötigte Zeit auswirken.

Fazit

Das Verständnis der unterschiedlichen Rollen der Formel- und Speicher-Engine (insbesondere VertiPaq) bei der Ausführung einer DAX-Abfrage ist der erste Schritt zur Optimierung dieser DAX-Abfrage. Viele Performance-Probleme, wie z.B. die umfangreiche Materialisierung von Datenspeichern oder eine übermäßige Anzahl von Speicher-Engine-Anfragen, sind oft die Symptome von Problemen im Datenmodell oder in DAX-Formeln.