Apache Iceberg mit versioniertem Katalog, auf Ihrem Storage

Data Lake und Data Warehouse in einer Architektur

Ein Data Lake hält Daten in einem gemeinsamen Speicher für unterschiedliche Verarbeitungen. Ein Data Warehouse stellt strukturierte Daten für wiederkehrende Analysen bereit. Die Lakehouse-Architektur von lavalake verbindet Objektspeicher mit verwalteten Iceberg-Tabellen und SQL-Abfragen über Trino. So können Teams Daten aufbereiten und für Kennzahlen verwenden, während der Speicher in ihrer Infrastruktur bleibt.

Apache Parquet und Iceberg: Datei und Tabelle

Apache Parquet ist ein spaltenorientiertes Dateiformat. Iceberg verwaltet darüber die Tabelle, ihre Metadaten und ihre Stände. Die Unterscheidung ist wichtig: Eine einzelne Parquet-Datei beschreibt noch nicht den vollständigen Zustand einer Iceberg-Tabelle. Für einen konsistenten Zugriff müssen auch die zugehörigen Tabellenmetadaten berücksichtigt werden.

Big-Data-Architektur: Speicher, Katalog und Rechenleistung

In lavalake übernimmt S3-kompatibler Storage die Speicherung, Nessie den versionierten Katalog und Trino die SQL-Verarbeitung. Diese Aufteilung macht die Aufgaben der Komponenten sichtbar. Bei der Dimensionierung zählen Datenmenge, Abfrageform und gleichzeitige Nutzer; die passende Größe sollte anhand eigener Arbeitslasten geprüft werden.

Änderungen gezielt weiterverarbeiten

Streams merken sich den Lesestand einer Tabelle und liefern die Nettoänderungen für nachgelagerte Verarbeitung. Zeitreise und Arbeitskopien helfen dabei, frühere Stände zu prüfen und Änderungen vorzubereiten.

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.

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

Iceberg-Wartung nach Zeitplan

Regeltermine können Dateien verdichten, alte Snapshots verwerfen und verwaiste Dateien entfernen. Die Aufbewahrung ist zwischen 7 und 365 Tagen wählbar, mit 7 Tagen als Vorgabe. Erst ein eingerichteter Wartungstermin startet diese Arbeiten; danach reicht Time Travel nur noch über die erhaltenen Snapshots zurück.

Leistungsklassen auf einer Maschine

Der Compose-Stapel teilt Abfragen anhand der Nutzerrolle in S, M und L ein. Die Klassen begrenzen gleichzeitige Abfragen und setzen weiche Speichergrenzen. Sie steuern die vorhandene Rechenleistung; zusätzliche Rechenknoten erweitern den gemeinsamen Cluster. Eigene Warehouse-Cluster stehen im Kubernetes-Weg bereit; deren KEDA-Betrieb wartet noch auf die Cluster-Abnahme.

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
• Eigene Warehouse-Cluster auf Kubernetes; KEDA-Praxisabnahme offen