Databricks trennt mit Lakebase die Datenbank in ihre Bausteine und legt Postgres-Daten als Parquet-Dateien auf S3 ab. Der Compute-Layer wird zustandslos, der Speicher wächst elastisch. Die Architektur trägt einen neuen Namen: LTAP.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Die LTAP-Architektur von Databricks verspricht fünffach höheren Schreibdurchsatz und halbierte Leselatenz, weil operative Postgres-Daten nur noch einmal existieren, direkt als spaltenorientiertes Parquet im Objektspeicher. Der bisher übliche zweite Datenbestand für Analysen entfällt komplett. Damit rückt eine Entkopplung von Speicher und Rechenleistung in die Datenbank selbst, die im Data-Warehouse längst Standard ist.
Das Wichtigste in Kürze
- LTAP steht für Lake Transactional/Analytical Processing und speichert operative Daten einmalig in offenen Spaltenformaten.
- Postgres schreibt weiter zeilenweise, ein PageServer wandelt die Seiten beim Materialisieren in Parquet um.
- Databricks nennt fünffachen Schreibdurchsatz, halbierte Leselatenz und mehr als zehnfache Kompression gegenüber Zeilendaten.
- Für DACH-Firmen zählt weniger das Format, mehr die Frage nach dem Katalog und der Datenhoheit.
Wie funktioniert die Trennung von Speicher und Rechenleistung?
Lakebase zerlegt die klassische Datenbank in unabhängige Dienste, sodass die Rechenschicht keine Daten mehr besitzt und beliebig hoch- oder herunterfahren kann. Ein SafeKeeper sichert das Write-Ahead-Log über Paxos-Replikation im Netz ab, statt sich auf eine einzelne Festplatte zu verlassen. Ein PageServer verwaltet die Datendateien, zieht die Log-Änderungen asynchron nach und schreibt die Seiten in den Objektspeicher.
Beim Materialisieren übersetzt der PageServer die Zeilen von Postgres in das spaltenorientierte Parquet-Format, während die Daten im Lake landen. Werte ohne direktes Spalten-Äquivalent, etwa NaN oder Unendlich, wandern in ein separates Überlauffeld und gehen nicht verloren. So bleibt die exakte Postgres-Darstellung bis aufs Bit erhalten, und trotzdem profitieren Analysen von der Spaltenstruktur.
Der Nutzen steckt in der Ökonomie des Objektspeichers. Der Speicher skaliert praktisch unbegrenzt und kostet einen Bruchteil klassischer Datenbankvolumes, die Rechenleistung fällt bei Leerlauf auf null. Analytische Abfragen holen den aktuellen Log-Stand von Postgres, lesen den Großteil der Daten direkt aus dem Objektspeicher und greifen nur für die jüngsten Änderungen auf den PageServer zu. Der Transaktionsbetrieb bleibt dabei ungestört.
Was Databricks‘ Lakebase-Architektur für Ihre Datenkosten bedeutet
Klassisches Warehouse gegen LTAP
- × Postgres plus separates Warehouse
- × CDC-Pipeline mit Zeitverzug
- × Doppelte Speicherkosten
- × Analysen bremsen den Betrieb
- ✓ Parquet einmalig im Objektspeicher
- ✓ Keine Pipeline nötig
- ✓ Compute skaliert auf null im Leerlauf
- ✓ Analysen ohne Transaktions-Störung
Warum ist der Trend zum entkoppelten Lakehouse mehr als Marketing?
Der eigentliche Fortschritt liegt im Wegfall der Datenpipeline zwischen operativem und analytischem System. Bislang hat ein Change-Data-Capture-Prozess Transaktionsdaten in ein zweites Warehouse gespiegelt, mit Zeitverzug, doppelten Kosten und ständiger Bruchgefahr. LTAP lässt beide Welten dieselbe frische Kopie lesen. Analysen laufen auf den Daten, die eine Transaktion gerade geschrieben hat.
Der Weg dorthin folgt einem Muster, das Snowflake und die frühen Lakehouse-Anbieter im Warehouse-Bereich vorgezeichnet haben. Databricks zieht diese Entkopplung nun bis in die Transaktionsdatenbank durch. Genau diese Verschiebung macht die Meldung für Entscheider relevant, die heute über ihre Datenarchitektur nachdenken. Bei neuen Projekten gehören offene Tabellenformate wie Delta oder Iceberg zur Bedingung, statt einer Bindung an ein proprietäres Speicherformat.
Offene Dateiformate lösen den Lock-in nicht auf, sie verschieben ihn nur nach oben.
— Markus Seyfferth, Chefredakteur Dr. Web
Was bedeutet LTAP für Datenarchitektur-Entscheidungen im DACH-Raum?
Das offene Format ist ein echter Vorteil, taugt aber nicht als Garantie gegen den Anbieter-Lock-in. Parquet, Delta und Iceberg liegen als öffentliche Spezifikationen vor, jede kompatible Engine liest die Dateien. Der Formatstreit gilt inzwischen als entschieden, Iceberg hat sich durchgesetzt. Damit wandert die eigentliche Bindung eine Ebene höher, zum Katalog und zur Governance-Schicht, die den Zugriff steuert. Über diese Verschiebung schweigt der Databricks-Beitrag.
Für Unternehmen in Deutschland, Österreich und der Schweiz zählt darum das Betriebsmodell mehr als das Datenblatt. Wo liegen die S3-Buckets, welche Cloud-Region, welcher Datenschutz? Ein Lakehouse lässt sich DSGVO-konform betreiben, doch die Datenresidenz und die Audit-Fähigkeit gehören vor der Migration geklärt. Ähnliche Abwägungen zeigen sich derzeit quer durch die Branche, etwa bei der Frage, warum unfertige Software zur Norm wird oder wie ein Passwortmanager ganz ohne Cloud auskommt.
Der konkrete To-do-Punkt für IT-Entscheider lautet: die Exit-Kosten vorab durchrechnen. Offene Dateien im eigenen Bucket klingen nach Freiheit, doch ohne portablen Katalog bleibt der Wechsel teuer. Für die Kompressionsvorteile und die einfache Hochverfügbarkeit gehört im Vertrag die Herausgabe der Metadaten und die Katalog-Portabilität festgeschrieben. So bleibt die Kostenersparnis echt und der spätere Umzug bezahlbar.
Mehr Newshunger?
- Halbgare Produkte: Warum unfertige Software zur Norm wird
- Bramble: Ein Local-first-Passwortmanager ohne Cloud
- Code als Bild: KI-Kosten um 60 Prozent senken
- Macht Würth die Lieferkette digital? Eine Übernahme zeigt es
- Standortübergreifende Überwachung: Alle Werke im Blick
- NLnet fördert 67 Open-Source-Projekte für ein freies Internet
