Klassische relationale Datenbanken sind für die Speicherung von Datenzeilen optimiert. Dies ist insbesondere bei Anwendungsfeldern wichtig, wo neue Daten geschrieben und z.B. transaktionale Geschäftsfälle beschrieben werden. Spaltenorientierte Datenbanken hingegen sind für den schnellen Abruf von Datenspalten optimiert und können somit ideal für analytische Anwendungen genutzt werden. Dieses Speicherungsprinzip nutzt auch der Power BI Import-Modus. Darüber hinaus nutzt ein Power BI Datenmodell die VertiPaq Engine, um die vorliegenden Daten zu komprimieren und den Speicherbedarf zu minimieren. Erfahren Sie in unserem Blog-Beitrag, wie diese Kompression im Detail funktioniert, um dieses Wissen für die optimale Modellierung Ihrer Power BI Datenmodelle zu nutzen.

Storage Engine und Formula Engine

Für die Erstellung aussagekräftiger Reports in Power BI verwenden die meisten User DAX, um Berechnungen, wie Aggregation, darzustellen. Jede DAX-Abfrage, wird technisch von zwei Engines verarbeitet: Der Formula Engine und der Storage Engine. In diesem Artikel wollen wir uns tiefergehend mit der Storage Engine beschäftigen und beschreiben, wie diese “unter der Haube” funktioniert. Dieses Wissen kann genutzt werden, den Arbeitsspeicherbedarf eines Datenmodells zu minimieren und dadurch Datasets sowie Reports zu optimieren.

Wenn Daten in Power BI im Import-Modus gespeichert werden, wird im Hintergrund ein Tabular Model auf Basis der SQL-Server Analysis Services generiert. Das Tabular Model leitet die DAX-Abfragen über die Formula Engine dann an die Storage Engine, die in diesem Fall VertiPaq Engine heißt. Im Vergleich dazu ist beim Konnektivitätsmodus DIrect Query die Storage Engine, die ursprünglich angesprochene Datenquelle. Dies könnte z.B. eine klassische relationale SQL-Datenbank sein.

Die VertiPaq Storage Engine

Daten werden in der VertiPaq Engine in einer spaltenorientierten Struktur gespeichert und jede Tabellenspalte mit unterschiedlichen Methoden komprimiert, die in diesem Artikel noch näher beschrieben werden. Im Vergleich hierzu ist eine herkömmlichen SQL-Server Tabelle zu nennen, die Daten physisch zeilenbasiert speichert.

Die VertiPaq Hauptcharakteristika zusammengefasst:

• Spaltenorientierte Datenbank (Inhalte werden physisch spaltenweise abgespeichert, wodurch Festplattenzugriffe reduziert werden. Dies bietet insbesondere Vorteile beim Bilden von Aggregationen über große Spalten ähnlicher Elemente.)
• Das Datenmodell wird komplett im Arbeitsspeicher vorgehalten.

Kompression

Da Spaltendaten in der VertiPaq stets einen einheitlichen Datentyp vorweisen müssen, stehen diverse Möglichkeiten zur Verfügung den physischen Speicherplatz zu reduzieren, was hingegen bei zeilenbasierten Tabellen weniger möglich ist. Die Kompression der Spalten hat jedoch auch den Nachteil, dass die Lesegeschwindigkeit darunter leiden kann. Der Zugriff auf einzelne Daten einer komprimierten Spalte können langsamer sein, da zunächst die Daten dekomprimiert werden müssen, um einen oder wenige Datensätze einzeln auszulesen.

VertiPaq-Komprimierungsalgorithmen zielen darauf ab, den Speicherbedarf des Datenmodells zu reduzieren. Die Reduzierung der Speicherauslastung ist aus zwei sehr guten Gründen eine sehr wichtige Aufgabe:‎

• Ein kleineres Modell nutzt die zugrundeliegende Hardware besser aus. Der Power BI Service sowie die lokale Entwicklung von Power BI Berichten unterliegt gewissen RAM-Grenzen anhand der Power BI Service-Kapazitätsgröße bzw. Arbeitsspeicherausstattung des eigenen Rechners. Einsparungen des RAM sind immer eine gute Option, wenn dies machbar ist.‎
• Ein kleineres Modell ist schneller zu scannen. So einfach diese Regel auch ist, sie ist sehr wichtig, wenn es um Leistung geht. Wenn eine Spalte komprimiert wird, scannt die Engine weniger RAM, um den Inhalt zu lesen, was zu einer besseren Leistung führt.‎

Im Folgenden schauen wir uns die Komprimierungsalgorithmen im Detail an.

Value Encoding

Für die Veranschaulichung können wir uns ein Szenario überlegen, in dem Preise von Produkten als Integer, also ganze Zahlen, gespeichert werden. Die Spalte enthält viele verschiedene Werte, und um sie alle darzustellen, braucht man eine bestimmte Anzahl von Bits.

In dem unten gezeigten Beispiel beträgt der maximale Preis eines Produktes 250 (Währungseinheiten). Daher werden mindestens 8 Bit für die Speicherung der einzelnen Werte benötigt.

Mit einer einfachen mathematischen Operation lässt sich der Speicherbedarf reduzieren. Im Beispiel identifiziert der Algorithmus, dass es durch Subtraktion des Minimalwerts (219) von allen Werten der Spalte den Wertebereich der Spalte ändern und ihn auf einen Bereich von 0 bis 31 reduzieren konnte. Die Speicherung der Zahlen von 0 bis 31 erfordert weniger Bits als die Speicherung von Zahlen bis 250. Auch wenn 3 Bits nur als eine kleine Ersparnis zu sein scheinen, ergeben sich erhebliche Speichervorteile, wenn dieses Beispiel um ein paar Milliarden Zeilen erweitert wird. Wenn die Spalte z.B. in einem Bericht verwendet wird, muss die Transformation in umgekehrter Richtung erneut angewendet werden, um den ursprünglichen Wert zu erhalten. Dies erhöht die CPU-Auslastung und reduziert jedoch die Anzahl der Lesevorgänge, was, wie bereits erwähnt, ein erwünschtes Verhalten ist.

Value Encoding erfolgt nur für Tabellenspalten im Integerformat, also Ganzzahlen. Dies schließt z.B. Kommawerte aus.

Wörterbuchkompression

Dieser Algorithmus wird ebenfalls von der VertiPaq Engine zur Reduzierung der zu speichernden Bits verwendet. Wie der Name bereits andeutet, wird ein Wörterbuch mit eindeutigen Werten erstellt. Daraufhin werden die ursprünglichen Spaltenwerte durch Indizes ersetzt, die auf das Wörterbuch referenzieren. Siehe hierfür das folgende Beispiel.

Bei der Wörterbuchkompression spielt es keine Rolle, ob ein String, eine Ganzzahl oder eine Fließkommazahl zur ursprünglichen Darstellung eines Wertes verwendet wird. Dies bedeutet auch, dass es für die VertiPaq Engine keinen erheblichen Unterschied macht, ob numerische Spalten als Integer oder String Datentyp gespeichert werden. Ausschlaggebend für den Speicherbedarf der Spalte ist die Kardinalität, also die Anzahl eindeutiger Werte in der Spalte, nicht der Datentyp. Dies ist insbesondere für gewisse ID-Spalten im Power BI Reporting relevant, da diese als String abgespeichert, intuitiver gefiltert und vielseitig im Reporting genutzt werden können. (Ausgenommen die Integer-Spalte kann durch Value Encoding komprimiert werden und es soll eine optimale Kompression erfolgen.)

Lauflängenkodierung (RLE – run-length encoding)

Der dritte Kompressionsalgorithmus, der von der VertiPaq Engine verwendet wird, reduziert die Größe eines Datensatzes durch die Vermeidung von sich wiederholenden Werten. Als Beispiel kann hierfür wieder eine Spalte mit den Produktkategorien in einer Produkttabelle betrachtet werden. Die Spalte kann den String “Video und TV” wiederholt in Reihe enthalten. In einem solchen Fall wird durch die Lauflängenkodierung die Speicherung sich wiederholender Werte vermieden. Dabei werden die ursprünglichen Werte durch eine Hilfstabelle ersetzt, die den Wert nur einmal enthält, wobei die Anzahl der zusammenhängenden Zeilen den gleichen Wert hat. Die Effizienz des Algorithmus hängt somit stark von dem Wiederholungsmuster der Spalte ab. Siehe hierfür das untere Beispiel:

In der tatsächlichen Anwendung werden die drei vorgestellten Kompressions-Algorithmen kombiniert von der VertiPaq Engine eingesetzt. Value Encoding oder die Wörterbuchkompression werden grundsätzlich im Vorfeld angewendet bevor mit RLE der Datensatz weiter komprimiert werden kann.

Wenn die Kardinalität einer Spalte verringert werden kann, erhöht sich auch die Wahrscheinlichkeit von Wiederholungen. Wenn zum Beispiel eine Spalte, die Zeitinformationen enthält, in der Granularität einer Sekunde gespeichert wird, gibt es bis zu 86.400 unterschiedliche Werte in der Spalte. Wenn dagegen dieselbe Zeitspalte mit der Granularität "Stunde" gespeichert wird, wurde nicht nur die Kardinalität verringert, sondern auch sich wiederholende Werte eingeführt (3.600 Sekunden entsprechen derselben Stunde), was zu einer wesentlich besseren Komprimierung führt. Die Änderung des Datentyps von DateTime zu Integer oder auch String hat jedoch keine relevanten Auswirkungen auf die Spaltengröße.

Die Faktoren, die bei der Arbeit mit einem Tabellenmodell in Bezug auf das Komprimierungsverhältnis somit zu berücksichtigen sind, sind in der Reihenfolge ihrer Bedeutung:

• Die Kardinalität der Spalte, also die Anzahl eindeutiger Werte in Tabellenspalte.‎
• Die Anzahl der Wiederholungen, d.h. die Verteilung der Daten in einer Spalte. Eine Spalte mit vielen wiederholten Werten wird stärker komprimiert als eine Spalte mit häufig wechselnden Werten.‎
• Die Anzahl der Zeilen in der Tabelle.
• Der Datentyp der Spalte. Dieser wirkt sich primär auf die Größe des generierten Wörterbuches aus.

Wir haben gesehen, welche Algorithmen die VertiPaq Engine zur Kompression des Datenmodells nutzt. Daraus lassen sich ganz praktische Umsetzungsmöglichkeiten für die eigne Modellierung ableiten. Zunächst ist es wichtig, die Spalten mit der größten Kardinalität zu überprüfen, ob diese im Datenmodell zwingend notwendig sind. Business Keys oder andere ID Spalten sind zumeist im Reporting weniger relevant und können entfernt werden. Des Weiteren hat das oben genannte Beispiel mit der Zeitdimension eindrucksvoll gezeigt, dass es mitunter ratsam ist die Granularität einer Spalte zu reduzieren, oder z.B. Informationen in mehrere einzelnen Spalte zu unterteilen. Im Vorfeld ist es kaum möglich zu sagen, wie stark ein Datenmodell komprimiert werden kann. Mit dem hier vorgestellten Wissen über die Kompressionslogik der VertiPaq Engine, können Sie jedoch Ihr Modell schrittweise optimieren und eventuelle Speicherlimits bewältigen

Wenn Sie Unterstützung zu Power BI und seiner optimalen Verwendung suchen, sprechen Sie uns gerne an!