+50 XP

Data Warehouse, Lake & Lakehouse: die richtige Architektur wählen

Jeder CDO kennt diese Frage: „Wie soll unsere Datenarchitektur aussehen?“

Die Antwort hat sich im letzten Jahrzehnt massiv verändert. Das monolithische Data Warehouse, einst der Goldstandard, ist heute nur eine Option unter vielen. Für die richtigen Architekturentscheidungen müssen Sie wissen, was es gibt, welche Trade-offs jede Option mitbringt und wie Sie Architektur und Business-Anforderung zusammenbringen.

Das Feld der Datenarchitekturen

Der Modern Data Stack hat auf Einfachheit zusätzliche Komplexität gelegt. Das gibt es heute:

Data Warehouse: Strukturierter, per SQL abfragbarer Speicher, optimiert für Analytics. Beispiele: Snowflake, BigQuery, Redshift. Am besten geeignet für: Business Intelligence, Dashboards, strukturiertes Reporting.

Data Lake: Rohdatenspeicher in großem Maßstab, strukturierte, semi-strukturierte und unstrukturierte Daten. Beispiele: AWS S3, Azure Data Lake, GCS. Am besten geeignet für: alles speichern, künftige Use Cases ermöglichen.

Data Lakehouse: Der Hybrid, der aus der Reibung zwischen Lakes und Warehouses entstanden ist. ACID-Transaktionen, Schema 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 an Domain-Teams verteilt. Jede Domain produziert Data Products. Federated Governance. Mehr dazu in Modul 3.2.

Data Fabric: Eine Architekturschicht, die verstreute Datenquellen über Metadaten und automatisierte Integration verbindet. Weniger Storage, mehr Konnektivität und Discovery.

Modern Data Stack Explained

Watch on YouTube

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 die Fachbereiche, die Daten sind gut strukturiert und das Team arbeitet SQL-native. Welche Architektur passt am besten?

3. Warum wird ein Data Mesh als grundlegend anders beschrieben als Warehouse, Lake oder Lakehouse?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Szenarien, in denen ein Data Lake die passendste Entscheidung ist.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Aussagen, die korrekt beschreiben, wann ein Lakehouse die richtige architektonische Wahl ist.

Wählen Sie alle richtigen Antworten aus.

Warehouse vs. Lake vs. Lakehouse

Die Debatte Warehouse–Lake–Lakehouse läuft in jedem Data-Team noch. So können Sie sie einordnen:

Nehmen Sie ein Data Warehouse, wenn: Ihr primärer Use Case BI und Reporting ist, Ihre Daten strukturiert sind, Ihr Team SQL-native arbeitet und Sie garantierte Query-Performance mit SLA-Zusagen an die Fachbereiche brauchen.

Nehmen Sie einen Data Lake, wenn: Sie riesige unstrukturierte Datenmengen haben (Logs, Clickstreams, Bilder, Dokumente), Rohdaten für künftige ML-Use-Cases erhalten wollen oder Storage-Kosten ein zentrales Thema sind.

Nehmen Sie ein Lakehouse, wenn: Sie die Flexibilität eines Lake mit der Verlässlichkeit eines Warehouse verbinden wollen. Sie sind eine datenintensive Organisation und machen sowohl ML als auch BI. Sie können sich zwei getrennte Systeme nicht leisten. Für datenreife Organisationen wird das zunehmend zum Standard.

Wie das Lakehouse entstand

Das Lakehouse-Muster entstand aus einem konkreten Schmerz: Organisationen bauten Data Lakes, stellten fest, dass daraus unbrauchbare Sümpfe unstrukturierter Daten wurden, und brauchten Warehouse-artige Verlässlichkeit, ohne ihre Lake-Investitionen aufzugeben.

Delta Lake (Databricks), Apache Iceberg und Apache Hudi lösten das, indem sie ACID-Transaktionen, Schema Evolution und Time-Travel-Funktionen auf Object Storage brachten. Das Ergebnis: Storage-Kosten eines Lake bei der Query-Verlässlichkeit eines Warehouse.

Netflix hat seine komplette Dateninfrastruktur auf Apache Iceberg migriert. Dort werden hunderte Petabyte an Daten verwaltet, mit Schema Evolution, Rollback-Möglichkeit und parallelem Lesen und Schreiben, also Funktionen, die es früher nur in teuren proprietären Warehouses gab.

Entscheidungsrahmen für die Architektur

Stellen Sie bei der Bewertung von Architekturoptionen vier Fragen:

  • Art der Workloads: Geht es um BI, ML, Streaming oder alle drei? Unterschiedliche Workloads sprechen für unterschiedliche Architekturen.
  • Skills im Team: SQL-native Teams tendieren zu Warehouses, Python-native Teams zu Lakes.
  • Datenvolumen und -vielfalt: Hohes Volumen + hohe Vielfalt = Lake oder Lakehouse. Strukturierte Daten bei moderatem Volumen = Warehouse.
  • Toleranz für Vendor Lock-in: Cloud-native Warehouses (Snowflake, BigQuery) bieten Bequemlichkeit auf Kosten der Portabilität. Offene Formate (Iceberg, Delta) maximieren Portabilität.

Es gibt keine allgemeingültig richtige Antwort. Eine gut begründete Architektur, die zu Ihren tatsächlichen Workloads passt, schlägt eine ausgefeilte Architektur, die Ihr Team nicht betreiben kann.

Quizfragen

1. Quelle est la principale différence entre un data lake et un data lakehouse ?

A) Le lakehouse est plus cher

B) Le lakehouse ajoute des transactions ACID et la fiabilité d'un warehouse sur un stockage de type lake

C) Le lakehouse ne supporte pas le SQL

D) Le lakehouse est uniquement pour les données non structurées

Réponse: B

2. Quelle architecture choisir en priorité pour une équipe BI SQL-native avec des données structurées ?

A) Data lake

B) Data mesh

C) Data warehouse

D) Data fabric

Réponse: C

3. Quel projet open source a permis à Netflix de gérer des centaines de pétaoctets avec des capacités ACID ?

A) Apache Kafka

B) Apache Hudi

C) Apache Iceberg

D) Delta Lake

Réponse: 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
Vollständiges Action Playbook ansehen

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.