Heute werden wir uns in einige technische Details der Business Intelligence (BI) Infrastruktur stürzen. Was für den Endnutzer im Verborgenen bleibt, ist für den BI-Experten eine wichtige Frage auf der Suche nach der richtigen Lösung. Er muss sich auf der Datenbank-Ebene zwischen zwei komplett verschiedenen Ansätzen entscheiden: dem multidimensionalen und dem tabellarischen Modell. Diese Frage ist beim Start jedes BI Projektes essenziell, denn es ist später nicht möglich, auf ein anderes Modell umzusteigen.
Die Frage, welches Modell besser geeignet ist, ist nicht einfach zu beantworten, sondern hängt von verschiedenen Faktoren ab. Daher betrachten wir heute beide Modelle im Detail.
Entwicklung und Funktionsweise der Modelle
Das Multidimensionale Model OLAP (Online Analytical Processing) wurde schon im Jahr 1998 als ein Teil des SQL Server 7 eingeführt. Eine richtige Verbreitung fand es aber erst mit dem SQL Server 2000, als Microsoft Analysis Services 2000 einführte. Seitdem wurden Multidimensionale Analyse Services bis zur Version „Analysis Services 2016“ stets entwickelt.
Das Multidimensionale Model basiert auf Cubes, Dimensionen und Measures oder Fakten. Die Datenmodellierung erfolgt mit Stern- oder ggf. einem Schneeflocke-Schema. Für jemanden aus dem klassischen Datenbank Umfeld muss beim Einstieg in die multidimensionale Modellierung ein Umdenken stattfinden, was die Fakten und Dimensionen angeht. Während Daten in OLTP (Online-Transaction-Processing) Quellsystemen quer durch das System verteilt sind und das Datenmodell sehr oft einem Spinnennetz ähnelt, sollten Daten in Source Systemen, die als Data–Source für einen Cube dienen, in Fakten und Dimensionen aufgeteilt werden, optimalerweise in einem Stern-Schema.
Bei der Daten-Modellierung sollte man stets die Logik der multidimensionalen Modelle im Hinterkopf behalten. Fakten sind Fakten oder Zahlen und sie werden während des Cube-Processing voraggregiert. Dimensionen beinhalten meistens Attribute, die Fakten beschreiben.
Dimensionstabellen sollten klein gehalten werden – je größer eine Dimensionstabelle ist, umso schlechter ist die Performance beim Cube Processing.
Bevor die Daten aus einem Cube konsumiert werden können, muss der Cube aufbereitet -„geprocessed“ – werden. Bei dem Process wird „SELECT DISTINCT “ auf den Dimensionstabellen ausgeführt und Zahlen werden in Faktentabellen voraggregiert. Aggregationen werden in der multidimensionalen Struktur in Zellen an Koordinaten gespeichert, die durch die Dimensionen angegeben sind. Bei Dimensionen ist bei ca. 2 Mrd. Elementen Schluss. Das heißt, ein Cube kann nicht mehr als 2 Mrd. Elemente in einem Dimensionsattribut beinhalten.
Trotz dieser Einschränkung ist das multidimensionale Modell sehr ausgereift und skalierbar. Das zeigt auch ein Beispiel der Firma Yahoo, bei der ein Cube von ca. 24 TB Größe aus einem 2 PB Hadoop Cluster mit täglicher Beladung von 135 GB zum Einsatz kommt.
Ab dem SQL Server 2012 wurde ein neues Modell eingeführt, das Tabular Model. Das tabellarische Modell basiert auf In-Memory oder xVelocity Technologie, die im SQL Server 2012 auch für relationale Datenspeicherung eingeführt wurde. Diese Technologie benutzt speicheroptimierte Datenspeicherung, den sogenannte Columnstore Index. Daten werden in der Datenbank nicht als Zeilen („Rows“) sondern als Spalten („Columns“) gespeichert. Bei der klassischen Datenbank werden alle Werte in Zeilen gespeichert. Wenn ein Attribut in eine Tabelle mehrmals vorkommt, wird es auch mehrmals gespeichert. Einzelne Zeilen werden dann in einer Datenkette gespeichert. Diese Datenspeicherung ist historisch bedingt – wenn Daten auf ein magnetisches Band oder einer Festplatte sequentiell gespeichert wurden, mussten Sie auch sequentiell gelesen werden also „row by row“.
Bei dem Columnstore Index werden die Daten in einzelne Spalten aufgeteilt und es werden nur eindeutige („distinct“) Werte einer Spalte in der Datenbank gespeichert. Einzelne Spalten werden dann im Arbeitsspeicher (RAM) miteinander verknüpft.
Daten müssen nicht sequentiell gelesen werden, sondern der Datenzugriff erfolgt direkt über die Adresse im Arbeitsspeicher (RAM). Deswegen heißt diese Technologie auch In-Memory Datenverwaltungstechnologie.
Das bringt bis zu hundertfache Performance Steigerung und bis zu siebenfacher Datenkomprimierung gegenüber klassischer Datenbank Technologie.
Wie der Name schon sagt ist der Arbeitsspeicher der Hauptbestandteil der Technologie. Entsprechend ist zur Nutzung dieser Technologie genügend RAM erforderlich.
Soviel zur Entstehung und Funktionsweise der Technologien die hinter beiden Modellen steckt. Zeit, sich mit den unterschiedlichen Features zu beschäftigen.
Wie schon erwähnt ist das multidimensionale Modell sehr ausgereift und wird ab Version 2012/2014 eigentlich nicht mehr weiter entwickelt, da alle wichtigen Features schon enthalten sind. Deswegen gibt es auch nicht viele Unterschiede zwischen Versionen 2012/2014 oder 2016.
Ganz anders ist die Situation bei dem tabellarischen Modell. Das Tabular Model wurde erst mit dem SQL Server 2012 eingeführt und bis Version 2017 stets weiterentwickelt. Entsprechend gibt es große Unterschiede zwischen den Versionen. Daher spielt die genutzte Version des SSAS Server im Unternehmen eine große Rolle bei der Entscheidung, welches Modell für den Business Intelligence Einsatz besser geeignet ist.
Ein weiterer wichtiger Punkt bei der Entscheidung ist der Kompatibilitätsgrad eines Modells. Der Kompatibilitätsgrad bezieht sich auf release-spezifische Verhalten in der Analysis Services-Engine. Also beispielsweise, welche Datenquellen unterstützt werden, welche Funktionen in eingebauten Skript Sprachen zu Verfügung stehen und welche Berechnungen durchgeführt werden können. Der Kompatibilitätsgrad hat auch Auswirkung auf die Leistung der Queries.
Grob verglichen können wir sagen, dass Tabular 2012 und 2014 eine relativ ähnliche Funktionalität anbieten. Dann gibt es einen großen technologischen Sprung zur Version 2016 und zwischen Version 2016 und 2017 gibt es wieder nur kleine Unterschiede. Daher vergleichen wir die Versionen 2012/2014 und 2016/2017 mit dem multidimensionalen Modell.
Hier sind die hauptsächlichen Unterschiede der Modelle im direkten Vergleich:
| Multidimensional | Tabellarisch 2012/2014 | Tabellarisch 2016/2017 | |
| Many to Many Relationships | Ja | Nein | Ja |
| Writeback (Benutzer kann in die SSAS Database schreiben) | Ja | Nein | Nein |
| Translations (Metadata und Attribute können in verschiedenen Sprachen ausgegeben werden) | Ja | Nein | Ja |
| Row Level (Cell) Security (Zugriff zu Daten durch Object Level Security gesteuert) | Ja | Nein | Ja |
| Unregelmäßige Hierarchien (nicht dieselbe Anzahl von übergeordneten Elementen) | Ja | Nein | Ja |
| Parent / Child Hierarchien (nicht dieselbe Anzahl von übergeordneten Elementen) | Ja | DAX Funktion | DAX Funktion |
| Role-Playing Dimensionen (Dimension mit mehreren Bedeutungen) | Ja | DAX Funktion | DAX Funktion |
| Display Folders (um die Measures besser zu organisieren) | Ja | Mit Add-in | Ja |
| Drillthrough (um die Detail Data zu sehen) | Ja | BIDS Helper Add-in | 2016: BIDS Helper Add-in 2017: Ja |
Zuletzt schauen wir uns noch die Datenquellen für beide Modelle an. Bei Datenquellen gibt es keine großen Unterschiede zwischen dem Tabular und Multi-Dimensional Model.
Für beide Modelle können zwei verschiedene Modi ausgewählt werden. Im ersten Modus werden Daten aus der Quelle zwischengespeichert, „gecached“. Dieser Modus ist natürlich schneller.
Im Multi-Dimensional Model heißt dieser Modus MOLAP. Dies ist der Standard Modus, bei dem die Daten aus dem Quellsystem beladen, voraggregiert und in einer speziellen multidimensionalen Form im Analysis Services gespeichert werden.
Im zweiten Modus werden Daten aus dem Quellsystem nicht zwischengespeichert und das Modell und alle Berechnungen werden „on the fly“ direkt auf dem Quellsystem durchgeführt.
Im Multi-Dimensional Model heißt diese Modus ROLAP. Dabei werden keine Daten aus dem Quellsystem gezogen, sondern es werden lediglich zusätzliche Datenbankobjekte, wie Indexed Views, generiert, auf denen die Berechnungen im Cube basieren. Im Tabular Model heißt dieser Modus Direct Query Modus.
Das Multi-Dimensional Model unterstützt als Datenquelle fast alle relationalen Datenbanken plus MS Access.
Das Tabular Model unterstützt hingegen im Cached Modus deutlich mehr Datenquellen. Neben vieler relationaler Datenquellen auch Analysis Services Cube, Excel, csv, Text Files, Data Feeds und Office Database Connection Files.
Das Direct Query Model arbeitet nur mit relationalen Datenbanken ausfolgenden Systemen: SQL Server, Azure SQL Database, Oracle, und Teradata.
Abschließend können wir also festhalten, dass beide Systeme komplett unterschiedlich arbeiten, obwohl am Ende aus der Sicht des Endbenutzers die gleichen Daten rauskommen.
Das Tabular Model ist die neuste Entwicklung im BI-Bereich und kann mit seiner vielseitigen Performance durchaus überzeugen. Allerdings gibt es große Unterschiede zwischen den Versionen. Während das multidimensionale Modell dem tabellarischen Modell in der Version 2012/2014 noch deutlich überlegen ist, bietet das Tabular Model ab der Version 2016 gut Paroli.
Nachdem wir nun die technische Seite beleuchtet haben, werde ich mich in einem meiner nächsten Beiträge mehr mit den Unterschieden auf Benutzerseite auseinandersetzen und darauf eingehen, wie die Daten in beiden Systemen modelliert und wie Berechnungen implementiert werden.
