Data Lakehouse Architektur erklärt: Wann lohnt sich der Umstieg?

TL;DR: Data Lakehouse kombiniert günstigen Object-Storage mit ACID-Garantien — funktioniert aber nur, wenn du die operative Disziplin für Compaction, Governance und Datenqualität mitbringst. Für reine SQL-Teams mit < 10 TB ist ein Warehouse einfacher. Für ML + BI auf großen Volumes ist Lakehouse heute der Default.

Data Lakehouse Architektur verspricht das Beste aus zwei Welten: den günstigen, skalierbaren Storage eines Data Lakes mit der Zuverlässigkeit und Performance eines Data Warehouses. Aber liefert sie das wirklich — und wann solltest du zweimal nachdenken, bevor du eine baust?

Dieser Artikel zerlegt, wie Data Lakehouse Architektur funktioniert, vergleicht sie mit klassischen Ansätzen und geht durch die praktischen Trade-offs, denen Data Engineers beim Bau begegnen.

Was ist ein Data Lakehouse?

Ein Data Lakehouse ist eine Datenmanagement-Architektur, die den günstigen Object-Storage eines Data Lakes mit den Transaktionsgarantien und der Schema-Durchsetzung eines Data Warehouses kombiniert. Der entscheidende Enabler: offene Tabellenformate wie Delta Lake, Apache Iceberg und Apache Hudi, die ACID-Transaktionen, Time Travel und Schema-Evolution oben auf Parquet-Files im Cloud-Object-Storage ergänzen.

Statt separate Systeme für Rohdaten (Lake) und kuratierte Daten (Warehouse) zu betreiben, fasst ein Lakehouse beides in einer einzigen Architektur mit klar getrennten Schichten zusammen.

Lakehouse-Architektur-Schichten

Die typische Data Lakehouse Architektur folgt einem Medallion-Muster — Bronze-, Silver- und Gold-Layer — gebaut auf Cloud-Object-Storage.

graph TD
    A["① Cloud Object Storage<br/>(S3, ADLS, GCS)"] --> B["② Bronze Layer<br/>Raw Ingestion"]
    B --> C["③ Silver Layer<br/>Cleaned & Conformed"]
    C --> D["④ Gold Layer<br/>Business-Ready Aggregates"]
    D --> E["⑤ BI & Analytics"]
    D --> F["⑤ ML & Data Science"]
    A --> G["Open Table Format<br/>(Delta Lake / Iceberg / Hudi)"]
    G -.->|"ACID, Schema, Time Travel"| B
    G -.->|"ACID, Schema, Time Travel"| C
    G -.->|"ACID, Schema, Time Travel"| D

    classDef blue fill:#F0F4FF,stroke:#1e3a8a,stroke-width:2px,color:#1e1e2e,font-weight:bold
    classDef green fill:#F0FFF4,stroke:#14532d,stroke-width:2px,color:#1e1e2e,font-weight:bold
    classDef amber fill:#FFFBEB,stroke:#92400e,stroke-width:2px,color:#1e1e2e,font-weight:bold
    classDef rose fill:#FFF0F0,stroke:#7f1d1d,stroke-width:2px,color:#1e1e2e,font-weight:bold
    classDef purple fill:#FAF0FF,stroke:#4c1d95,stroke-width:2px,color:#1e1e2e,font-weight:bold
    classDef default fill:#FAFAF8,stroke:#1e1e2e,stroke-width:2px,color:#1e1e2e

    class A blue
    class B amber
    class C green
    class D purple
    class E,F rose
    class G default

① Cloud Object Storage — Alle Daten liegen auf günstigem, skalierbarem Blob-Storage (S3, ADLS, GCS). Keine proprietären Formate.

② Bronze Layer — Rohdaten landen hier unverändert. Append-only-Ingestion aus APIs, CDC-Streams oder Batch-Loads. Schema-on-Read.

③ Silver Layer — Daten werden bereinigt, dedupliziert und auf Standard-Schemas konformisiert. Hier passiert die Datenqualitätsdurchsetzung.

④ Gold Layer — Business-fertige Aggregate, Dimensionen und Faktentabellen, optimiert für Query-Performance.

⑤ Consumers — BI-Dashboards, ML-Trainingspipelines und Ad-hoc-Analytics fragen alle dieselben Gold-Layer-Tabellen ab.

Storage / Raw Data / Cleaned Data / Curated Data / Consumers / Infrastructure

Delta-Lake-Architektur: die häufigste Implementierung

Wenn jemand "Data Lakehouse Architektur" sagt, meint er oft Delta Lake — das offene Tabellenformat, das ursprünglich von Databricks gebaut wurde. Die Databricks-Lakehouse-Plattform hat Delta Lake zum De-facto-Standard für Lakehouse-Implementierungen gemacht, auch wenn Apache Iceberg schnell aufholt.

Delta Lake fügt einen Transaction-Log (_delta_log/) oben auf Parquet-Files hinzu. Jeder Write — Insert, Update, Delete oder Schema-Change — erzeugt einen neuen JSON-Eintrag in diesem Log und ermöglicht:

• ACID-Transaktionen über parallele Reads und Writes hinweg
• Time Travel über versionierte Snapshots
• Schema-Durchsetzung und -Evolution ohne Daten umzuschreiben
• Z-Ordering und Data Skipping für Query-Performance

So sieht ein typischer Delta-Lake-Write in PySpark aus:

# PySpark — Writing to a Delta Lake silver layer table
from pyspark.sql import SparkSession
from pyspark.sql.functions import col, current_timestamp, sha2, concat_ws

spark = SparkSession.builder \
    .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
    .config("spark.sql.catalog.spark_catalog", "org.apache.spark.sql.delta.catalog.DeltaCatalog") \
    .getOrCreate()

# Read bronze-layer raw events
bronze_df = spark.read.format("delta").load("s3://my-lake/bronze/events/")

# Clean and deduplicate for silver layer
silver_df = (
    bronze_df
    .dropDuplicates(["event_id"])
    .filter(col("event_timestamp").isNotNull())
    .withColumn("processed_at", current_timestamp())
    .withColumn("row_hash", sha2(concat_ws("||", *bronze_df.columns), 256))
)

# Write with merge schema to handle evolution
silver_df.write \
    .format("delta") \
    .mode("overwrite") \
    .option("mergeSchema", "true") \
    .save("s3://my-lake/silver/events/")

Lakehouse vs Data Warehouse vs Data Lake

Die Lakehouse-vs-Warehouse-Debatte ist nicht "eines davon ist universell besser". Jede Architektur macht andere Trade-offs:

Wann ein Data Warehouse: Workload ist überwiegend SQL-Analytics, das Team ist SQL-first, Datenvolumen moderat (< 10 TB), und du legst Wert auf Einfachheit statt Flexibilität.

Wann ein Data Lake: Du brauchst günstigen Storage für massive Mengen unstrukturierter Daten (Bilder, Logs, Video), und deine Konsumenten sind Data Scientists in Python/Spark.

Wann ein Data Lakehouse: Du willst eine einzige Architektur für BI- und ML-Workloads, hast große Mengen strukturierter und semistrukturierter Daten, und dein Team kann mit der zusätzlichen operativen Komplexität umgehen.

Gold-Layer-Lakehouse-Tabellen abfragen

Sobald deine Lakehouse-Pipeline Gold-Layer-Tabellen produziert, ist das Abfragen mit Spark SQL geradeaus:

-- Spark SQL — Query gold-layer aggregates with time travel
SELECT
    region,
    product_category,
    SUM(revenue) AS total_revenue,
    COUNT(DISTINCT customer_id) AS unique_customers,
    AVG(order_value) AS avg_order_value
FROM delta.`s3://my-lake/gold/order_summary/`
VERSION AS OF 42  -- time travel to specific version
WHERE order_date >= '2026-01-01'
GROUP BY region, product_category
ORDER BY total_revenue DESC;

Genau hier glänzt das Lakehouse gegenüber einem klassischen Data Lake: du bekommst Warehouse-artige SQL-Semantik mit Data-Lake-Ökonomie.

Wenn du mit Gold-Layer-Tabellen arbeitest, die als CSV exportiert oder über APIs verfügbar gemacht werden, lassen Tools wie Harbinger Explorer sie direkt im Browser via DuckDB WASM abfragen — nützlich für schnelle Ad-hoc-Exploration ohne Spark-Cluster-Hochfahren.

Häufige Pitfalls

Eine Data Lakehouse Architektur zu bauen ist nicht "Delta Lake auf S3 werfen und fertig". Das sind die Fehler, die Teams ausbrennen:

1. Compaction überspringen

Kleine Files killen die Query-Performance. Wenn deine Ingestion Tausende winzige Parquet-Files produziert (häufig bei Streaming), brauchst du regelmäßige OPTIMIZE-Läufe. Das ist nicht optional — das ist operative Hygiene.

2. Partition-Strategie ignorieren

Über-Partitionierung auf High-Cardinality-Spalten (wie user_id) erzeugt das Small-File-Problem getarnt. Unter-Partitionierung bedeutet Full Table Scans. Investiere Zeit ins Modellieren deiner Access-Patterns, bevor du Partition-Spalten wählst.

3. Keine Datenqualitätsdurchsetzung

Ein Lakehouse ohne Datenqualitäts-Checks ist nur ein Data Lake mit Extra-Schritten. Nutze Expectations (Great Expectations, Soda oder Delta-Live-Tables-Expectations) an der Bronze-zu-Silver-Grenze.

4. Den Gold-Layer als Dump behandeln

Der Gold-Layer sollte ein kuratiertes, gut dokumentiertes Set business-fertiger Tabellen sein — keine Kopie von Silver mit ein paar Aggregationen. Definiere klare Eigentümerschaft, SLAs und Naming-Konventionen.

5. Governance unterschätzen

Offene Tabellenformate geben dir die Bausteine, aber du brauchst weiterhin einen Catalog (Unity Catalog, AWS Glue, Project Nessie), um Access-Control, Lineage und Discoverability zu managen. Das gilt besonders im Databricks-Lakehouse-Stack, wo Unity Catalog zunehmend der erwartete Governance-Layer ist.

6. Vorzeitige Optimierung

Z-Ordering, Liquid Clustering, Bloom-Filter — mächtig, aber sie anzuwenden, bevor du deine Query-Patterns verstehst, ist verschwendete Mühe. Profile zuerst, tune danach.

Wann KEIN Lakehouse

Data Lakehouse Architektur ist nicht immer die richtige Antwort. Lass es weg, wenn:

• Deine Daten in PostgreSQL passen. Bei < 100 GB strukturierter Daten und einfachen Queries ist eine relationale Datenbank mit dbt einfacher, billiger und einfacher zu betreiben. Nicht überarchitekturieren.

• Dein Team pure SQL ist, null Spark. Lakehouses setzen ein Mindestmaß an Komfort mit Spark oder ähnlichen verteilten Compute-Frameworks voraus. Wenn dein gesamtes Team SQL-only ist, ist ein Managed Warehouse (Snowflake, BigQuery) produktiver.

• Du keinen ML- oder Data-Science-Workload hast. Der Hauptvorteil eines Lakehouses gegenüber einem Warehouse ist Unified Access für BI und ML. Wenn du nur Dashboards und Reports baust, ist ein Warehouse simpler.

• Du nicht in Operations investieren kannst. Lakehouses brauchen laufende Wartung: Compaction, Vacuum, Partition-Größen monitoren, Catalog-Metadaten managen. Ohne Engineering-Bandbreite frisst der operative Overhead deine Produktivitätsgewinne.

• Vendor-Lock-in für dich kein Thema ist. Wenn du dich bereits auf ein Cloud-Warehouse festgelegt hast und es funktioniert, lohnt eine Migration zu Lakehouse für theoretische Vorteile selten die Disruption.

Die Open-Table-Format-Landschaft

Die Wahl des offenen Tabellenformats formt deine Lakehouse-Implementierung. Stand Anfang 2026:

• Delta Lake — stärkstes Ökosystem (Databricks), beste Spark-Integration, am reifsten. Default-Wahl für Databricks-Lakehouse-Deployments.
• Apache Iceberg — bester Multi-Engine-Support (Spark, Trino, Flink, Snowflake), stärkste Partition-Evolution. Wächst schnell.
• Apache Hudi — am besten für inkrementelle / Upsert-lastige Workloads, starker CDC-Support. Kleinere Community.

Meine Einschätzung: Wenn du auf Databricks bist, ist Delta Lake die pragmatische Wahl. Wenn du maximale Engine-Flexibilität willst, ist Iceberg der Punkt, auf den die Industrie zuläuft. Hudi ist solide, aber zunehmend nische.

FAQ

Was ist der Unterschied zwischen Data Lakehouse und Data Warehouse?

Ein Data Warehouse speichert Daten in proprietären, optimierten Formaten und koppelt Compute eng mit Storage. Ein Lakehouse trennt beides: Object-Storage (S3, ADLS, GCS) mit offenen Tabellenformaten (Delta, Iceberg, Hudi), die ACID-Garantien obendrauf legen.

Brauche ich Spark für ein Lakehouse?

Nicht zwingend. Viele Lakehouse-Implementierungen laufen auf Spark, aber Trino, DuckDB, Flink, Snowflake und Polars können Delta- oder Iceberg-Tabellen direkt abfragen. Für Datenqualität und Streaming bleibt Spark in der Praxis Standard.

Ist Delta Lake DSGVO-konform?

Delta Lake hat alle technischen Bausteine: ACID-Deletes für Right-to-be-Forgotten, Time Travel für Audit, Schema-Enforcement für Validierung. DSGVO-Konformität entsteht aber durch das Gesamtsystem (Governance, Access-Control, Retention) — nicht durch das Tabellenformat allein.

Sollte ich Delta Lake oder Apache Iceberg wählen?

Auf Databricks: Delta Lake. Sonst: Iceberg, vor allem wenn du mehrere Engines (Spark, Trino, Snowflake) parallel nutzen willst. Die Plattformen konvergieren ohnehin — UniForm und Iceberg-Reads in Delta machen den Unterschied kleiner.

Wie viel Operations-Aufwand habe ich monatlich?

Realistisch 0,2–0,5 FTE für ein produktives Lakehouse — Compaction-Jobs, Vacuum-Cleanups, Catalog-Verwaltung, Partition-Pflege. Bei großen Volumes (> 100 TB) kann das schnell 1 FTE werden.

Key Takeaways

Data Lakehouse Architektur löst ein reales Problem — die Kosten und Komplexität, getrennte Lake- und Warehouse-Systeme zu unterhalten. Mit offenen Tabellenformaten, die ACID-Transaktionen auf günstigem Object-Storage liefern, ist das technische Fundament solide.

Aber das ist keine Magie. Du brauchst das richtige Team, das passende Workload-Profil (BI und ML) und die operative Disziplin, Compaction, Governance und Datenqualität zu managen. Starte mit einem einzigen Use-Case, weise mit einer Gold-Layer-Tabelle den Wert nach und expandiere dann. Versuch nicht, den Ozean zu kochen.

Stand: 14. Mai 2026.