Mit LTAP (Lake Transactional/Analytical Processing) stellt Databricks eine neue Architektur vor, die operative Datenbanken und analytische Systeme enger zusammenführt. Stattdessen sollen beide auf einer gemeinsamen Datenbasis arbeiten, anstatt Daten per ETL- oder CDC-Prozessen zwischen beiden Systemen zu kopieren. Diese Architektur soll die zunehmende Bedeutung von KI-Agenten beantworten, die aktuelle Daten benötigen.
Operative Datenbanken und Data Warehouses
In vielen Unternehmen existieren heute zwei getrennte Datenwelten. Operative Anwendungen speichern ihre Daten in Transaktionsdatenbanken wie PostgreSQL oder Oracle, während diese Daten anschließend in einem Data Warehouse oder Lakehouse kopiert werden. Diese Kopien verursachen zusätzlichen Betriebsaufwand und zeitliche Verzögerungen.
HTAP-Systeme
Bereits vor rund 15 Jahren versuchten HTAP-Systeme, 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.
LTAP: Eine neue Echtzeit-Transcodierung
Genau darin sieht Databricks den entscheidenden Unterschied zu früheren HTAP-Ansätzen. Eine einzelne Engine sei für beide Aufgaben zwangsläufig kompromissbehaftet. 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. Dadurch können beide Engines dieselbe Datenbasis nutzen, obwohl sie unterschiedliche Anforderungen an die Datenorganisation stellen.
Zusammenarbeit der Datenbanken
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.
Cloud- und regionenübergreifende Funktionen
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.
Ersatz von ETL-Prozessen
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.
Schlussfolgerung
Databricks' Ansatz mit LTAP bietet eine neue Möglichkeit, transaktionale und analytische Workloads in einer gemeinsamen Datenbasis zu vereinen, ohne zusätzliche Datenkopien oder ETL-Prozesse zu benötigen. Dies könnte die zunehmende Bedeutung von KI-Agenten beantworten und die Effizienz der Datenverarbeitung verbessern.
Kommentare