Was ist Streaming SQL? Funktionsweise, Engines & Use Cases

Streaming SQL ist SQL, das kontinuierlich auf Daten in Bewegung läuft. Statt eine Tabelle einmal abzufragen und ein festes Ergebnis zurückzugeben, abonniert eine Streaming-SQL-Abfrage einen Strom von Events, etwa Kafka Topics, Datenbank-Change-Logs oder Sensordaten, und aktualisiert ihr Ergebnis jedes Mal, wenn neue Daten eintreffen. Die Abfrage läuft so lange weiter, bis Sie sie stoppen.

Für Datenteams verändert das, wer Echtzeit-Pipelines bauen kann. Live-Events zu filtern, zu verknüpfen und zu aggregieren bedeutete früher, Java- oder Scala-Code für ein Stream-Processing-Framework zu schreiben. Mit Streaming SQL kann ein Analyst oder Data Engineer, der SQL bereits beherrscht, dieselbe Logik deklarativ ausdrücken, und die Engine kümmert sich im Hintergrund um State, Reihenfolge und Fehlertoleranz.

Was ist Streaming SQL?

Eine klassische SQL-Abfrage arbeitet mit begrenzten Daten. Die Datenbank liest die Zeilen, die zum Zeitpunkt der Abfrage existieren, berechnet ein Ergebnis und hört auf. Eine Streaming-SQL-Abfrage arbeitet mit unbegrenzten Daten: Der Input endet nie, also wird die Abfrage nie „fertig“. Sie liefert fortlaufend Ergebnisse und überarbeitet sie, sobald weitere Events eintreffen.

Dafür begegnet Ihnen auch der Begriff SQL Stream Processing, und die Idee ist älter als die meisten Tools, die sie heute nutzen. Frühe Produkte wie StreamSQL von StreamBase erweiterten SQL für Event-Streams, und moderne Engines wie Apache Flink, ksqlDB und Spark Structured Streaming haben den Ansatz in den Mainstream gebracht. Bei allen ist das Ziel dasselbe: Entwicklern das vertraute SQL-Modell für Stream Processing an die Hand zu geben statt einer neuen Programmier-API.

Streaming SQL ist kein eigener Sprachstandard. Jede Engine implementiert ihren eigenen Dialekt auf Basis von Standard-SQL und ergänzt Konstrukte für Zeit, Windows und kontinuierliche Ausgabe. Die Kernideen sind über alle Engines hinweg einheitlich, deshalb lohnt es sich, die Konzepte zu verstehen, bevor Sie ein Tool auswählen.

Wie funktioniert Streaming SQL?

Streams als Dynamic Tables

Die zentrale Idee lautet: Ein Stream und eine Tabelle sind zwei Sichten auf dieselben Daten. Apache Flink nennt das eine Dynamic Table, also eine Tabelle, deren Inhalt sich im Lauf der Zeit ändert, während Events eintreffen. Eine kontinuierliche Abfrage liest aus einer oder mehreren Dynamic Tables und erzeugt als Ausgabe eine weitere Dynamic Table, die die Engine inkrementell aktuell hält, statt sie von Grund auf neu zu berechnen.

Diese Ausgabe kann in ein anderes Kafka Topic, eine Datenbank oder einen Data Lake geschrieben oder als Materialized View vorgehalten werden, die Anwendungen direkt abfragen. Streaming Databases bauen ihr gesamtes Produkt um dieses letzte Muster herum: Sie definieren eine Materialized View in SQL, und die Datenbank hält sie aktuell, während sich die zugrunde liegenden Streams ändern.

Windows

Viele Fragen im Streaming-Umfeld ergeben nur über einen bestimmten Zeitausschnitt Sinn, etwa „Umsatz pro Filiale in den letzten fünf Minuten“. Windows teilen einen unbegrenzten Stream in endliche Gruppen auf, mit denen eine Aggregation arbeiten kann. Die meisten Engines unterstützen drei Typen:

• Tumbling Windows: Intervalle fester Größe ohne Überlappung, etwa alle fünf Minuten
• Hopping Windows: Intervalle fester Größe, die sich überlappen, etwa ein 10-Minuten-Window, das jede Minute weiterrückt
• Session Windows: Windows variabler Größe, die nach einer Phase der Inaktivität schließen und sich für Benutzersitzungen und Geräteaktivität eignen

Event Time, Processing Time und Watermarks

Events kommen nicht immer in der Reihenfolge an, in der sie stattgefunden haben. Eine mobile App kann Events offline zwischenspeichern, und Netzwerkverzögerungen können die Reihenfolge von Nachrichten durcheinanderbringen. Streaming-SQL-Engines unterscheiden deshalb zwischen Event Time, also dem Zeitpunkt, zu dem etwas passiert ist, und Processing Time, also dem Zeitpunkt, zu dem die Engine es gesehen hat.

Um zu entscheiden, wann ein Window vollständig ist, verwenden Engines Watermarks. Ein Watermark ist ein Signal, das anzeigt, dass die Event Time bis zu einem bestimmten Punkt fortgeschritten ist und keine früheren Events mehr erwartet werden. Sie legen fest, wie viel Verspätung toleriert wird, zum Beispiel 10 Sekunden, und die Engine schließt Windows und gibt Ergebnisse aus, sobald das Watermark diesen Punkt überschreitet. Dieser Zielkonflikt zwischen Latenz und Vollständigkeit ist eine der wichtigsten Designentscheidungen in jeder Streaming-SQL-Pipeline.

State und Joins

Aggregationen, Deduplizierung und Joins setzen alle voraus, dass sich die Engine an frühere Events erinnert. Dieses Gedächtnis heißt State, und die Engine speichert es und sichert es per Checkpoint, damit bei einem Ausfall keine Ergebnisse verloren gehen. Bei Joins spielt State die größte Rolle: Einen Stream von Zahlungen mit einer Tabelle von Kundenprofilen zu verknüpfen ist unkompliziert, während ein Join zweier unbegrenzter Streams eine zeitliche Begrenzung braucht, da der State sonst unendlich wachsen würde.

Standard-SQL vs. Streaming SQL

Die Syntax wirkt vertraut, aber das Ausführungsmodell ist ein anderes. Die folgende Tabelle fasst die wichtigsten Unterschiede zusammen.

Die praktische Konsequenz: Streaming SQL belohnt es, Zeit und State explizit mitzudenken. Eine Abfrage, die in einer Batch-Datenbank günstig ist, etwa ein unbegrenztes GROUP BY auf einem Schlüssel mit hoher Kardinalität, kann in einer Streaming-Engine einen großen State aufbauen.

Streaming-Daten mit SQL abfragen

Das folgende Beispiel nutzt Flink SQL, um Bestell-Events aus einem Kafka Topic zu lesen und den Umsatz pro Filiale in Tumbling Windows von fünf Minuten zu berechnen.

CREATE TABLE orders (
  order_id   STRING,
  store_id   STRING,
  amount     DECIMAL(10, 2),
  order_time TIMESTAMP(3),
  WATERMARK FOR order_time AS order_time - INTERVAL '10' SECOND
) WITH (
  'connector' = 'kafka',
  'topic' = 'orders',
  'properties.bootstrap.servers' = 'broker:9092',
  'format' = 'json',
  'scan.startup.mode' = 'earliest-offset'
);

SELECT window_start, window_end, store_id, SUM(amount) AS revenue
FROM TABLE(
  TUMBLE(TABLE orders, DESCRIPTOR(order_time), INTERVAL '5' MINUTES))
GROUP BY window_start, window_end, store_id;

Das CREATE TABLE-Statement kopiert keine Daten. Es bildet das Kafka Topic auf eine Dynamic Table ab und teilt Flink mit, dass order_time die Event-Time-Spalte ist. Die WATERMARK-Klausel toleriert Events, die bis zu 10 Sekunden verspätet eintreffen, bevor ein Window schließt.

Das SELECT-Statement wendet eine Tumbling-Window-Funktion auf diese Tabelle an und gruppiert nach Window und Filiale. Alle fünf Minuten Event Time gibt es pro Filiale eine Zeile mit dem Umsatz dieses Windows aus. In der Produktion würden Sie dieses Ergebnis typischerweise mit einem INSERT INTO-Statement in ein anderes Topic oder eine Datenbanktabelle schreiben, damit nachgelagerte Systeme es nutzen können.

Streaming-SQL-Engines im Vergleich

Die Wahl einer Streaming-SQL-Engine hängt von Ihren Latenzanforderungen, der Größe des State, den bereits betriebenen Plattformen und davon ab, ob Sie Abfrageergebnisse direkt an Anwendungen ausliefern möchten.

Flink SQL ist die übliche Wahl für Streaming SQL im allgemeinen Einsatz, und auch das Managed Stream Processing von Confluent basiert darauf. ksqlDB bleibt eine einfache Option für Teams, die vollständig in Kafka arbeiten. Spark Structured Streaming eignet sich für Organisationen, die eine einzige Engine für Batch und Streaming möchten, mit Latenzen im Sekunden- statt im Millisekundenbereich. Streaming Databases tauschen etwas Flexibilität bei der Verarbeitung gegen den Komfort ein, Ergebnisse über eine PostgreSQL-kompatible Schnittstelle abfragen zu können.

Anwendungsfälle für Streaming SQL

Betrugs- und Risikoerkennung

Banken und Zahlungsdienstleister nutzen Streaming SQL, um jede Transaktion mit der jüngsten Aktivität derselben Karte oder desselben Kontos abzugleichen. Eine Window-Aggregation kann eine ungewöhnlich hohe Zahl von Transaktionen in kurzer Zeit markieren, und ein Join mit Referenzdaten kann das Händlerrisiko prüfen, bevor die Zahlung abgeschlossen ist.

Bestände und Betrieb in Echtzeit

Händler und Hersteller pflegen Live-Ansichten von Lagerbeständen, Auftragsrückständen und Maschinenstatus. Statt auf einen nächtlichen Batch zu warten, sehen Betriebsteams Änderungen innerhalb von Sekunden, und Alerts werden ausgelöst, sobald eine Kennzahl einen Schwellenwert überschreitet.

Change-Data-Capture-Pipelines

Change Data Capture streamt jedes Insert, Update und Delete aus operativen Datenbanken. Streaming SQL kann diese Änderungen noch während der Übertragung bereinigen, maskieren und verknüpfen, bevor sie in einem Data Warehouse oder Lakehouse landen. So bleiben analytische Kopien aktuell, ohne die Quellsysteme zusätzlich zu belasten.

Aktueller Kontext für KI-Agenten

KI-Agenten und Machine-Learning-Modelle sind nur so gut wie die Daten, auf deren Basis sie handeln. Streaming SQL kann Features berechnen, etwa die Ausgaben eines Kunden in der letzten Stunde, und sie aktuell halten, sodass Modelle und Agenten mit dem arbeiten, was gerade passiert, statt mit dem Snapshot von gestern. Mimacoms Streamhouse auf IBM Confluent wendet diese Idee auf Live-Daten für KI-Agenten an.

Mehr zur Analytics-Ebene, die auf diesen Pipelines aufsetzt, finden Sie in unserem Leitfaden zu Streaming Analytics.

Grenzen und wann Sie darauf verzichten sollten

Streaming SQL deckt einen großen Teil der Echtzeit-Workloads ab, aber nicht alle. Komplexe Event-Logik, etwa mehrstufige Mustererkennung mit eigenen Regeln, lässt sich in SQL mitunter nur umständlich ausdrücken, und manche Teams verlagern diese Logik in die DataStream API oder in Anwendungscode. Sehr großer State, etwa bei Joins über Monate an Historie, erfordert ein sorgfältiges Design, damit Speicherbedarf, Checkpoint-Größe und Kosten unter Kontrolle bleiben.

Auch der Betrieb kontinuierlicher Abfragen unterscheidet sich vom Ausführen von Reports. Eine Abfrage, die über Monate läuft, braucht Monitoring, Versionierung und einen Plan, wie sich ihre Logik ändern lässt, ohne State zu verlieren. Die Dialekte unterscheiden sich zwischen den Engines, sodass die Migration einer Pipeline von ksqlDB zu Flink SQL bedeutet, Abfragen neu zu schreiben, statt sie einfach zu kopieren. Teams, die ganz ohne Code auskommen möchten, können sich No-Code Stream Processing ansehen, das Flink-Jobs über eine visuelle Oberfläche erstellt.

Wie Mimacom Sie unterstützen kann

Mimacom arbeitet seit 2017 mit Confluent zusammen und ist seit 2021 Confluent-Trainingspartner. Nach der Übernahme von Confluent durch IBM sind wir als IBM-Partner tätig und konzipieren und betreiben Event-Streaming-Plattformen und Flink-SQL-Pipelines auf IBM Confluent für Unternehmen aus den Branchen Banken, Versicherungen, Fertigung und Handel.

Wir beginnen mit dem Anwendungsfall, nicht mit der Engine. Unsere Architekten bewerten Ihre Anforderungen an Latenz, State und Governance, empfehlen den passenden Streaming-SQL-Ansatz und bauen und betreiben die Pipelines anschließend gemeinsam mit Ihrem Team. Erfahren Sie mehr über unsere Confluent-Beratungsleistungen oder laden Sie das Whitepaper The Data Streaming Foundation for AI herunter.

Häufig gestellte Fragen

Unterstützt SQL Streaming?

Standard-SQL wurde für begrenzte Tabellen entwickelt und kennt daher kein eingebautes Konzept für unbegrenzte Streams, Event Time oder Watermarks. Streaming-Engines wie Flink SQL, ksqlDB und Spark Structured Streaming erweitern SQL um diese Konzepte, sodass Sie vertraute SELECT-, JOIN- und GROUP BY-Statements schreiben können, die kontinuierlich über Streams laufen.

Was ist eine Streaming Database?

Eine Streaming Database ist eine Datenbank, die Streams aufnimmt und Materialized Views inkrementell aktuell hält, sobald neue Events eintreffen. RisingWave und Materialize sind zwei Beispiele. Anders als eine Stream-Processing-Engine, die Ergebnisse in andere Systeme schreibt, stellt eine Streaming Database diese Ergebnisse auch direkt bereit, sodass Anwendungen sie mit Standard-SQL-Clients abfragen können.

Eignet sich Streaming SQL für OLTP-Workloads?

Nein, Streaming SQL ergänzt OLTP-Datenbanken, statt sie zu ersetzen. Transaktionale Systeme verarbeiten einzelne Lese- und Schreibvorgänge mit strikter Konsistenz, während Streaming SQL den Fluss der Änderungen verarbeitet, den diese Systeme erzeugen. Ein gängiges Muster besteht darin, Änderungen aus der OLTP-Datenbank per Change Data Capture zu erfassen und sie nachgelagert mit Streaming SQL zu verarbeiten.

Streaming SQL macht Echtzeitdaten für alle SQL-Anwender zugänglich

Streaming SQL bringt die am weitesten verbreitete Datensprache in Echtzeit-Pipelines. Sobald Ihr Team kontinuierliche Abfragen, Windows, Watermarks und State verstanden hat, wird die Wahl zwischen Flink SQL, ksqlDB, Spark und Streaming Databases zu einer Frage der Passgenauigkeit und nicht des Erlernens eines neuen Paradigmas. Beginnen Sie mit einem Anwendungsfall mit hohem Mehrwert, planen Sie Zeit und State von Anfang an ein und bauen Sie von dort aus weiter aus.