Lakehouse-Architektur erklärt: Medallion (Bronze/Silver/Gold) in der Praxis

Pexon Consulting | 10 Min. Lesezeit | 19.06.2026

TL;DR

Lakehouse mit Medallion-Pattern (Bronze, Silver, Gold) ist 2026 die Standard-Architektur für Daten-Plattformen — sowohl auf Microsoft Fabric (OneLake) als auch Databricks (Unity Catalog). Pexon Consulting setzt produktive Lakehouses in 4-6 Wochen als Festpreis-Sprint zwischen 32 und 58k EUR mit klarer Medallion-Trennung, Audit-Trail und Multi-Use-Case-Anbindung.

Warum Medallion sich als Standard durchgesetzt hat

Wir hören das wöchentlich in CTO-Erstgesprächen: „Bronze/Silver/Gold — warum diese Schichtung? Reicht nicht eine Schicht?“

Drei Gründe für die Drei-Schichten-Architektur.

Grund 1: Audit-Konsistenz. Bronze hält Rohdaten unverändert. Bei Audit-Anfragen oder Datenstreit ist Bronze die Quelle der Wahrheit. Mehr im breiten Compliance-as-Code-Pattern.

Grund 2: Pipeline-Wiederverwendung. Silver-Schicht wird von mehreren Use-Cases gemeinsam genutzt. Statt jede Pipeline eigene Bereinigung zu bauen, einmal Silver, alle profitieren.

Grund 3: Performance. Gold-Schicht ist auf Read-Performance optimiert. BI-Dashboards lesen aus Gold, nicht aus Silver.

Bronze-Layer im Detail

Was passiert hier. Rohdaten von Quell-Systemen (SAP, IIoT, APIs, File-Uploads) landen unverändert in Delta-Lake-Format. Schema-on-Read, kein Validierungs-Schritt.

Wichtige Designentscheidungen.

• Append-Only. Bronze wird nicht überschrieben, nur ergänzt.
• Versionierung. Delta-Lake-Versionierung ermöglicht Point-in-Time-Restore.
• Aufbewahrung. Typisch 7-10 Jahre bei regulierten Branchen.

# Beispiel: Bronze-Ingestion in Databricks
import dlt

@dlt.table(name="bronze_sap_orders", comment="Roh-Aufträge aus SAP")
def bronze_sap_orders():
    return (
        spark.readStream
        .format("cloudFiles")
        .option("cloudFiles.format", "json")
        .option("cloudFiles.schemaLocation", "/Volumes/schemas/bronze/")
        .load("/Volumes/raw/sap/orders/")
    )

Mehr zur konkreten Implementierung im Fabric vs Databricks-Vergleich.

Silver-Layer im Detail

Was passiert hier. Daten werden bereinigt, validiert, mit Kontext angereichert. Schema-on-Write, klare Datentypen.

Typische Transformationen.

• Plausibilitäts-Checks (numerische Bereiche, Format-Validierung).
• Joins mit Stamm-Daten (z.B. Aufträge mit Kunden-Details).
• Einheiten-Normalisierung (kWh, EUR, kg).
• Duplikat-Entfernung.

@dlt.table(name="silver_orders_enriched")
def silver_orders_enriched():
    return (
        dlt.read_stream("bronze_sap_orders")
        .join(dlt.read("silver_customers"), on="customer_id", how="left")
        .withColumn("order_value_eur", convert_to_eur(F.col("amount"), F.col("currency")))
        .filter(F.col("order_value_eur") > 0)
        .dropDuplicates(["order_id"])
    )

Gold-Layer im Detail

Was passiert hier. Aggregate für konkrete Use-Cases. Pro Use-Case eigene Gold-Tabelle.

Typische Aggregationen.

• Monats-Umsätze pro Region und Produktkategorie.
• Tages-OEE pro Maschine.
• Quartals-Scope-Emissionen pro Standort. Mehr im CSRD-Reporting-Pattern.

@dlt.table(name="gold_revenue_by_region_month")
def gold_revenue_by_region_month():
    return (
        dlt.read("silver_orders_enriched")
        .groupBy("region", F.date_trunc("month", "order_date").alias("month"))
        .agg(F.sum("order_value_eur").alias("revenue_eur"))
    )

Power BI oder Tableau lesen aus Gold via Direct Lake (Fabric) oder Unity Catalog (Databricks).

Häufige Engineering-Fallen

Falle 1: Silver-Schicht überspringen. Direkter Sprung von Bronze zu Gold führt zu Mehrfach-Bereinigung in verschiedenen Gold-Tabellen. Pflegehölle.

Falle 2: Gold-Aggregate als View statt Tabelle. Bei großen Daten-Volumen lohnt sich materialisierte Aggregation als physische Tabelle.

Falle 3: Bronze-Schicht zu sauber haben wollen. Bronze MUSS rohe Daten enthalten. Wer hier bereinigt, verliert Audit-Konsistenz.

Falle 4: Schema-Evolution unkontrolliert. Bei Quell-System-Änderungen muss Schema-Evolution kontrolliert ablaufen. Delta Lake hilft, aber nicht ohne Konfiguration.

Wann Medallion sich nicht lohnt

Bei sehr kleinen Setups mit < 5 Workloads und < 100 GB Daten ist Medallion oft Over-Engineering. Direct-Load in eine einzelne Schicht reicht.

Sobald 8+ Workloads, mehrere Quell-Systeme oder Compliance-Anforderungen greifen, ist Medallion der pragmatische Pfad.

Pexon-Sprint und Investment

4-6-Wochen-Festpreis-Sprint: 32-58k EUR. Plattform-Setup, Medallion-Architektur, Ingestion-Pipelines, BI-Anbindung.

Häufig gestellte Fragen

Welche Plattform unterstützt Medallion besser?

Sowohl Fabric (OneLake) als auch Databricks (Unity Catalog) sind voll Medallion-tauglich. Mehr im Plattform-Vergleich.

Wie verhält sich das mit Streaming-Daten?

Streaming-Daten landen in Bronze direkt aus Eventstream oder Structured Streaming. Silver- und Gold-Transformationen mit Delta Live Tables (Databricks) oder Notebook (Fabric).

Was bei sehr großen Bronze-Volumen?

Lifecycle-Policies. Heißes Bronze (< 30 Tage) auf Hot-Tier, älteres auf Cool oder Archive. Bei einem Pexon-Setup haben wir damit 65% Storage-Kosten gespart.

Können wir Medallion in PostgreSQL nachbauen?

Technisch ja, aber Delta-Lake-Features (Time-Travel, Schema-Evolution, ACID-Transactions auf Daten-Lakes) fehlen. Bei kleinen Setups Postgres ok, bei Skalierung Lakehouse der pragmatische Pfad.

Wie verhält sich das mit Microsoft Fabric OneLake?

OneLake nutzt Delta Lake nativ. Medallion-Pattern dort identisch zu Databricks. Mehr im OneLake-Detail.

Nächster Schritt

Wenn ihr Lakehouse-Architektur produktiv aufsetzen wollt: 30-Minuten-Call. Wir skizzieren Sprint.

Verwandte Themen