Databricks Streaming Tables: DLT vs Structured Streaming im Vergleich

Die meisten Databricks-Teams starten mit rohem Structured Streaming — spark.readStream, writeStream, Checkpoints. Funktioniert. Dann kommt Delta Live Tables dazu und plötzlich gibt es zwei Wege, dieselbe Sache zu bauen. Wer früh versteht, wann welches Tool das richtige ist, erspart sich schmerzhafte Rewrites mitten im Projekt.

TL;DR

• DLT Streaming Tables sind das richtige Default für neue Medallion-Pipelines — automatische Checkpoints, Data-Quality-Expectations, eingebaute Lineage.
• Raw Structured Streaming bleibt richtig, wenn du komplexe Stateful-Logik, Custom-Sinks (Cassandra, Elasticsearch) oder maximale Kostenkontrolle brauchst.
• DBU-Aufschlag bei DLT: Core +0,2×, Pro +0,25×, Advanced +0,3× — kann bei High-Volume-Pipelines spürbar sein.
• Beide nutzen Structured Streaming unter der Haube — DLT ist eine deklarative Abstraktion, kein eigener Streaming-Stack.

Zwei Wege, Streaming-Pipelines zu bauen

Databricks bietet dir zwei First-Class-Optionen für Streaming:

1. Structured Streaming — die zugrunde liegende Spark-API, volle Kontrolle, maximale Flexibilität.
2. DLT Streaming Tables — eine deklarative Abstraktion auf Structured Streaming, opinionated und managed.

Die beiden schließen sich nicht aus — DLT Streaming Tables sind Structured Streaming unter der Haube. Die Frage ist nur, wie viel Plumbing du selbst besitzen willst.

Structured Streaming: volle Kontrolle

Structured Streaming verarbeitet Daten als kontinuierliche Folge von Micro-Batches. Du definierst Source, Transformation und Sink. Databricks kümmert sich um die Ausführung.

# PySpark — Basic Structured Streaming pipeline
from pyspark.sql.functions import col, from_json, schema_of_json

# Read from Event Hub (Kafka protocol)
raw = (
    spark.readStream
    .format("kafka")
    .option("kafka.bootstrap.servers", "eh-namespace.servicebus.windows.net:9093")
    .option("subscribe", "sensor-events")
    .option("startingOffsets", "latest")
    .load()
)

# Parse JSON payload
parsed = (
    raw
    .selectExpr("CAST(value AS STRING) as json_payload", "timestamp as kafka_ts")
    .withColumn("data", from_json(col("json_payload"), "sensor_id STRING, temp DOUBLE, ts LONG"))
    .select("kafka_ts", "data.*")
)

# Write to Delta
(
    parsed.writeStream
    .format("delta")
    .outputMode("append")
    .option("checkpointLocation", "/mnt/checkpoints/sensors_bronze")
    .trigger(processingTime="30 seconds")
    .table("bronze.sensor_events")
)

Du besitzt den Checkpoint, das Trigger-Intervall, die Retry-Logik und das Monitoring. Maximale Kontrolle, maximale Verantwortung.

DLT Streaming Tables: deklarative Pipelines

Delta Live Tables führt eine deklarative SQL- oder Python-API ein, in der du definierst, was du willst — nicht wie es laufen soll. DLT verwaltet Ausführung, Retries, Schema-Enforcement und Data Quality.

# Python DLT — Streaming Table definition
import dlt
from pyspark.sql.functions import col, from_json

@dlt.table(
    name="sensor_events_bronze",
    comment="Raw sensor events from Event Hub",
    table_properties={"quality": "bronze"}
)
def sensor_events_bronze():
    return (
        spark.readStream
        .format("kafka")
        .option("kafka.bootstrap.servers", "eh-namespace.servicebus.windows.net:9093")
        .option("subscribe", "sensor-events")
        .option("startingOffsets", "latest")
        .load()
        .selectExpr("CAST(value AS STRING) as raw_payload", "timestamp as kafka_ts")
    )

@dlt.table(name="sensor_events_silver")
@dlt.expect_or_drop("valid_temp", "temp BETWEEN -50 AND 150")
def sensor_events_silver():
    return (
        dlt.read_stream("sensor_events_bronze")
        .withColumn("data", from_json(col("raw_payload"), "sensor_id STRING, temp DOUBLE"))
        .select("kafka_ts", "data.sensor_id", "data.temp")
    )

DLT übernimmt die Checkpoints automatisch. Der Decorator @dlt.expect_or_drop erzwingt Data Quality — Zeilen, die die Expectation verletzen, werden gedroppt (oder in Quarantine geschickt, je nach Annotation). Kein Checkpoint-Management, kein manuelles Recovery.

Streaming Tables in SQL

DLT unterstützt auch SQL-first Streaming Tables, seit Ende 2024 GA:

-- DLT SQL — Streaming Table
CREATE OR REFRESH STREAMING TABLE sensor_events_silver
COMMENT 'Validated sensor readings'
AS SELECT
    kafka_ts,
    raw_payload:sensor_id::STRING AS sensor_id,
    raw_payload:temp::DOUBLE AS temp
FROM STREAM(LIVE.sensor_events_bronze)
WHERE raw_payload:temp::DOUBLE BETWEEN -50 AND 150;

Der STREAM()-Wrapper sagt DLT, dass das ein Streaming-Read ist. Das LIVE.-Prefix referenziert eine andere DLT-Tabelle in derselben Pipeline.

Direkter Vergleich

DLT-DBU-Aufschlag: die echten Kosten

DLT-Pipelines laufen auf Core-, Pro- oder Advanced-Tier — jeweils mit DBU-Multiplikator on top der Standard-Databricks-Kosten:

(Stand: April 2026 — Pricing kann sich ändern, verifiziere bei Databricks.)

Für kostensensitive Pipelines mit einfachen Transformationen kann rohes Structured Streaming auf einem Standard-Job-Cluster deutlich günstiger sein. Rechne die Zahlen durch, bevor du dich für DLT bei High-Volume- und Always-On-Pipelines committest.

Stateful Streaming: Watermarks und Windows

Beide Ansätze unterstützen Stateful-Aggregationen — aber du musst explizit Watermarks setzen, sonst wächst dein State Store unbegrenzt.

# PySpark — Windowed aggregation with watermark
from pyspark.sql.functions import window, avg

aggregated = (
    parsed
    .withWatermark("event_time", "10 minutes")   # tolerate 10-min late data
    .groupBy(
        window(col("event_time"), "5 minutes"),  # 5-min tumbling window
        col("sensor_id")
    )
    .agg(avg("temp").alias("avg_temp"))
)

In DLT werden Stateful-Aggregationen unterstützt, brauchen aber mehr Sorgfalt — nutze dlt.read_stream() mit expliziten Watermarks und vermeide unbegrenzten State durch klare Windows.

Häufige Fallstricke

1. Fehlende Watermarks bei Stateful-Aggregationen Ohne Watermark hält Spark den State für immer. Memory-Druck und irgendwann OOM-Errors sind die Folge.

2. Falsches Trigger-Intervall trigger(once=True) verarbeitet alle verfügbaren Daten und stoppt — das ist ein Micro-Batch-Job, kein kontinuierliches Streaming. Nutze trigger(availableNow=True) als modernes Äquivalent in Databricks Runtime 11.3+.

3. DLT für einmalige Batch-Loads DLT hat Startup-Overhead. Für einfache One-Time-Ingestion ist ein normaler Notebook-Job schneller und günstiger.

4. Checkpoints zwischen Runs teilen Verwende nie ein Checkpoint-Directory für eine andere Stream-Definition wieder. Der Checkpoint encodiert den Query-Plan — Mismatches führen zu Failures oder stillem Data Loss.

5. _rescued_data von Autoloader-Sources ignorieren Wenn du Databricks Autoloader in eine DLT-Pipeline fütterst, stell sicher, dass deine Silver-Tabelle die Spalte _rescued_data explizit behandelt.

Wann welcher Ansatz

DLT Streaming Tables, wenn:

• Du eine Medallion-Architektur mit mehreren Hops baust.
• Data-Quality-Expectations First-Class-Requirements sind.
• Dein Team SQL-first arbeitet.
• Du eingebaute Lineage und Pipeline-Observability willst.
• Du DLT bereits für Batch-Tables nutzt.

Raw Structured Streaming, wenn:

• Du komplexe Stateful-Logik brauchst (custom flatMapGroupsWithState).
• Kosten der primäre Constraint sind und der DLT-DBU-Aufschlag wehtut.
• Du Non-Delta-Sinks brauchst (Cassandra, Elasticsearch, Custom).
• Du in eine bestehende Airflow- oder Databricks-Workflows-Orchestrierung integrierst.

FAQ

Sind DLT Streaming Tables teurer als rohes Structured Streaming?

Ja — DLT addiert einen DBU-Multiplikator (0,2×–0,3× je nach Tier). Bei einer 24/7-Pipeline mit großem Cluster macht das auf Monatssicht echte Beträge aus. Bei kleinen oder triggered Pipelines ist der Unterschied marginal — und du sparst die Engineering-Stunden für Checkpoint-Management.

Kann ich DLT- und Structured-Streaming-Code mischen?

Ja, in derselben Architektur, aber nicht in derselben Pipeline. Viele Production-Setups nutzen rohes Structured Streaming für High-Volume-Event-Ingestion am Edge und DLT für die Bronze-to-Gold-Transformation.

Was passiert mit meinem Checkpoint, wenn ich eine DLT-Pipeline neu erstelle?

DLT verwaltet Checkpoints intern und an die Pipeline-ID gebunden. Wenn du die Pipeline löschst und neu erstellst, startet die Verarbeitung vom konfigurierten startingOffsets neu — was bei latest zu Datenverlust führen kann. Für Production-Migrationen nutze immer startingOffsets: "earliest" oder verwalte die Offsets manuell außerhalb von DLT.

Funktioniert DLT mit Kafka direkt oder nur mit Event Hubs?

Beides. DLT unterstützt jede Spark-Source — Kafka, Event Hubs (Kafka-Protokoll), Kinesis, Pub/Sub, Auto Loader auf Cloud-Storage. Der Code in den Beispielen oben funktioniert mit beliebigen Kafka-kompatiblen Brokern, inklusive Confluent Cloud, MSK und Self-Hosted-Kafka.

Fazit

DLT Streaming Tables sind das richtige Default für neue Medallion-Pipelines — sie nehmen dir operativen Overhead ab und addieren Data-Quality-Enforcement. Raw Structured Streaming bleibt die richtige Wahl, wenn du volle Kontrolle über Stateful-Logik, Custom-Sinks oder maximale Kostenkontrolle brauchst.

Die beiden Ansätze sind keine Rivalen — viele Production-Architekturen nutzen rohes Structured Streaming für High-Volume-Event-Ingestion am Edge und DLT für die Bronze-to-Gold-Transformation.

Weiterlesen

• Databricks Autoloader Guide
• Medallion Architecture with DLT
• Delta Table Optimization Guide

Stand: Mai 2026. Databricks ändert Preise und Features regelmäßig — verifiziere kritische Annahmen direkt bei Databricks.