Medallion Architecture erklärt: Bronze, Silver, Gold im Lakehouse

Jeder Data-Engineer, der ein Lakehouse aufsetzt, stößt irgendwann auf dieselbe Frage: Wie kommst du von einem rohen S3-Dump zu einer sauberen, vertrauenswürdigen Tabelle, mit der ein Data-Scientist oder Analyst tatsächlich arbeiten kann? Medallion Architecture ist die Antwort, auf die die meisten Production-Lakehouses konvergieren — ein Bronze → Silver → Gold Layering-Pattern, das rohes Ingestion-Chaos in governed, business-ready Daten verwandelt. Hier ist, was es bedeutet, wie es in der Praxis funktioniert, und wo es bricht.

TL;DR

• Bronze = Raw-Ingestion, append-only, kein Transform — dein Replay-Backup
• Silver = bereinigte, conformed Daten, Schema-Enforcement, Deduplizierung
• Gold = business-ready Aggregate für spezifische Consumer (Dashboards, ML-Features)
• Pattern, keine Methodologie — sagt nichts über wie du modellierst
• Nicht overkill nutzen — kleine static Datensätze brauchen keine drei Layer

Was Medallion Architecture ist

Medallion Architecture ist ein Daten-Design-Pattern, um Lakehouse-Daten in progressiv saubere Layer zu organisieren. Jeder Layer hat einen spezifischen Qualitäts-Vertrag:

• Bronze: Raw-Ingestion. Daten landen exakt wie sie aus Source-Systemen kommen — kein Transform, kein Filter.
• Silver: Bereinigt und conformed. Schema-Enforcement, Deduplizierung, Type-Casting, Business-Rules. Hier passiert der meiste Transform.
• Gold: Business-ready Aggregate. Pre-joined, pre-aggregiert, optimiert für spezifische Analytics-Use-Cases.

Der Name ist eine Qualitäts-Metapher, kein technisches Requirement. Auch "Multi-Hop-Architecture" oder das "Bronze-Silver-Gold-Pattern" genannt. Das zugrundeliegende Storage ist meist Delta Lake (in Databricks) oder Apache Iceberg (in anderen Lakehouses), aber das Pattern funktioniert mit jedem ACID-fähigen Storage-Format.

Architektur-Übersicht

graph LR
    SRC["① Raw-Quellen<br/>APIs, DBs, Files"]:::blue --> BRZ["② Bronze-Layer<br/>Raw-Ingestion"]:::amber
    BRZ --> SLV["③ Silver-Layer<br/>Bereinigt & Conformed"]:::green
    SLV --> GLD["④ Gold-Layer<br/>Business-Ready"]:::rose
    GLD --> CON["⑤ Consumer<br/>BI-Tools & APIs"]:::light

    classDef blue fill:#D6DCF5,stroke:#7B83B0,stroke-width:1.5px,color:#2B3674,font-weight:bold
    classDef green fill:#D8E4BF,stroke:#9AAF78,stroke-width:1.5px,color:#2B3674,font-weight:bold
    classDef amber fill:#F0E2C8,stroke:#C4A97A,stroke-width:1.5px,color:#2B3674,font-weight:bold
    classDef rose fill:#F5D5D5,stroke:#C49A9A,stroke-width:1.5px,color:#2B3674,font-weight:bold
    classDef light fill:#F8F6F1,stroke:#D4D0C8,stroke-width:1.5px,color:#4A4A4A

① Raw-Quellen — jedes Origin-System: REST-APIs, relationale Datenbanken via CDC, CSV-Uploads, Event-Streams, Third-Party-SaaS-Exports.

② Bronze-Layer — Daten landen hier sofort und unverändert. Die einzigen erlaubten Transforms sind technische: Hinzufügen eines _ingested_at-Timestamps, eines _source-Tags oder einer _raw-JSON-Spalte für die volle Payload. Bronze ist deine Zeitmaschine — wenn downstream was bricht, replayst du von hier.

③ Silver-Layer — hier passiert Engineering. Schema-Enforcement, Deduplizierung, NULL-Handling, Type-Casting und Cross-Source-Joins. Silver-Tabellen sind die "Single Version of Truth" für eine Domain (z. B. silver.orders, silver.customers).

④ Gold-Layer — denormalisierte, aggregierte Tabellen für spezifische Consumer. Eine gold.daily_revenue_by_region-Tabelle bedient ein Dashboard. Eine gold.customer_360-Tabelle bedient einen ML-Feature-Store. Gold-Tabellen werden oft aus Silver auf einem Schedule neu gebaut.

⑤ Consumer — Dashboards, ML-Modelle, APIs und Ad-hoc-Analysten. Consumer lesen aus Gold (oder gelegentlich Silver für Power-User). Niemals aus Bronze.

Layer-Vergleich

Bronze zu Silver: PySpark-Beispiel

Realistische Bronze → Silver Transformation für einen Orders-Datensatz. Sie handhabt Schema-Casting, Deduplizierung und NULL-Filterung — die drei häufigsten Silver-Layer-Tasks.

# PySpark — Bronze zu Silver Transformation für Orders
# Dialekt: Spark SQL / PySpark (Databricks Runtime 14+)

from pyspark.sql import SparkSession
from pyspark.sql import functions as F
from pyspark.sql.types import StructType, StructField, StringType, DoubleType, TimestampType
from pyspark.sql.window import Window
from delta.tables import DeltaTable

spark = SparkSession.builder.appName("bronze_to_silver_orders").getOrCreate()

# 1. Aus Bronze lesen (append-only, Raw-Ingestion)
bronze_df = (
    spark.read
    .format("delta")
    .load("/mnt/datalake/bronze/orders")
    # Nur Records verarbeiten, die noch nicht in Silver sind (Watermark-basiert)
    .filter(F.col("_ingested_at") > spark.sql("SELECT MAX(processed_at) FROM silver.orders").collect()[0][0])
)

# 2. Silver-Layer Transforms anwenden
silver_df = (
    bronze_df
    # Typen casten — Bronze landet alles als String aus JSON-Payload
    .withColumn("order_id",    F.col("order_id").cast("string"))
    .withColumn("customer_id", F.col("customer_id").cast("string"))
    .withColumn("amount",      F.col("amount").cast(DoubleType()))
    .withColumn("order_date",  F.to_timestamp(F.col("order_date"), "yyyy-MM-dd'T'HH:mm:ss"))

    # Zeilen ohne kritische Keys droppen
    .filter(F.col("order_id").isNotNull())
    .filter(F.col("customer_id").isNotNull())
    .filter(F.col("amount") > 0)

    # Deduplizieren — neuesten Record pro order_id behalten
    .withColumn(
        "row_num",
        F.row_number().over(
            Window.partitionBy("order_id").orderBy(F.col("_ingested_at").desc())
        )
    )
    .filter(F.col("row_num") == 1)
    .drop("row_num")

    # Processing-Metadata hinzufügen
    .withColumn("processed_at", F.current_timestamp())
    .withColumn("_source_layer", F.lit("silver"))
)

# 3. MERGE in Silver (Upsert — handhabt spät eintreffende Records)
silver_table = DeltaTable.forName(spark, "silver.orders")

(
    silver_table.alias("target")
    .merge(
        silver_df.alias("source"),
        "target.order_id = source.order_id"
    )
    .whenMatchedUpdateAll()
    .whenNotMatchedInsertAll()
    .execute()
)

print(f"Silver merge complete. Records processed: {silver_df.count()}")

Schlüssel-Entscheidungen:

• Schema-Casting in Silver, nicht Bronze — Bronze akzeptiert was die Source sendet; Silver erzwingt Contracts.
• MERGE statt Overwrite — handhabt spät eintreffende Records und Korrekturen aus dem Source-System.
• Watermark-basiertes inkrementelles Processing — reprozessiere nicht die ganze Bronze-Tabelle bei jedem Lauf.

Häufige Stolpersteine

1. Business-Logic in Bronze Bronze ist ein Safety-Net. Sobald du in Bronze filterst, umbenennst oder transformst, verlierst du die Fähigkeit, sauber zu replayen, wenn sich Business-Logic ändert. Halte Bronze so raw wie möglich.

2. Silver überspringen und direkt zu Gold Es ist verlockend, Bronze direkt in Gold zu mergen für einfache Use-Cases. Das funktioniert bis dein Source-Schema sich ändert, ein Dedup-Bug auftaucht oder ein neuer Downstream-Consumer leicht andere Logik braucht. Silver ist die Versicherung.

3. Gold-Tabellen ohne Owner Gold-Tabellen akkumulieren. Nach 12 Monaten hast du oft 40 Gold-Tabellen, von denen 8 aktiv genutzt und 32 stale sind. Behandle Gold-Tabellen wie APIs — sie brauchen Owner, SLAs und Deprecation-Prozesse.

4. Eine einzelne Pipeline für alle drei Layer Bronze → Silver → Gold sollten unabhängige, schedulbare Jobs sein. Sie in einer Pipeline zu koppeln, heißt: ein Silver-Failure blockiert dein Bronze-Landing, und ein Gold-Rebuild triggert Full-Silver-Reprocessing.

5. Schema-Evolution vergessen Source-Systeme ändern ihre Schemas. Bronze soll Schema-Änderungen still absorbieren (Schema-Evolution aktiv). Silver soll validieren und auf unerwartete Spalten alerten. Gold soll bei Silver-Schema-Änderungen neu gebaut werden.

Wann Medallion Architecture NICHT einsetzen

Medallion Architecture fügt Overhead hinzu. Für manche Szenarien das falsche Tool:

Kleine oder statische Datensätze: Wenn du eine 50k-Zeilen-Referenztabelle einmal im Monat aus einer Vendor-CSV lädst, ist das Drei-Layer-Pattern Overkill. Eine einzelne bereinigte Tabelle reicht.

Reine Streaming-Pipelines: Real-time Pipelines mit Sub-Sekunden-Latenz profitieren nicht vom Batch-orientierten Bronze → Silver → Gold-Rhythmus. Nutze Kafka + Flink oder Spark Structured Streaming mit einfacherem Schema.

Proof-of-Concept-Arbeit: Verbring nicht zwei Wochen mit Medallion-Infra, um eine einmalige analytische Frage zu beantworten. Nutze es, wenn die Pipeline production-grade sein und vom Team gewartet werden muss.

Single-Source, Single-Consumer-Pipelines: Wenn eine Source einen Consumer bedient ohne Wiederverwendung, fügt Bronze-Silver-Gold Layer hinzu, ohne Wert hinzuzufügen.

FAQ

Lohnt sich Medallion für ein 2-Personen-Daten-Team? Bronze und Silver: ja, fast immer. Gold: nur wenn du klare Consumer mit SLAs hast.

Delta Lake oder Apache Iceberg? Delta Lake, wenn du in Databricks bist. Iceberg, wenn du Multi-Engine willst (Spark + Trino + Flink). Beide funktionieren mit Medallion.

Wie unterscheidet sich Medallion von Data Vault? Medallion ist ein Pipeline-Pattern. Data Vault ist eine Modellierungs-Methodologie. Sie können kombiniert werden: Data Vault im Silver-Layer, Star-Schema in Gold.

Was, wenn meine Source nicht append-only ist? Du brauchst trotzdem CDC oder Snapshots. Mit Delta Lake/Iceberg im Bronze kannst du auch Updates atomar einfangen.

Fazit

Medallion Architecture ist der richtige Default für Production-Lakehouses mit mehreren Quellen, mehreren Consumern und einem Team, das klare Owner-Grenzen braucht. Bronze gibt dir Durability und Replayability. Silver gibt dir die Single Version of Truth. Gold gibt dir Performance und Consumer-spezifische Optimierung.

Starte mit Bronze und Silver zuerst — bring eine Domain (z. B. Orders oder Customers) end-to-end zum Funktionieren, bevor du Gold-Aggregate hinzufügst. Bau Gold-Tabellen nur, wenn du einen spezifischen Consumer mit klarem SLA hast. Lass das Pattern mit deiner Daten-Komplexität wachsen, nicht voraus.

Stand: 14. Mai 2026.