Zum Inhalt springen
L

Wikipedia · einfach zusammengefasst · Stand

Apache Parquet

Lauflängenkodierung-Bit-Packing-Hybrid ist eine Kombination aus Bit-Packing und Lauflängenkodierung, um wiederholte Werte effizienter zu speichern. Die …

Inhalt5 Abschnitte
  1. 1. Überblick
  2. 2. Entstehung und Apache-Projekt
  3. 3. Aufbau einer Parquet-Datei
  4. 4. Lesen, Komprimieren und Schützen von Daten
  5. 5. Einsatz in Cloud-Speichern und Data Lakes

Überblick

Apache Parquet ist ein quelloffenes, spaltenorientiertes Datenspeicherformat. Spaltenorientiert bedeutet: Die Werte einer Tabellenspalte werden zusammen gespeichert, nicht jede vollständige Tabellenzeile nacheinander. Das Format ist eine Grundlage vieler cloud-nativer Anwendungen zur Datenanalyse.

Parquet wurde 2013 von Twitter und Cloudera entwickelt. Es ist in Java geschrieben, steht unter der Apache-Lizenz 2.0 und gehört zur Kategorie Datenformat. Das Erscheinungsjahr ist der 13. März 2013; als aktuelle Version ist 1.18.1 vom 13. September 2026 angegeben.

Entstehung und Apache-Projekt

2010 veröffentlichte Sergey Melnik das VLDB-2010-Dremel-Paper, das Google Dremel beschreibt. Auf dieser Grundlage entwickelten Twitter und Cloudera Parquet als effizientes spaltenorientiertes Speicherformat für Apache Hadoop.

Parquet 1.0 erschien im Juli 2013. Seit dem 27. April 2015 ist Parquet ein Top-Level-Projekt der Apache Software Foundation.

Aufbau einer Parquet-Datei

Das binäre Dateiformat verwendet die Datei „parquet.thrift“. Sie enthält formale, von Thrift abgeleitete Definitionen der Metadaten und beschreibt damit, wie Daten strukturiert und gespeichert werden.

Daten werden zunächst in Zeilengruppen (Row Groups) aufgeteilt. Innerhalb jeder Zeilengruppe sind sie spaltenweise als Column Chunks gespeichert; diese bestehen wiederum aus Pages, also Datenseiten. Eine Tabelle mit den Spalten ID, Teilnehmer, Alter und Staat enthält beispielsweise pro Row Group jeweils Column Chunks für diese vier Spalten und darin einzelne Pages.

Die Datei besitzt einen Header mit der Magic Number „PAR1“ und einem Verweis auf den Beginn des Footers. Im Footer stehen die Metadaten: unter anderem die Zeilenzahl je Row Group, Byte-Offset und Datenlänge, Angaben zu Column Chunks und Pages sowie der Kompressionsalgorithmus und das Encoding-Format. Page-Metadaten enthalten den Typ der Page, Daten oder Wörterbuch, außerdem Offset, Datenlänge und Min-/Max-Statistiken. Die Dateimetadaten enthalten das Schema mit Spaltentypen und Sortierung, „Erstellt von“ sowie Key-Value-Eigenschaften; auch am Ende steht die Magic Number „PAR1“.

Lesen, Komprimieren und Schützen von Daten

Encoding- und Kompressionstechniken werden für jede einzelne Spalte abhängig von ihrem Datentyp optimiert. Wenn bei einer Abfrage nur wenige von vielen Spalten benötigt werden, muss deshalb nur dieser kleine Datenbereich gelesen werden.

Parquet verwendet automatische Wörterbuch-Codierung. Besonders wenn eine Spalte nur wenige unterschiedliche Werte besitzt, kann damit eine hohe Datenkompression erreicht werden. Außerdem gibt es einen Lauflängenkodierung-Bit-Packing-Hybrid: Er verbindet Bit-Packing mit Lauflängenkodierung, um wiederholte Werte effizienter zu speichern.

Die Verschlüsselung ist flexibel. Sie kann die gesamte Datei oder nur einzelne Spalten mit schützenswerten Daten betreffen; für jede Spalte kann ein eigener Schlüssel verwendet werden. Für Anwendungen mit Geoinformationssystemen stellt Parquet Geospatial-Datentypen bereit.

Einsatz in Cloud-Speichern und Data Lakes

Parquet ist als Basisdateiformat in cloud-basierten Data-Lake-Architekturen weit verbreitet. Cloud-Speichersysteme wie Amazon S3, Azure Data Lake Storage und Google Cloud Storage speichern Daten meist im Parquet-Format, weil es eine effiziente spaltenorientierte Darstellung und Suchfunktionen bietet.

Data-Lake-Frameworks wie Apache Iceberg, Delta Lake, Ducklake und Apache Hudi legen eine zusätzliche Metadatenschicht über Parquet-Dateien. Dadurch unterstützen sie Schema-Evolution, Time-Travel-Abfragen und ACID-konforme Transaktionen. Die Parquet-Dateien bilden dabei die unveränderliche Speicherschicht. Die jeweilige Data-Lake-Implementierung verwaltet dagegen Datenversionierung und Transaktionsintegrität.

Weiterlesen