Data Warehouse: Was es leistet und wo die Grenze als alleinige Plattform liegt
Ein Data Warehouse liefert verlässliches Reporting auf strukturierten Daten. Wo die Grenze als alleinige Plattform liegt, wenn Data Science, Streaming und KI dazukommen.
Die Kernaussagen auf einen Blick.
- Ein Data Warehouse ist eine zentrale, modellierte Datenbasis, die strukturierte Daten aus mehreren Quellsystemen für Reporting und Business Intelligence zusammenführt.
- Sein wesentlicher Wert liegt in einer klaren Modellierungs- und Integrationslogik: dimensionale Modellierung, ein vorab festgelegtes Schema und eine konsistente Datenbasis für verbindliches Reporting.
- Vor der Plattformentscheidung ist eine Frage zu klären: Bleibt es bei strukturierter SQL-Analyse, oder greifen später auch Data Science, Streaming und KI auf dieselben Daten zu?
- Empfehlenswert ist, die bewährten Modellierungsprinzipien des Data Warehouse beizubehalten und sie als Serving-Schicht auf einer offenen Plattform einzuplanen, bevor die gesamte Datenplattform an ein geschlossenes System gebunden wird.
Inhaltsverzeichnis
Das Warehouse unterstützt das Reporting, stößt bei weiteren Workloads jedoch an Grenzen
Ein Unternehmen betreibt seit Jahren ein verlässliches Data Warehouse. Die Quartalszahlen stimmen, die Berichte laufen pünktlich, das Datenmodell ist über mehrere Releases gewachsen. Später kommt ein produktives Machine-Learning-Projekt hinzu. Für das Modelltraining benötigt das Team Roh- und Verhaltensdaten, die im Warehouse entweder nicht vorhanden oder bereits stark aggregiert sind. Die Daten werden deshalb in eine zweite Umgebung übertragen, die separat betrieben und gepflegt werden muss.
In wachsenden Datenplattformen tritt diese Situation häufig auf. Das Warehouse erfüllt seine ursprüngliche Aufgabe weiterhin zuverlässig. Probleme entstehen, wenn das Warehouse zusätzlich als zentrale Grundlage für Workloads eingesetzt wird, für die es ursprünglich nicht konzipiert wurde.
Ist das Warehouse grundsätzlich veraltet, oder wird es lediglich für Anforderungen eingesetzt, die über seinen ursprünglichen Zweck hinausgehen? Brauchen wir ein zweites System für Data Science, oder ist der Zuschnitt der Plattform falsch? Wie lässt sich die Verlässlichkeit der Kennzahlen erhalten, wenn die Plattform offener und flexibler wird? Ab wann reicht ein reines Warehouse nicht mehr aus, weil weitere Workloads hinzukommen?
Ein Data Warehouse bleibt für strukturierte Analyse und Reporting relevant. Nicht die Modellierungsprinzipien sind überholt, sondern der Anspruch, ein geschlossenes Warehouse als alleinige Datenplattform einzusetzen.
Was ist ein Data Warehouse?
Ein Data Warehouse ist eine zentrale Datenbasis, die strukturierte Daten aus verschiedenen Quellsystemen integriert und für analytische Auswertungen vorhält. Es ist auf Reporting, Business Intelligence und historische Auswertungen ausgelegt, im Unterschied zur operativen Datenbank, die das Tagesgeschäft mit einzelnen Transaktionen bedient. Die Abkürzung DWH (Data Warehouse) bezeichnet eine solche analytische Datenplattform. Data Warehousing bezeichnet den Prozess, Daten zu integrieren, aufzubereiten und historisiert bereitzustellen.
Die klassische Definition geht auf Bill Inmon zurück: Ein Data Warehouse ist themenorientiert, integriert, zeitvariant und nicht-flüchtig. Themenorientiert bedeutet, die Daten sind nach Geschäftsthemen wie Umsatz, Kunde oder Produkt organisiert und folgen nicht der Struktur der einzelnen Quellsysteme. Integriert bedeutet, dass Daten aus CRM, ERP und weiteren Systemen in ein gemeinsames Modell überführt werden. Zeitvariant bedeutet, dass historische Entwicklungen nachvollziehbar bleiben: Das Warehouse hält den Verlauf über Jahre und damit mehr als den aktuellen Stand. Nicht flüchtig bedeutet, dass Daten geladen und gelesen, aber im Betrieb nicht laufend überschrieben werden.
Ein zentrales Prinzip ist Schema-on-Write: Die Struktur der Daten wird festgelegt, bevor sie geladen werden. Beim Laden müssen die Daten einem zuvor definierten Modell entsprechen. Dadurch sind Struktur und Qualität der Daten bereits vor der Auswertung festgelegt. Neue Quellen und Strukturänderungen erfordern jedoch in der Regel eine vorherige Anpassung des Datenmodells. Wie sich dieser Ansatz von einem offenen Datenspeicher unterscheidet, ordnen wir im Lakehouse-Hub ein.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Wie ist ein Data Warehouse aufgebaut?
Die Architektur eines Data Warehouse folgt in der Regel drei Schichten. In der Quell- und Staging-Schicht landen die Rohdaten aus den operativen Systemen, oft zunächst unverändert, bevor sie bereinigt werden. Der analytische Kern enthält die integrierten und modellierten Daten als verbindliche Grundlage für Auswertungen. Die BI- und Serving-Schicht stellt diese Daten für Berichte, Dashboards und Ad-hoc-Analysen bereit, häufig über fachbereichsbezogene Data Marts.
Ein Data Mart ist ein themenbezogener Ausschnitt des Warehouse für einen Fachbereich, etwa Vertrieb oder Finance. Er stellt die für den jeweiligen Fachbereich relevanten Tabellen und Kennzahlen bereit. In einer Lakehouse-Architektur lässt sich ein Data Mart mit einer fachlich ausgerichteten Gold-Schicht vergleichen: kuratierte, geschäftsfertige Daten für eine klar umrissene Nutzergruppe.
Die Architektur trennt operative und analytische Verarbeitung voneinander. Operative Datenbanken sind für OLTP (Online Transaction Processing) ausgelegt: viele kleine Schreib- und Lesevorgänge im Tagesgeschäft, etwa eine Bestellung oder eine Buchung. Ein Data Warehouse ist für OLAP (Online Analytical Processing) gebaut: wenige, große Abfragen, die über Millionen Zeilen aggregieren. Dadurch beeinträchtigen umfangreiche Analysen nicht die operativen Systeme.
Modellierung, ETL und eine konsistente Wahrheitsschicht
Der Wert eines Data Warehouse liegt vor allem in verbindlichen Modellierungs- und Integrationsregeln, weniger in der reinen Technik. Drei Elemente sind dafür besonders wichtig.
Dimensionale Modellierung
Kimballs Ansatz organisiert Daten in Fakten- und Dimensionstabellen. Das Star Schema aus Faktentabelle und Kontext-Dimensionen wie Zeit, Produkt oder Kunde macht Abfragen performant und für Fachbereiche verständlich.
ETL als Integrationsschicht
ETL- oder ELT-Prozesse bereinigen, vereinheitlichen und historisieren Daten aus den Quellsystemen. Der Integrationsschritt kostet Aufwand, schafft aber die Grundlage für konsistente Auswertungen.
Eine konsistente Wahrheitsschicht
Vertrieb, Controlling und Geschäftsführung sehen dieselbe Kennzahl. Diese Konsistenz entsteht durch Modellierung und Governance, nicht allein durch die eingesetzte Technologie.
Diese verbindlichen Regeln machen das Warehouse besonders wertvoll. Sie gehen verloren, wenn Daten ohne klare Struktur und Verantwortlichkeit gespeichert werden. Zusätzliche Rechenleistung kann fehlende Modellierung und Governance nicht ausgleichen.
Ist ein Data Warehouse noch zeitgemäß?
Der Begriff Data Warehouse verliert gegenüber neueren Plattformbegriffen an Aufmerksamkeit. In den Suchanfragen wächst das Lakehouse-Vokabular, während die klassischen Warehouse-Begriffe zurückgehen. Daraus lässt sich jedoch nicht ableiten, dass das Data Warehouse an Bedeutung verloren hat. Die Bezeichnung verändert sich, der Bedarf an verlässlicher Modellierung und strukturiertem Reporting bleibt bestehen.
Für klar strukturierte Analyse-Anforderungen ist ein Warehouse oft die einfachste und verlässlichste Wahl. Die Vorteile zeigen sich besonders bei stabilen, strukturierten Analyseanforderungen: Abfragen über große, modellierte Datenmengen laufen schnell, weil Struktur und Indizierung vorab feststehen. Berechtigungen und Governance sind innerhalb des Systems reif und erprobt. Die festgelegten Strukturen ermöglichen nachvollziehbare und reproduzierbare Ergebnisse. Für eine Reporting-Landschaft mit stabilen Kennzahlen und wiederkehrenden Auswertungen ist das genau die richtige Grundlage.
Ein typisches Beispiel findet sich im Handel. Ein Unternehmen mit Filialnetz fährt sein Umsatz-, Bestands- und Warenkorb-Reporting auf strukturierten Daten aus Kassensystemen und Warenwirtschaft. Die Datenmodelle sind stabil, die Fragen wiederkehrend, die Workloads bestehen aus SQL-Auswertungen. In diesem Szenario stellt ein Data Warehouse verlässliche Kennzahlen mit überschaubarem Betriebsaufwand bereit. Ein Wechsel der Architektur wäre hier nur sinnvoll, wenn zusätzliche Anforderungen dies tatsächlich erforderlich machen.
Entscheidend ist daher weniger, ob das Warehouse-Modell relevant bleibt, als die Frage, für welche Workloads es eingesetzt wird. Zu prüfen ist, ob dieselbe Plattform zusätzlich Data Science, Streaming und KI unterstützen soll.
Die Grenze als alleinige Plattform
Sobald neben SQL und BI weitere Workloads auf dieselben Daten zugreifen sollen, zeigt sich, wofür ein klassisches Data Warehouse nicht gebaut wurde. Die Einschränkungen liegen weniger im Betrieb als in der grundlegenden Architektur.
Schema-on-Write erschwert Flexibilität
Was beim strukturierten Reporting ein Vorteil ist, wird zur Hürde, sobald halb- und unstrukturierte Daten wie Logfiles, Sensordaten, Texte oder Bilder verarbeitet werden sollen. Für Machine Learning fehlen oft die Rohdaten, die im Warehouse bereits bereinigt oder verdichtet wurden.
SQL-zentrierter Zugriff
Data Science, KI und Streaming nutzen Werkzeuge, die ein klassisches Warehouse nur eingeschränkt unterstützt. Die Daten müssen häufig in eine zweite Umgebung übertragen werden: zusätzliche Kopien, mehr Betriebsaufwand, mögliche Inkonsistenzen.
Format kann an einen Anbieter binden
In vielen Warehouse-Systemen ist das Datenformat eng mit der Engine verbunden. Sobald andere Werkzeuge auf dieselben Daten zugreifen sollen, bedeutet das Export, Konvertierung oder eine parallele Kopie.
Keine Stärke bei Echtzeitverarbeitung
Klassische Warehouses sind auf periodische Ladeprozesse ausgelegt. Kontinuierlich eintreffende Streaming-Daten, die sofort ausgewertet werden sollen, erfordern zusätzliche Komponenten oder eine andere Architektur.
Diese Einschränkungen sprechen nicht grundsätzlich gegen ein Data Warehouse. Sie zeigen jedoch, dass ein Data Warehouse nicht automatisch die gesamte Datenplattform abdecken sollte.
Was unterscheidet ein Data Warehouse von Data Lake und Lakehouse?
Als Alternative zum Data Warehouse wird häufig ein Data Lake betrachtet. Auch ein Data Lake bringt jedoch eigene Einschränkungen mit. Ein Data Lake speichert beliebige Daten, auch unstrukturierte, günstig in offenen Dateiformaten. Er ist flexibel, bringt aber von sich aus wenig Struktur, Transaktionssicherheit und Governance mit. Ohne klare Strukturen und Governance kann die Übersicht über Datenqualität und Verbindlichkeit verloren gehen.
Ein Lakehouse kombiniert Eigenschaften von Data Warehouse und Data Lake: offener Objektspeicher mit Tabellenformaten wie Delta Lake oder Apache Iceberg, die Transaktionen, Governance und strukturierte Abfragen auf offenen Daten ermöglichen. Die Apache-Iceberg-Spezifikation beschreibt ein offenes Tabellenformat, das genau diese Funktionen auf offenem Objektspeicher bereitstellt. Delta Lake dokumentiert dafür ACID-Transaktionen auf offenem Objektspeicher, die das Warehouse-Versprechen auf offene Daten übertragen.
| Achse | Data Warehouse | Data Lake | Lakehouse |
|---|---|---|---|
| Datenstruktur | strukturiert, Schema-on-Write | roh, schemafrei | offen und strukturiert |
| Schema-Zeitpunkt | vor dem Laden | beim Lesen | vor oder beim Lesen |
| Typische Workloads | SQL, BI, Reporting | Rohdaten-Ablage, Data Science | BI, Data Science, Streaming, KI auf einer Kopie |
| Governance | reif, im System eingeschlossen | muss zugebaut werden | zentral über einen Katalog |
| Bindung an den Anbieter | hoch | niedrig | niedrig bis mittel |
Ein wesentlicher Unterschied liegt im verwendeten Daten- und Tabellenformat. In vielen Warehouse-Systemen sind die Daten eng an die jeweilige Abfrage-Engine gebunden, im Lakehouse liegen sie offen und für mehrere Werkzeuge lesbar vor. Dadurch können BI, Data Science und Streaming auf denselben Datenbestand zugreifen. Separate Kopien für die einzelnen Workloads lassen sich so reduzieren. Wie sich Warehouse, Lake und Lakehouse Achse für Achse unterscheiden, führen wir im Vergleich von Warehouse, Lake und Lakehouse aus. Den klassischen Warehouse-Begriff im heutigen Cloud-Kontext ordnet das moderne Data Warehouse ein.
Was das Data Warehouse nicht zeigt
Ein Data Warehouse beantwortet die Frage „Wie betreiben wir strukturierte Analyse verlässlich?“ sehr gut. Die Fragen rund um offene Speicherung, Machine Learning und Streaming beantwortet es nicht selbst. An dieser Stelle werden ergänzende Architekturkonzepte wie Data Lake und Lakehouse relevant. Warehouse und Lakehouse sind dabei nicht zwingend Gegensätze; sie können unterschiedliche Ebenen derselben Architektur abbilden.
Die Modellierungsprinzipien des Data Warehouse bleiben auch in einer Lakehouse-Architektur erhalten. Databricks beschreibt die Medaillon-Architektur mit Bronze-, Silber- und Gold-Schicht als schrittweise Veredelung der Daten. Die strukturierte und modellierte Datenbasis wird in diesem Modell häufig als Gold-Schicht umgesetzt: kuratierte, geschäftsfertige Tabellen, auf denen das Reporting läuft. Sie liegt dabei auf offenem Speicher statt ausschließlich in einem proprietären System.
- Rohdaten und unstrukturierte Quellen offen ablegen, ohne sie sofort in ein festes Modell zu pressen: das führt zum Data Lake mit seinen Stärken und Lücken.
- Wie aus rohen Daten über Bronze, Silber und Gold eine verlässliche Serving-Schicht entsteht, zeigen wir im Überblick zur Medaillon-Architektur.
- Wer das Liefermodell statt der Architektur betrachtet und das Warehouse als verwalteten Cloud-Dienst sucht, findet die Einordnung beim Cloud Data Warehouse.
Das Data Warehouse übernimmt einen klar definierten Teil der Datenarchitektur. Es unterstützt strukturierte Analyse und Reporting zuverlässig. Ob dieselbe Plattform zusätzlich Data Science, Streaming und KI unterstützen soll, muss im Rahmen der übergreifenden Architektur entschieden werden.
Grenzen
Ein Data Warehouse liefert eine verlässliche Grundlage für strukturierte Analysen und eine konsistente Kennzahllogik. Für eine Plattform, die zusätzlich Data Science, Streaming oder KI unterstützen soll, reicht diese Sicht allein nicht aus.
Ausgelegt auf strukturierte Daten
Halb- und unstrukturierte Quellen passen schlecht in das vorab definierte Modell. Neue, flexibel strukturierte Quellen erhöhen den Modellierungsaufwand und können zusätzliche Systeme erforderlich machen.
Kann an Format und Anbieter binden
Die Plattform kann an ein bestimmtes Datenformat und einen Anbieter gebunden sein. Eine parallele Nutzung durch andere Werkzeuge bedeutet Export oder Konvertierung. Das sollte vor der Festlegung geprüft werden.
Modellierung ist Voraussetzung für alles andere
Die Qualität des Datenmodells entscheidet über verlässliche Ergebnisse. Fehlt die Pflege, liefert auch ein modernes Warehouse widersprüchliche Zahlen. Technologie kann diese Arbeit nicht ersetzen.
Ersetzt keine plattformweite Governance
Berechtigungen und Lineage gelten zunächst innerhalb des Systems. Sobald Daten in andere Werkzeuge fließen, braucht es ein übergreifendes Governance-Modell, etwa über einen zentralen Katalog wie Unity Catalog.
Das Warehouse-Modell bleibt sinnvoll, solange das Workload-Profil überwiegend aus strukturierter Analyse besteht. Sobald Data Science, Streaming und KI auf dieselben Daten greifen sollen, sollte die zugrunde liegende Plattformarchitektur neu bewertet werden. Die Warehouse-Prinzipien können dann als strukturierte Serving-Schicht innerhalb einer offenen Plattform umgesetzt werden.
Fazit
Ein Data Warehouse trägt strukturierte BI-Analyse zuverlässig: bei zusätzlichen KI-, Data-Science- oder Streaming-Workloads gehört seine Modellierungslogik als Gold-Schicht in eine offene Architektur.
Ein Data Warehouse ist besonders geeignet, wenn die Plattform überwiegend strukturierte Analyse und Business Intelligence bedienen muss und verlässliche, konsistente Auswertungen im Vordergrund stehen. Besonders gut passt es für Unternehmen mit stabilen Datenmodellen, wiederkehrenden Auswertungen und klaren Kennzahlen, bei denen das Reporting verbindlich sein muss.
Typische Einsatzszenarien sind:
- ein Finanz- oder Vertriebsreporting, dessen Kennzahlen als verbindliche Entscheidungsgrundlage dienen
- strukturierte Quelldaten aus ERP, CRM und Fachsystemen mit stabiler Modelllogik
- ein Team, das eine einzige verbindliche Wahrheitsschicht für viele Berichte braucht
Steht dagegen absehbar Data Science, Streaming oder KI auf derselben Datenbasis an, reicht ein reines Data Warehouse als alleinige Plattform häufig nicht aus. Dann sollte das Datenfundament bewertet werden, bevor ein konkretes Produkt ausgewählt wird. Ein offenes Tabellenformat ermöglicht BI, Machine Learning und Streaming den Zugriff auf einen gemeinsamen Datenbestand und reduziert den Bedarf an zusätzlichen Datenkopien.
Ziel sollte nicht sein, die Warehouse-Prinzipien vollständig zu ersetzen. Ziel ist, die bewährte Modellierungs- und Serving-Logik unabhängig von einem geschlossenen Gesamtsystem weiterzuverwenden.
Prüft, ob euer Workload-Profil über strukturierte SQL-Analyse hinausgeht, bevor ihr die Plattformarchitektur festlegt.
Data & AI Assessment
Ob euer Data Warehouse als Serving-Schicht weiterträgt oder eine offene Plattform die bessere Grundlage ist, lässt sich in einem ersten Data & AI Assessment gut einordnen.
- welche eurer Workloads echte Kandidaten für ein Warehouse sind und welche eine offene Plattform brauchen
- welche Governance-, Format- und Lock-in-Risiken vor der Festlegung geprüft werden müssen
- welcher Architekturpfad die Modellierungs-Disziplin erhält und die Plattform zugleich öffnet
FAQ
Ein Data Warehouse ist eine zentrale Datenbasis, die strukturierte Daten aus mehreren Quellsystemen für Reporting und Business Intelligence zusammenführt. Es ist themenorientiert, integriert, historisiert und auf analytische Auswertungen ausgelegt, im Unterschied zur operativen Datenbank für das Tagesgeschäft. Die deutsche Abkürzung dafür ist DWH.
