Kommentar von Gerrit Bury, Inform Sind Data Warehouses alternativlos?

Anbieter zum Thema

Disy Informationssysteme GmbH

Confluent Germany GmbH

INFORM GmbH

Wer Daten aus verschiedenen Quellen für komplexe Analysen nutzen möchte, betreibt in der Regel ein Data Warehouse. Doch um auch Lastspitzen abfangen zu können, sind Aufwand und Kosten hoch. Gibt es Alternativen?

Ein Data Warehouse (DWH) ist für Unternehmen notwendig, wenn Analysen (Reporting, Advanced Analytics, Business Intelligence, Machine Learning, Data Mining) unterschiedliche Daten gezielt nutzen möchten. Die Datensätze werden dann dafür von entsprechenden Werkzeugen aus den jeweiligen Quellsystemen in die Datenbank transferiert. Immer mehr Unternehmen entscheiden sich hier für eine ELT-Strategie (Extract, Load, Transform – oder auch Schema on Read), bei der die Transformationen bei der Abfrage durchgeführt und sowohl strukturierte als auch unstrukturierte Daten im Rohformat abgespeichert werden.

Ein On-Premises-Data-Warehouse sollte von der Hardware so skaliert sein, dass Abfragen auch bei Lastspitzen entsprechend bedient werden können. Das impliziert, dass die Hardware zu einem Großteil der Zeit überdimensioniert ist. Außerdem müssen sich eigene Mitarbeiter um den Betrieb der ETL-Strecken kümmern. Der Betrieb eines On-Premises Data Warehouse ist somit (neben den reinen Hardware- und Lizenzkosten) auch wegen der Skalierbarkeit und Zukunftssicherheit eine Herausforderung. Außerdem gibt es Bedingungen, wie Governance-Regelungen, die ein lokales DWH unabdingbar machen. Gibt es also überhaupt Alternativen zum On-Premises-Betrieb?

Möglichkeit 1: Qlik Sense als DWH-Ersatz

Keine Frage, Qlik Sense ist ein sehr gutes und modernes Business Intelligence (BI) Tool. Es kann hervorragend zur Visualisierung von Daten genutzt werden, insbesondere, wenn Daten aus mehreren Quellen geladen werden müssen.

Qlik Sense bringt eine eigene SQL-ähnliche und sehr mächtige Abfragesprache mit und kann im Gegensatz zu anderen BI-Tools dank dieser ETL-Abfragemöglichkeiten ein Data Warehouse prinzipiell sogar ersetzen. Hierzu lässt sich die Qlik-eigene Möglichkeit nutzen, Daten nach der Abfrage („Extract“) und ggf. weiteren Berechnungen, wie z. B. Data Cleansing oder dem Vereinheitlichen unterschiedlicher Quellen („Transform“), als eine QVD-Datei auf der Festplatte abzuspeichern. Die Datenhaltung innerhalb dieser QVD-Dateien ist spaltenorientiert und komprimiert, sodass ein Komprimierungsfaktor von eins zu zehn gegenüber den Rohdaten üblich ist. Der spätere Zugriff auf diese Daten ist sehr performant.

Aus den QVD-Dateien lassen sich entsprechende Analysen, Reports und Dashboards erstellen oder auch ad-hoc Self-Service-BI-Abfragen starten. Über ein geschicktes Abspeichern der QVD-Dateien können darüber hinaus Delta-Loads realisiert, Data Marts aufgebaut und auch historische Aufzeichnungen von Datenquellen umgesetzt werden.

Die positiven Aspekte einer solchen Entwicklung sind üblicherweise, dass ein Qlik-Projekt deutlich schneller, agiler und damit auch kostengünstiger zu realisieren ist, als ETL-Strecken für ein Data Warehouse zu programmieren. Sowohl die Extraktion der Daten, die Datenmodellierung als auch die Datenvisualisierung und das Reporting finden im gleichen Tool statt, sodass Lizenzkosten für das DWH und ggf. notwendige ETL-Tools entfallen.

Nachteil dieser Option ist jedoch ein starker Vendor-Lock-in: QVD-Dateien können ausschließlich von Qlik-Produkten ausgelesen und verwendet werden. Eine weitere Nutzung der Daten außerhalb von Qlik (z. B. für Machine-Learning-Projekte mit R oder Python) ist nur schwierig umsetzbar. Hinzu kommt eine schlechte Skalierbarkeit: QVD-Dateien sind nicht für eine Langzeitarchivierung in Terabyte- oder Petabyte-Größe vorgesehen. Sie können also nicht als vollwertiger Ersatz für Big Data Use-Cases in Betracht gezogen werden.

Möglichkeit 2: Query Engine auf einem (Cloud) Data Lake

Eine weitere Alternative zum Betrieb eines Data Warehouse ist ein schneller, aber günstiger Cloud-Data-Lake-Storage (z. B. Azure Data Lake Storage gen 2) für die Datenspeicherung in Kombination mit einer Query-Engine (z. B. Dremio) für die Abfrage der Daten. Ein Vorteil dieser Architektur ist, dass die volle Skalierbarkeit der Cloud bzgl. Speicherplatz (Storage) und Rechenleistung (Compute) unabhängig voneinander genutzt werden können. Das Befüllen des Data Lakes gestaltet sich im Vergleich zu einem konventionellen DWH deutlich einfacher und schneller, da hier die Rohdaten eins zu eins im Data Lake abgelegt werden. Die Strategie ist ELT („Extract, Load, Transform“).

Notwendige Transformationen finden zu diesem Zeitpunkt (noch) nicht statt, sondern werden auf nachgelagerte Abfragen z. B. in Qlik Sense oder anderen Tools verschoben. Alternativ können jedoch vorbereitete Views, „Materialized Views“ oder „Reflections“ zur Verfügung gestellt werden, in denen bereits Logik verbaut ist, um Abfragen zu vereinfachen und zu beschleunigen. Für die Abfragen der Daten, selbst auf unstrukturierten Daten wie JSON-Dateien, kann die weit verbreitete Abfragesprache SQL genutzt werden. Die Notwendigkeit, die Daten in ein geordnetes Schema eines DWH zu transformieren, entfällt hierbei. Es gibt keinen Vendor-Lock-in, da sich die Daten jederzeit problemlos z. B. zu einem anderen Cloud-Anbieter transferieren lassen. Zu den bereits beschrieben Vorteilen kommt hinzu, dass die Daten nicht in einem DWH (in Cubes, Data Marts, …) dupliziert werden müssen und dafür Kosten entfallen.

Nachteilig ist dagegen die Notwendigkeit, mehr Aufwand in die Erstellung von vorbereiteten Views oder Virtual Datasets zu stecken, damit auch weniger eingearbeitete Anwender gesicherte Datenabfragen auf Basis einer geprüften Datengrundlage (ad-hoc) durchführen können. Ein Großteil des Aufwands wird in die Abfrage der Daten in entsprechenden Tools (Qlik, Tableau, Power BI, R, Python) verlagert. Die geringere Komplexität durch das Vermeiden von ETL verschiebt sich also nur auf einen späteren Zeitpunkt und zum Teil in andere Werkzeuge.

Möglichkeit 3: Cloud Data Warehouses

Die dritte Alternative ist die Nutzung eines modernen Cloud Data Warehouse (z. B. Snowflake oder Azure Synapse). Im Zusammenspiel mit einem Cloud-Data-Lake-Storage ergeben sich nahezu unbegrenzte Speichermöglichkeiten und Skalierbarkeit. Gegenüber einem On-Premises Data Warehouse bieten die Cloud-basierten Varianten erhebliches Potenzial für die Kostensenkung bei gleichzeitiger Steigerung von Security und Verfügbarkeit. Durch die „Pay-per-use“-Strategie ist laut dem Forrester Wave Cloud Data Warehouse Report mindestens mit Einsparungen von 20 Prozent im Vergleich zu lokalen Data Warehouses zu rechnen. Einige Unternehmen konnten dadurch sogar Einsparungen zwischen 70 und 80 Prozent realisieren.

Ein Hauptproblem von DWH-Architekturen ist die arbeitsaufwendige Erstellung und der Betrieb der ETL-Strecken zum Befüllen der DWH-Systeme. Sollten sich Änderungen am Quellsystem ergeben, zieht das eine Vielzahl von Tätigkeiten und Programmieraufwänden in den nachgelagerten Systemen nach sich. Durch DWH-Automation-Werkzeuge wie z. B. Qlik Replicate oder Compose lassen sich Data Marts aber automatisiert erstellen und Daten im Change-Data-Capture-Verfahren live in die Cloud übertragen.

Der manuelle Aufwand bei der Erstellung und Betreuung der ETL-Strecken wird hierbei drastisch reduziert und somit einer der Hauptkritikpunkte von DWH-Lösungen eliminiert. Die Kombination aus verschiedenen Lösungen (Storage, DWH-System, Automatisierung, BI) führt aber natürlich zu erhöhten Lizenzkosten.

Kann Qlik Sense ein DWH ersetzen?

Ja, wenn strukturierte Daten z. B. aus ERP-Systemen ausschließlich zu Reporting-Zwecken und Dashboarding (vielleicht sogar zwingend On-Premises) aufbereitet werden sollen, ist für Qlik Sense kein DWH erforderlich. Es ist hier zwar mit einem starken Vendor-Lock-in zu rechnen, positiv sind jedoch insbesondere die Entwicklungsschnelligkeit und die Einsparungen gegenüber den DWH-Kosten hervorzuheben.

Kann eine Query-Engine in Kombination mit einem Cloud-Storage ein DWH ersetzen?

Ja, allerdings verschiebt sich dann der Aufwand der ETL-Strecken während der Datenabfrage bei einem DWH-Betrieb auf die entsprechende ELT-Query-Engine, in den Bau von Materialized Views und Reflections oder in nachfolgende Analysetools. In Kombination mit einem BI-Tool können einige Nachteile gegenüber dem reinen Qlik-Betrieb abgefangen werden, nämlich der Vendor-Lock-in oder die Skalierbarkeit.

Insbesondere bei unstrukturierten Daten, wie bei JSON-Files von IoT-Geräten, hat die ELT-Methodik durch „Schema on Read“ deutliche Vorteile gegenüber einem DWH mit ETL samt „Schema on Write“. In diesen Fällen ist die Kombination aus performanten Cloud Data Lake Storage und schneller Query-Engine sehr zu empfehlen. Die Daten müssen allerdings ggf. mit einem entsprechenden Tool (z. B. Qlik Replicate o. ä.) in den Cloud-Data-Lake übertragen werden.

Fazit

Generell empfehlenswert ist der Betrieb eines modernen Cloud Data Warehouse (z. B. Snowflake oder Azure Synapse) in Kombination mit Data-Warehouse-Automation (z. B. mit Qlik Replicate & Compose). So können alle Vorteile der Cloud (Skalierbarkeit bei Compute und Storage, Hochverfügbarkeit, Pay-per-Use) mit den Vorteilen eines DWH (SQL, Sicherheitskonzepte, wohldefiniertes Schema) kombiniert werden. Die üblicherweise sehr aufwendige Programmierung und spätere Pflege der ETL-Strecken lassen sich zu einem Großteil durch entsprechende Tools automatisieren. Selbst unstrukturierte Daten können in beliebiger Größe in entsprechenden Data-Lake-Storages gespeichert und trotzdem im DWH über SQL abgefragt werden.

Dieses Setup garantiert die Verfügbarkeit der Daten auch für zukünftige Fragestellungen, die im Moment noch überhaupt nicht im Fokus sind. Das System kann mit den Anforderungen mitwachsen. Die Nachteile eines größeren Tool-Stacks, den damit verbundenen Kosten, und der Notwendigkeit für ein breiteres Skill-Set der Mitarbeiter, werden durch die Vorteile und die Zukunftssicherheit übertroffen.

(ID:46738972)