Data Warehouse, Lake & Lakehouse: die richtige Architektur wählen
Jeder CDO stand schon vor dieser Frage: „Wie soll unsere Datenarchitektur aussehen?“
Die Antwort hat sich im letzten Jahrzehnt stark verändert. Das monolithische Data Warehouse, einst der Goldstandard, ist heute nur eine Option unter vielen. Um die richtigen architektonischen Entscheidungen zu treffen, müssen Sie wissen, was es gibt, welche Trade-offs jede Option mitbringt und wie Sie die Architektur zum Geschäftsbedarf passend wählen.
Die Landschaft der Datenarchitekturen
Der Modern Data Stack hat Komplexität über Einfachheit geschichtet. Das gibt es heute:
Data Warehouse: Strukturierter, per SQLSQLSales Qualified Lead: ein Prospect, den das Sales-Team als bereit für direkte Ansprache und ein Angebot validiert hat, weil er klare Qualifizierungskriterien erfüllt.Vollständige Definition ansehen → abfragbarer Speicher, optimiert für Analytics. Beispiele: Snowflake, BigQuery, Redshift. Am besten geeignet für: Business IntelligenceBusiness IntelligenceTechnologien und Prozesse, die Rohdaten über Reporting, Dashboards und Analysen in verwertbare Insights überführen, damit Teams auf Basis von Fakten statt Intuition entscheiden.Vollständige Definition ansehen →, Dashboards, strukturiertes Reporting.
Data Lake: Rohdatenspeicher im großen MaMaEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen →ßstab, strukturierte, semi-strukturierte und unstrukturierte Daten. Beispiele: AWS S3, Azure Data LakeData LakeEin Data Lake ist ein zentraler Speicher, der große Datenmengen im Rohformat ablegt, von strukturierten Tabellen bis zu unstrukturierten Dateien, bis sie gebraucht werden.Vollständige Definition ansehen →, GCS. Am besten geeignet für: alles speichern, kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →ünftige Use Cases ermöglichen.
Data Lakehouse: Der Hybrid, der aus der Reibung zwischen Lakes und Warehouses entstanden ist. ACID-Transaktionen, SchemaSchemaEin Schema ist der formale Bauplan, der festlegt, wie Daten in einer Datenbank, einer Datei oder einer Nachricht strukturiert, benannt, typisiert und miteinander verknüpft sind.Vollständige Definition ansehen → Enforcement und SQL-Abfragen auf Lake-Storage. Beispiele: Databricks Delta Lake, Apache Iceberg, Apache Hudi.
Data Mesh: Keine Technologie, sondern ein organisatorisches und architektonisches Paradigma. Data Ownership wird auf Domain-Teams verteilt. Jede Domain produziert Data Products. Federated Governance. Mehr dazu in Modul 3.2.
Data Fabric: Eine Architekturschicht, die unterschiedliche Datenquellen über Metadaten und automatisierte Integration verbindet. Weniger Storage, mehr Konnektivität und Discovery.
Wissenscheck
1. Was unterscheidet ein Data Lakehouse grundlegend von einem klassischen Data Lake?
2. Ein Handelsunternehmen braucht vor allem schnelle, verlässliche BI-Dashboards mit SLA-Zusagen an das Business, die Daten sind gut strukturiert und das Team ist SQL-native. Welche Architektur passt am besten?
3. Warum wird ein Data Mesh als grundlegend anders beschrieben als Warehouse, Lake oder Lakehouse?
4. Wählen Sie ALLE Szenarien, in denen ein Data Lake die passendste Entscheidung ist.
Wählen Sie alle richtigen Antworten aus.
5. Wählen Sie ALLE Aussagen, die korrekt beschreiben, wann ein Lakehouse die richtige Architekturentscheidung ist.
Wählen Sie alle richtigen Antworten aus.
Warehouse vs. Lake vs. LakehouseLakehouseEine hybride Architektur, die die Flexibilität eines Data Lake mit den analytischen Fähigkeiten eines Data Warehouse auf einer einzigen Storage-Schicht verbindet.Vollständige Definition ansehen →
Die Debatte Warehouse-Lake-Lakehouse läuft in jedem Data-Team noch. So können Sie darüber nachdenken:
Wählen Sie ein Data Warehouse, wenn: Ihr Haupt-Use-Case BI und Reporting ist, Ihre Daten strukturiert sind, Ihr Team SQL-native ist und Sie garantierte Query-Performance mit SLASLAFormale Zusage, die das von einem Anbieter garantierte Serviceniveau definiert, mit messbaren Zielen und Konsequenzen bei Nichteinhaltung.Vollständige Definition ansehen →-Zusagen an das Business brauchen.
Wählen Sie einen Data Lake, wenn: Sie riesige Mengen unstrukturierter Daten haben (Logs, Clickstreams, Bilder, Dokumente), Sie Rohdaten für künftige ML-Use-Cases aufbewahren wollen oder Storage-Kosten ein zentrales Thema sind.
Wählen Sie ein Lakehouse, wenn: Sie die Flexibilität eines Lakes mit der Zuverlässigkeit eines Warehouse wollen. Sie sind eine datenintensive Organisation, die sowohl ML als auch BI macht. Sie können sich nicht zwei separate Systeme leisten. Für datenreife Organisationen wird das zunehmend zum Standard.
Die Entstehung des Lakehouse
Das Lakehouse-Muster entstand aus einem konkreten Schmerz: Organisationen bauten Data Lakes, stellten fest, dass sie unbrauchbare Sümpfe unstrukturierter Daten waren, und brauchten Warehouse-ähnliche Zuverlässigkeit, ohne ihre Lake-Investitionen aufzugeben.
Delta Lake (Databricks), Apache Iceberg und Apache Hudi lösten das, indem sie Object Storage um ACID-Transaktionen, Schema Evolution und Time-Travel-Funktionen erweiterten. Das Ergebnis: Storage-Kosten eines Lakes bei der Query-Zuverlässigkeit eines Warehouse.
Netflix hat seine gesamte Dateninfrastruktur auf Apache Iceberg migriert. Sie verwalten hunderte Petabyte an Daten mit Schema Evolution, Rollback-Fähigkeit und paralleler Lese-/Schreibunterstützung, Fähigkeiten, die es vorher nur in teuren proprietären Warehouses gab.
Framework für die Architekturentscheidung
Stellen Sie bei der Bewertung von Architekturoptionen vier Fragen:
- Art der Workload: Geht es um BI, ML, Streaming oder alles drei? Unterschiedliche Workloads sprechen für unterschiedliche Architekturen.
- Skills im Team: SQL-native Teams tendieren zu Warehouses; Python-native Teams tendieren zu Lakes.
- Datenvolumen und -vielfalt: Hohes Volumen + hohe Vielfalt = Lake oder Lakehouse. Strukturierte Daten in moderatem Volumen = Warehouse.
- Toleranz für Vendor Lock-in: Cloud-native Warehouses (Snowflake, BigQuery) bieten einfache Nutzung auf Kosten der Portabilität. Offene Formate (Iceberg, Delta) maximieren die Portabilität.
Es gibt keine allgemeingültig richtige Antwort. Eine gut begründete Architektur, die zu Ihren tatsächlichen Workloads passt, schlägt eine anspruchsvolle Architektur, die Ihr Team nicht betreiben kann.
Quizfragen
- Was ist der wesentliche Unterschied zwischen einem Data Lake und einem Data Lakehouse?
A) Das Lakehouse ist teurer
B) Das Lakehouse ergänzt Lake-Storage um ACID-Transaktionen und die Zuverlässigkeit eines Warehouse
C) Das Lakehouse unterstützt kein SQL
D) Das Lakehouse ist nur für unstrukturierte Daten
Antwort: B
- Welche Architektur wählt man vorrangig für ein SQL-natives BI-Team mit strukturierten Daten?
A) Data Lake
B) Data Mesh
C) Data Warehouse
D) Data Fabric
Antwort: C
- Welches Open-Source-Projekt hat es Netflix ermöglicht, hunderte Petabyte mit ACID-Fähigkeiten zu verwalten?
A) Apache Kafka
B) Apache Hudi
C) Apache Iceberg
D) Delta Lake
Antwort: C
Was Sie aus dieser Lektion umsetzen
Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.
- Architektur anhand von Workload, Team-Skills, Volumen und Lock-in-Toleranz wählen
Verwandte Artikel
Aktuelle Blogartikel, die auf dieser Lektion aufbauen.
- DataDuckDB hat die Stellenbeschreibung des Analysten überflüssig gemacht, und das sollten CDOs jetzt tunNatural-Language-BI lässt den Abstand zwischen einer fachlichen Frage und einer funktionierenden Query zusammenschrumpfen. CDOs, die darin ein Tooling-Upgrade statt eines Umbaus ihrer Organisation sehen, führen bald ein Team, das für Probleme gebaut wurde, die es nicht mehr gibt.
- DataData Mesh vs. Data Lakehouse: Was CDOs 2026 wirklich entscheiden müssenDie Debatte zwischen Data-Mesh- und Data-Lakehouse-Architekturen hat die Theorie verlassen und ist in den Budgetgesprächen der Vorstandsetage angekommen. Das steckt tatsächlich hinter der Entscheidung, und deshalb ist es der erste Fehler der meisten CDOs, die Frage als Entweder-oder zu stellen.
- DataData Mesh vs. Data Lakehouse: Worüber CDOs 2026 wirklich entscheiden müssenDie Debatte zwischen Data Mesh und Lakehouse-Architekturen hat die Whitepaper-Theorie verlassen und hat inzwischen konkrete organisatorische Folgen. CDOs, die das als rein technische Entscheidung behandeln, sind bereits im Rückstand.