Mit LTAP (Lake Transactional/Analytical Processing) stellt Databricks eine Architektur vor, die operative Datenbanken und analytische Systeme enger zusammenführen soll. Statt Daten per ETL- oder CDC-Prozessen zwischen beiden Welten zu kopieren, sollen künftig beide auf derselben Datenbasis arbeiten. Databricks sieht darin eine Antwort auf den zunehmenden Einsatz von KI-Agenten, die jederzeit auf aktuelle Unternehmensdaten zugreifen müssen.

In vielen Unternehmen existieren heute zwei getrennte Datenwelten. Operative Anwendungen speichern ihre Daten für den laufenden Geschäftsbetrieb in Transaktionsdatenbanken wie PostgreSQL oder Oracle. Für Berichte, Analysen oder KI-Anwendungen werden diese Daten anschließend in ein Data Warehouse oder Lakehouse kopiert. Dazwischen liegen ETL-Prozesse oder sogenannte Change-Data-Capture-Pipelines (CDC), die Änderungen laufend zwischen beiden Systemen synchronisieren. Diese Architektur gilt seit Jahren als Standard, verursacht jedoch zusätzlichen Betriebsaufwand, Datenkopien und zeitliche Verzögerungen.

Nach Ansicht von Databricks stößt dieses Modell zunehmend an seine Grenzen. KI-Agenten und moderne Anwendungen benötigten aktuelle operative Daten und könnten nicht mit Minuten oder Stunden alten Replikaten arbeiten. Mit LTAP will der Hersteller deshalb transaktionale und analytische Workloads enger zusammenführen.

Zwei Engines statt einer

Neu ist die Idee allerdings nicht. Bereits vor rund 15 Jahren versuchten HTAP-Systeme (Hybrid Transactional/Analytical Processing), Transaktionen und Analysen in einer gemeinsamen Datenbank-Engine auszuführen. Der Nachteil: Dieselbe Engine musste gleichzeitig schnelle Schreibzugriffe und komplexe analytische Abfragen bewältigen, was häufig zulasten der jeweiligen Optimierung ging.

Genau darin sieht Databricks den entscheidenden Unterschied zu früheren HTAP-Ansätzen. Eine einzelne Engine sei für beide Aufgaben zwangsläufig kompromissbehaftet, erläutert Rich Radley, Vice President Field Engineering EMEA bei Databricks. LTAP setzt stattdessen auf zwei spezialisierte Engines: Lakebase übernimmt die transaktionale Verarbeitung auf Basis von PostgreSQL, das Lakehouse die analytischen Abfragen. Beide greifen jedoch auf dieselbe Datenbasis zu.

Grundlage dafür ist Lakebase, ein serverloses PostgreSQL-System, das Daten direkt im Objektspeicher des Lakehouse ablegt. Nach Angaben des Herstellers werden die für Transaktionsdaten typischen zeilenorientierten Daten beim Schreiben automatisch in ein für analytische Abfragen optimiertes spaltenorientiertes Format überführt.

Erst dadurch können beide Engines dieselbe Datenbasis nutzen, obwohl sie unterschiedliche Anforderungen an die Datenorganisation stellen. Radley bezeichnet diese Echtzeit-Transcodierung als eigentlichen technischen Durchbruch der Architektur. Dadurch können zwei spezialisierte Engines parallel auf denselben Daten arbeiten, ohne dass Daten zwischen operativen und analytischen Systemen repliziert werden müssen.

Gemeinsame Datenbasis statt Datenkopien

Lakebase legt die Daten auf derselben Speicherschicht wie das Lakehouse in offenen Tabellenformaten wie Delta oder Iceberg ab. Über den Unity Catalog werden sie gemeinsam verwaltet; dieser übernimmt Berechtigungen, Metadaten und Governance. Dadurch können sowohl die transaktionale Datenbank als auch das Lakehouse auf dieselbe Datenbasis zugreifen, ohne dass zusätzliche Datenkopien entstehen.

Lakebase ergänzt Databricks zudem um cloud- und regionenübergreifende Disaster Recovery, Git-ähnliche Branches und Snapshots sowie autonome Datenbankfunktionen, bei denen Agenten den Zustand überwachen und Optimierungsvorschläge liefern.

Architektur statt Revolution

Mit seinem Ansatz, transaktionale und analytische Workloads enger zusammenzuführen, will sich Databricks sowohl von den HTAP-Systemen (Hybrid Transactional/Analytical Processing) als auch von den neueren Zero-ETL-Konzepten absetzen. Während HTAP beide Workloads in einer gemeinsamen Engine vereinen wollte, argumentiert Databricks, dass Zero ETL vor allem den Integrationsaufwand zwischen bestehenden Systemen reduziere, die zugrunde liegenden Datenkopien jedoch bestehen blieben. LTAP setzt dagegen auf zwei spezialisierte Engines, die auf einer gemeinsamen Datenbasis arbeiten und Datenkopien vollständig vermeiden sollen.

Ob dieser Architekturansatz ETL- und Replikationsprozesse tatsächlich in größerem Umfang ersetzen kann, muss sich allerdings erst im produktiven Einsatz zeigen. LTAP ist bislang nicht allgemein verfügbar, unabhängige Benchmarks oder belastbare Erfahrungen aus Produktivumgebungen liegen ebenfalls nicht vor.

Zusammen mit Lakehouse//RT zeigt LTAP die strategische Richtung von Databricks: Analyse-, Transaktions- und KI-Workloads sollen künftig nicht mehr über zahlreiche Datenkopien und spezialisierte Zwischensysteme verbunden werden, sondern auf einer gemeinsamen Datenbasis zusammenlaufen. Sollte sich dieser Architekturansatz im produktiven Einsatz bewähren, könnte er den Aufbau datenintensiver KI-Anwendungen und Agentensysteme vereinfachen.

(axk)