Traditionelles vs. virtuelles Data Warehouse: Vergleich der ETL-Performance

Durch die Virtualisierung von ETL-Prozessen kann eine Data-Warehouse-Architektur an Flexibilität gewinnen, der daraus resultierende Nachteil ist eine reduzierte Performanz bei der Verarbeitung von analytischen Anfragen. Dieser Artikel fasst die Ergebnisse meiner Masterarbeit zusammen, die aus einer Kooperation von inovex und der Otto-von-Guericke-Universität entstanden ist. In dieser wurden die Auswirkungen der Virtualisierung von ETL-Prozessen einer traditionellen Data Warehouse Architektur auf dessen Query-Performanz untersucht.

Einführung

Das Analysieren von firmeninternen Daten ist eine wertvolle Unterstützung des Managements bei der Entscheidungsfindung. Diese Aufgabe ist jedoch anspruchsvoll und mit einem hohen Aufwand verbunden. Häufig sind die Firmendaten auf einer Vielzahl von heterogenen Quellsystemen verteilt, besitzen einen hohen Umfang und wachsen schnell. Um aus ihnen einen verlässlichen und maximalen Nutzen generieren zu können, müssen sie bereinigt, standardisiert und integriert werden. Ein hierfür verwendetes System muss also gewisse Anforderungen an Performanz und Skalierbarkeit erfüllen. Demgegenüber stehen meist begrenzte Ressourcen. Ein Projekt für die Umsetzung solch eines Systems muss mit einem begrenzten Budget und innerhalb eines begrenzten Zeitraumes fertiggestellt werden. Die umzusetzende Architektur muss somit alle Anforderungen zukunftssicher erfüllen und möglichst wenige Ressourcen verbrauchen.

Data Warehouse

Eine Möglichkeit, firmeninterne Daten zu integrieren und für Analysen zu nutzen, ist die Verwendung eines Data Warehouses. Es gibt eine Menge Möglichkeiten, wie man solch ein Data Warehouse praktisch umsetzten kann. Viele dieser Möglichkeiten können in zwei Bereiche eingeordnet werden. In den Bereich der „traditionellen“ Data Warehouses, bei denen die Schichten der Architektur persistiert werden, und in den Bereich der virtuellen Data Warehouses, bei denen die Schichten der Architektur mehr oder weniger nur logisch beschrieben werden und keine / kaum physische Repräsentationen existieren.

Die traditionellen Ansätze versuchen durch eine redundante Datenhaltung die Performanz bei der Verarbeitung von analytischen Anfragen zu optimieren, die abzufragende Präsentationsschicht wird hierbei häufig durch einen multidimensionalen Data Mart repräsentiert. Die virtuellen oder meist semi-virtuellen Ansätze versuchen Redundanzen zu minimieren, indem Prozesse nur logisch beschrieben werden und nur bei Abruf „on the fly“ berechnet werden. Es wird somit Performanz für eine erhöhte Flexibilität und eine schnellere Entwicklung geopfert. Diese beiden Ansätze liegen somit auf verschiedenen Enden des Trade-offs zwischen hoher Performanz und hoher Flexibilität.

Die folgende Abbildung stellt eine abstrakte Architektur eines traditionellen Data Warehouses dar:

Die erste Schicht besteht immer aus den sogenannten Quellsystemen. Diese beinhalten die zu analysierenden Daten und können durch verschiedene Systeme repräsentiert werden, am häufigsten handelt es sich dabei um relationale Datenbanken. Diese Daten werden durch sogenannte ETL-Prozesse zunächst aus den Quellen extrahiert und in eine sogenannte Staging Area überführt. Hier werden die Daten transformiert. Konkret werden die Daten von Fehlern bereinigt, in ein einheitliches Format überführt und integriert.

Zum Schluss werden die Daten in ein Core Data Warehouse geladen. Dieses sichert sämtliche integrierten und hochqualitativen Firmendaten und wird deshalb auch als „Single Point of Truth“ bezeichnet. Aus diesem Core Data Warehouse können anschließend Teile extrahiert, voraggregiert und in einen sogenannten Data Mart geladen werden. Hier werden die Daten für analytische Anfragen optimiert zwischengespeichert. Häufig orientieren sich diese Data Marts an Abteilungen oder an Geschäftsprozessen des Unternehmens und bilden als ganzes die Präsentationsschicht, die letztendlich durch die Anwender:innen abgefragt wird.

Was ist ein virtuelles Data Warehouse?

Virtualisierung ist ein Konzept, bei dem Ressourcen von ihren technischen Details abgekoppelt werden. Im Falle eines Data Warehouses werden dessen persistierte Schichten durch virtuelle Tabellen ersetzt, wodurch eine erhöhte Flexibilität, schnellere Entwicklungszeiten und eine einfachere Wartbarkeit des Systems erreicht werden kann. Anstatt die Ergebnisse von ETL-Prozessen zu persistieren, werden diese Prozesse in virtuellen Tabellen gespeichert und nur bei Abruf der Tabellen ausgeführt. Die erhöhte Flexibilität ergibt sich durch eine Reduzierung von Redundanzen bei den gehaltenen Daten. Mit der Virtualisierung entstehen aber auch Nachteile: Der Größte davon ist eine reduzierte Performanz bei der Verarbeitung von analytischen Anfragen. Der Grund hierfür ist die Notwendigkeit, die ETL-Prozesse bei Abruf spontan durchführen zu müssen.

Das Problem ist nun, dass es schwierig ist, den Einfluss der Virtualisierung auf die Performanz einzuschätzen. Zum einen gibt es wenig Material in diesem Bereich, zum anderen gibt es viele Faktoren, welche die Auswirkungen der Virtualisierung beeinflussen. Aus diesem Grunde wurden in meiner Masterarbeit die Auswirkungen der Virtualisierung auf die Verarbeitungszeiten von analytischen Anfragen untersucht. Konkret habe ich ein traditionelles Data Warehouse, bei dem die Präsentationsschicht durch einen multidimensionalen Datenwürfel repräsentiert wird, mit einem semi-virtuellen Data Warehouse verglichen. Das semi-virtuelle Data Warehouse persistierte nur die unverarbeiteten historisierten Quelldaten, sämtliche (E)TL-Prozesse wurden virtualisiert. Das Ziel der Masterarbeit war es, den negativen Einfluss der Virtualisierung auf die Performanz anhand eines Use-Cases greifbarer und konkreter zu machen.

Evaluierung der beiden Ansätze

Für die Evaluierung der beiden Ansätze wurden die folgenden Schritte durchgeführt:

1. Definition und Umsetzung der Quellsysteme
2. Umsetzung des traditionellen und semi-virtuellen Data Warehouses
3. Durchführung einer Menge von analytischen Anfragen
4. Messung der Verarbeitungszeiten bei beiden Ansätzen

Damit die gemessenen Unterschiede relevant sind, mussten die Unterschiede zwischen den beiden Data Warehouses auf deren Architekturen minimiert werden. Es wurden somit beide in derselben Umgebung und mit denselben Technologien umgesetzt. Die durchgeführten ETL-Prozesse sind auch äquivalent. Der Entscheidende Unterschied ist, dass das semi-virtuelle Data Warehouse diese ETL-Prozesse nur logisch beschreibt und die Ergebnisse nicht persistiert. Somit konnten die Unterschiede soweit es ging auf die Architekturen reduziert werden.

Zusätzlich wurden bei den Tests die folgenden Parameter variiert, um zu schauen, ob sich durch die Virtualisierung die Auswirkungen dieser Parameter ändern:

• Datenvolumen
• Partitionierung: Profitieren beiden Ansätze durch eine Partitionierung der Faktentabelle auf eine ähnliche Art und Weise?
• Anzahl der Quellsysteme: Durch eine Erhöhung der Anzahl der Quellsysteme steigt der Integrationsaufwand beim virtuellen Data Warehouse. Wie hoch ist dieser Aufwand?
• Anfragevolumen: Der zu scannende Teil der Faktentabelle wird durch das Anfragevolumen beschrieben. Durch eine Selektion können die Daten gefiltert und der Aufwand kann reduziert werden.
• Anfragekomplexität: Die Anfragekomplexität beschreibt den Aufwand der durchzuführenden Berechnungen auf den zu scannenden Faktendaten. Dieser Aufwand besteht aus Aggregationen, Verbunden zwischen verschiedenen Tabellen und das Gruppieren und Sortieren von Daten.

Ergebnisse

Ich war positiv überrascht über die Leistung des semi-virtuellen Data Warehouses. Es war bei allen Tests um einen konstanten Faktor langsamer als der untersuchte traditionelle Ansatz. Dieser Faktor lag immer beim Drei- bis Fünffachen, d.h. das semi-virtuelle Data Warehouse konnte unter den Bedingungen genauso gut skalieren wie das traditionelle. Es stellte sich jedoch heraus, dass die untersuchten Datenmengen für das verwendete Rechencluster nicht groß genug waren. Die nachfolgende Grafik fasst sämtliche durchgeführten analytischen Anfragen in einer Abbildung zusammen und gibt einen generellen Überblick über die Ergebnisse.

Auf der X-Achse werden die Anfragen nach den zu verarbeitenden Datenmengen und dem jeweiligen Data Warehouse aufgeteilt, auf der Y-Achse wird die zur Verarbeitung benötigte Zeit in Sekunden angegeben. Man kann direkt erkennen, dass das traditionelle Data Warehouse in allen Fällen schneller ist als das virtuelle. Der Unterschied liegt im Mittel bei einem Faktor zwischen 3 und 5. Die aufwendigsten Anfragen werden vom traditionellen Data Warehouse in ~1.5 Minuten verarbeitet, das semi-virtuelle Data Warehouse benötigt ~3.3 Minuten.

In der Tabelle werden die mittleren Laufzeiten von beiden Ansätzen bei verschiedenen Datenmengen zusammengefasst. Die letzte Zeile gibt den Faktor an, um den das semi-virtuelle Data Warehouse langsamer ist als das traditionelle. Bei dem letzten Übergang von 25 GB an Daten auf 50 GB an Daten erreichen beide Ansätze ungefähr eine lineare Skalierung. Das bedeutet, dass bei einer Verdopplung der Datenmenge auch die benötigte Zeit zum Verarbeiten von analytischen Anfragen sich verdoppelt.

Ein weiteres Ergebnis war, dass beide Ansätze auf eine sehr ähnliche Art und Weise durch die untersuchten Parameter beeinflusst wurden. Wenn Beispielsweise bei beiden die Faktendaten entlang der Zeit-Dimension partitioniert wurden, dann profitierten selektierende Anfragen entlang dieser Dimension bei beiden Ansätzen ähnlich gut. Entscheidende Unterschiede gab es wie erwartet nur bei einer Variation der Anzahl der Quellsysteme. Das traditionelle Data Warehouse wird hierdurch kaum beeinflusst, weil die entstehenden Unterschiede durch die Vorverarbeitung der ETL-Prozesse ausgebügelt werden. Das virtuelle Data Warehouse muss diesen Aufwand jedoch on the fly erledigen und wird durch eine Erhöhung der Anzahl der Quellsysteme negativ beeinflusst.

Zusammenfassung und Ausblick

Die Virtualisierung von Ressourcen ist in der Informatik ein sehr wertvolles Konzept. Ich hoffe, dass ich mit diesem kurzen Artikel einen Überblick über die Anwendung dieses Konzeptes im Bereich von Data Warehouse Architekturen verschaffen konnte. Die Ergebnisse der Evaluierung waren überraschend positiv, der semi-virtuelle Ansatz konnte genauso gut skalieren wie der traditionelle Ansatz und reagierte auf sich variierende Parameter sehr ähnlich. Die Performanz war dennoch deutlich langsamer.

Diese Ergebnisse liefern jedoch nur einen kleinen Einblick in die Möglichkeiten der Virtualisierung und gelten nur innerhalb der gesetzten Rahmenbedingungen. Es gibt sehr viele weitere noch nicht untersuchte Faktoren, die einen Einfluss auf die Leistungen der Data Warehouses haben könnten. Bei umfangreicheren ETL-Prozessen, größeren Datenmengen und weiteren Quellsystemen könnten die Ergebnisse ganz anders aussehen.

Allgemein ist dies ein Forschungsbereich, in dem noch nicht viel gearbeitet wurde – es gibt sehr viele Stellen, an denen man tiefer graben könnte. Beispielsweise könnte man schauen, ob unterschiedliche Teile der ETL-Prozesse verschiedene Auswirkungen auf die Performanz haben und ob es einen optimalen Grad an Virtualisierung gibt. Umfangreichere Tests auf größeren Datenmengen und mit zusätzlichen Parametern könnten die Ergebnisse festigen. Auch eine Untersuchung von verschiedenen Optimierungstechniken beim virtuellen Data Warehouse wäre interessant. Man könnte beispielsweise untersuchen, bei welchen Arten von virtuellen Tabellen es sich besonders lohnt, sie im Arbeitsspeicher oder auf der Festplatte zu cachen.

Weiterlesen

Mehr zum Thema Business Intelligence gibt es auf unserer Website. Außerdem sind wir auf der Suche nach neugierigen BI-Entwickler:innen, die in dieser Richtung weiterdenken.