Das spart Kosten, löst Lizenzabhängigkeiten – und wirft Fragen auf: Was sind Parquet, Delta Lake, Iceberg? Kurze Antwort: Nicht so viel Neues. Nur anders verpackt.
Die bekannte Welt
Hinter jedem CREATE TABLE in Oracle oder PostgreSQL stecken mehrere Schichten:
- Datenspeicher: Datafiles im Tablespace – dort liegen die Daten physisch.
- Tabellendefinition: Spaltennamen, Datentypen, Constraints - das Schema.
- System Catalog: DBA_TABLES, pg_catalog - das Verzeichnis aller Objekte und Statistiken.
- Indizes: B-Tree, Bitmap – beschleunigen Abfragen durch gezielte Zugriffspfade.
Die Datenbank-Engine verwaltet all das als Einheit. Die Daten gehören der Engine.
Alte Konzepte, neue Verpackung
Im Lakehouse existieren dieselben Schichten – nur entkoppelt von einer einzelnen Engine.
Datenspeicher → Parquet auf Object Storage
Apache Parquet ist das Äquivalent zum Datafile: spaltenbasiert, komprimiert, mit eingebetteten Statistiken. Wie ein Column Store, nur als offene Datei auf Object Storage (Azure Blob, S3, GCS) statt im proprietären Tablespace. Die Daten gehören dem Unternehmen, nicht der Engine.
Tabellendefinition → Delta Lake oder Apache Iceberg
Ein Verzeichnis voller Parquet-Dateien ist nur ein Haufen Dateien – keine Tabelle. Delta Lake und Apache Iceberg ergänzen eine Metadatenschicht: Schema-Evolution (Spalten hinzufügen, umbenennen – ohne Rewrite), Time Travel (ältere Versionen abfragen) und ACID-Transaktionen auf Tabellenebene. Iceberg hat das breitere Engine-Ökosystem, Delta Lake die tiefere Databricks-Integration. Beide basieren auf Parquet.
System Catalog → Iceberg REST Catalog, Unity Catalog und Co.
Woher weiß eine Engine, wo auf dem Object Storage die aktuelle Version einer Tabelle liegt? Dafür gibt es den Catalog – das Äquivalent zu pg_catalog oder DBA_TABLES. Er hält den Pointer auf die aktuellen Metadaten und übernimmt die Concurrency Control, wenn mehrere Engines gleichzeitig schreiben.
Indizes → Data Skipping, Clustering und Partitionierung
Klassische B-Tree-Indizes gibt es nicht. Stattdessen nutzen Iceberg und Delta Lake Statistiken auf Metadatenebene (Min/Max-Werte pro Datei und Partition), um irrelevante Dateien beim Lesen zu überspringen. Dazu kommen Clustering (Z-Ordering, Hilbert-Kurven) und Partitionierung.
Was fehlt
Constraints wie Primary Keys oder Fremdschlüssel existieren oft nur als Metadaten für den Optimizer, ohne dass sie tatsächlich geprüft oder erzwungen werden. Tabellenübergreifende Transaktionen gibt es nicht. Saubere Datenmodellierung wird dadurch nicht weniger wichtig – im Gegenteil.
Fazit
Tablespace, System Catalog, Schema-Evolution, Indizes – alles da, nur anders verpackt. Wer relationale Datenbanken versteht, versteht auch schnell die Lakehouse-Welt. Das Fundament ist dasselbe. Databricks, Snowflake, Microsoft Fabric, Dremio, DuckDB und Spark basieren auf genau diesen Konzepten. PostgreSQL bietet mit pg_lake bereits gute Iceberg-Unterstützung, Oracle bisher nur ansatzweise in der Autonomous Cloud. Iceberg und Delta Lake halten in produktiven Umgebungen, was sie versprechen: kosteneffizient, performant, zuverlässig und wartbar – auch in Branchen, wo Stabilität und Nachvollziehbarkeit keine Option, sondern Pflicht sind.
Andreas Buckenhofer
Senior Data Architect bei Adam Riese in Controlling, Finanzen, Datenmanagement & Regulatorik
Kontakt: Andreas.Buckenhofer@adam-riese.de
