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.
-- 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.
| Schicht | Was läuft dort | Ihre Wahl |
|---|---|---|
| Engine | Trino, verteilt | Anzahl Worker |
| Katalog | Nessie | mitgeliefert |
| Tabellenformat | Apache Iceberg | offen, auch für Spark und Flink |
| Objektspeicher | S3-Protokoll | MinIO, 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