Lakehouse RT

Lakehouse RT (Real-Time) bezeichnet den Betriebsmodus von Databricks, in dem analytische Abfragen und Streaming-Verarbeitung mit wenigen Sekunden Verzögerung direkt auf den Tabellen des Lakehouses laufen, also auf denselben Delta-Tabellen (transaktionale Datei-Tabellen im offenen Parquet-Format), die auch die tägliche Batch-Auswertung tragen. Statt eines separaten Streaming-Stacks (Kafka als Puffer, Flink zur Verarbeitung, Data Warehouse für Abfragen) kombiniert Lakehouse RT die Bausteine Delta Lake, Structured Streaming, Spark Declarative Pipelines und Photon (der schnelle Query-Motor von Databricks) zu einer gemeinsamen Ausführungsschicht für Batch- und Echtzeit-Workloads.

Was ist Lakehouse RT?

Lakehouse RT ist eine Konfigurations- und Architektur-Ausprägung der Databricks-Plattform ohne eigenes Produkt-SKU. Der Kerngedanke: eine einzige Plattform trägt sowohl den Batch-Report vom Vortag als auch das operative Dashboard, das sich alle paar Sekunden aktualisiert. Ereignisse aus Quellen wie Kafka, Kinesis oder Cloud Storage werden fortlaufend in Delta-Tabellen geschrieben, und dieselben Tabellen dienen als Grundlage für analytische Abfragen. Zwei Welten (Batch und Echtzeit) und zwei Speicher (Warehouse und Streaming-Store) fallen zusammen zu einer.

Die tragenden Bausteine sind vier: Delta Lake liefert den transaktionalen Speicher mit ACID-Garantien (Atomarität, Konsistenz, Isolation, Dauerhaftigkeit), Auto-Compaction für kleine Dateien und Liquid Clustering für abfragefreundliche Datenlayouts. Structured Streaming ist die Ausführungs-Engine, die kontinuierlich eintreffende Ereignisse als wachsende Tabelle verarbeitet. Spark Declarative Pipelines (und deren Databricks-Ausprägung Lakeflow Declarative Pipelines, früher Delta Live Tables) definieren die Streaming-Logik deklarativ als Tabellen; der Anwendungscode beschreibt Zieltabellen und Transformationen, die Engine übernimmt Checkpoints, Wiederanlauf und Abhängigkeitsauflösung. Photon ist der vektorisierte C++-Query-Motor, der analytische Abfragen auf Delta-Tabellen mit Latenzen im Sub-Sekunden-Bereich beantwortet.

Das Latenz-Ziel von Lakehouse RT liegt bei Sekunden bis wenigen zehn Sekunden Ende-zu-Ende, gemessen vom Eintreffen des Events an der Quelle bis zur aggregierten Antwort im Dashboard. Das ist eine Größenordnung schneller als klassisches Batch (Minuten bis Stunden) und eine Größenordnung langsamer als spezialisierte Sub-Sekunden-OLAP-Engines wie Druid, Pinot oder ClickHouse. Für die meisten operativen Analytics-Fälle (Live-Kennzahlen, Fraud-Signale, Near-Real-Time-Feature-Streams für ML) ist diese Größenordnung ausreichend.

Der Begriff existiert, weil in klassischen Architekturen Batch- und Echtzeit-Pfade streng getrennt gebaut wurden: ein Data Warehouse für die Analytik, daneben ein Kafka-Cluster mit Flink oder Spark Streaming für Live-Daten und häufig ein dritter spezialisierter Speicher (Druid, Pinot, ClickHouse) für schnelle Abfragen auf frischen Events. Diese Trennung erzeugt doppelte Pipelines, doppelte Governance und doppelte Betriebskosten. Lakehouse RT reduziert dies auf eine Plattform mit einheitlichem Katalog (Unity Catalog), einer Speicherform (Delta) und einer Ausführungsschicht (Spark plus Photon).

Abgrenzung zu Batch-Lakehouse, Data Streaming, Real-Time Analytics und Kappa

Lakehouse RT wird häufig mit dem Oberbegriff Data Streaming, mit dem Anwendungsfall Real-Time Analytics oder mit dem Referenzmuster Kappa-Architektur vermengt. Die Trennlinien laufen entlang Ausführungsschicht, Perspektive und Abstraktionsebene.

Der wichtigste Unterschied liegt zwischen Lakehouse RT und einem klassischen Batch-Lakehouse: Bausteine und Tooling sind identisch, aber Trigger-Modi, Compute-Profile und Tabellen-Layouts unterscheiden sich. Ein Batch-Job liest einmal pro Stunde und schreibt in eine Append-Bronze-Tabelle; ein Lakehouse-RT-Job läuft mit einem Trigger von wenigen Sekunden gegen dieselbe Kafka-Quelle, wendet MERGE INTO auf eine hoch-aktualisierte Silver-Tabelle an und nutzt Photon-Compute für abfragende Endpunkte. Für die Endabfrage bleibt die Tabelle formal gleich; die operative Charakteristik ändert sich fundamental.

Gegenüber spezialisierten OLAP-Engines liegt der Trade-off in der Latenz. Druid, Pinot und ClickHouse antworten in Millisekunden auf Milliardenzeilen mit hoher Nebenläufigkeit; Lakehouse RT liegt im niedrigen Sekundenbereich und deckt dafür Batch, Streaming, Machine Learning und BI auf einer Plattform ab. Wo Latenzen unter 500 Millisekunden bei hoher Query-Frequenz gefordert sind (Ad-Tech-Bidding, Live-Sport-Statistiken, hochfrequente Fraud-Detection), ist eine spezialisierte Engine neben dem Lakehouse berechtigt; für die überwiegende Zahl operativer Analytics-Fälle reicht Lakehouse RT.

Beispiel: Auftragsdurchsatz-Dashboard mit CDC-Streaming

Ein typischer Lakehouse-RT-Aufbau bedient ein operatives Dashboard für den Auftragsdurchsatz eines Handelsunternehmens. Debezium erfasst Änderungen in der transaktionalen Datenbank des Bestellsystems und schreibt sie als Change-Events in ein Kafka-Topic. Eine Spark-Declarative-Pipeline konsumiert das Topic mit einem 5-Sekunden-Trigger, wendet MERGE INTO auf eine Silver-Delta-Tabelle orders_current an und aggregiert daraus in einer nachgelagerten Gold-Tabelle orders_throughput_1m den Durchsatz je Minute und Region.

Databricks SQL Serverless mit Photon beantwortet aus der Gold-Tabelle die Dashboard-Abfragen unter zwei Sekunden. Ende-zu-Ende dauert der Weg vom Datenbank-Commit bis zur aktualisierten Kennzahl im Dashboard etwa zehn Sekunden. Dieselbe orders_current-Tabelle liefert nachts den Batch-Report für das Controlling und dient tagsüber als Feature-Quelle für ein ML-Modell zur Betrugserkennung: eine Speicherform, drei Konsumenten, gemeinsame Governance über Unity Catalog. Betrieblich bleibt so eine Pipeline, eine Berechtigungslogik und ein SLA übrig, wo eine klassische Trennung drei parallele Stränge verlangt.