Die 40 Jahre alte Datenbankregel, die Agenten soeben gebrochen haben: Wie LTAP OLTP- und OLAP-Workloads vereinheitlicht

Jonathan Katz hat seine Karriere auf beiden Seiten einer Grenze verbracht, mit der sich der Großteil der Datenbranche einfach abgefunden hat. Als langjähriger Postgres-Contributor und jetziger Senior Staff Product Manager bei Databricks hat er miterlebt, wie operative und analytische Systeme als zwei getrennte Welten existieren, die nur durch Pipelines, Kopien und Kompromisse miteinander verbunden sind.

In diesem Gespräch erklärt Jonathan, warum diese Trennung überhaupt existierte, warum AI-Agenten sie nun endlich aufheben und wie LTAP die Lücke schließt, indem es den Ort neu überdenkt, an dem die beiden Welten aufeinandertreffen: nicht in einer einzelnen Engine, sondern in einer einheitlichen Speicherschicht.

Die Annahme, die von AI-Agenten widerlegt wurde

Die Branche lebt seit Jahrzehnten mit einer strikten Trennung zwischen operativen und analytischen Datenbanksystemen. Warum bricht der Aufstieg autonomer AI-Agenten diese Trennung nun auf?

Jonathan Katz: Es gibt zwei Welten von Daten. Operative Daten sind das, womit man arbeitet, wenn man eine Kreditkartentransaktion verarbeitet oder nach Betrug sucht: sehr kurze, schnelle Abfragen, bei denen die Daten Zeile für Zeile betrachtet werden. Analytische Daten sind das, was man über Wochen, Monate oder Jahre hinweg ansammelt. Wenn man diese abfragt, betrachtet man den gesamten Datensatz. Beide Ansätze versuchen, so schnell wie möglich eine Antwort zu liefern, gehen dabei aber völlig unterschiedliche Wege.

Dieser Unterschied ist nicht willkürlich. Er lässt sich auf die Physik zurückführen. Wenn man Daten in Zeilen speichert, liefert man eine einzelne, schnelle Antwort so rasch wie möglich. Wenn man sie in Spalten speichert, kann man den gesamten Bestand so schnell wie möglich scannen und aggregieren. Zudem kann eine analytische Abfrage konstruktionsbedingt die gesamten Ressourcen eines massiv parallelisierten Systems beanspruchen, um eine Antwort für einen sehr großen Datensatz zu erhalten, während eine operative Abfrage so konzipiert ist, dass sie so wenig Ressourcen wie möglich verbraucht und dennoch schnell eine Antwort liefert. Dies führt zu zwei völlig unterschiedlichen Herangehensweisen an den Entwurf und die Verwaltung von Datensystemen und erfordert verschiedene Arten von Optimierungen.

Postgres, eine der am weitesten verbreiteten Datenbanken weltweit, basiert auf Zeilen, da sie für operative Workloads optimiert ist. Analytische Engines basieren aus dem umgekehrten Grund auf Spalten. Aufgrund dieses grundlegenden physikalischen Unterschieds mussten die beiden Systeme schon immer getrennt voneinander betrieben werden. Jedes Mal, wenn man operative Daten analysieren wollte, musste man sie an einen anderen Ort übertragen.

Der Aufstieg von AI-Agenten hat die Anforderungen an Datenbanken verändert. Das ist einer der Gründe, warum die Architektur von Lakebase überhaupt existiert: Datenbanken, die so konzipiert sind, dass sie mit der tatsächlichen Arbeitsweise von Agenten Schritt halten können. Beispielsweise haben Agenten die Aufgabe, nach Betrug oder Anomalien zu suchen, und diese Ereignisse spielen sich im Bereich von Hunderten von Millisekunden ab. Gleichzeitig verarbeitet dieses System jedoch auch ein riesiges Volumen an Schreibvorgängen und kurzen Lesevorgängen. Ein einzelner Agent ist vielleicht intelligent genug, um zu wissen, welche Abfrage er ausführen muss. Eine ganze Gruppe von Agenten kann ein operatives System jedoch leicht überlasten, wenn keine entsprechenden Schutzmechanismen (Guardrails) vorhanden sind.

Was LTAP eigentlich ist

Was ist LTAP und wie funktioniert es eigentlich unter der Haube?

Jonathan Katz: Mit LTAP (Lake Transactional/Analytical Processing) können Sie analytische Abfragen direkt auf aktiven operativen Daten ausführen, ohne diese Daten verschieben zu müssen und ohne das System zu belasten, das Ihre Transaktionen verarbeitet. Dies wird erreicht, indem transaktionale und analytische Daten in einer einzigen logischen Speicherschicht zusammengeführt werden, anstatt sie über eine Pipeline durch separate Systeme zu schleusen.

Unter der Haube ist LTAP nur möglich, weil Lakebase selbst so aufgebaut ist: zustandslose, flüchtige Compute-Ressourcen, die vollständig vom Speicher im Lake entkoppelt sind. Diese von Neon übernommene Trennung bedeutet, dass die dauerhafte Speicherschicht Schreibvorgänge mit hohem Durchsatz verarbeiten und diese periodisch zur dauerhaften Speicherung in den Objektspeicher übertragen kann – unabhängig davon, welche Compute-Ressourcen gerade darauf zugreifen. Da diese Daten ohnehin bereits für den Cloud-Speicher optimiert wurden, warum sollte man sie nicht im selben Spaltenformat darstellen, das das Lakehouse bereits verwendet? So können Engines wie Apache Spark und SQL sie direkt lesen und hochperformante analytische Lesevorgänge ohne eine zweite Kopie ermöglichen.

Der schwierigste Teil bestand darin, sicherzustellen, dass bei der Übersetzung nichts verloren geht. Postgres hat seine eigenen Datentypen und Codierungen, und offene Formate wie Iceberg und Delta haben ebenfalls ihre eigenen. Wir mussten die Daten so schreiben, dass die exakte physikalische Darstellung der ursprünglichen Postgres-Daten bitgenau erhalten bleibt, und sie in eine Parquet-Datei übertragen. Das ist der Baustein, mit dem wir die operativen und analytischen Darstellungen derselben Daten zusammenführen konnten. In der Praxis arbeitet die Speicherschicht in zwei Ebenen: einer heißeren Ebene, die Daten im Zeilenformat für den schnellen operativen Zugriff bereithält, und einer kälteren Ebene, die sie im Spaltenformat für analytische Lesevorgänge speichert, sodass beide Seiten effizient auf das zugreifen können, was sie benötigen.

Warum LTAP dort erfolgreich ist, wo HTAP ins Stocken geraten ist

HTAP hat vor Jahren versucht, Echtzeit-Analysen zu lösen, und ist ins Stocken geraten. Warum ist dieser Ansatz auf der Lakehouse-Speicherschicht erfolgreich, während traditionelles HTAP gescheitert ist?

Jonathan Katz: Man kann HTAP-Systeme zum Laufen bringen, aber sie sind teuer. Sie sind sperrig, schwer zu betreiben und in der Regel proprietär. Der Unterschied beim LTAP-Modell besteht darin, dass Sie serverlose operative Compute-Ressourcen und serverlose analytische Compute-Ressourcen als zwei separate Dinge erhalten. Sie können genau festlegen, wie viel Compute Sie für jeden Workload unabhängig voneinander nutzen, anstatt für ein einziges System zu bezahlen, das versucht, beide Aufgaben gleichzeitig zu erledigen. Speicher ist der günstige Teil eines jeden Datensystems. Compute ist der teure Teil.

Das ist das Hauptargument für die Vereinheitlichung der Speicherschicht anstelle der Engine: Sie behalten die spezialisierte, effiziente Engine für jede Aufgabe und zahlen nur für Compute, wo Sie es tatsächlich benötigen, anstatt ein einziges teures System zu betreiben, das versucht, in allem gleichzeitig gut zu sein.

Was schiefgeht, wenn Agenten mit veralteten Daten arbeiten

Beschreiben Sie mir einen konkreten agentenbasierten Workflow, der heute fehlschlägt oder beeinträchtigt wird, weil er veraltete Daten liest und darauf reagiert. Was genau läuft schief?

Jonathan Katz: Betrugserkennung ist das anschaulichste Beispiel. Kreditkartentransaktionen werden in Hunderten von Millisekunden oder weniger abgewickelt. Wenn der für die Betrugserkennung zuständige Agent mit einer Batch-Kopie der Daten arbeitet, die Minuten oder Stunden alt ist, ist er einfach zu langsam, um etwas zu bemerken, bevor die Transaktion bereits abgeschlossen ist. Sie möchten also, dass dieser Agent direkt mit dem operativen System arbeitet.

Das operative System verarbeitet jedoch einen ständigen Strom von Schreib- und kurzen Lesevorgängen und wurde nicht dafür ausgelegt, auch noch schwere analytische Abfragen zu bewältigen. Wenn der Agent eine Abfrage ausführt, die die gesamte Kaufhistorie eines Kunden scannt, um nach Anomalien zu suchen, ist dies eine rechenintensive Abfrage für ein System, das für genau den gegenteiligen Workload optimiert ist. Dies kann die Leistung aller anderen Transaktionen beeinträchtigen, die zur gleichen Zeit abgewickelt werden sollen. Zudem benötigt eine moderne Architektur in der Regel Daten sowohl von der operativen als auch von der analytischen Seite, um eine gute Entscheidung zu treffen, sodass der Agent Daten aus beiden Quellen abrufen muss. Ein einzelner Agent verhält sich dabei vielleicht noch verantwortungsvoll. Eine ganze Flotte von Agenten, die gleichzeitig ähnliche Abfragen ausführen, kann das operative System jedoch schnell überlasten, wenn es keine Regeln dafür gibt, wie viel Last sie erzeugen dürfen.

Governance, Offenheit und der Nutzen für Unternehmen

Wie implementiert Databricks LTAP heute konkret, und wie würden Sie das jemandem beschreiben, der bereits versteht, warum HTAP zu kurz greift?

Jonathan Katz: Neben der Speichermechanik ist der Katalog die andere wichtige Komponente. Eine der echten Innovationen des Lakehouse bestand darin, Unternehmen eine zentrale, einheitliche Sicht auf all ihre Daten zu bieten: wer worauf Zugriff hat, konsistente Richtlinien für alles, sodass niemand beispielsweise eine Sozialversicherungsnummer lesen kann, es sei denn, er gehört einer privilegierten Gruppe an. Das galt für operative Systeme eigentlich nie, da diese von Anfang an als Datensilos konzipiert waren. Die Beziehung zwischen operativen und analytischen Daten sah früher so aus: Man baut eine Pipeline, überträgt die Daten und wünscht danach viel Glück. Niemand fühlte sich dafür verantwortlich, was nachgelagert damit geschah. LTAP stellt das auf den Kopf. Es sind all Ihre Daten in einem einzigen, einheitlichen Speichermodell unter einem gemeinsamen Katalog. Sie müssen sich keine Sorgen mehr machen, dass operative Daten jemals eine Governance-Grenze überschreiten, nur weil jemand sie analysieren musste.

Es gibt auch gute Gründe dafür, warum dies auf einem offenen Fundament aufgebaut sein muss. Postgres nähert sich dem dritten Platz der am besten bewerteten Datenbanken im Ranking von DB-Engines. Das ist nicht unbedingt ein Maß für die tatsächliche Verbreitung, aber es ist ein starkes Signal dafür, wohin die Reise geht, und es zeigt den Wert von Flexibilität und Wahlfreiheit. Open Source treibt seit Jahrzehnten einige der wichtigsten Systeme der Welt an. LTAP erweitert genau dieses Prinzip. Selbst innerhalb von Postgres sind Ihre Daten zwar zwischen verschiedenen Postgres-Systemen portierbar, aber Sie sind immer noch an Postgres gebunden. Mit der einheitlichen Speicherschicht von LTAP verschieben Sie keine Daten mehr, um die richtige Engine darauf anzuwenden. Sie bringen die Engine zu den Daten.

Die grundlegende Veränderung: einheitlicher Speicher

Wenn Sie die grundlegende Veränderung, die LTAP darstellt, in einem einzigen Satz beschreiben müssten – wie auch immer Sie ihn formulieren würden –, wie würde dieser lauten?

Jonathan Katz: Die vereinfachte Version ist ein einheitlicher Speicher. Erzählen Sie das jemandem aus dem Analytics-Bereich, und er versteht es fast sofort. Erzählen Sie es jemandem aus dem operativen Bereich, und er fragt Sie vielleicht, was Sie damit meinen. Aber sobald Sie die operativen und analytischen Repräsentationen derselben Daten zusammenführen können, ohne etwas zu verschieben und ohne dass sich auch nur ein Bit ändert, lösen sich viele Probleme in Luft auf, die früher unvermeidbar schienen. Ich muss keine Pipelines mehr ausführen, nur um Daten in einen Bronze- oder Silver-Layer zu bringen. Ich kann mit der Analyse beginnen, sobald sie geschrieben werden. Ich würde es auch umdrehen: Hier geht es weniger darum, etwas Neues zu erfinden, sondern vielmehr darum, zwei Welten wieder zusammenzubringen, die niemals hätten getrennt werden dürfen. Daten sind einfach Daten. Je mehr wir sie so behandeln können, desto einfacher wird es für Menschen – und jetzt auch für Agenten –, damit zu arbeiten, ohne dass sich alle erst über eine Pipeline hinweg abstimmen müssen.

Beide Welten wieder zusammenbringen

Vierzig Jahre lang bestand die Grenze zwischen operativen und analytischen Daten, weil die Physik der Speicherung dies erforderte. Agenten sind die ersten Workloads, die die Verzögerung, die diese Grenze verursacht, nicht tolerieren können. LTAP versucht nicht, den Unterschied zwischen einer Transaktion und einer analytischen Abfrage aufzuheben. Es beseitigt den Overhead, der früher mit der Ausführung von beidem auf denselben Daten verbunden war. Für einen Data Architect, der evaluiert, ob ein agentenbasierter Workload dieses Muster tatsächlich benötigt, ist der von Jonathan beschriebene Test hilfreich: Wenn die nächste Entscheidung eines Agenten von Daten abhängt, die sich noch konsolidieren – auf einem System, das darauf ausgelegt ist, diese Daten nah und geschützt zu halten –, wird das alte Pipeline-und-Kopie-Modell nicht schnell genug sein. Das ist genau das Problem, für dessen Lösung LTAP entwickelt wurde.

Um mehr über LTAP zu erfahren, lesen Sie Vom Monolithen zur Lakebase zu LTAP: Die Datenbank vom Speicher her neu gedacht.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag