Delta Live Tables vs Classic ETL: Welcher Ansatz passt zu deiner Pipeline?

Du hast Classic-ETL-Pipelines gebaut. PySpark-Jobs, Airflow-DAGs, explizite MERGE-Statements. Funktioniert. Dann erwähnt jemand im Team Delta Live Tables und du fragst dich, ob das wirklich besser ist oder nur neue Syntax über dieselbe Komplexität. Die Antwort: DLT löst spezifische Probleme sehr gut und führt andere Probleme ein. Hier ist, wie du den Trade-off zwischen Delta Live Tables und Classic ETL bewertest — ohne Hype.

TL;DR

• DLT gewinnt bei: eingebauter Data-Quality-Enforcement, vereintem Batch+Streaming, Out-of-the-Box-Observability.
• Classic ETL gewinnt bei: Debugging, Unit-Testing, Plattform-Portabilität und maximaler Flexibilität.
• DBU-Aufschlag für DLT: 0,2× (Core) bis 0,36× (Advanced) on top der Compute-Kosten.
• Faustregel: Databricks-native, Streaming + Quality-Requirements → DLT. Cross-Platform, schwierige Tests, Custom-Checkpointing → Classic ETL.

Was beide Ansätze wirklich sind

Classic ETL ist expliziter Pipeline-Code: du schreibst PySpark- (oder SQL-) Transformationen, verdrahtest sie mit einem Orchestrator (Airflow, Prefect, Databricks Workflows), managst Dependencies manuell und implementierst dein eigenes Error-Handling und deine Quality-Checks.

Delta Live Tables (DLT) ist Databricks' deklaratives ETL-Framework. Du definierst, was Tabellen enthalten sollen, nicht wie sie gebaut werden. DLT übernimmt Dependency-Resolution, Pipeline-Execution-Order, Quality-Enforcement und Retry-Logik. Es ist by Design opinionated.

Der fundamentale Unterschied: Classic ETL ist imperativ (du kontrollierst Execution), DLT ist deklarativ (du deklarierst Expectations, DLT übernimmt Execution).

Feature-Vergleich

DLT-Preise

Stand: März 2026. DLT addiert einen Aufschlag auf Standard-Databricks-DBU-Kosten. Aktuell bei databricks.com/product/pricing.

DLT-Kosten sind additiv zu deinem zugrundeliegenden Cluster-Compute. Ein mittelgroßer Cluster mit DLT-Pro-Pipelines läuft messbar teurer als ein vergleichbarer Classic-Job — modelliere das, bevor du committest, besonders bei High-Frequency-Streaming-Pipelines.

DLT in der Praxis: die Expectations-Syntax

Das spannendste Feature von DLT sind Data-Quality-Expectations. Statt Custom-Assertion-Code zu schreiben, deklarierst du Quality-Regeln, die DLT zur Runtime enforced.

# Python — Delta Live Tables with expectations
# Databricks Runtime with Delta Live Tables

import dlt
from pyspark.sql import functions as F

# Bronze layer: raw ingestion (DLT handles scheduling and incrementalism)
@dlt.table(
    name="bronze_orders",
    comment="Raw order events from the source API — no transformations applied",
    table_properties={"quality": "bronze"}
)
def bronze_orders():
    return (
        spark.readStream
        .format("cloudFiles")          # Auto Loader — handles new file detection
        .option("cloudFiles.format", "json")
        .option("cloudFiles.schemaLocation", "/mnt/datalake/schemas/orders")
        .load("/mnt/datalake/landing/orders/")
    )


# Silver layer: cleaned orders with quality expectations
@dlt.table(
    name="silver_orders",
    comment="Cleaned and validated orders — enforced quality contract",
    table_properties={"quality": "silver"}
)
# expect: record the violation, but keep the row (for monitoring)
@dlt.expect("positive_amount", "amount > 0")

# expect_or_fail: halt the pipeline if ANY row violates this rule
@dlt.expect_or_fail("non_null_order_id", "order_id IS NOT NULL")

# expect_or_drop: silently remove rows that violate this rule
@dlt.expect_or_drop("valid_status", "status IN ('pending', 'shipped', 'delivered', 'cancelled')")

def silver_orders():
    return (
        dlt.read_stream("bronze_orders")
        .select(
            F.col("order_id").cast("string"),
            F.col("customer_id").cast("string"),
            F.col("amount").cast("double"),
            F.col("status").cast("string"),
            F.to_timestamp(F.col("order_date"), "yyyy-MM-dd'T'HH:mm:ss").alias("order_date")
        )
    )


# Gold layer: daily revenue aggregation (batch, reads from Silver)
@dlt.table(
    name="gold_daily_revenue",
    comment="Daily revenue aggregated from silver_orders — rebuilt daily"
)
def gold_daily_revenue():
    return (
        dlt.read("silver_orders")
        .groupBy(F.date_trunc("day", F.col("order_date")).alias("date"))
        .agg(
            F.sum("amount").alias("total_revenue"),
            F.count("*").alias("order_count")
        )
        .orderBy("date")
    )

Die drei Expectation-Modi sind der DLT-Kern-Differentiator:

• @dlt.expect — logged den Violation im Pipeline-Event-Log, behält die Zeile.
• @dlt.expect_or_fail — stoppt die Pipeline bei jedem Violation (gut für kritische Keys).
• @dlt.expect_or_drop — quarantänisiert invalide Zeilen leise (gut für optionale Felder).

In Classic ETL würdest du alle drei Modi als Custom-Code implementieren — typisch 30–50 Zeilen Assertion-Logik, Custom-Exception-Handling und Logging-Setup. DLT macht das in einem Decorator.

Ehrliche Trade-offs

Wo DLT echt gewinnt

Data-Quality-Enforcement ist legitim besser. Das Expectations-System deckt den 80-Prozent-Case mit Null Boilerplate. Das Pipeline-Event-Log captured jeden Expectation-Violation row-level — das haben die meisten Classic-ETL-Pipelines nur, wenn jemand signifikanten Engineering-Aufwand investiert hat.

Streaming + Batch in einem Framework. DLT abstrahiert, ob eine Tabelle Streaming oder Batch ist — du switchst durch dlt.read zu dlt.read_stream ohne Pipeline-Restructure. Classic ETL hält die als fundamental unterschiedliche Code-Pfade.

Observability out of the Box. Der DLT-Pipeline-Graph zeigt Data-Flow, Lineage und Quality-Metriken ohne Setup. Classic-Pipelines brauchen Assembly aus Airflow-/Workflows-Logs, Custom-Dashboards und Great Expectations.

Wo Classic ETL gewinnt

Debugging. DLT-Pipelines sind isoliert schwer zu debuggen. Du kannst nicht einfach eine einzelne Table-Definition außerhalb des Pipeline-Kontexts laufen lassen. In Classic ETL läufst du den Spark-Job direkt im Notebook und inspizierst Intermediate-DataFrames.

Testing. Unit-Testing von DLT-Code ist ein aktiver Pain Point. Das DLT-Unit-Test-Framework entwickelt sich. Classic-PySpark-Code ist mit Standard-pytest und databricks-connect testbar.

Flexibilität. DLT ist auf die DLT-API-Surface beschränkt. Wenn du Custom-Checkpoint-Logik, komplexes Conditional-Branching oder Integration mit Non-Databricks-Systemen brauchst, stößt du schnell an Framework-Grenzen. Classic ETL hat diese Decke nicht.

Portabilität. DLT ist Databricks-only. Classic-PySpark läuft auf jedem Spark-Cluster — EMR, GCP-Dataproc, Self-Hosted-Cluster. Wenn Cross-Cloud-Portabilität zählt, ist DLT ein Lock-in-Risiko.

Wann welcher Ansatz

DLT wählen, wenn:

• Du Streaming-Pipelines auf Databricks baust und Batch/Streaming vereint willst.
• Data-Quality-Enforcement Core-Requirement ist und du es ohne DIY-Boilerplate willst.
• Die Pipeline einer klaren Bronze → Silver → Gold-Pattern mit definierten Expectations folgt.
• Dein Team Databricks-fokussiert ist und operative Einfachheit über Flexibilität geht.
• Du den Databricks-Cost-Premium akzeptierst.

Classic ETL wählen, wenn:

• Du Plattform-Portabilität brauchst (vielleicht weg von Databricks oder Multi-Cloud).
• Debugging und Unit-Testing isoliert Priorität sind.
• Die Pipeline-Logik komplex genug ist für volle programmatische Kontrolle.
• Du existierende Airflow-Infrastruktur und Team-Expertise hast.
• Die Pipeline Non-Databricks-Systeme oder Custom-Checkpointing involviert.

FAQ

Lohnt sich DLT bei kleinen Pipelines?

Selten. Bei <10 Tabellen ohne Streaming-Anforderung ist der DBU-Aufschlag und die reduzierte Debug-Flexibilität meist nicht den Komfortgewinn wert. DLT zahlt sich aus bei mittelgroßen bis großen Pipelines (>20 Tabellen) mit klarer Medallion-Struktur.

Kann ich von Classic ETL auf DLT migrieren?

Ja, aber rechne 2–6 Wochen für mittelgroße Pipelines. Migration-Path: Schreibe DLT-Tables parallel, validiere Output-Gleichheit, schalte um. Erstaunlich oft scheitert die Migration nicht am Code, sondern an der Test-Coverage — die nimm dir vorher vor.

Wie steht DLT zu Apache Iceberg?

DLT ist Delta-Lake-only. Wenn dein Team auf Iceberg standardisiert (oder darüber nachdenkt wegen Lock-in-Reduktion), ist DLT der falsche Pfad. Classic-PySpark mit Iceberg-Catalog ist hier die portable Wahl.

Was ist mit DLT Serverless?

Seit Mitte 2024 GA. Eliminiert Cluster-Management-Overhead und kann bei variablen Workloads günstiger sein. Wenn du DLT bewertest, rechne unbedingt Serverless mit — die Pricing-Mathematik verschiebt sich spürbar.

Fazit

DLT ist kein universeller Upgrade über Classic ETL — es ist ein anderes Set von Trade-offs. Wenn dein Team Databricks-nativ ist, Streaming-Lakehouses mit Data-Quality-Anforderungen baut und reduzierte Debug-Flexibilität akzeptiert, ist DLT genuin die richtige Wahl. Wenn du Portabilität, Testability oder Pipeline-Komplexität jenseits der DLT-API-Surface brauchst, bleibt Classic ETL mit Airflow die praktischere Option.

Die Expectations-Syntax und die Streaming-Unifikation sind DLTs echte Argumente. Bewerte sie gegen deine echten Pipeline-Bedürfnisse, nicht gegen das abstrakte Versprechen von „weniger Code".

Weiterlesen

• Medallion Architecture Explained
• Databricks vs Snowflake vs BigQuery (2026)
• Excel to SQL Migration Guide

Stand: März 2026. Databricks ändert DLT-Pricing und API-Surface regelmäßig — verifiziere kritische Annahmen direkt in der Doku.