Apache Parquet: Definition des Lakehouse-Standardformats

Apache Parquet ist ein offenes Dateiformat für Tabellen, das Daten spaltenweise (Spalte für Spalte statt Zeile für Zeile) auf der Festplatte ablegt und komprimiert. Es ist der De-facto-Standard, um große Analyse-Datenmengen im Lakehouse (Datenplattform, die Data Lake und Data Warehouse verbindet) zu speichern. Zu jedem Datenblock legt Parquet Statistiken ab (etwa kleinster und größter Wert), damit ein Lese-Programm irrelevante Blöcke überspringen kann und nur einen Bruchteil der Datei tatsächlich einliest.

Was ist Apache Parquet?

Apache Parquet ist ein binäres, spaltenorientiertes Dateiformat für tabellarische Daten. Statt eine Tabelle Zeile für Zeile abzulegen, gruppiert Parquet die Werte spaltenweise: alle Werte der Spalte preis liegen zusammen, alle Werte der Spalte land liegen zusammen. Das ist der Kern: eine Abfrage, die nur zwei von hundert Spalten braucht, liest auch nur diese zwei Spalten von der Platte. Eine Parquet-Datei beginnt mit einer Kennung PAR1 und enthält eine Folge von Row Groups (Zeilenblöcken von typisch 128–512 MB) sowie einen Footer (Metadaten am Dateiende) mit Schema und Statistiken. Jede Row Group besteht aus Column Chunks (einem Datenpaket pro Spalte), die wiederum in kleinere Data Pages (typisch 1 MB) unterteilt sind. Zu jedem Chunk speichert Parquet Statistiken wie kleinsten und größten Wert, Anzahl leerer Zellen und Anzahl unterschiedlicher Werte. Auf dieser Struktur setzen zwei zentrale Optimierungen auf: Predicate Pushdown (Filter-Vorprüfung anhand der Statistiken) wertet vor dem eigentlichen Lesen aus, welche Row Groups die WHERE-Bedingung überhaupt erfüllen können, und überspringt den Rest. Column Projection (Spalten-Auswahl) lädt nur die tatsächlich abgefragten Spalten; eine Auswertung über drei Spalten einer breiten Tabelle mit hundert Spalten kostet daher nicht das gesamte Zeilenvolumen.

Pro Spalte kommen typenbewusste Encodings zum Einsatz: Dictionary-Encoding bei niedriger Kardinalität, Run-Length-Encoding und Bit-Packing bei sortierten Ganzzahl-Sequenzen, Delta-Encoding bei monoton wachsenden Werten. Auf das Encoding-Ergebnis wird optional eine allgemeine Kompression angewendet (Snappy als Default, ZSTD, Gzip, LZ4, Brotli). Der Reader dekodiert nur die tatsächlich benötigten Column Chunks der relevanten Row Groups. Das Format unterstützt komplexe verschachtelte Typen (STRUCT, LIST, MAP) über Definition- und Repetition-Level, seit Format-Version 2.4 zusätzlich Modular Encryption auf Column-Level und Bloom-Filter pro Column Chunk für weiter beschleunigten Predicate Pushdown.

Das Projekt startete 2013 als gemeinsame Initiative von Twitter und Cloudera. Ziel war ein sprachunabhängiges, komprimiertes Spalten-Format, das die analytischen Vorteile von Google Dremel ([Dremel-Paper](https://research.google/pubs/pub36632/), VLDB 2010) für das Hadoop-Ökosystem verfügbar macht, insbesondere die spaltenweise Speicherung nested/repeated Datenstrukturen über den Record-Shredding-Algorithmus. 2015 wurde Parquet Apache-Top-Level-Projekt. Committer und Contributoren kommen historisch aus Twitter, Cloudera, Databricks, Netflix, Uber, Meta und Apple. Referenz-Reader/Writer existieren für Java (parquet-mr), C++ (parquet-cpp, heute Teil von Apache Arrow), Python (via pyarrow), Rust, Go und weitere Sprachen.

Abgrenzung zu ORC, Avro, Arrow und Delta Lake

Apache Parquet wird häufig mit benachbarten Datenformaten verwechselt, weil On-Disk-Format, Zeilen-/Spalten-Layout, In-Memory-Repräsentation und Tabellenformat in derselben Pipeline auftauchen.

Begriff	Schicht	Verhältnis zu Parquet
ORC	On-Disk-Format (komprimiert, spaltenorientiert)	Direktes Pendant aus dem Hive-/Hortonworks-Umfeld. Struktur ähnlich (Stripes statt Row Groups, PostScript-Footer). Vergleichbare Kompression und Scan-Geschwindigkeit; die Wahl folgt heute meist dem Ökosystem: Parquet dominiert bei Delta Lake, Iceberg, Databricks und Spark; ORC bei klassischen Hive-Warehouses und Trino-Bestand.
Avro	On-Disk-Format (binär, zeilenorientiert)	Zeilenorientiert, auf Schema-Evolution und Streaming ausgelegt (Kafka, CDC). Faustregel: Avro schreibt und transportiert, Parquet liest analytisch. Eine typische Pipeline landet Avro-Events in einer Bronze-Schicht und materialisiert sie spaltenweise nach Parquet.
Arrow	In-Memory-Format (unkomprimiert, spaltenorientiert)	RAM-Layout, kein persistenter Speicher. Parquet-Reader dekodieren Column Chunks in Arrow-Buffers, auf denen die Engine dann vektorisiert rechnet. Komplementär, kein Ersatz.
Delta Lake, Iceberg, Hudi	Tabellenformat (Transaktions-Log, Schema-Evolution)	Verwalten Sammlungen von Parquet-Dateien mit einem Transaktions-Log und liefern ACID, Schema-Evolution und Time Travel (Eigenschaften, die Parquet selbst nicht kennt). Parquet ist die Datei, Delta/Iceberg/Hudi die Tabelle darüber.

Der wichtigste konzeptionelle Punkt ist die Trennung Datei-Format vs. Tabellenformat. Ein Ordner voller Parquet-Dateien ist noch keine Delta- oder Iceberg-Tabelle: Ohne Transaktions-Log fehlen Atomicity, konsistente Schema-Änderungen und Time Travel. Umgekehrt ändert Delta Lake das Parquet-Format nicht, es legt nur einen _delta_log/-Ordner neben die Datendateien.

Beispiel: Delta-Bronze-Ingest und Gold-Layer auf Databricks

Ein häufiger Einsatz ist eine Delta-Tabelle im Gold-Layer eines Databricks-Lakehouse. Physisch besteht die Tabelle aus komprimierten Parquet-Dateien von typisch 128–256 MB mit ZSTD- oder Snappy-Kompression sowie einem _delta_log/-Ordner mit den Transaktions-Commits. Ein [SQL-Warehouse](https://docs.databricks.com/aws/en/sql/)-Reader nutzt Predicate Pushdown auf die Parquet-Statistiken und zusätzlich Data Skipping über die Delta-Metadaten, um nur die relevanten Dateien und Row Groups anzufassen. OPTIMIZE und Liquid Clustering fassen kleine Files zu größeren Parquet-Dateien zusammen und ordnen die Daten nach den häufigsten Query-Prädikaten.

Ein zweiter typischer Einsatz ist die Bronze-Landing-Zone. Ein [Auto-Loader](https://docs.databricks.com/aws/en/ingestion/cloud-object-storage/auto-loader/)-Job liest CSV- oder JSON-Dateien inkrementell aus einem Object Store und schreibt sie als Parquet in eine Bronze-Delta-Tabelle. Die Konvertierung von JSON zu Parquet reduziert das Speichervolumen typischerweise um Faktor 3 bis 10, abhängig von Struktur und Kardinalität, und beschleunigt spätere analytische Queries um Größenordnungen, weil Column Projection und Predicate Pushdown erst auf einem Spalten-Format greifen. Der Zwischenschritt zu Parquet ist der Grund, warum ein Bronze-Layer im Lakehouse überhaupt sinnvoll ist.