Databricks stellt mit Lakehouse//RT eine Engine für Echtzeitanalysen auf Delta-Lake- und Apache-Iceberg-Tabellen vor. Anwendungen und KI-Agenten sollen dadurch direkt auf Daten im Lakehouse zugreifen können, ohne dass zusätzliche Serving-Systeme oder spezialisierte Echtzeitdatenbanken erforderlich sind.
Der Markt für Echtzeitanalysen wird bislang von spezialisierten Systemen wie ClickHouse, Apache Pinot oder Apache Druid geprägt. Unternehmen setzen diese häufig zusätzlich zu ihren Analyseplattformen ein, um Anwendungen, Dashboards oder KI-Systeme mit niedrigen Antwortzeiten zu versorgen. Die dafür erforderlichen Datenkopien und Synchronisationsprozesse erhöhen jedoch Komplexität und Kosten.
Mit Lakehouse//RT will Databricks diese Architektur vereinfachen. Die neue Engine führt Abfragen mit Latenzen im Millisekundenbereich direkt auf Delta-Lake- und Apache-Iceberg-Tabellen aus. Eine separate Echtzeit-Serving-Schicht soll dadurch entfallen. Die Technologie ist ab sofort als Beta verfügbar. Databricks begründet den Schritt unter anderem mit dem zunehmenden Einsatz von KI-Agenten. Diese greifen nach Vorstellung des Herstellers kontinuierlich auf Unternehmensdaten zu und benötigen dafür aktuelle Informationen mit möglichst geringer Latenz. Lakehouse//RT soll deshalb Daten direkt aus dem Lakehouse bereitstellen, ohne sie zuvor in zusätzliche Systeme zu kopieren.
Echtzeitabfragen direkt auf Delta- und Iceberg-Tabellen
Nach Angaben des Herstellers richtet sich Lakehouse//RT an Anwendungen mit hohen Parallelitätsanforderungen. Dazu zählen interaktive Dashboards, kundenseitige Anwendungen sowie KI-Agenten. Die Engine greift direkt auf verwaltete Delta-Lake- und Apache-Iceberg-Tabellen zu und soll auch bei einer großen Zahl gleichzeitiger Anfragen niedrige Antwortzeiten ermöglichen. Bislang setzen viele Unternehmen für solche Szenarien auf zusätzliche Echtzeit-Serving-Systeme.
Databricks argumentiert, dass diese Architektur zu Datenkopien, separaten Governance-Strukturen und zusätzlichem Betriebsaufwand führt. Lakehouse//RT soll diese Zwischenschicht ersetzen und Analysen unmittelbar auf den im Lakehouse gespeicherten Daten ermöglichen.
Technische Grundlage von Lakehouse//RT ist Reyden, eine neue Rechen-Engine mit vollständig asynchronem Ausführungsmodell. Nach Herstellerangaben erreicht sie Antwortzeiten von rund 10 Millisekunden bei kleineren Datensätzen sowie unter 100 Millisekunden bei größeren Datenbeständen. Bei Standard-Analyse-Benchmarks nennt Databricks Latenzen von unter 100 Millisekunden bei 12.000 Abfragen pro Sekunde. Gegenüber bestehenden Echtzeit-Serving-Stacks sollen Kunden Leistungssteigerungen um den Faktor 16 gemessen haben. Welche Datensätze und Abfragetypen den Benchmarks zugrunde liegen, erläutert der Hersteller bislang nicht im Detail. Anders als viele auf niedrige Latenzen optimierte Systeme sei Reyden nicht nur für einfache Schlüssel-Wert-Abfragen ausgelegt, sondern könne auch komplexere analytische Abfragen verarbeiten.
Governance im bestehenden Lakehouse
Lakehouse//RT integriert sich in den Unity Catalog von Databricks. Richtlinien, Berechtigungen und Audit-Funktionen gelten damit auch für Echtzeitabfragen. Zusätzliche Governance-Schichten oder proprietäre Datenformate sollen nicht erforderlich sein. Nach Angaben des Herstellers genügt es, bestehende Delta- oder Iceberg-Tabellen auszuwählen, um innerhalb weniger Minuten auf Live-Daten zuzugreifen. Separate CDC- oder Synchronisationspipelines seien nicht notwendig.
Databricks ordnet Lakehouse//RT als Erweiterung seiner bestehenden Engine-Familie ein. Neben Spark für Data Engineering und Data Science sowie Photon für analytische Workloads soll die neue Engine den Bereich niedriger Latenzen abdecken.
Erste Referenzkunden und offene Fragen
Als Referenzkunden nennt Databricks unter anderem Cisco und den Werbetechnologieanbieter Magnite. Cisco berichtet von einer fünffachen Verbesserung der Antwortzeiten bei der Bedrohungssuche auf Live-Daten. Magnite gibt Antwortzeiten von unter 200 Millisekunden für zentrale Dashboard-Abfragen an. Ob Lakehouse//RT tatsächlich spezialisierte Echtzeitdatenbanken ersetzen kann, bleibt offen. Die bislang veröffentlichten Leistungsdaten stammen ausschließlich von Databricks und ausgewählten Referenzkunden. Unabhängige Benchmarks oder direkte Vergleiche mit anderen Echtzeitsystemen liegen bislang nicht vor.
Sollte sich die Architektur in der Praxis bewähren, könnte sie einen weiteren Schritt in Databricks’ Strategie markieren, Analyse-, Transaktions- und KI-Workloads auf einer gemeinsamen Plattform zusammenzuführen. Der Beta-Status zeigt allerdings auch, dass sich dieser Anspruch erst noch im produktiven Einsatz beweisen muss. Parallel dazu kündigt Databricks weitere Schritte an, bislang getrennte operative und analytische Datenarchitekturen enger miteinander zu verzahnen.
(axk)
