Was ist ein Data Warehouse?

Was ist ein Data Warehouse?

Das Konzept des Data Warehouses ist bereits recht alt und stammt aus den späten 1980er Jahren^[1]. Dennoch stellen wir in der Praxis fest, dass der Begriff „Data Warehouse“ oft missverstanden wird. Die Existenz eines ähnlichen Begriffs, eines Data Lakes, macht die Sache nicht einfacher, da die beiden Konzepte häufig verwechselt oder vermischt werden.

Die Definition

Es gibt zwei kanonische Definitionen eines Data Warehouses:

„A data warehouse is a copy of transaction data specifically structured for query and analysis.“

„Ein Data Warehouse ist eine Kopie von Transaktionsdaten, die speziell für Abfragen und Analysen strukturiert ist.“

Ralph Kimball

„A data warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of management’s decision making process.“

„Ein Data Warehouse ist eine themenorientierte, integrierte, zeitvariabel und nicht flüchtige Sammlung von Daten zur Unterstützung des Management-Entscheidungsprozesses.“

Bill Inmon

Beide Definitionen sind sehr prägnant und eher auf einer hohen Ebene gehalten. Sie beschreiben, welche Eigenschaften ein Data Warehouse haben muss oder welche Bedingungen ein Datenspeicher erfüllen sollte, um als Data Warehouse zu gelten. Tatsächlich beschreiben sie nicht direkt, wie ein Data Warehouse aussieht oder wie man eines erstellt. Aber wenn man sie sorgfältig liest, weiß man genau, was ein Data Warehouse ist und was nicht.

Was ist kein Data Warehouse?

Wenn wir die obigen Definitionen erneut betrachten, sehen wir, dass beide ein Data Warehouse als eine Art Datensammlung definieren („Kopie von Transaktionsdaten“, „Sammlung von Daten“). Es ist also sicherlich kein Prozess zur Sammlung, Transformation oder Analyse von Daten. Es ist kein Tool für die Datenintegration. Ebenso wenig ist es ein Reporting-Tool. Es handelt sich um einen Datenspeicher, und dies ist die entscheidende Eigenschaft.

Aber nicht jeder Datenspeicher ist ein Data Warehouse. Diese Daten müssen einem spezifischen Zweck dienen. Kimball sagt, sie dienen „Abfragen und Analysen“, Inmon beschreibt es als „Unterstützung des Management-Entscheidungsprozesses“. Eine Datensammlung, die für diese Zwecke nicht geeignet ist, kann offensichtlich nicht als Data Warehouse bezeichnet werden. Ein Ordner mit gescannten Rechnungen der letzten fünf Jahre, obwohl er sicherlich wertvolle Informationen enthält, ist für Analysen völlig ungeeignet. Ein S3-Bucket mit einer Sammlung von Logs oder JSON-strukturierten Website-Event-Details ist kaum für einen solchen Zweck nutzbar. Keiner dieser Datenspeicher kann als Data Warehouse angesehen werden.

Selbst eine Transaktionsdatenbank, die alle Transaktionsinformationen in der sauber gestalteten 3. Normalform enthält, erfüllt unsere Bedingungen nicht. Sie ist dazu gedacht, ein System oder eine Anwendung zu betreiben und (Geschäfts-)Transaktionsdaten zu speichern. Sie ist speziell dafür strukturiert, Transaktionen zu erfassen, jedoch nicht für Abfragen und Analysen. Technisch gesehen kann man zwar Abfragen auf einer Transaktionsdatenbank ausführen, aber sie ist nicht für den Zweck von analytischen Abfragen ausgelegt. Außerdem enthält sie die Transaktionsdaten und nicht, wie von Kimball definiert, eine Kopie der Transaktionsdaten. Auch Inmons Bedingungen der Nicht-Flüchtigkeit und Integration der Daten werden nicht erfüllt.

Ins Detail gehen

Themenorientiert

Eine wichtige Eigenschaft eines Data Warehouses ist, dass es „themenorientiert“ ist. Die Daten sollten um die Themen organisiert werden, die sie beschreiben oder auf die sie sich beziehen, anstatt nach den Systemen, aus denen sie stammen. Kimball et al. schreiben in ihrem Klassiker Data Warehouse Toolkit Classics, dass der Schlüsselpunkt darin liegt, die Geschäftsprozesse zu identifizieren und zu beschreiben. Diese Prozesse, nicht die Organisationsstruktur des Unternehmens oder die Architektur der verwendeten Computersysteme, bestimmen, wie die Daten strukturiert werden sollten.

Zum Beispiel besteht der typische Verkaufsprozess aus mehreren Schritten: Auftragserstellung, Bezahlung, Versand usw. Jeder dieser Schritte kann von einer separaten Organisationseinheit oder sogar von einem externen Anbieter ausgeführt werden. Jeder von ihnen würde verschiedene Datenbanken oder Informationssysteme verwenden, um die Arbeit zu erledigen. Die Rolle des Data Warehouses besteht darin, den gesamten Prozess zu beschreiben, nicht die einzelnen Komponenten. Die Organisation der Daten dreht sich um den Prozess, nicht um Abteilungen oder die Herkunft der Daten.

Integriert

Die Tatsache, dass die Daten aus verschiedenen Quellen stammen, führt uns zur nächsten Eigenschaft: integriert. Dies bedeutet nicht nur die Vielzahl von Quellen. Viel wichtiger ist, dass die Daten aus verschiedenen Systemen abgestimmt und vereinheitlicht werden müssen. Dazu gehört die Einführung eines einheitlichen Messsystems, einheitlicher Datenformate und einer konsistenten Namenskonvention. Konflikte zwischen den Daten aus unterschiedlichen Quellen sollten gelöst werden.

Nicht-flüchtig

Das Attribut „nicht-flüchtig“ impliziert eine dauerhafte Speicherung der Daten. Somit kann kein System, das Daten „on the fly“ sammelt, transformiert oder generiert, gemäß der Definition als Data Warehouse betrachtet werden. Darüber hinaus bedeutet Nicht-Flüchtigkeit, dass Daten im Allgemeinen nur hinzugefügt, aber nicht entfernt werden sollten. Das ist logisch – die Daten spiegeln bestimmte Geschäftsprozesse zu einem bestimmten Zeitpunkt wider. Selbst wenn sich der Zustand eines Prozesses in der Zukunft ändert, enthalten die bisher gesammelten Daten die Fakten über vergangene Zustände. Wenn wir diese Daten für die Analyse der Prozesshistorie oder deren zeitliche Veränderungen nutzen wollen, sollten solche Informationen nicht gelöscht oder verändert werden.

Das Verbot, Informationen zu verändern, ist jedoch nicht absolut und, entgegen der weit verbreiteten Meinung, nicht gleichbedeutend mit dem Verbot, die zugrunde liegenden Daten zu ändern. Es bedeutet nicht, dass die Daten nur gelesen werden dürfen, abgesehen vom Laden. Es bedeutet auch nicht, dass alte Daten nicht durch neue überschrieben werden können. Es bedeutet sicherlich nicht, dass die Ausführung eines ALTER-Statements verboten ist. Dennoch sollten solche Operationen historische Informationen nicht zerstören oder müssen gut begründet sein. Klassische Beispiele für legitime Änderungen der Daten sind das Handling von Type 1 und Type 2 Slowly Changing Dimensions.

Zeitvariabel

Ein Snapshot der Transaktionsdaten, der ordnungsgemäß integriert und strukturiert ist, erfüllt alle oben besprochenen Bedingungen. Auf den ersten Blick passt er vollständig zur Definition von Kimball. Doch wie nützlich wäre ein solcher Snapshot tatsächlich für Analysen oder Entscheidungsprozesse? Die Analyse wäre auf den spezifischen Zeitpunkt des Snapshots und (vielleicht) dessen Historie begrenzt. Mit der Zeit würde der Nutzen eines solchen Snapshots schnell abnehmen. Es ist offensichtlich, dass jeder für die Entscheidungsfindung die aktuellsten Informationen haben möchte. Damit ein Data Warehouse seinen Zweck erfüllt, muss dessen Inhalt regelmäßig und häufig aktualisiert werden.

Sicherlich können zwei unterschiedliche Informationssätze zu unterschiedlichen Antworten führen, wenn dieselbe Frage gestellt wird. Wenn sich die Daten im Data Warehouse im Laufe der Zeit ändern, hängen die Ergebnisse der Abfragen im Allgemeinen vom Zeitpunkt der Ausführung ab. Technisch gesehen ist ein Data Warehouse ein zeitvariant System. In der Praxis bedeutet dies, dass es kein reiner Speicher für vergangene Daten ist, sondern dass es „lebt“ und sich verändert.

Das zeitvariabel Attribut aus Inmons Definition wird oft fälschlicherweise als „bezogen auf historische Daten“ oder „fokussiert auf zeitliche Veränderungen“ interpretiert^[2]. Natürlich speichert ein Data Warehouse historische Daten und tut dies über einen wesentlich längeren Zeitraum als Transaktionssysteme. Die Analyse von zeitlichen Veränderungen spielt eine wichtige Rolle in Entscheidungsprozessen. Es ist oft die Art und Weise, wie die gesammelten Daten genutzt werden. Aber zeitabhängig bedeutet tatsächlich, dass die Ergebnisse im Laufe der Zeit variieren. Das liegt daran, dass die Daten im Data Warehouse nicht statisch sind – sie werden hinzugefügt und aktualisiert.

Ist ein Data Warehouse eine Datenbank?

Keine der Definitionen erwähnt explizit eine Datenbank. Kimball sagt lediglich, dass die Daten „speziell strukturiert“ sein müssen. Bis vor Kurzem war es ziemlich offensichtlich, dass Daten, die für Analysezwecke oder Entscheidungsunterstützung gespeichert werden, in einer Datenbank abgelegt sein müssen. Tatsächlich beschrieben sowohl Kimball als auch Inmon in ihren Methoden die Implementierung eines Data Warehouses in einer relationalen Datenbank.

Ihre ursprünglichen Arbeiten zu diesem Thema stammen jedoch aus den 1990er Jahren, mit einigen Aktualisierungen in den 2000er Jahren. Das war vor der Zeit von Hadoop, und es gab praktisch keine anderen Speicheroptionen, die „für Abfragen und Analysen“ geeignet waren. Heute wäre es möglich, die Aufgabe auch ohne Datenbank zu erfüllen, indem alternative Speicheroptionen und Abfrage-Engines verwendet werden. Dennoch sind Implementierungen eines Data Warehouses mit einer relationalen Datenbank (wie Oracle oder PostgreSQL) oder einer Massive Parallel Processing (MPP) Datenbank (wie Amazon Redshift, Netezza, Vertica oder Greenplum) nach wie vor die häufigsten.

Heute, mit der Entwicklung von Hadoop, der Cloud und verwandten Tools gibt es mehr Möglichkeiten. Es wurden viele Data Warehouse-Implementierungen mit Daten realisiert, die als Dateien auf HDFS gespeichert sind. Hive oder Impala können dann als Abfrage-Engine verwendet werden, um eine SQL-ähnliche Erfahrung zu bieten. Ähnliche Tools existieren in der Public Cloud – Amazon Redshift Spectrum oder Athena sind nur zwei Beispiele.

Unabhängig vom verwendeten Speichersystem und der Abfrage-Engine ändern sich die Grundsätze nicht: Die Daten müssen speziell für Abfragen und Analysen strukturiert sein. Ein unorganisiertes Ablegen auf HDFS oder S3 führt zwangsläufig zu Problemen und ist kein Data Warehouse.

Nicht alle Datenbanken sind gleich

Obwohl es offensichtlich sein sollte, ist es wert, zu wiederholen, dass nicht jede Datenbank ein Data Warehouse ist oder als solches behandelt werden kann, selbst wenn sie viele historische Daten zu verschiedenen Themen enthält. Es muss eine Unterscheidung zwischen On-Line Transaction Processing (OLTP) und On-Line Analytical Processing (OLAP) Systemen getroffen werden. Erstere sind dafür ausgelegt, eine vordefinierte Reihe von Operationen schnell auszuführen, die jeweils auf einem einzelnen Datensatz oder höchstens auf wenigen Datensätzen basieren. Typische Operationen sind das Schreiben einzelner Datensätze oder das Aktualisieren vorhandener. OLTP-Systeme können eine sehr große Anzahl solcher Operationen ausführen, aber jede einzelne Operation ist relativ einfach.

Im Gegensatz dazu sind OLAP-Systeme, zu denen auch ein Data Warehouse gehört, für die Analyse großer Mengen historischer Daten ausgelegt. Die Abfragen sind relativ selten, aber oft operieren sie auf Millionen von Datensätzen. Es handelt sich fast ausschließlich um Leseabfragen, und daher sollte ein Data Warehouse für den Lesezugriff optimiert sein. Die Prozesse zum Laden der Daten schreiben typischerweise ganze Datenmengen (Batches) anstatt einzelner Datensätze.

Die Liste der Unterschiede ist nicht vollständig, aber es sollte bereits klar sein, dass diese beiden Arten von Datenbanken völlig unterschiedlich entworfen werden müssen. Kein Wunder, dass es Relationale Datenbankmanagementsysteme (RDBMS) gibt, die für OLTP- oder „Allzweck“-Anwendungen entwickelt wurden, und solche, die speziell für Data Warehousing konzipiert sind. Das Vermischen der beiden Zwecke oder das Ausführen von Analyseabfragen direkt auf der OLTP-Datenbank (sogar auf der „Read-Only“-Replik) kann insbesondere im großen Maßstab zu schlechten Ergebnissen führen.

Aber wie baut man es?

Bisher haben wir nur darüber gesprochen, was ein Data Warehouse ist oder was es nicht ist. Abgesehen von einigen Hinweisen haben wir kein klares Rezept dafür gegeben, wie ein solches System aufgebaut werden sollte. Selbst ein sehr kurzer Leitfaden müsste viele Seiten lang sein und würde nur die Grundlagen und die gängigsten Konzepte abdecken. Darüber hinaus gibt es drei verschiedene Methoden, um die Aufgabe anzugehen, sowie spezifische system- und werkzeugabhängige Varianten davon.

Interessierte sollten sich an die klassischen Materialien wenden:

• Data Warehouse Toolkit Classics by R. Kimball et. al
• Building the Data Warehouse by W.H. Inmon
• Data Vault Series by D. Linstedt

Natürlich können Sie sich auch an uns wenden , und wir beraten und unterstützen Sie gerne.