Streaming auf Databricks: Wann es lohnt und welcher Pfad passt
Die Kernaussagen auf einen Blick.
- Streaming ist auf Databricks vor allem eine Architekturentscheidung: Je kürzer die gewünschte Aktualität, desto stärker steigen Compute-Kosten, Betrieb und Monitoring-Aufwand.
- Viele Anforderungen, die als „Echtzeit" beschrieben werden, lassen sich günstiger über Near-Real-Time oder inkrementellen Batch lösen.
- Für Standard-Ingest ist Lakeflow Declarative Pipelines meist einfacher zu betreiben als selbst gebautes Structured Streaming.
- Empfehlenswert ist, zuerst Latenzbedarf und Kostenrahmen festzulegen und dann den Pfad zu wählen: im Zweifel Near-Real-Time über den deklarativen Pfad, echte Real-Time nur bei belegtem Sub-Sekunden-Bedarf.
Inhaltsverzeichnis
Echtzeit ist die teuerste Antwort
Ein Fachbereich fordert „Echtzeit-Daten". Das Data-Team baut den ersten Structured-Streaming-Job, die Pipeline läuft, und ein paar Wochen später fällt in der Kostenübersicht auf, dass ein Cluster jetzt rund um die Uhr läuft und nie mehr abschaltet. Auf Nachfrage im nächsten Steering stellt sich heraus: Der Fachbereich braucht die Daten alle paar Minuten. „Echtzeit" war das Wort, gemeint war ein Aktualitätsstand von wenigen Minuten.
Dieses Muster wiederholt sich in fast jeder wachsenden Datenplattform. „Echtzeit" ist ein Wunsch ohne Einheit. Solange niemand den Latenz-SLA in Sekunden oder Minuten festschreibt, wird die teuerste Variante gebaut, weil sie sich am sichersten anfühlt.
Vor dem Bau einer Streaming-Strecke lohnen sich ein paar nüchterne Fragen:
- Wie schnell muss diese Zahl wirklich aktuell sein, damit die Entscheidung dahinter besser wird?
- Was passiert konkret, wenn die Daten fünf Minuten alt sind statt fünf Sekunden?
- Und wer bezahlt am Ende ein Cluster, das nie abschaltet?
- Ist der Weg Structured Streaming von Hand oder ein deklarativer Pfad, und wer betreibt das in zwei Jahren?
Streaming auf Databricks ist damit eine Architektur- und Kostenentscheidung. Die erste Frage gilt deshalb dem Latenzbedarf, den der Use Case belegen kann, und den Kosten der dazu passenden Stufe. Dass die Plattform Echtzeit beherrscht, steht dabei außer Frage.
Was ist Data Streaming auf Databricks?
Data Streaming beschreibt die kontinuierliche Verarbeitung von Daten, während sie eintreffen. Es wird also nicht erst gewartet, bis ein vollständiger Datenbestand für den nächsten geplanten Lauf bereitsteht.
Auf Databricks übernimmt diese Aufgabe Structured Streaming. Der wichtige Punkt: Structured Streaming nutzt dieselbe DataFrame- und SQL-Logik wie Batch-Verarbeitung. Eine Pipeline kann deshalb häufig von einem täglichen Lauf auf kontinuierliche Verarbeitung umgestellt werden, ohne die fachliche Verarbeitungslogik komplett neu zu bauen. Databricks beschreibt Structured Streaming als einheitliche Engine für Batch- und Stream-Verarbeitung über dieselben DataFrame-APIs.
Für den Betrieb ist das entscheidend. Statt zwei getrennte Stacks zu pflegen, einen für Batch und einen für Streaming, läuft alles über eine Engine, eine Codebasis und ein ähnliches Betriebsmodell. Das reduziert den Aufwand und senkt die Zahl der Stellen, an denen Fehler entstehen können.
Data Streaming ist aber nicht automatisch die richtige Antwort auf jeden „Live"-Use Case. Kontinuierliche Verarbeitung und schnelle Abfragen sind zwei unterschiedliche Themen. Nur weil Daten aktuell wirken sollen, muss nicht immer ein Streaming-Job laufen. Oft reicht auch ein inkrementeller Batch mit kurzen Intervallen.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Wann kontinuierliche Verarbeitung wirklich nötig ist
Die erste wichtige Entscheidung ist nicht das Streaming-Werkzeug, sondern die Frage, ob Daten wirklich dauerhaft verarbeitet werden müssen. In vielen Fällen reicht inkrementeller Batch: Es wird nur verarbeitet, was seit dem letzten Lauf neu dazugekommen ist. Der Job läuft in kurzen Intervallen und die Compute-Umgebung schaltet danach wieder ab.
Für solche Fälle ist Trigger.AvailableNow oft der passende Modus. Er verarbeitet alle neuen Daten, die bis zum Start des Laufs eingetroffen sind, und beendet den Job danach automatisch. Microsoft Learn beschreibt diesen Modus als empfohlenen Weg für geplante, inkrementelle Near-Real-Time-Pipelines.
Für viele analytische Lakehouse-Workloads ist das sinnvoller als ein dauerhaft laufender Stream. Die Verarbeitung bleibt zuverlässig und wiederholbar, aber Compute wird nur verbraucht, wenn tatsächlich Daten verarbeitet werden.
Die Entscheidung lässt sich an drei Fragen festmachen:
Wie frisch müssen die Daten wirklich sein? Wenn ein Report alle paar Minuten oder stündlich reicht, braucht es meist keinen Dauer-Stream.
Rechtfertigt der Nutzen dauerhaft laufenden Compute? Ein kontinuierlicher Stream verursacht auch dann Kosten, wenn gerade wenig passiert.
Kann das Team den Betrieb sicher tragen? Streaming braucht saubere Checkpoints, Wiederanlauf, Monitoring und Umgang mit Zustand. Wenn diese Betriebsreife noch fehlt, ist ein geplanter inkrementeller Lauf oft der bessere Startpunkt.
Wenn keine dieser Fragen klar für kontinuierliches Streaming spricht, ist inkrementeller Batch meist der robustere und günstigere Ausgangspunkt.
Welche Latenz der Use Case braucht
Der Begriff „Echtzeit" verdeckt drei Latenzbänder mit sehr unterschiedlichen Kosten. Die meisten Anforderungen, die im Steering als „Echtzeit" formuliert werden, sind Near-Real-Time im Sekunden- bis Minutenbereich.
| Latenzband | Typischer Use Case | Databricks-Baustein | Kostencharakter |
|---|---|---|---|
| Echte Real-Time (unter einer Sekunde, bis in den Millisekunden-Bereich) | Betrugsabwehr, dynamische Preise, Live-Anomalie-Alarme | Real-Time Mode in Structured Streaming | Dauer-Compute rund um die Uhr, teuerste Stufe |
| Near-Real-Time (Sekunden bis Minuten) | Operative Dashboards, Monitoring, Personalisierung | Structured Streaming (Micro-Batch) oder Lakeflow Declarative Pipelines | Compute während der Verarbeitung, mittlere Stufe |
| Inkrementeller Batch (Minuten bis Stunden) | Reporting, Analytik, Gold-Schicht | , geplante Jobs | Compute nur im Verarbeitungsfenster, günstigste Stufe |
Die Konsequenz für die Architektur: Jede Stufe nach oben kostet mehr Compute und mehr Betrieb. Liegt die Latenz eine Stufe höher als der Use Case verlangt, entstehen Dauerkosten für einen Nutzen, den niemand abgefragt hat.
Eine Engine für Batch und Stream
Der Vorteil der einheitlichen Engine zeigt sich besonders bei der Umstellung von Batch auf Streaming. Eine Pipeline, die heute geplant läuft, kann über den Trigger-Modus auf kontinuierliche Verarbeitung umgestellt werden. Die Transformationslogik bleibt dabei in vielen Fällen gleich. Dieselbe Logik, die heute einmal täglich einen Stand berechnet, kann dann neue Daten fortlaufend in eine Delta-Tabelle schreiben.
Neben dem Trigger ist der Ausgabemodus wichtig. Er bestimmt, wie Ergebnisse in die Zieltabelle geschrieben werden.
- Append schreibt nur neue Zeilen und passt gut für reinen Ingest.
- Update schreibt nur geänderte Ergebnisse und eignet sich für laufende Aggregationen.
- Complete schreibt das gesamte Ergebnis neu. Das kann bei kleinen Übersichtstabellen funktionieren, wird bei wachsenden Datenmengen aber schnell teuer.
Trigger und Ausgabemodus sollten deshalb gemeinsam bewertet werden. Sie entscheiden nicht nur über die Aktualität der Daten, sondern auch über Compute-Kosten, Laufzeit und Betriebsverhalten.
Trigger.AvailableNow, Micro-Batch und Real-Time Mode im Vergleich
Der Trigger-Modus entscheidet maßgeblich darüber, wie frisch Daten verfügbar sind und wie viel Compute dafür läuft. Für den Regelbetrieb sind vor allem drei Varianten relevant.
Micro-Batch ist der Standard. Daten werden in kurzen, abgegrenzten Intervallen verarbeitet. Das passt für die meisten Streaming-Workloads, bei denen Latenz im Sekunden- oder Minutenbereich ausreicht.
Trigger.AvailableNow verarbeitet alle offenen Daten und beendet den Lauf danach. Das ist der passende Modus für inkrementellen Batch, wenn Daten regelmäßig aktualisiert werden sollen, aber kein dauerhaft laufender Stream nötig ist.
Trigger.ProcessingTime startet die Verarbeitung in festen Zeitabständen. Das liegt zwischen dauerhaftem Stream und getriggertem Lauf, ist aber je nach Compute-Variante nicht überall gleich verfügbar.
Für besonders niedrige Latenz gibt es zusätzlich den Real-Time Mode. Databricks hat ihn 2025 als Public Preview vorgestellt. Er ist für operative Szenarien gedacht, in denen wenige Millisekunden entscheidend sind, zum Beispiel Betrugsabwehr oder Live-Alarme. Für normale analytische Workloads ist das meist überdimensioniert.
Die Wahl des Triggers ist deshalb nicht nur eine technische Frage. Derselbe Job kann dauerhaft laufen oder in kurzen Intervallen starten und wieder stoppen. Der Unterschied bei Latenz, Betrieb und Compute-Kosten ist erheblich.
Kafka, Kinesis, Event Hubs, Pub/Sub und Auto Loader anbinden
Für kontinuierliche Ereignisdaten sind Message-Broker die typische Quelle, und Structured Streaming bindet die gängigen direkt als Quelle an. Apache Kafka ist der Standard für hohen Durchsatz, Amazon Kinesis wird nativ unterstützt, Azure Event Hubs bietet einen Kafka-kompatiblen Endpunkt, und Google Pub/Sub lässt sich ebenfalls direkt anbinden. In allen Fällen bleibt die Verarbeitung auf der Lakehouse-Plattform, ohne dass eine zweite Streaming-Plattform daneben betrieben werden muss.
Davon abzugrenzen ist der dateibasierte Ingest aus dem Objektspeicher. Kommen die Daten als Dateien in S3, ADLS oder GCS an, ist Auto Loader das Mittel der Wahl gegenüber dem generischen Datei-Stream. Er erkennt neue Dateien über cloud-native Benachrichtigungen, verarbeitet Milliarden von Dateien effizient und bringt Schema-Erkennung samt Schema-Entwicklung mit.
Die konkrete Ausgestaltung dieser Ingest-Bausteine hat jeweils eigene Tiefe. Für Ereignisdaten, die ohne eigenen Broker direkt in die Plattform geschrieben werden sollen, ordnen wir den managed Weg im Überblick zu Zerobus ein.
Lakeflow Declarative Pipelines vs Structured Streaming
Über Structured Streaming gibt es in Databricks einen deklarativen Weg für Streaming- und Ingest-Pipelines. Früher hieß diese Schicht Delta Live Tables, heute Lakeflow Declarative Pipelines. Der alte Name DLT taucht in vielen Projekten, Dokus und Suchanfragen weiterhin auf, meint aber denselben Produktbereich. Microsoft Learn ordnet die Umbenennung unter der Frage „Was ist mit Delta Live Tables passiert?" ein.
Der Unterschied liegt vor allem im Betriebsmodell. Bei selbst gebautem Structured Streaming müssen Checkpoints, Wiederanlauf, Abhängigkeiten und Datenqualitätslogik bewusst umgesetzt werden. Lakeflow Declarative Pipelines nimmt davon einen großen Teil ab und beschreibt die Pipeline stärker über gewünschte Zielzustände.
Dafür nutzt Lakeflow vor allem drei Bausteine:
- Streaming Tables nehmen neue Daten aus append-only Quellen auf und verwalten den Verarbeitungsstand.
- Materialized Views bilden komplexere Transformationen ab und werden bei Änderungen inkrementell aktualisiert.
- Expectations definieren Datenqualitätsregeln direkt in der Pipeline. Je nach Regel können fehlerhafte Datensätze markiert, verworfen oder die Pipeline gestoppt werden.
| Aspekt | Structured Streaming | Lakeflow Declarative Pipelines |
|---|---|---|
| Kontrolle | maximale Kontrolle über Trigger, State und Schreiblogik | stärker deklarativ, weniger Handarbeit |
| Betrieb | Checkpoints, Restart und Abhängigkeiten selbst verantworten | Orchestrierung und Wiederanlauf stärker integriert |
| Data Quality | selbst bauen | Expectations eingebaut |
| Passt gut für | Sonderfälle und sehr spezifische Logik | Standard-Ingest, Streaming Tables und Materialized Views |
Für viele Standard-Ingest-Strecken ist Lakeflow der einfachere Betriebsweg. Selbst gebautes Structured Streaming bleibt sinnvoll, wenn Trigger, Zustandshaltung oder Schreiblogik sehr individuell gesteuert werden müssen. Wie die deklarativen Pipelines im Detail aufgebaut werden, erklären wir im Überblick zu Declarative Pipelines.
Checkpoints, Zustand und Wiederanlauf im Streaming-Betrieb
Streaming wird im Betrieb vor allem dann anspruchsvoll, wenn Fehler auftreten. Ein Stream läuft dauerhaft oder sehr regelmäßig. Deshalb muss klar sein, was passiert, wenn ein Job abbricht, neu startet oder verspätete Daten eintreffen.
Wichtig ist dabei die exactly-once-Verarbeitung. Sie sorgt dafür, dass Datensätze nach einem Neustart nicht verloren gehen und nicht doppelt verarbeitet werden. Databricks erreicht das über Checkpoints des Streams und das Transaktions-Log der Delta-Tabelle. Wenn ein Job ausfällt, kann er an der letzten sicheren Stelle weitermachen.
Komplexer wird es bei Aggregationen, Zeitfenstern oder Joins zwischen Streams. Dann muss sich die Engine Zwischenergebnisse merken. Diese Zustandshaltung wird über einen State Store verwaltet. Damit dieser Zustand nicht unbegrenzt wächst, werden Watermarks genutzt. Sie legen fest, wie lange verspätete Daten noch berücksichtigt werden, bevor sie verworfen werden.
Zur Betriebssicherheit gehört außerdem Monitoring. Ein Stream kann laufen und trotzdem hinter der eingehenden Datenmenge zurückfallen. Deshalb sollten Verarbeitungszeit, Rückstand, Fehlerraten und Latenz überwacht werden. Bei Lakeflow Declarative Pipelines kommt zusätzlich das Ereignis-Log hinzu. Darüber lassen sich auch Datenqualitätsregeln und Expectations nachvollziehen.
Genau an dieser Stelle wird der deklarative Pfad attraktiv. Checkpoints, Wiederanlauf, Abhängigkeiten und Datenqualitätsereignisse müssen nicht in jeder Pipeline selbst gebaut werden. Lakeflow übernimmt einen größeren Teil dieser Betriebslogik und macht Streaming-Strecken dadurch leichter wartbar.
Was kostet Data Streaming?
Die Kostenfrage bei Streaming wird oft falsch gestellt. Inkrementelle Verarbeitung ist fast immer günstiger als eine vollständige Neuberechnung, weil nur neue Daten verarbeitet werden. Der größere Kostenhebel ist aber nicht die Datenmenge, sondern wie lange Compute läuft.
Ein dauerhaft laufender Stream hält Compute rund um die Uhr aktiv, auch wenn nur wenig oder gar keine neuen Daten eintreffen. Ein getriggerter Lauf mit Trigger.AvailableNow verarbeitet die neuen Daten, schreibt den Fortschritt sauber fort und schaltet danach wieder ab. Compute fällt dann nur während der tatsächlichen Verarbeitung an.
Genau dieser Unterschied macht in vielen Fällen den größten Teil der Kosten aus: Dauer-Compute gegen geplante, inkrementelle Läufe.
Als Faustregel gilt: Wenn Daten alle fünf, zehn oder fünfzehn Minuten aktuell sein müssen, reicht oft ein getriggerter inkrementeller Lauf. Ein dauerhaft laufender Stream oder Real-Time Mode sollte nur eingesetzt werden, wenn ein echter Sub-Sekunden-SLA dahintersteht. Alles andere erzeugt schnell laufende Compute-Kosten, ohne dass der fachliche Nutzen dazu passt.
Wann ist Data Streaming die falsche Lösung?
Nicht jeder „Live"-Use Case braucht Streaming. Entscheidend ist, ob Daten wirklich kontinuierlich verarbeitet werden müssen oder ob ein geplanter inkrementeller Lauf reicht.
Streaming ist meist nicht die richtige Wahl, wenn:
Kein klares Latenzziel existiert
Wenn niemand sagen kann, ob die Daten nach Sekunden, fünf Minuten oder einer Stunde verfügbar sein müssen, ist ein inkrementeller Batch oft der bessere Startpunkt.
Die Daten selten genutzt werden
Ein Wert, der nur in einem Tagesreport oder selten geöffneten Dashboard landet, rechtfertigt keinen dauerhaft laufenden Stream.
Eigentlich schnelle Abfragen gemeint sind
Frischer Ingest und schnelle Query-Antwortzeiten sind zwei unterschiedliche Themen. Die Abfrage-Latenz ordnen wir im Überblick zu Lakehouse-Echtzeit ein.
Der Use Case in Richtung ML oder Features geht
Streaming-Daten für Modelle haben eigene Anforderungen an Feature-Bereitstellung, Training, Serving und Monitoring. Das behandeln wir im Überblick zu Real-Time ML.
Die Abfrage-Latenz ordnen wir im Überblick zu Lakehouse-Echtzeit ein, Streaming-Daten für Modelle im Überblick zu Real-Time ML.
Für viele Fälle ist deshalb ein getriggerter inkrementeller Lauf der bessere Ausgangspunkt. Die konkreten Ingest-Bausteine behandeln wir im Databricks Data Engineering-Strang separat.
Grenzen von Databricks Streaming
Streaming auf Databricks vereinfacht vieles, weil Batch und Stream über dieselbe Engine laufen. Die Architekturentscheidung hängt aber nicht an der Engine allein, sondern vor allem am tatsächlichen Latenzbedarf.
Ohne klares Latenzziel gibt es keine saubere Entscheidung. Bevor Trigger, Compute oder Streaming-Pfad gewählt werden, muss fachlich geklärt sein, wie frisch die Daten wirklich sein müssen. Sekunden, Minuten oder Stunden führen zu unterschiedlichen Architekturen und Kosten.
Real-Time Mode ist nur für wenige Fälle relevant. Sub-Sekunden-Latenz ist nicht der Normalfall. Der Real-Time Mode ist für klar SLA-getriebene operative Abläufe gedacht. Für die meisten analytischen Workloads bleibt Near-Real-Time mit Micro-Batches oder getriggerten Läufen der sinnvollere Weg.
Lakeflow reduziert Betrieb, nimmt aber Feinsteuerung ab. Lakeflow Declarative Pipelines sind für viele Standard-Ingest-Strecken der einfachere Betriebsweg. Wer sehr spezifische Trigger, eigene State-Logik oder Sonderfälle braucht, bleibt mit selbst gebautem Structured Streaming oft flexibler.
Konkrete Latenz und Kosten müssen im eigenen Setup gemessen werden. Herstellerangaben helfen bei der Einordnung, ersetzen aber keinen Test mit den eigenen Daten, der eigenen Compute-Umgebung und der erwarteten Last.
Fazit
Streaming auf Databricks lohnt sich, wenn ein Use Case wirklich frische Daten im Sekunden- oder Minutenbereich braucht und der Nutzen die zusätzlichen Compute-Kosten rechtfertigt.
Streaming auf Databricks lohnt sich, wenn ein Use Case wirklich frische Daten im Sekunden- oder Minutenbereich braucht und der Nutzen die zusätzlichen Compute-Kosten rechtfertigt. Besonders relevant ist das für Betrugsabwehr, Monitoring, operative Dashboards und Personalisierung, also für Fälle, in denen verspätete Daten zu schlechteren Entscheidungen führen.
Gute Kandidaten für Streaming sind:
- Use Cases mit einem klaren Latenz-SLA, den ein Tagesreport nicht mehr erfüllt
- bestehende Batch-Strecken, bei denen der Fachbereich nachweislich frischere Daten braucht
- Kafka-, Kinesis- oder CDC-Quellen, die kontinuierlich Ereignisse liefern
- Standard-Ingest-Strecken, die über Lakeflow Declarative Pipelines einfacher betrieben werden können
Wenn kein konkreter Latenzbedarf definiert ist, sollte Streaming nicht das nächste Projekt sein. Solange „Echtzeit" nur ein Wunsch ohne klare Einheit ist, ist inkrementeller Batch im Minutentakt meist günstiger, robuster und schneller umgesetzt.
Mein Vorschlag: zuerst Latenzbedarf und Kostenrahmen klären, dann den technischen Pfad wählen. Für viele Fälle reicht Near-Real-Time über getriggerte oder deklarative Verarbeitung. Echte Real-Time sollte nur eingesetzt werden, wenn ein belegter Sub-Sekunden-Bedarf dahintersteht. Die teuerste Fehlentscheidung ist oft ein dauerhaft laufender Cluster für eine Anforderung, die niemand wirklich in Sekunden beziffert hat.
Streaming oder reicht inkrementeller Batch?
- welche Use Cases echte Kandidaten für kontinuierliche Verarbeitung sind
- welcher Latenzbedarf fachlich wirklich getragen werden muss
- welche Kosten-, Zustands- und Betriebsrisiken vor dem Bau geprüft werden sollten
- welcher Pfad zwischen Structured Streaming und Lakeflow Declarative Pipelines zu eurer Situation passt
FAQ
Streaming läuft auf Databricks über Structured Streaming, die einheitliche Engine für Batch und Stream. Sie verarbeitet eintreffende Daten fortlaufend mit derselben DataFrame- und SQL-Logik wie die Batch-Verarbeitung, schreibt das Ergebnis in Delta-Tabellen und sichert über Checkpoints, dass jeder Datensatz auch nach einem Neustart genau einmal wirksam wird. Der Trigger-Modus steuert dabei, ob dauerhaft oder in getriggerten Läufen verarbeitet wird.
![Mitarbeiter am Schreibtisch vor zwei Monitoren, überlagert von einer Karte 'Policy: pii' mit einer Tabelle, die dieselbe Kartenzahlungs-Spalte je nach Rolle unterschiedlich zeigt: Finance sieht VISA •••• 4417, Data Eng sieht [REDACTED], Analyst sieht einen Hash-Wert, sowie einem Badge 'Tag: pii · Policy aktiv'](/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2Fajsqxuma%2Fproduction%2F0127d64d384ec70b3186a60fe880484d6d5d393a-1376x768.avif%3Fw%3D1920%26fit%3Dmax%26auto%3Dformat%26q%3D75&w=3840&q=75)