Auf dem diesjährigen Data & AI Summit hat Databricks Lake Transactional/Analytical Processing (LTAP) vorgestellt. Diese Datenverarbeitungsarchitektur vereint Transaktionen, Analysen, Streaming und Betriebsdaten auf einer einzigen Speicherkopie im Lake. Mit LTAP verfügen Unternehmen über eine einzige, regulierte Grundlage zum Auslesen, Auswerten und Handeln – ohne Pipelines, Replikate oder den ETL-Aufwand, der die Dateninfrastruktur seit Jahrzehnten geprägt hat. Angetrieben von bedeutenden Fortschritten bei Lakebase bietet LTAP eine neue Datenbasis für das Zeitalter der KI-Anwendungen.

Vier Jahrzehnte lang wurden Transaktions- und Analyse-Workloads in getrennten Systemen abgewickelt: Operative Datenbanken bedienten Anwendungen, Analysesysteme beantworteten Fragen. Um sie zu verbinden, mussten CDC-Pipelines aufgebaut werden, die instabil und anfällig für Ausfälle unter Last waren. Das war bereits ein schlechter Kompromiss, als Menschen Software in menschlichem Tempo schrieben. KI hilft Software-Entwicklern dabei, etwa 50-mal mehr Anwendungen als je zuvor zu schreiben, von denen viele von Agenten angetrieben werden, die Daten nahezu in Echtzeit lesen, interpretieren und darauf reagieren müssen. Die alte Architektur ist dafür nicht ausgelegt.

Die Datenbranche hat bereits zuvor versucht, das Problem unterschiedlicher Systeme zu lösen. HTAP versprach, Transaktions- und Analysedaten in einer einzigen Engine zu vereinen, zerstörte dabei jedoch die Workload-Isolation, beeinträchtigte die Leistung beider Bereiche und hinterließ in Unternehmen einen massiven, teuren proprietären Fußabdruck. Zero ETL verfolgte einen anderen Ansatz und verbarg die CDC-Pipeline, anstatt sie zu eliminieren. Das zugrunde liegende architektonische Problem blieb bestehen. LTAP verfolgt einen grundlegend anderen Ansatz: Anstatt beide Workloads in eine Engine zu zwängen oder die Pipeline zu verbergen, vereint es Daten auf der Speicherebene. Alle operativen Daten sind sofort abfragbar und stehen im Lake für Analysen zur Verfügung – ganz ohne Pipelines. Transaktionale und analytische Workloads skalieren unabhängig voneinander bei voller Leistung und strikter Isolation. LTAP basiert auf offenen Standards, funktioniert also mit jeder Anwendung, die Postgres versteht, und mit jedem Reader, der offene Tabellenformate wie Iceberg und Delta versteht.

„Jahrzehntelang war eine komplizierte Dateninfrastruktur der Preis, den Teams zahlen mussten“, sagt Ali Ghodsi, Mitbegründer und CEO von Databricks. „Dann kamen die Agenten. Innerhalb weniger Monate verdoppelten Unternehmen ihre Belegschaft praktisch – nur nicht mit Menschen. Agenten schreiben Code, führen Aufrufe durch und führen Schleifen in einem Tempo aus, das menschliche Teams niemals erreichen könnten. Die Infrastruktur, die die letzte Ära der Datenverarbeitung antrieb, ist nun der Engpass, den sich niemand mehr leisten kann. LTAP beseitigt ihn.“

Lakebase erweitert um Disaster Recovery, Git-ähnliche Verzweigungen und Snapshots

Der erste Schritt in Richtung LTAP war Lakebase, das Postgres-native Transaktionen in den Objektspeicher brachte. Sie ist die gleiche Ebene, auf der auch das Lakehouse basiert. Durch die Trennung von Compute und Storage verändert Lakebase die Wirtschaftlichkeit des gleichzeitigen Betriebs von Tausenden von Anwendungen und Agenten. Lakebase wurde erst im letzten Jahr eingeführt und bedient bereits Tausende von Kunden, darunter Block, Ensemble, Superhuman und Zillo. Täglich werden 12 Millionen Mal Datenbanken gestartet.

Databricks kündigte neue Funktionen an, die Lakebase für skalierbare Unternehmens-KI erweitern. Dank neuer, cloud- und regionenübergreifender Disaster Recovery können Unternehmen widerstandsfähigere Datenarchitekturen aufbauen – was zunehmend an Bedeutung gewinnt, da Agenten immer mehr geschäftskritische Aufgaben übernehmen. Darüber hinaus ermöglichen neue Git-ähnliche Branches und Snapshots sicheres Experimentieren mit Produktionsdaten. Autonome Datenbankoperationen wiederum ermöglichen es Agenten, den Zustand zu überwachen, Verlangsamungen zu erkennen, Indizes vorzuschlagen und bei der Wiederherstellung zu helfen.

Lakebase und das Lakehouse teilten sich bereits eine Speicherschicht, aber jedes System verwaltete seine eigene Datenkopie in seinem eigenen Format. LTAP schließt diese Lücke. Lakebase speichert Daten direkt im Unity Catalog und verwendet dabei dieselben offenen Formate wie das Lakehouse. Das Ergebnis ist eine übersichtlichere Architektur, die durch drei Eigenschaften definiert ist, die zusammen die Kompromisse beseitigen, die die Dateninfrastruktur von Unternehmen seit Jahrzehnten geprägt haben:

• Einheitliche Governance, eine „Single Source of Truth“: Alle operativen, analytischen und Streaming-Daten liegen in offenen Formaten – Delta und Iceberg – auf offenem Objektspeicher vor, ohne Transformation oder Qualitätsverlust. Alles wird über den Unity Catalog mit einer einzigen Identität, Berechtigungen und einem einzigen Audit-Modell verwaltet, sodass jede Engine dieselbe Kopie liest und Agenten eine einzige kontrollierte Oberfläche nutzen, auf der sie agieren.
• Keine Leistungseinbußen egal welcher Workload: Transaktionale Workloads laufen in Standard-Postgres mit vollständiger ACID-Semantik. Analytische Workloads laufen im gesamten Lakehouse in beliebiger Skalierung und Parallelität. Jede Komponente skaliert unabhängig, und da keine Daten zwischen den Systemen verschoben werden, sind operative und analytische Ergebnisse stets synchron – ohne Kopien oder Schatteninfrastruktur.
• Keine ETL-Pipelines (auch keine versteckten): Es gibt keine Pipelines zur Synchronisierung von operativen und analytischen Speichern, keine Replikate, die gewartet werden müssen und keine Konnektoren, die Daten zwischen Systemen verschieben. Die Architektur eliminiert die ETL-Schicht vollständig und senkt so die Betriebskosten für die Synchronisierung der Systeme, während gleichzeitig sichergestellt wird, dass die Daten aktuell bleiben.

LTAP wird in Kürze als Teil von Lakebase verfügbar sein.