LTAP-Architektur

Lake Transactional/Analytical Processing (LTAP) ist eine Datenarchitektur, die sowohl transaktionale (OLTP) als auch analytische (OLAP) Workloads von einer einheitlichen Datenspeicherschicht im Lake aus unter einem Governance-Modell bedient, sodass Sie keine separaten transaktionalen und analytischen Systeme synchron halten müssen. Sie entfernt die Change Data Capture (CDC), Replikations- und Transformationspipelines, die Teams traditionell pflegen, um operative Daten in ein separates Analysesystem zu kopieren. Azure Databricks baut LTAP auf der Lakebase-Speicherarchitektur. Für die Ankündigung siehe Databricks launcht LTAP: die erste Lake Transactional/Analytical Processing-Architektur.

LTAP ist eine Architektur, kein einzelnes Merkmal. Azure Databricks liefert sie über eine Reihe von Lakebase-Funktionen, die aktiv entwickelt und erweitert werden. Die Ihnen zur Verfügung stehenden Fähigkeiten hängen von Ihrer Cloud ab. Diese Seite erklärt die Architektur. Für die Fähigkeiten, die Sie heute in Ihrer Cloud nutzen können, siehe Fähigkeiten, die LTAP implementieren.

Die Kosten dafür, zwei Stacks synchron zu halten

Anwendungen teilen ihre Datenarbeit in zwei Arten von Arbeitsbelastungen auf. Transaktionale (OLTP) Workloads arbeiten jeweils auf wenige Zeilen und benötigen schnell den vollständigen Inhalt dieser Zeilen, wie zum Beispiel die Bearbeitung einer Zahlung oder die Rückgabe eines API-Ergebnisses. Analytische (OLAP) Workloads suchen nach Erkenntnissen über große Datensätze hinweg und aggregieren oft viele Zeilen, wie zum Beispiel Umsatzprognosen oder Betrugserkennung. Diese Muster verlaufen in entgegengesetzte Richtungen: OLTP benötigt konstante, latenzarme Lese- und Schreibvorgänge auf einzelnen Zeilen, während OLAP große Datenmengen scannen und aggregieren muss. Jahrzehntelang war die Antwort zwei separate Systeme: eine transaktionale Datenbank für die Anwendung und ein Data Warehouse oder Lakehouse für Analyse.

Die Überbrückung dieser beiden Stacks ist der aufwendige Teil. Sie synchron zu halten bedeutet, Change Data Capture (CDC), Streaming-Pipelines und Lesereplikate zu betreiben, deren einzige Aufgabe darin besteht, Daten von einem System in das andere zu kopieren. Diese Infrastruktur ist fragil, sie erhöht die Latenz zwischen dem Zeitpunkt der Datenschreibung und der Analyse, und sie konkurriert um Ressourcen mit der primären transaktionalen Datenbank. Da Anwendungen und KI-Agenten zunehmend Analysen zu den aktuellsten Transaktionsdaten benötigen, verlangsamt diese Lücke die Teams. Das Kopieren von Daten zwischen zwei Systemen schafft auch Governance-Risiken: Die Abstammung kann zerbrechen, wenn Daten übertragen werden, was Verpflichtungen wie DSGVO-Löschungsanträge erschwert.

Wie LTAP Daten auf der Speicherschicht vereinheitlicht

Anstatt eine bessere Pipeline zwischen zwei Stacks zu bauen, macht LTAP eine Pipeline überhaupt überflüssig. Dies geschieht, indem die Datenbank vom Speicher ausgehend neu konzipiert wird.

Lakebase trennt bereits die statuslose Postgres-Rechenleistung von einer dauerhaften Speicherschicht aus Safekeepers, Pageservern und Cloud-Objektspeicher. Eine Transaktion wird committed, sobald ein Quorum von Safekeepers sein Write-Ahead-Protokoll dauerhaft aufzeichnet, und Pageserver übertragen diese Änderungen anschließend asynchron in den Cloud-Objektspeicher, sodass die Daten nicht mehr innerhalb einer einzigen Datenbank-Engine gesperrt sind.

LTAP fügt dieser Speicherschicht einen Schritt hinzu. Während der Lakebase-Speicher Daten in den Objektspeicher materialisiert, transkodiert er die zeilenorientierten Postgres-Daten in Parquets säulenartiges Layout, sobald die Daten im See landen, wo sie über offene Tabellenformate wie Delta und Iceberg lesbar sind. Diese Transkodierung ermöglicht es, dass eine einzelne Datenkopie sowohl OLTP- als auch OLAP-Workloads bedient. Sie ist so gestaltet, dass die Spaltenfassung eine getreue, effiziente Darstellung des Postgres-Originals bleibt:

• Semantik bleibt erhalten. Lakebase-Speicher transkodiert jeden Wert in seine Spaltenform, während die ursprüngliche Postgres-Darstellung erhalten bleibt, sodass jede Postgres-kompatible Engine die Daten neu interpretieren kann, ohne Informationen zu verlieren. Typen, die sich nicht eindeutig auf Parquet abbilden lassen, wie NaN, NUMERIC Überläufe oder Erweiterungstypen wie Vektor, Array, Geographie und JSON, werden in einem Überlauffeld beibehalten, das die kanonische Postgres-Darstellung enthält.
• Zeilenversionen bleiben erhalten. Die Transkodierung behält Zwischenzeilenversionen, sodass die Spaltenkopie dieselben Versionsinformationen wie die Zeilendaten enthält.
• Columnar-Daten komprimieren sich gut. Das spaltenförmige Layout ist stark komprimiert, was den Speicherbedarf und die Menge an Daten, die zu und von Objektspeicher übertragen werden, reduziert.

Die Transkodierung läuft vollständig in der Speicherschicht, isoliert von der primären Postgres-Instanz, sodass es Ihre transaktionale Serving-Workload nicht beeinflusst. Dies baut auf einer Funktion auf, die Lakebase bereits nutzt: dem Flushing von committeten Daten in den Cloud-Objektspeicher. LTAP fügt diesem Flush lediglich das spaltenorientierte Format hinzu. Es gibt keine Pipeline, die du aufbauen kannst, und keinen externen Prozess, der deine Datenbank abfragt.

Nicht alles ist transcodiert. Postgres-Indizes bleiben in ihrer ursprünglichen Form in der dauerhaften Speicherschicht, anstatt in Spalten umgewandelt zu werden, sodass transaktionale punktuelle Lesezugriffe und Nachschlagevorgänge schnell bleiben, während die spaltenorientierte Kopie für Analysen genutzt wird.

Da die Daten in externalisiertem, versioniertem Speicher liegen, ist das Erstellen eines Zweigs oder die Wiederherstellung auf einen bestimmten Zeitpunkt eine Metadatenoperation und keine physische Kopie. Sie können in Sekundenschnelle einen Branch einer großen Produktionsdatenbank erstellen, ein Experiment oder eine riskante Migration auf diesem Branch ausführen und ihn anschließend verwerfen, ohne die zugrunde liegenden Daten zu duplizieren.

Dieser Speicheransatz unterscheidet LTAP von Change Data Capture (CDC). Die CDC repliziert Daten aus Ihrem OLTP-Speicher in eine separate Analyse-Schicht, indem ein externer Prozess die primäre Datenbank kontinuierlich abfragt, und eine Pipeline, die Zeilenänderungen in Spaltendaten umwandelt, verwendet. Diese Pipeline verbraucht Ressourcen in deiner primären Transaktionsdatenbank, lässt dich Schemaänderungen und Randfälle selbst bearbeiten und tauscht Datenaktualität gegen Pipeline-Kosten ab, während sie gleichzeitig Fehlerpunkte hinzufügt. LTAP verfolgt stattdessen einen Speicher-Level-Ansatz: Lakebase Storage transkodiert Daten im Rahmen des normalen Speicherbetriebs in den Lake, ohne dass ein externer Prozess mit Ihrer Arbeitslast konkurriert und es keine Pipeline gibt, die Sie aufbauen oder warten können.

Die drei Säulen von LTAP

Das Vereinheitlichen von Daten auf der Speicherschicht verleiht LTAP drei definierende Eigenschaften.

• Universelle Regierung. Unity Catalog steuert den analytischen Zugriff auf eine logische Kopie Ihrer Daten über beide Workloads hinweg.
• Speziell entwickelte Motoren. Postgres bedient Transaktionen und das Lakehouse unterstützt Analysen, und keines von beiden beeinträchtigt das andere.
• Eine einzelne logische Kopie im offenen Speicher. Beide Engines lesen eine Kopie deiner Daten in offenen Formaten, ohne Repliken oder Pipelines, die synchron gehalten werden müssen.

Universelle Verwaltung

Unity Catalog regelt den analytischen Zugriff auf Ihre Daten über beide Workloads hinweg. Nachdem du eine Lakebase-Datenbank registriert hast, wendet Unity Catalog Berechtigungen, Lineage und Überwachung auf die externen Rechenressourcen an, die auf sie zugreifen.

Speziell entwickelte Motoren

Postgres bedient Ihre transaktionale Arbeitsbelastung und das Lakehouse bietet Analytics, jeweils mit den Stärken, für die es entwickelt wurde. Ein weit verbreitetes Missverständnis ist, dass die Vereinigung beider Dinge bedeutet, dass Ihre Betriebsdaten zu kalten Daten werden, die im Eisberg liegen. Das ist nicht der Fall. Lakebase bleibt standardmäßiges Postgres. Indexierung, Verzweigungen, Point-in-Time-Wiederherstellung, Erweiterungen sowie latenzarme Punktlese- und -schreibvorgänge funktionieren auch weiterhin genau so wie heute.

Analytische Lesevorgänge konkurrieren nicht mit Ihrer transaktionsbezogenen Arbeitslast, da sie von der primären Postgres-Instanz isoliert sind. Wenn eine Analyse-Engine wie Lakehouse//RT Live-Lakebase-Daten abfragt, liefert sie ein frisches, transaktionskonsistentes Ergebnis, ohne Daten zu kopieren:

• Die Engine liest den Großteil der Daten aus der Spaltenkopie im Objektspeicher, nicht aus Postgres.
• Um eine transaktionell konsistente Ansicht zu erhalten, fragt es Postgres nur nach der aktuellen Log-Sequenznummer (LSN), einem einzelnen Wert, der eine Position im Write-Ahead-Log markiert. Das ist eine günstige Metadatensuche.
• Eine kleine Menge sehr aktueller Änderungen, die noch nicht in den Lake übertragen wurden, wird vom Pageserver gelesen und anschließend darüber zusammengeführt.

Postgres bedient keinen analytischen Leseverkehr außer der Rückgabe dieses einzelnen LSN, und die Transkodierung läuft in der Speicherschicht, nicht auf der Postgres-Instanz, die Ihre Anwendung bedient. Deine operative Arbeitsbelastung läuft weiterhin wie erwartet.

Eine einzelne logische Kopie im offenen Speicher

Da die Daten im See als säulenförmiges Parquet liegen, das über offene Tabellenformate wie Delta und Iceberg lesbar ist, teilen Lakebase (OLTP) und Lakehouse (OLAP) dasselbe Speicherfundament. Sie führen eine logische Kopie der Daten über beide Arbeitslasten hinweg, anstatt eine transaktionale Datenbank mit einer separaten analytischen Kopie abzugleichen.

Jede Engine kann diese Daten für die Leistung in einem anderen physischen Format cachen oder darstellen. Lakebase nutzt Postgres-Seiten für schnelle OLTP-Punktabfragen, während Analytics-Engines spaltenorientiertes Parquet lesen. Man arbeitet weiterhin mit einem einzigen logischen Datensatz, anstatt separate transaktionale und analytische Kopien zu pflegen und sie synchron zu halten.

Jede Tabelle verfügt über einen einzigen Writer, entweder Lakebase oder das Lakehouse. Beide Engines lesen diese eine logische Kopie, sodass dieselben Daten deinen Anwendungen und der Analytik ohne zweite Kopie zur Verfügung stehen.

Musst du ändern, wie du Lakebase nutzt?

No. Die Einführung von LTAP-Funktionen erfordert keine Datenmigration oder eine Änderung der Verbindung Ihrer Anwendungen zu Lakebase. Lakebase bleibt Standard Postgres: Ihre bestehenden Erweiterungen, Indizes, Abfragen und Anwendungscode funktionieren weiterhin unverändert. Jede der LTAP-Funktionen ist unabhängig, sodass du jede davon übernehmen kannst, wann immer eine Arbeitslast sie benötigt.

Fähigkeiten, die LTAP implementieren

Man setzt die LTAP-Architektur durch eine Reihe von Lakebase-Fähigkeiten in die Praxis um. Jede baut auf der oben beschriebenen Shared-Storage-Grundlage auf und gemeinsam decken sie die Pfade ab, die Daten durch LTAP nehmen:

• Verwalten und registrieren: Lakebase-Daten unter den Unity-Katalog bringen.
• Lakehouse-Daten in Lakebase bereitstellen: synchronisierte Tabellen, beschleunigt durch LTAP Direct Writes.
• Abfrage von Live-Lakebase-Daten: Lakehouse//RT für Analysen, Lakebase Change Data Feed für Veränderungsströme.

Das folgende Diagramm zeigt, wie diese Funktionen in eine einzige Kopie Ihrer Daten schreiben und aus dieser lesen, die von Unity Catalog verwaltet wird.

Lakehouse//RT und Lakebase Change Data Feed lesen beide dieselben zugrundeliegenden Daten, stellen sie aber unterschiedlich dar. Lakehouse//RT liest den aktuellen Stand von Live-Postgres-Daten für Analysen. Change Data Feed stellt einen Stream von Änderungen auf Zeilenebene für nachgelagerte Pipelines und Audit-Zwecke bereit. Ebenso wenig ist es der externe CDC, den LTAP entfernt: Beide arbeiten mit der einzigen Datenkopie.

Die folgende Tabelle listet jede LTAP-Funktion und deren Tätigkeit sowie ihren Release-Status in Ihrer Cloud auf. Die Verfügbarkeit variiert je nach Cloud, daher wird eine Fähigkeit, die in Ihrer Cloud nicht angeboten wird, als nicht verfügbar markiert.

Wie man die Umsetzung angeht

Jetzt, da du die Funktionen kennst, stellt sich die Frage, welche davon deine Workload benötigt. Sie implementieren LTAP, indem Sie die Funktionen kombinieren, die dem Datenfluss durch Ihre Architektur entsprechen.

Die zentrale Entscheidung betrifft die Richtung: für jeden Datensatz, welches System die Schreibhoheit hat? Jede Tabelle hat einen einzelnen Schreiber, und das bestimmt, welche Fähigkeiten du nutzt.

• Lakebase ist für das Schreiben zuständig. Deine Anwendung schreibt an Postgres, und du willst diese operativen Daten für Analysen verfügbar haben, ohne sie zu kopieren. Zum Beispiel schreibt eine Verkaufsanwendung Bestellungen und Zahlungen an Lakebase, sobald sie stattfinden. Nutze Lakehouse//RT, um ein Live-Revenue Dashboard für diese Bestellungen zu führen, oder Lakebase Change Data Feed, um jede Auftragsänderung in eine Downstream-Pipeline oder ein Audit-Log zu streamen.
• Das Lakehouse ist für das Schreiben zuständig. Ihre Daten werden im Lakehouse erzeugt oder verwaltet, und Sie möchten aus Ihrer Anwendung heraus OLTP-Lesezugriffe mit geringer Latenz darauf durchführen. Zum Beispiel berechnet ein nächtlicher Seehaus-Job Produktempfehlungen oder eine Preistabelle. Verwenden Sie synchronisierte Tabellen , um diese Daten in Lakebase zu liefern, damit Ihre Anwendung sie mit geringer Latenz lesen kann, und aktivieren Sie LTAP Direct Writes, um die Erstladung einer großen Tabelle zu beschleunigen.

Ordnen Sie jeden Datensatz einem dieser Pfade zu, registrieren Sie die Datenbank im Unity Catalog für Governance-Zwecke und folgen Sie dann der Dokumentation zu den jeweiligen Funktionen, um den jeweiligen Pfad umzusetzen. Eine einzelne Anwendung nutzt oft beide Richtungen: Sie stellt Referenzdaten aus dem Lakehouse in Postgres bereit und führt ihre eigenen transaktionalen Schreibvorgänge wieder der Analytik zu. Die Verfügbarkeit variiert je nach Cloud, also schau dir die obige Fähigkeitstabelle an, um zu bestätigen, was in deiner Cloud angeboten wird.

Nächste Schritte

• Lakebase-Architektur: Verstehen Sie, wie Lakebase stateless Compute von dauerhaftem Speicher trennt. Siehe Lakebase-Architektur.
• Registrieren Sie eine Datenbank im Unity-Katalog: Verwalten Sie Lakebase-Daten und fragen Sie sie im Lakehouse ab. Siehe Registrieren einer Lakebase-Datenbank im Unity-Katalog.
• Daten mit synchronisierten Tabellen bereitstellen: Synchronisieren Sie Unity-Catalog-Tabellendaten in Lakebase für latenzarme Lesevorgänge und beschleunigen Sie große Lasten mit LTAP Direct Writes. Siehe Lakehouse-Daten mit synchronisierten Tabellen bereitstellen.

• Lakebase Change Data Feed: Überträgt Änderungen auf Zeilenebene an das Lakehouse für Pipelines und Auditzwecke. Siehe Lakebase Change Data Feed.

Weitere Informationen

• Ankündigung: Databricks bringt LTAP auf den Markt: die erste Lake Transactional/Analytical Processing-Architektur
• Ingenieur-Blog: Vom Monolithen über Lakebase bis LTAP: Die Datenbank von der Speicherung aufwärts neu denken
• Demo: LTAP: Die erste Lake Transactional/Analytical Processing-Architektur