Databricks revolutioniert Datenpipelines: Echtzeit-Analyse und Transaktionen in einem System

In der Welt der Datenverarbeitung kämpfen Unternehmen seit Jahrzehnten mit einem fundamentalen Dilemma: Wie lassen sich operative und analytische Datenbanken so verbinden, dass weder Verzögerungen noch Performance-Einbußen entstehen? Die wachsende Nachfrage nach KI-Agenten, die kontinuierlich Entscheidungen auf Basis aktueller Daten treffen müssen, hat dieses Problem weiter verschärft. Denn Agenten tolerieren keine Latenzzeiten zwischen ihrer Anfrage und der Datenbereitstellung.

Auf dem Data + AI Summit in dieser Woche stellte Databricks zwei innovative Produkte vor, die genau diese Herausforderung adressieren. Mit Lakehouse//RT und LTAP (Lake Transactional/Analytical Processing) setzt das Unternehmen auf eine radikale Vereinfachung der Dateninfrastruktur – und eliminiert damit jahrzehntelang bestehende Architekturprobleme.

LTAP: Transaktions- und Analysedaten in einem Speicherformat

Die Kernidee von LTAP besteht darin, transaktionale PostgreSQL-Daten direkt in den offenen Formaten Delta und Iceberg zu speichern. Dadurch entfällt die Notwendigkeit, separate ETL-Pipelines zwischen operativen und analytischen Systemen zu betreiben – ein Ansatz, der seit Jahrzehnten die Datenlandschaft prägt. Bislang mussten Unternehmen ihre PostgreSQL-Daten zunächst in proprietäre Formate konvertieren, bevor analytische Engines wie Spark darauf zugreifen konnten.

Reynold Xin, Mitgründer von Databricks, betont die Bedeutung einer schlanken Infrastruktur für KI-Agenten: „Agenten bevorzugen eine deutlich einfachere Architektur, weil sie dadurch viel schneller agieren können.“ Die neue Lösung nutzt die Lakebase-Architektur, die bereits im Februar als serverlose PostgreSQL-Alternative in der Cloud verfügbar wurde. Statt auf eine Konvergenz der Abfrage-Engines setzt Databricks auf eine Vereinheitlichung auf Speicherebene – ein Ansatz, den der Branchenanalyst Gartner bereits 2014 unter dem Begriff HTAP (Hybrid Transactional/Analytical Processing) diskutiert hatte.

Doch LTAP geht weiter: Während HTAP-Anbieter wie SAP HANA oder Oracle MySQL Heatwave auf eine Konvergenz der Abfrage-Engines setzten, speichert LTAP transaktionale Daten direkt in Delta- oder Iceberg-Formaten. Die PostgreSQL-Engine bleibt dabei unverändert für Transaktionen zuständig, während Spark und andere analytische Tools auf dieselbe Datenbasis zugreifen können.

# Beispiel: Transaktionale Daten in LTAP schreiben
INSERT INTO ltap_analytics_table (id, name, timestamp) VALUES (1, 'Beispiel', NOW());

Ein zentrales technisches Hindernis war lange die Latenz bei der Datenbereitstellung. Object Storage bietet zwar Skalierbarkeit, aber Antwortzeiten im Sekundenbereich – viel zu langsam für OLTP-Workloads, die Millisekunden-Reaktionszeiten erfordern. Databricks begegnet diesem Problem mit einem Caching-Layer, der zwischen PostgreSQL-Compute-Instanzen und Object Storage geschaltet ist. Hier wird die Zeilen-zu-Spalten-Konvertierung durchgeführt, bevor die Daten in den Object Storage gelangen. Durch die Komprimierung der Daten wird der Netzwerkverkehr um mehr als das Zehnfache reduziert.

Lakehouse//RT: Echtzeit-Analysen ohne separate Serving-Schicht

Neben LTAP stellt Databricks mit Lakehouse//RT eine weitere Lösung vor, die das Problem dedizierter Realtime-Serving-Tier-Systeme adressiert. Viele Unternehmen unterhalten seit Jahren separate Systeme neben ihren Data Lakes, um niedrige Latenzzeiten für Echtzeitabfragen zu gewährleisten – doch dies geht einher mit Datenkopien, komplexen Berechtigungsstrukturen und zusätzlichem Governance-Aufwand.

Lakehouse//RT eliminiert diese Nachteile, indem es direkt auf Delta- und Iceberg-Tabellen zugreift. Der neu entwickelte Reyden-Compute-Engine ist speziell für hochkonkurrierende, latenzarme Abfragen optimiert und liefert:

• Sub-100ms-Latenz bei bis zu 12.000 Abfragen pro Sekunde
• Spitzenleistungen von bis zu 16-facher Performance im Vergleich zu herkömmlichen Serving-Stacks
• Nahtlose Integration in Unity Catalog für einheitliche Governance – ohne zusätzliche Berechtigungsschichten oder Datenkopien

„Jede Abfrage läuft innerhalb des Unity Catalogs mit denselben Sicherheits- und Zugriffsregeln wie der Rest des Data Lakes“, erklärt Xin. Dies vereinfacht nicht nur die Architektur, sondern reduziert auch den Betriebsaufwand erheblich.

Analysten sehen Potenzial – aber auch Herausforderungen

Während die Probleme, die Databricks mit LTAP und Lakehouse//RT löst, in der Branche bekannt sind, wird der agentische Ansatz als entscheidender Unterschied hervorgehoben. Stephanie Walter, Practice Leader für KI-Stacks bei HyperFRAME Research, betont: „Unternehmen nutzen zwar seit Jahren HTAP, Streaming oder Cloud-Datenlager – doch die agentische KI erfordert mehr: Echtzeitdaten, historischen Kontext, Governance und die Möglichkeit, Ergebnisse zurückzuschreiben – alles in einem durchgehenden Workflow.“

Mike Leone von Moor Insights and Strategy ergänzt: „Die Offenheit des Delta- und Iceberg-Formats ist mittlerweile Standard. Die wahre Innovation liegt darin, dass transaktionale Schreibvorgänge direkt in diesen offenen Formaten landen.“

Ob die neuen Lösungen jedoch die Latenz-, Zuverlässigkeits- und Betriebsanforderungen erfüllen können, die CIOs erwarten, bleibt abzuwarten. Die Architektur mag überzeugen – doch die Praxistauglichkeit muss sich erst noch in groß angelegten Deployments beweisen.

Ein Schritt in die richtige Richtung – aber der Weg ist noch lang

Mit LTAP und Lakehouse//RT adressiert Databricks zwei der drängendsten Probleme der modernen Datenarchitektur: die Vereinheitlichung von Transaktions- und Analysedaten sowie die Bereitstellung von Echtzeitanalysen ohne zusätzliche Infrastruktur. Die Lösungen könnten besonders für Unternehmen interessant sein, die KI-Agenten einsetzen oder ihre Datenpipelines radikal vereinfachen möchten.

Doch wie bei jeder bahnbrechenden Technologie gilt: Der Proof liegt im Einsatz. Die kommenden Monate werden zeigen, ob Databricks mit diesen Innovationen tatsächlich die jahrzehntelange Suche nach der perfekten Dateninfrastruktur beendet – oder ob weitere Anpassungen notwendig sein werden.