Zukunft der Datenarchitektur: Data Lakehouse oder klassisches Data Warehouse?

Eine differenzierte Betrachtung der architektonischen Unterschiede

Mit der wachsenden Datenflut und der zunehmenden Bedeutung datengetriebener Entscheidungen rückt die Wahl der passenden Datenarchitektur in den Fokus moderner Unternehmen. Klassische Data Warehouses (DWH) gelten seit Jahrzehnten als bewährte Lösung für strukturierte Datenanalysen. Unternehmen setzen zeitgemäße Modellierungsansätze wie Data Vault 2.0 und Unified Star Schema ein, um den Anforderungen an Skalierbarkeit und Agilität gerecht zu werden. In den letzten Jahren hat sich jedoch ein neues Architekturparadigma etabliert: das Data Lakehouse.

Es verspricht die Vorteile von Data Lakes (hohe Flexibilität, geringe Kosten) mit den Stärken eines Data Warehouses (strukturierte Analyse, ACID-Compliance) zu kombinieren. 

Doch wie schneidet das Data Lakehouse gegenüber dem klassischen DWH wirklich ab? Nur „alter Wein in neuen Schläuchen“ oder doch kleine Quantensprünge? Das liegt im Auge des Betrachters. Insbesondere im Hinblick auf die Datenbeladung sowie die infrastrukturellen Anforderungen beleuchten wir beide Architekturen tiefergehend. 

Data Warehouse und Data Lakehouse: Die Grundprinzipien

Data Warehouse

Ein Data Warehouse ist eine zentralisierte Datenbank, die optimiert ist für analytische Abfragen auf strukturierten Daten. Die Daten werden oftmals vor der Integration transformiert (ETL: Extract, Transform, Load), wodurch eine hohe Datenqualität und -konsistenz sichergestellt wird. Häufig werden dafür Systeme genutzt, die insbesondere für große Datenmengen und komplexe Aggregationen (ELT: Extract, Load, Transform) innerhalb der Datenbank ausgelegt sind. Die aktuellen Anforderungen an Skalierbarkeit sind durch das Angebot von Cloud-Lösungen mittlerweile gut abgedeckt. 

Data Lakehouse

Ein Data Lakehouse ist ein hybrider Ansatz, der die Datenspeicherung eines Data Lakes mit der Abfrage-Performance und -Struktur eines Data Warehouses verbindet. Es nutzt oft offene Dateiformate (wie Parquet oder Avro), und kombiniert sie mit Transaktionsunterstützung (ACID), um sowohl strukturierte als auch semi-/unstrukturierte Daten effizient analysieren zu können. Außerdem bietet die Verwendung eines offenen Tabellenformats wie Apache Iceberg eine bessere Nutzbarkeit von Metadaten für die Erfüllung von Governance-Bedürfnissen. 

ELT steht für die gesamte Verarbeitung und Aufbereitung der Daten im Vordergrund. Dies birgt insbesondere für die Wertschöpfung durch Generative AI neue Möglichkeiten. 

Unterschiedliche Strategien der Datenbeladung

ETL im Data Warehouse

Die klassische Datenpipeline im Data Warehouse basiert auf dem ETL-Prinzip. Die Daten werden aus Quellsystemen extrahiert, transformiert (d.h. bereinigt, aggregiert, harmonisiert) und anschließend in das Warehouse geladen. Die Transformation erfolgt meist über komplexe ETL-Prozesse, die wartungsintensiv und teuer in der Entwicklung sind. Je nachdem, wie die Daten innerhalb des Warehouses organisiert sind, können weitere Schritte zur Transformation und Aggregation nach dem ELT-Prinzip folgen. 

Häufige Kritikpunkte sind dabei möglicherweise: 

  • Langer Time-to-Insight durch aufwändige Transformationsketten 
  • Schwierigkeiten bei sich ändernden Datenquellen (durch Modellierung nach Data Vault weitgehend gelöst) 
  • Abhängigkeit von zentralen ETL-Jobs für das jeweilige Datenformat 

In Teilen kann diesen Punkten mit generativen Ansätzen, Frameworks und Cloud-DWH-Interfaces flexibel begegnet werden, die Transformation bleibt jedoch ein Aufwandstreiber bei der Datenbeladung. 

ELT im Data Lakehouse

Im Data Lakehouse dominiert hingegen der ELT-Ansatz. Die Rohdaten werden in ihrem ursprünglichen Format direkt in den zugrundliegenden Object Storage bzw. Data Lake geladen (Extract + Load), und erst bei Bedarf transformiert (Transform). Dieser „Schema-on-read„-Ansatz erhöht die Flexibilität für Ad-hoc-Analysen und Data Science. 

Dadurch können sich folgende Vorteile ergeben: 

  • Schnellere Verfügbarkeit von Daten durch teilweise entfallende Beladungsschritte 
  • Flexibilität für verschiedene Nutzergruppen (z.B. Analysten, Data Scientists)
  • Transformationslogik kann iterativ und bedarfsorientiert entwickelt werden 

Zeit- und Kostenaspekte der Infrastruktur

Infrastruktur beim Data Warehouse

Ein Data Warehouse benötigt vor allem im Enterprise-Segment spezialisierte Datenbanktechnologie (z. B. Snowflake, Exasol, Teradata, Cloud-Services). Diese können proprietär, ressourcenintensiv und teuer in der Skalierung werden, insbesondere dann, wenn sie mit den datenstrategischen Bedürfnissen nicht abgestimmt sind. Zudem wird häufig für verschiedene Zwecke (ETL, Reporting, ML) separate Infrastruktur benötigt. 

Kostentreiber können hier höhere Aufwände für Lizenzgebühren und Compute-Ressourcen sowie die Aufteilung auf separate Umgebungen für Entwicklung, Test und Produktion sein. 

Infrastruktur beim Data Lakehouse

Lakehouses basieren meist auf Cloud-nativen Speichersystemen (z. B. S3, Azure Blob Storage), kombiniert mit Open-Source-Engines als Cloud-Services (z.B. Apache Spark oder Databricks). Dies erlaubt eine Trennung von Compute und Storage, wodurch sich Ressourcen flexibler skalieren lassen. 

Einsparpotenziale ergeben sich hier also durch den kostengünstigen Objektspeicher, die Möglichkeiten zur Nutzung von Open-Source-Komponenten und eine bedarfsgerechtere Nutzung von Compute-Ressourcen für die unterschiedlichen Aufgaben im Tech Stack. 

Jeder Lösungsansatz hat seine Stärken

Auf Basis unserer langjährigen Projekterfahrung und fachlichen Expertise in beiden Bereichen haben wir zentrale Indikatoren identifiziert. Diese möchten wir im Folgenden anschaulich vergleichen: 

Umstieg, Einstieg oder in Kombination?

Das Data Lakehouse stellt eine vielversprechende Weiterentwicklung traditioneller Architekturen dar. Insbesondere in einer Welt, in der Datenvolumen und -vielfalt rasant zunehmen, bietet es die Flexibilität und Skalierbarkeit, die moderne Unternehmen benötigen. 

Die Kombination von kostengünstiger Speichertechnologie, offenen Standards und transaktionaler Integrität schafft eine einheitliche Plattform für Analyse, BI und Data Science. 

Gleichzeitig haben klassische Data Warehouses ihre Berechtigung in vielen Szenarien, in denen maximale Performance, Governance und strukturierte Prozesse im Vordergrund stehen.

Grundsätzlich schließen sich die beiden Architektur-Paradigmen nicht aus. Sie lassen sich bei Bedarf sogar gut kombinieren. Die Query-Engines diverser Cloud-Datamanagement-Lösungen können das Open Table-Format des Data Lakehouses mittlerweile einfach integrieren.

Unsere Empfehlung

Unternehmen sollten nicht dogmatisch auf ein Modell setzen, sondern je nach Use Case prüfen, ob ein hybrider Ansatz oder der Übergang zum Lakehouse wirtschaftlicher und zukunftssicherer ist. Für beide Ansätze gibt es gleichermaßen berechtige Nutzungsszenarien.  

Die Data Warehouse Architektur weist einen starken Reifegrad auf, der sich insbesondere durch Klarheit kennzeichnet. Bei einer stärkeren Gewichtung von Skalierbarkeit und Time-to-Market kann jedoch der Data Lakehouse Ansatz Vorteile bieten. 

Wir bieten Ihnen eine kostenlose Data Lakehouse Beratung an, in der wir Ihre aktuelle Datenlandschaft analysieren und gemeinsam den passenden Lösungsansatz entwickeln. Zögern Sie nicht – die Auseinandersetzung mit diesem Thema bietet wertvolle Chancen und wird sich für Ihr Unternehmen nachhaltig auszahlen. 

Nach oben scrollen