← Learning Hub Referenz Databricks-Latenzstufen Gegen die Doku geprüft: Aug–Sep 2026

Latenzstufen & Echtzeit-Eignung

Kurzreferenz für die Entscheidung, wie frisch eine Databricks-Pipeline sein muss, was das kostet und wann du die Workload besser ganz aus dem Lakehouse heraushältst.

1. Die Tabelle der Latenzstufen

Stufe	Latenz	Umsetzung mit	Compute-Profil	Einsetzen, wenn
Inkrementell / getriggert	Minuten	Serverless Job + `Trigger.AvailableNow()` oder getriggerte Lakeflow-Pipeline	Startet in Sekunden, arbeitet den Rückstand ab, beendet sich	Medaillon-ETL, geplante Prognosen, Outputs mit Marktfristen
Continuous	Sekunden	Lakeflow-Pipeline im Continuous-Modus	Dauerhaft laufender Cluster	Live-Monitoring, Bilanzkreis-Sichten, Frische unterhalb einer Minute
Real-Time-Modus	~300 ms typisch, <1 s im Tail, 5 ms Untergrenze	`.trigger(realTime='5 minutes')`	Dedizierte Compute, alle Stufen gleichzeitig eingeplant	Betrugserkennung, operatives Alerting, sofortige automatisierte Aktion

Quellen: Real-time mode concepts, Triggered vs. continuous pipeline mode, Streaming on serverless compute.

Die Nahtstelle bei „ein paar Minuten“

Die Doku verortet den getriggerten Modus bei „alle 10 Minuten, stündlich oder täglich“ und Continuous bei „alle 10 Sekunden bis wenige Minuten“. Ein 5-Minuten-Takt liegt genau auf der Grenze — entscheide über einen Benchmark der Tageskosten mit deinem realen Volumen, nicht durch noch intensiveres Lesen der Doku.

2. Trigger-Syntax

# Getriggert / inkrementell — am günstigsten, Frische im Minutenbereich
(df.writeStream
   .trigger(availableNow=True)
   .option("checkpointLocation", checkpoint_path)
   .toTable("catalog.schema.target"))

# Zeitbasierter Micro-Batch — nur Classic Compute, NICHT Serverless
.trigger(processingTime="5 minutes")

# Real-Time-Modus — im Sub-Sekunden-Bereich, dedizierte Compute
.trigger(realTime="5 minutes")   # Argument = Batch-Länge, nicht Latenz

# Seit DBR 11.3 veraltet — auf availableNow migrieren
.trigger(once=True)

⚠ Trigger-Einschränkungen bei Serverless

Unterstützt: Trigger.AvailableNow() (empfohlen), Trigger.Once() (veraltet).
Nicht unterstützt: Trigger.ProcessingTime(interval), Trigger.Continuous(interval).
Kein expliziter Trigger → die Query scheitert mit INFINITE_STREAMING_TRIGGER_NOT_SUPPORTED (Spark fällt auf ProcessingTime("0 seconds") zurück).
Dauerhaft laufender Stream auf Serverless → nutze eine Lakeflow-Pipeline im Continuous-Modus.
Laufzeitobergrenze bei Serverless: 7 Tage. Längere Läufe werden beendet und nicht erneut gestartet.

3. Produktionsregeln für Streaming-Jobs

Regel	Warum
Niemals All-Purpose-Compute für Streaming verwenden	Nutze Jobs Compute; beim Retry werden neue Ressourcen bereitgestellt
Niemals klassisches Autoscaling für einen Streaming-Job aktivieren	Das Herunterskalieren ist unzuverlässig; nutze das Enhanced Autoscaling von Lakeflow
Ein Checkpoint-Verzeichnis pro Query, im Cloud-Storage	Wiederverwendete Checkpoints beschädigen die Fortschrittsverfolgung
Lakeflow-Pipelines gegenüber selbstgebautem Streaming bevorzugen	Ausdrückliche Empfehlung von Databricks für neue Pipelines
Die Logik in `foreachBatch` idempotent gestalten	`foreachBatch` garantiert At-least-once, nicht Exactly-once
Den Trigger niemals ungesetzt lassen	Standard ist ein Polling von 0 ms → ausufernde API-Kosten im Cloud-Storage
In einem Job kein `awaitTermination()` aufrufen	Blockiert den Jobs-Service beim Verfolgen der Query
Jobs so konfigurieren, dass sie bei Fehlern automatisch neu starten	Der Continuous-Job-Trigger wiederholt mit exponentiellem Backoff

Quelle: Production considerations for Structured Streaming.

4. Hebel, wenn es schneller sein muss (nach Kosten sortiert)

Die schnelle Spur verkleinern. Alles, was nicht von frischen Daten abhängt, auf einen langsameren Takt verschieben. Kostenlos.
Output-Modus update statt append, wo unterstützt; niemals complete. Setzt einen idempotenten Sink voraus.
Das Watermark verkürzen. Weniger State, geringere Latenz — um den Preis verworfener später Datensätze. Starte bei etwa dem Doppelten deines Latenz-SLA.
Storage-Zwischenschritte entfernen. Logik über mehrere Jobs zu verteilen kostet jedes Mal einen Roundtrip zum Object Storage.
RocksDB State Store + Changelog-Checkpointing für zustandsbehaftete Queries; asynchrones State-Checkpointing, wenn das Checkpointing die Batch-Dauer dominiert.
Asynchrones Progress Tracking für kontinuierliche Streams (nicht kombinierbar mit AvailableNow/Once).
Quelle und Sink mit niedriger Latenz. Kafka / Kinesis / Pub-Sub / Delta CDF hinein, Message Bus oder operative DB hinaus.
Real-Time-Modus. Letztes Mittel. Dedizierte Compute, seltener Checkpoints, längeres Replay im Fehlerfall.

5. Der Test auf „gehört nicht hierher“

Halte es aus dem Lakehouse heraus, wenn …

Eine Maschine auf den Output reagiert, ohne dass ein Mensch oder ein Marktschritt dazwischenliegt.
Es sich um Sicherheits-, Schutz- oder Regelungslogik handelt (Auslösung, Abregelungsbefehl, Sollwert).
Es ein Industrieprotokoll terminiert (OPC UA, IEC 60870-5-104, Modbus).
Es eine Antwort pro Anfrage unter ~50 ms braucht.
Es einen Socket offen hält, auf einem Port lauscht oder HTTP beantwortet — das ist eine Anwendung, keine Pipeline.

6. Dimensionierungs-Heuristiken für die Energiedomäne

Signal	Typischer Takt	Spur
NWP-Lauf (ICON, ECMWF, GFS)	1–6 Stunden	Langsam
SCADA-Telemetrie	1–10 Minuten	Schnell
Zähler- / Abrechnungsdaten	15 Min. – täglich	Langsam
Intraday-Marktpreise	Kontinuierlich, von der Gate Closure (Handelsschluss) getrieben	Schnell
Modell-Neutraining	Täglich – wöchentlich	Langsam

Regel: Die schnelle Spur berechnet nur das neu, was frische Telemetrie verändern kann — gemessene Einspeisung, Verfügbarkeit, Abregelungszustand und eine Bias-/Persistenzkorrektur mit kurzem Horizont. Alles andere fährt auf der langsamen Spur.

← Lektion 12: Databricks für 5-Minuten-SCADA Architektur-Spickzettel →

Rechtliches: Impressum