Ein Data Warehouse dient Unternehmen oft als Datenquelle für Business-Intelligence- und Machine-Learning-Systeme. Das müssen Sie zum Thema wissen. [...]
Datenbanken werden klassischerweise als relational (SQL), NoSQL, transaktional (OLTP), analytisch (OLAP) oder hybrid (HTAP) klassifiziert. Spezielle Datenbanken – etwa für einzelne Abteilungen – wurden anfangs als Verbesserung betrachtet, später als „Inseln“ verspottet.
Der Versuch, eine einheitliche Datenbank für alle Daten in einem Unternehmen zu schaffen, wird als Data Lake bezeichnet, wenn die Daten in ihrem ursprünglichen Format belassen werden. Wenn die Daten in ein gemeinsames Format und Schema überführt werden, spricht man von einem Data Warehouse. Die Teilmengen eines Data Warehouse werden als Data Marts bezeichnet.
Data Warehouse – Definition
Bei einem Data Warehouse handelt es sich im Wesentlichen um eine analytische (in der Regel eine relationale) Datenbank, die aus zwei oder mehr Datenquellen erstellt wird. In der Regel dienen Data Warehouses zur Speicherung historischer Daten, die in Petabyte-Größen auftreten können. Data Warehouses verfügen oft über erhebliche Rechen- und Speicherressourcen, um komplizierte Abfragen durchzuführen und Berichte zu erstellen. Sie kommen häufig als Datenquellen für Business-Intelligence– und Machine-Learning-Systeme zum Einsatz.
Ein wichtiger Grund für den Einsatz eines Data Warehouse: Operative (OLTP-)Datenbanken sind hinsichtlich der Anzahl und Art der Indizes, die Sie erstellen können, eingeschränkt, die Analysefähigkeiten verlangsamt. Sobald Sie Ihre Daten in das Data Warehouse kopiert haben, können Sie alles, was Ihnen wichtig ist, im Data Warehouse indizieren, um eine gute analytische Abfrageleistung zu erzielen – ohne dabei die Schreibleistung der OLTP-Datenbank zu beeinträchtigen.
Ein weiterer Grund für ein unternehmensweites Data Warehouse ist die Möglichkeit, Daten aus verschiedenen Quellen für die Analyse zusammenzuführen. Ihre OLTP-Anwendung für den Vertrieb braucht beispielsweise wahrscheinlich keine Informationen über das Wetter an Ihren Verkaufsstandorten, aber Ihre Umsatzprognosen könnten diese Daten nutzen. Wenn Sie Ihrem Data Warehouse historische Wetterdaten hinzufügen, wäre es ein Leichtes, diese in Ihre Modelle für historische Verkaufsdaten einzubeziehen.
Data Warehouse vs. Data Lake
Data Lakes, die Dateien in ihrem nativen Format speichern, sind im Wesentlichen „schema on read“. Das bedeutet, dass jede Anwendung, die Daten aus dem Lake liest, ihre eigenen Typen und Beziehungen auf diese anwenden muss. Data Warehouses hingegen sind „schema on write“ – Datentypen, Indizes und Beziehungen werden den Daten bei der Speicherung auferlegt.
„Schema on read“ ist gut für Daten, die in verschiedenen Kontexten verwendet werden können, und birgt dabei ein geringes Risiko für Datenverlust. Gleichwohl besteht die Gefahr, dass die Daten überhaupt nicht verwendet werden. Qubole, ein Anbieter von Cloud-Data-Warehouse-Tools für Data Lakes, schätzt, dass 90 Prozent der Daten in den meisten Data Lakes inaktiv sind. „Schema on write“ ist gut für Daten, die einen bestimmten Zweck erfüllen und solche, die ordnungsgemäß mit Daten aus anderen Quellen verknüpft werden müssen. Die Gefahr: Falsch formatierte Daten können beim Import verworfen werden, wenn sie nicht richtig in den gewünschten Datentyp konvertiert werden.
Data Warehouse vs. Data Mart
Data Warehouses enthalten Daten aus dem gesamten Unternehmen, während Data Marts sich auf die konzentrieren, die sich auf einen bestimmten Geschäftszweig beziehen. Data Marts können vom Data Warehouse unabhängig oder abhängig (das heißt aus einer operativen Datenbank oder einer externen Quelle stammen) oder eine Mischung aus beidem sein.
Data Marts werden unter anderem wegen ihres geringeren Platzbedarfs, der schnelleren Rückgabe von Abfrageergebnissen und der (im Vergleich zu einem vollständigen Data Warehouse) geringeren Betriebskosten eingesetzt. Häufig enthält ein Data Mart zusammengefasste und ausgewählte Daten anstelle von oder zusätzlich zu den detaillierten Daten im Data Warehouse.
Data Warehouse – Architektur & Design
Im Allgemeinen weist ein Data Warehouse eine mehrschichtige Architektur auf:
- Quelldaten,
- eine Staging-Datenbank,
- ETL- (Extrahieren, Transformieren und Laden) oder ELT- (Extrahieren, Laden und Transformieren) Tools,
- die eigentliche Datenspeicherung und
- Datenpräsentations-Tools.
Jede Schicht dient einem anderen Zweck:
Zu den Quelldaten gehören häufig operative Datenbanken aus Vertrieb, Marketing und anderen Unternehmensbereichen. Sie können auch soziale Medien und externe Daten wie Umfragen und demografische Daten umfassen.
Auf der Staging-Ebene werden die aus den Datenquellen abgerufenen Daten gespeichert. Wenn eine Quelle unstrukturiert ist, etwa Texte aus sozialen Medien, wird hier ein Schema festgelegt. Zudem finden auf dieser Ebene auch Qualitätsprüfungen statt, um qualitativ schlechte Daten zu entfernen und gängige Fehler zu korrigieren.
ETL-Tools ziehen die Daten, führen alle gewünschten Zuordnungen und Umwandlungen durch und laden die Daten in die Datenspeicherungsschicht. ELT-Tools speichern die Daten zuerst und transformieren sie später. Wenn Sie ELT-Tools einsetzen, können Sie auch einen Data Lake verwenden und die traditionelle Staging-Schicht überspringen.
Die Datenspeicherungsschicht eines Data Warehouse enthält bereinigte, transformierte Daten, die für die Analyse bereitstehen. Dabei handelt es sich häufig um einen zeilenorientierten relationalen Speicher, der aber auch spaltenorientiert sein kann oder über invertierte Listenindizes für die Volltextsuche verfügt. Data Warehouses haben oft viel mehr Indizes als operative Datenspeicher, um analytische Abfragen zu beschleunigen.
Die Datenpräsentation aus einem Data Warehouse erfolgt häufig durch die Ausführung von SQL-Abfragen, die mit Hilfe eines GUI-Tools erstellt werden können. Die Ausgabe der SQL-Abfragen wird verwendet, um Anzeigetabellen, Diagramme, Dashboards, Berichte und Prognosen zu erstellen, häufig mit Hilfe von Business Intelligence Tools.
Seit kurzem unterstützen einige Data-Warehouse-Lösungen auch Machine Learning, um die Qualität von Modellen und Prognosen zu verbessern. Google BigQuery wurde beispielsweise um SQL-Anweisungen erweitert, um lineare Regressionsmodelle für Prognosen und binäre logistische Regressionsmodelle für die Klassifizierung zu unterstützen. Einige Data Warehouses wurden sogar in Deep-Learning-Bibliotheken und Tools für automatisiertes maschinelles Lernen (AutoML) integriert.
Es gibt zwei wesentliche Strömungen, wenn es darum geht, wie ein Data Warehouse zu gestalten ist. Der Unterschied zwischen den beiden liegt in der Ausrichtung des Datenflusses zwischen Data Warehouse und Data Marts:
- Beim Top-down-Design (auch bekannt als Inman-Ansatz) wird das Data Warehouse als zentraler Datenspeicher für das gesamte Unternehmen betrachtet. Data Marts werden aus dem Data Warehouse abgeleitet.
- Beim Bottom-up-Design (bekannt als Kimball-Ansatz) werden die Data Marts als primär betrachtet und in das Data Warehouse integriert. Nach Kimballs Definition ist das Data Warehouse „eine Kopie der Transaktionsdaten, die speziell für Abfragen und Analysen strukturiert ist“.
In den Bereichen Versicherung und industrielle Fertigung sind Data-Warehouse-Lösungen eher nach der Top-Down-Methode von Inman ausgerichtet. Das Marketing beispielsweise bevorzugt eher den Kimball-Ansatz.
Data Warehouse – Cloud oder On-Prem?
Ein Data Warehouse kann vor Ort, in der Cloud oder als Mischform implementiert werden. In der Vergangenheit wurden Data Warehouses immer vor Ort implementiert. Die Kosten und die mangelnde Skalierbarkeit von On-Premises-Servern in Rechenzentren waren dabei des Öfteren ein Problem. Als die Anbieter erste Data Warehouse Appliances auf den Markt brachten, stieg die Zahl der Implementierungen. Heute geht der Trend jedoch dahin, entweder das gesamte Data Warehouse oder Teile davon in die Cloud zu verlagern. Dabei spielen vor allem die Skalierbarkeit und die Möglichkeit zur Anbindung an andere Cloud Services eine Rolle.
Die Kehrseite der massenhaften Verlagerung von Daten in die Cloud: die Betriebskosten, sowohl für die Datenspeicherung als auch für die Rechen- und Speicherressourcen des Cloud-basierten Data Warehouse. Der Zeitaufwand für den Upload der Daten in die Cloud ist hingegen zu vernachlässigen, seit die Hyperscaler Datentransferdienste mit hoher Kapazität anbieten.
Data Warehouse, Data Mart oder Data Lake?
Letztendlich hängt jede Entscheidung bezüglich eines Data Warehouse von Ihren Zielen, Ressourcen und Budget ab. Im ersten Schritt sollten Sie sich die Frage stellen, ob Sie überhaupt ein Data Warehouse benötigen. Ist das der Fall, müssen Sie im nächsten Schritt Ihre Datenquellen, deren Größe und aktuelle Wachstumsrate ermitteln und analysieren, wie Sie diese derzeit nutzen. Danach können Sie damit beginnen, mit Data Lakes, Data Marts und Data Warehouses zu experimentieren, um herauszufinden, was für Ihr Unternehmen am besten geeignet ist.
Empfehlenswert ist, einen Proof of Concept mit einer kleinen Teilmenge von Daten aufzusetzen – entweder On-Premises oder innerhalb einer kleinen Cloud-Instanz. Sobald Ihr Entwurf validiert und die Vorteile für das Unternehmen nachgewiesen sind, können Sie auf eine vollständige Data-Warehouse-Installation mit vollem Management-Support aufstocken. (fm)
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.
*Martin Heller schreibt als freier Autor für die Schwesterpublikation InfoWorld.
Be the first to comment