Databricks Lakebase: Was LTAP für deine Datenplattform ändert

Eine Anwendung schreibt Aufträge in Postgres, während das Controlling dieselben Daten im Lakehouse auswertet. Dazwischen liegt häufig eine Pipeline, die Änderungen überträgt und eine zweite Datenhaltung aktuell halten muss. Databricks Lakebase setzt mit seiner LTAP-Architektur anders an: Der Data Lake soll die gemeinsame Speichergrundlage für operative Datenbankzugriffe und Analytics bilden. Databricks erläutert jetzt technische Details dieses Ansatzes. Für dich ist vor allem entscheidend, welche Integrationsarbeit dadurch entfällt – und welche weiterhin notwendig bleibt.

Kurz gesagt: Die beschriebene LTAP-Architektur von Lakebase nutzt den Data Lake als dauerhafte Speicherbasis der Datenbank, nicht als nachgelagerte Replik. Postgres-Zugriffe und analytische Abfragen verwenden unterschiedliche physische Darstellungen derselben Daten; aktuelle Änderungen werden für Analytics bei Bedarf aus den Pageservern ergänzt. Dadurch soll eine separate CDC-Pipeline zur Herstellung einer Lake-Kopie entfallen, ohne auf konsistente Abfragestände zu verzichten.

Was ist neu an Databricks Lakebase und LTAP?

Neu an der beschriebenen LTAP-Architektur ist, dass Postgres und Analytics auf einer gemeinsamen dauerhaften Datengrundlage arbeiten, statt zwei eigenständige Datenbestände durch Replikation abzugleichen.

Der aktuelle Beitrag konkretisiert diese Architektur; er ist nicht mit einer pauschalen Verfügbarkeitszusage für jede Azure-Umgebung gleichzusetzen. Databricks beschreibt insbesondere, wie Speicherhierarchie, Datenformate und konsistente Lesezugriffe zusammenspielen.

Bei einer klassischen CDC-Anbindung, also Change Data Capture, werden Änderungen aus einer Quelldatenbank in ein Zielsystem übertragen. Beide Seiten besitzen einen eigenen Datenstand und müssen synchron gehalten werden. LTAP soll diesen zusätzlichen Abgleich für die Lakebase-Daten vermeiden: Die Tabelle liegt dauerhaft im Lake, während vorgelagerte Speicherstufen schnelle Datenbankzugriffe ermöglichen.

Eine gemeinsame Datengrundlage bedeutet dabei nicht, dass jedes Byte nur einmal gespeichert wird. Logs, Caches und weitere physische Strukturen bleiben erforderlich. Der Unterschied liegt darin, dass diese Schichten keine unabhängig nutzbare zweite Datenbank mit eigener Zeitlinie bilden.

Wo liegt der Nutzen für den Mittelstand?

Der größte mögliche Nutzen liegt in weniger Integrationsbetrieb zwischen operativer Anwendung und analytischer Plattform. Gerade wenn ein kleines Datenteam viele Schnittstellen betreut, ist jede zusätzliche Synchronisationsstrecke eine dauerhafte Betriebsaufgabe.

Ein denkbares Einsatzfeld ist eine selbst entwickelte Serviceanwendung: Mitarbeitende bearbeiten Vorgänge in Postgres, während das Unternehmen Bearbeitungsstände und Auslastung in Databricks analysiert. Eine gemeinsame Speicherbasis kann hier die technische Trennung zwischen Anwendung und Auswertung reduzieren.

Für die Bewertung solltest du drei Fragen auseinanderhalten:

• Datenübertragung: Wird eine Pipeline nur benötigt, um operative Tabellen überhaupt im Lake verfügbar zu machen?
• Datenaufbereitung: Welche Transformationen, Qualitätsprüfungen und fachlichen Modelle brauchen deine Auswertungen?
• Systemintegration: Welche weiteren Quellen und Empfänger müssen unabhängig von Lakebase angebunden bleiben?

LTAP adressiert vor allem die erste Aufgabe. Es ersetzt weder die Vereinheitlichung von Artikelnummern noch fachliche Kennzahlenmodelle oder die Anbindung externer Systeme. Bei der Planung deiner Datenplattform bleibt diese Trennung wichtig: Weniger Transportlogik bedeutet nicht automatisch weniger fachliche Datenarbeit.

Wie bleiben Postgres-Zugriffe und Analytics gleichzeitig schnell?

Postgres-Zugriffe und Analytics nutzen in der beschriebenen Architektur unterschiedliche verlustfreie Darstellungen derselben Tabellen: Heap Pages für operative Zugriffe und Parquet für analytische Scans.

Unterschiedliche Zugriffsmuster brauchen unterschiedliche Formate

Eine Anwendung liest häufig einen einzelnen Datensatz anhand einer ID. Eine Auswertung untersucht dagegen viele Zeilen und nur bestimmte Spalten. Ein einziges physisches Layout wäre für diese beiden Aufgaben meist ein Kompromiss.

Lakebase verwendet deshalb Postgres Heap Pages für Einzelzugriffe und Änderungen. Analytische Engines lesen Parquet-Dateien hinter Delta oder Iceberg. Zusätzliche physische Metadaten ermöglichen es, die ursprünglichen Seiten aus der spaltenorientierten Darstellung wiederherzustellen. Werte, die Parquet nicht verlustfrei abbilden kann, werden laut Architektur über ein zusätzliches Feld erhalten.

Caches und Pageserver bleiben zentral

Ein Schreibvorgang ist dauerhaft abgesichert, sobald sein Write-Ahead Log, kurz WAL, ein Quorum der sogenannten Safekeepers erreicht hat. Der Pageserver verarbeitet das Log, hält häufig benötigte Seiten vor und materialisiert Daten im Object Storage. Lesezugriffe verwenden zunächst lokale Caches und bei Bedarf den Pageserver.

Die gemeinsame Speichergrundlage beseitigt damit nicht alle Leistungsfragen. Insbesondere folgen die erzeugten Parquet-Dateien zunächst der Reihenfolge der Postgres-Seiten. Für häufige Auswertungen nach Bestelldatum oder Produktgruppe kann eine anders organisierte, abgeleitete Tabelle weiterhin sinnvoll sein. LTAP spart nicht zwangsläufig das analytische Datenmodell.

Wie aktuell und konsistent sind analytische Abfragen?

Analytische Abfragen lesen im beschriebenen LTAP-Zugriffsweg einen konsistenten Stand, indem sie materialisierte Daten im Object Storage um jüngere Änderungen aus den Pageservern ergänzen.

Dafür ermittelt die Abfrage zu Beginn eine Log Sequence Number, kurz LSN, als gemeinsamen Grenzpunkt. Der überwiegende Teil der Daten kommt aus dem Lake. Änderungen, die bis zu diesem Grenzpunkt bereits bestätigt, aber noch nicht dort materialisiert sind, werden ergänzend gelesen.

Das ist auch für Verknüpfungen mehrerer Tabellen relevant: Auftrag und Auftragspositionen sollen zum selben logischen Stand ausgewertet werden. Unterschiedliche Fortschritte einzelner Übertragungspipelines sollen diesen Stand nicht auseinanderziehen.

Dabei gelten zwei wichtige Grenzen:

• Eine laufende Abfrage sieht keine Änderungen nach ihrem gewählten Grenzpunkt. Das ist konsistentes Lesen, kein Übertragungsfehler.
• Die beschriebene Aktualität entsteht durch den integrierten Zugriff einschließlich der Pageserver. Ein Werkzeug, das ausschließlich vorhandene Parquet-Dateien liest, erhält diese Eigenschaft nicht automatisch.

Für deine Architekturprüfung ist deshalb der konkrete Leseweg entscheidend, nicht allein das Vorhandensein eines offenen Tabellenformats.

Was solltest du bei Azure und Databricks prüfen?

Für eine Azure-/Databricks-Landschaft solltest du zuerst Verfügbarkeit, unterstützte Zugriffswege und Betriebsanforderungen prüfen, bevor du bestehende Replikationsstrecken ablöst.

Der Architekturansatz macht eine beliebige bestehende Postgres-Installation nicht automatisch zur LTAP-Datenbank. Ebenso wenig folgt daraus, dass alle beschriebenen Mechanismen bereits in jeder Region und Produktkonfiguration bereitstehen. Der Beitrag bezeichnet APIs zum Lesen jüngster Änderungen seit einem Grenzpunkt ausdrücklich als in Entwicklung.

Eine belastbare Prüfung umfasst:

• Produktumfang: Welche Lakebase-Funktionen sind in deiner vorgesehenen Umgebung verfügbar und unterstützt?
• Anwendungskompatibilität: Passen benötigte Postgres-Erweiterungen, Verbindungen und Transaktionsmuster?
• Sicherheit: Wie werden Identitäten, Netzwerkzugriffe, Berechtigungen und Datenresidenz umgesetzt?
• Betrieb: Wie funktionieren Wiederherstellung, Monitoring und die Behandlung von Ausfällen?
• Wirtschaftlichkeit: Wie verändern sich Compute-, Speicher- und Betriebskosten unter deiner tatsächlichen Last?

Ein begrenzter technischer Pilot sollte Einzelzugriffe, Schreiblast und analytische Abfragen gemeinsam untersuchen. Vorhandene CDC-Strecken bleiben dort relevant, wo andere Quellsysteme angebunden oder Änderungen an weitere Empfänger verteilt werden müssen.

Was das für dich bedeutet

Lakebase LTAP ist besonders interessant, wenn du Postgres-Anwendungen und Databricks enger verbinden möchtest und heute viel Aufwand in die Synchronisation ihrer Daten steckst. Der mögliche Vorteil liegt in einer einfacheren Speicher- und Integrationsarchitektur – nicht im Wegfall von Governance, Datenmodellierung oder Betriebsverantwortung.

Prüfe deshalb zuerst einen klar abgegrenzten Anwendungsfall. Ailio unterstützt dich als Databricks-Partner bei der Architekturentscheidung und der technischen Bewertung. Sprich mit uns über deine Databricks-Architektur.

Redaktionelle Aufbereitung und Einordnung auf Basis des Databricks-Blogbeitrags „Dispelling LTAP myths“.