Der richtige Treibstoff: Die Evolution der Tabellenformate im Lakehouse
- Databricks
- Databricks
- 5 Min Lesezeit
Tobias Vogler
Die Auswahl der Speicher- und Metadatenarchitektur ist das wichtigste und zugleich oft unterschätzteste Fundament einer modernen Datenplattform. Fehlentscheidungen an dieser Stelle ziehen Performance-Engpässe, inkonsistente Datenzustände und explodierende Speicherkosten nach sich.
Wie eine Rakete den falschen Treibstoff nicht verzeiht, verzeiht eine Datenplattform die falsche Formatentscheidung nicht. Dieses Wiki räumt mit dem Missverständnis auf, dass Dateiformate wie Apache Parquet und Tabellenformate wie Delta Lake konkurrierende Technologien sind. Es erzählt die Geschichte, wie sie als symbiotische Schichten das moderne Data Lakehouse definieren – und warum die Wahl des richtigen Treibstoffs über Erfolg oder Absturz Ihrer Datenplattform entscheidet.
Inhaltsverzeichnis
- 1. Executive Summary: Die Synthese aus Data Warehouse und Data Lake
- 2. Die Tanks: Warum Parquet der universelle Behälter für analytischen Treibstoff ist
- 3. Missionskontrolle: Delta Lake als intelligenter Storage-Layer
- 4. Der offene Markt: Delta Lake vs. Apache Iceberg vs. Apache Hudi
- 5. Fazit und Architektur-Empfehlung
1. Executive Summary: Die Synthese aus Data Warehouse und Data Lake
Die Geschichte der modernen Datenarchitektur ist geprägt von einem scheinbar unlösbaren Dilemma. Auf der einen Seite stand das klassische DWH (Data Warehouse). Es bot verlässliche ACID-Transaktionen (Atomicity, Consistency, Isolation, Durability – also Atomarität, Konsistenz, Isolation und Dauerhaftigkeit), strikte Concurrency (parallele Zugriffe), Schema-Validierung und performante Dateneingriffe mittels DML (Data Manipulation Language wie UPDATE oder DELETE). Der Preis dafür war jedoch hoch: Proprietäre Systemgrenzen, mangelnde Flexibilität bei unstrukturierten Daten wie Videos oder Freitexten und eine starre Kopplung von Rechenleistung (Compute) und Speicher (Storage), die Skalierungsprojekte extrem teuer machte.
Auf der anderen Seite lockte der Data Lake mit Freiheit und Kosteneffizienz: billiger Cloud-Speicher (Object Storage), eine strikte Trennung von Rechenleistung und Speicher, und die Fähigkeit, beliebige Datenmengen – strukturiert oder unstrukturiert – abzulegen. Klingt verheissungsvoll. Doch ohne ordnende Struktur verwandelten sich diese Speicherseen schnell in unbrauchbare Datensümpfe (Data Swamps): Transaktionssicherheit, Multi-User-Garantien und verlässliches Schema-Management fehlten schlicht.
Die moderne Lösung heisst Data Lakehouse – und sie ist tatsächlich so elegant wie sie klingt. Statt das Rad neu zu erfinden, setzt sie eine intelligente Metadaten-Ebene (das sogenannte Table Format) direkt auf bestehende, hocheffiziente Dateiformate auf. Das Ergebnis ist architektonisch bahnbrechend: Zum ersten Mal vereint eine Plattform die Verlässlichkeit, Governance und Transaktionssicherheit eines klassischen Data Warehouse mit der Kosteneffizienz, Offenheit und Skalierbarkeit eines Data Lakes. Kein Kompromiss – sondern das Beste aus beiden Welten, auf einer gemeinsamen, offenen Infrastruktur.
2. Die Tanks: Warum Parquet der universelle Behälter für analytischen Treibstoff ist
Bevor wir den richtigen Treibstoff wählen können, brauchen wir den passenden Tank. Unsere Reise beginnt auf der reinen Dateiebene. Hier hat sich Apache Parquet als der weltweite De-facto-Standard für analytische Workloads etabliert. Parquet speichert relationale und tabellarische Daten nicht zeilenweise (wie traditionelle CSV- oder JSON-Dateien), sondern in hochkomprimierten Spaltenblöcken (Columnar Storage).
Diese physische Anordnung erlaubt es der Abfrage-Engine, zwei fundamentale Optimierungsmechanismen direkt beim Lesezugriff zu nutzen:
- Column Pruning (Spalten-Projektion): Wenn eine analytische Abfrage nur 3 von 150 Spalten einer Tabelle benötigt, liest die Engine physikalisch auch nur die Blöcke dieser 3 Spalten ein. Der restliche Lese- und Schreibaufwand (I/O) entfällt komplett.
- Predicate Pushdown (Zeilen-Filterung): Parquet-Dateien enthalten in ihren Dateifusszeilen (Footern) statistische Minimal- und Maximalwerte für jeden Datenblock. Die Engine kann dadurch bereits vor dem eigentlichen Einlesen ganzer Dateien entscheiden, ob ein gesuchter Datensatz (z. B. Kunde_ID = 45982) überhaupt in diesem Block existieren kann. Nicht relevante Datei-Partitionen werden sofort übersprungen.
Der Konstruktionsfehler: Warum rohe Parquet-Seen abstürzen
Obwohl Parquet als Dateiformat extrem effizient ist, stösst es isoliert in Enterprise-Szenarien an eine logische Grenze. Eine Geschäftstabelle besteht in der Praxis aus tausenden einzelnen Parquet-Dateien. Ohne eine übergeordnete Instanz führt das zu massiven Problemen:
Wenn ein ETL-Prozess (Extract, Transform, Load) neue Dateien schreibt, während ein Analyst dieselbe Tabelle abfragt, sieht der Analyst inkonsistente Teilzustände, da es keine parallele Zugriffskontrolle gibt. Zudem erfordert jedes UPDATE oder DELETE das vollständige Einlesen, Modifizieren und Neuschreiben von Millionen Zeilen in neuen Dateien – ein massiver Performance-Killer.
Also, wer Parquet ohne Metadaten-Layer einsetzt, macht dasselbe wie jemand, der versehentlich Diesel tankt: Der Tank ist voll, aber der Motor läuft einfach nicht.
3. Missionskontrolle: Delta Lake als intelligenter Storage-Layer
An dieser Stelle betritt Delta Lake die Bühne. Delta Lake ist kein neues Dateiformat, sondern eine offene Metadaten-Ebene, die direkt auf den Parquet-Dateien operiert. Es fungiert als das „Gehirn“, das den physischen Dateien die mathematische Verlässlichkeit einer relationalen Datenbank zurückgibt.
Der Kern dieser Technologie ist das JSON-basierte Transaktionsprotokoll, das sogenannte Transaction Log (oder Delta Log). Jeder Schreib-, Lösch- oder Update-Befehl wird sequenziell als atomarer Zustandseintrag (Commit) in diesem Log verzeichnet. Erst wenn der Eintrag im Log erfolgreich geschrieben wurde, gilt die Änderung für nachgelagerte Abfrage-Engines als existent.
Die Kernfunktionen des Delta-Protokolls im Detail:
4. Der offene Markt: Delta Lake vs. Apache Iceberg vs. Apache Hudi
Delta Lake steht in einer modernen Multi-Cloud-Architektur nicht allein. Es teilt sich den Markt der offenen Tabellenformate mit zwei weiteren grossen Open-Source-Initiativen: Apache Iceberg und Apache Hudi. Alle drei nutzen Parquet als physische Basis, unterscheiden sich jedoch grundlegend in ihrer architektonischen Philosophie.
Technischer Vergleich der Tabellenformate:
Kurskorrektur 2026: Der Shift zu Iceberg und Polaris
Wie aktuelle Marktentwicklungen – insbesondere die Übernahme der Query-Engine Dremio durch SAP im Mai 2026 – zeigen, bricht das bisherige Exklusiv-Privileg einzelner Formate auf. Die SAP BDC (Business Data Cloud) öffnet sich nativ für Apache Iceberg und den offenen Polaris Catalog.
Für Enterprise-Architekten bedeutet dies, dass Plattformen zunehmend format-agnostisch konzipiert werden müssen. Um den gefürchteten Katalog-Wildwuchs (Unity Catalog für Databricks, Polaris für SAP/Dremio/Snowflake) zu verhindern, ist die Etablierung einer übergeordneten Catalog Orchestration Layer (wie Atlan oder Collibra) sowie die Kapselung über das MCP (Model Context Protocol) für KI-Szenarien dringend ratsam.
5. Fazit und Architektur-Empfehlung
Die richtige Kombination aus physischen Datei-Strukturen und intelligenten Tabellenformaten ist der Treibstoff, der Ihre Lakehouse-Mission auf Kurs hält. Sie verwandelt unstrukturierte Speicherschichten in agile, transaktionssichere Analytics-Plattformen – bereit für den Liftoff.
Für Ihre Architektur-Roadmap leitet das s-peers Kompetenzteam drei klare Empfehlungen ab:
- Keine Roh-Parquet-Seen: Speichern Sie geschäftskritische Daten niemals als reines Parquet ohne Metadaten-Layer ab. Der administrative Aufwand für manuelle Schema-Pflege und Concurrency-Workarounds holt Sie unweigerlich ein.
- Entkopplung wahren: Nutzen Sie die inhärente Stärke der Formate aus – halten Sie Compute und Storage strikt getrennt.
- Multi-Format-Bereitschaft: Planen Sie Ihre Plattform so, dass sie über offene REST-Katalog-Schnittstellen sowohl Delta- als auch Iceberg-Strukturen konsumieren kann. Dies sichert Ihre Investitionen gegen zukünftige strategische Schwenks der grossen Plattform-Hersteller ab.
Ihre Architektur ist individuell – Lassen Sie uns ins Gespräch kommen
Die Auswahl des passenden Metadaten-Layers und die Orchestrierung Ihrer Kataloge bestimmen massgeblich die Zukunftssicherheit Ihrer BI- und KI-Initiativen. Gemeinsam analysieren wir Ihre bestehende SAP- und Cloud-Landschaft und bauen ein performantes, ausfallsicheres Daten-Fundament.
Andreas & Yvonnes Databricks-Guide
Möchten Sie alle wichtigen Informationen auf einen Blick?
Laden Sie sich jetzt den kostenlosen Guide zur SAP Databricks!
Ihre Datenstrategie ist individuell – Ihre Beratung sollte es auch sein
Die Wahl des richtigen Formats und der passenden Technologie-Ebene hängt stark von Ihren spezifischen Anwendungsfällen ab – ob Streaming-Daten, große Batch-Verarbeitungen oder komplexe Analyse-Workloads.
Lassen Sie uns unverbindlich darüber sprechen, welche Architektur für Ihre Daten und Ziele die richtige ist. Kontaktieren Sie uns für ein persönliches Gespräch.
