Zum Inhalt springen
MCP-Server eingebautWie das funktioniert
Zurück zum Plattform-Überblick

Lakehouse & Storage

Apache Iceberg mit versioniertem Katalog, auf Ihrem Storage

Der Kern von lavalake ist kein eigenes Tabellenformat, sondern ein offenes: Apache Iceberg auf S3-kompatiblem Objektspeicher, verwaltet über einen versionierten Katalog. Das ist die Schicht, die entscheidet, ob Sie Ihre Daten später noch woanders lesen können.

Tabellenformat
Apache Iceberg
Katalog
Nessie, versioniert
Engine
Trino
Speicher
S3-kompatibel

Warum das Format die wichtigste Entscheidung ist

Bei einem klassischen Warehouse liegen Ihre Tabellen in einem Format, das nur dieses Warehouse liest. Der Wechsel zu einem anderen Anbieter ist dann kein Konfigurationsschritt, sondern ein Exportprojekt. Iceberg dreht das: die Tabelle besteht aus Parquet-Dateien und einer Metadatenschicht, die offen spezifiziert ist. Spark, Flink und Trino lesen dieselbe Tabelle, ohne dass jemand etwas umkopiert.

Für ein Produkt, dessen Versprechen Datenhoheit ist, ist das kein Detail am Rand. Datenhoheit heißt nicht nur, dass die Festplatte in Ihrem Serverraum steht – sie heißt auch, dass Sie die Daten ohne Mitwirkung des Herstellers weiterverwenden können.

Offener Speicherort und offenes Format sind zwei verschiedene Dinge. Nur beides zusammen ergibt Unabhängigkeit.

Der Katalog ist versioniert

Über den Iceberg-Tabellen liegt Nessie – ein Katalog, der sich wie Git verhält. Es gibt einen Hauptzweig, es gibt Zeitpunkte, und es gibt die Möglichkeit, einen Stand abzufragen, ohne den aktuellen anzutasten. Praktisch heißt das: ein Stichtag ist reproduzierbar, auch wenn die Tabelle seither weitergeschrieben wurde.

Worksheet
-- Aktueller Stand
SELECT count(*) FROM lakehouse.raw.auftraege;

-- Derselbe Blick, Stand 1. August
SELECT count(*) FROM lakehouse.raw.auftraege
FOR TIMESTAMP AS OF TIMESTAMP '2026-08-01 00:00:00';

Der Unterschied zu einem Datenbank-Backup ist wesentlich. Ein Point-in-Time-Recovery setzt einen ganzen Cluster auf einen Zeitpunkt zurück. Time Travel fragt eine einzelne Tabelle zu einem Zeitpunkt ab, während alles andere aktuell bleibt – im laufenden Betrieb, aus einer gewöhnlichen Abfrage heraus.

Storage und Compute sind getrennt

Die Daten liegen im Objektspeicher, die Engine greift von außen darauf zu. Das ist dasselbe Architekturprinzip, mit dem Cloud-Warehouses arbeiten – nur dass beide Hälften bei Ihnen stehen. Speicher wächst, ohne dass Rechenkapazität mitwachsen muss, und umgekehrt.

SchichtWas läuft dortIhre Wahl
EngineTrino, verteiltAnzahl Worker
KatalogNessiemitgeliefert
TabellenformatApache Icebergoffen, auch für Spark und Flink
ObjektspeicherS3-ProtokollMinIO, Ceph, StorageGRID, Dell ECS

Zum Ausprobieren bringt lavalake MinIO mit, sodass der ganze Stapel auf einer Maschine läuft. Im Betrieb zeigen Sie stattdessen auf den Objektspeicher, der bei Ihnen schon steht.

Was Trino dabei erzwingt

Jede Anweisung läuft unter dem eingetauschten Token des angemeldeten Nutzers. Damit entscheiden Trinos eigene Grants und die Row-Access- und Masking-Policies, was in einer Ergebnismenge landet – nicht die Oberfläche, die die Abfrage abgeschickt hat. Diese Kette ist der Grund, warum auch Suchtreffer und Dashboard-Kacheln je Betrachter unterschiedlich ausfallen können.

  • ACID-Transaktionen auf Tabellenebene
  • Schema Evolution, ohne die Tabelle neu zu schreiben
  • Time Travel und Branching über den Nessie-Katalog
  • Partitionierung, die sich ändern darf, ohne alte Daten anzufassen
  • Elastische Compute-Cluster mit Auto-SuspendIn Entwicklung

Sehen, statt nachzulesen

In einer halben Stunde zeigen wir die Plattform an Ihren Fragen – Ingestion, Rechte, Suche, Agent. Ohne Folien.

Live-Demo buchen