Was ist eine Parquet-Datei?

Parquet ist ein Binärformat, das nur einem Programm etwas sagt, das es kennt. Eingesetzt wird es für die Archivierung und den Austausch zwischen Programmen.

Die Endung lautet .parquet, der volle Name Apache Parquet. Beides sagt weniger aus als das, was die Datei halten kann — und davon handelt der Rest dieser Seite.

Apache Software Foundation hat es 2013 veröffentlicht.

Das Alter ist aus einem praktischen Grund interessant: je älter ein Format, desto mehr Programme hatten Zeit, es zu lernen.

Sie ist vollständig veröffentlicht, das Format lässt sich also aus dem Dokument umsetzen statt durch Nachsehen. Deshalb taucht es in so vielen Programmen auf, und deshalb gehen Dateien von vor zwanzig Jahren heute noch auf. Veröffentlicht heißt allerdings nicht lizenzfrei: Wo ein Format einen Codec einpackt, ist die Patentfrage eine eigene, die der Standard nicht mitbeantwortet.

Parquet speichert seinen Inhalt exakt. Erneutes Speichern ändert nichts, es lässt sich also beliebig oft öffnen, bearbeiten und wieder ablegen, ohne dass sich Schaden ansammelt — genau das macht es zu einem Arbeitsformat und nicht zu einem Ausgabeformat.

Parquet bringt eine Prüfsumme, mit der eine beschädigte Datei auffällt statt stillschweigend falsch gelesen zu werden und optionale Verschlüsselung mit.

Eine verschlüsselte Datei muss aufgeschlossen werden, bevor sie irgendetwas umwandeln kann — hier wie überall. Ein Passwort ist nichts, was ein Umwandler umgehen kann, und einem, der es behauptet, sollte man die Datei erst recht nicht geben.

pandas, Apache Spark und DuckDB lesen es, und die meisten Programme derselben Art ebenfalls.

Wenn eine Datei nicht aufgeht, liegt es selten am Format — häufiger daran, dass das Programm älter ist als das Format. Die Umwandlung in etwas Älteres ist der verlässliche Weg daran vorbei, und dafür gibt es den Rest dieser Website.

Kein Browser liest es.

Das ist der häufigste Grund, es umzuwandeln: nicht dass das Format schlecht wäre, sondern dass die Stelle, an der die Datei erscheinen soll, es nicht lesen kann.

Parquet ist zum Weitergeben gedacht, nicht zum Arbeiten. Eines zu bearbeiten ist möglich und selten angenehm; der vernünftige Weg führt über die Quelle und einen neuen Export.

Die wiederkehrenden Klagen: außerhalb des eigenen Reviers ist die Unterstützung lückenhaft.

Nichts davon ist ein Grund, das Format zu meiden. Es sind die Dinge, die man kennen sollte, bevor eines davon einen überrascht — das ist eine andere und eine nützlichere Behauptung.

Eine CSV-Datei schreibt einen Datensatz nach dem anderen: Name, Datum, Land, Betrag, dann den nächsten Datensatz. Parquet schreibt eine Spalte nach der anderen: erst alle Namen zusammen, dann alle Daten, dann alle Länder.

Diese eine Umsortierung ist das ganze Format. Sie klingt nach einer Ordnungsfrage und verändert doch die Wirtschaftlichkeit von allem, was danach kommt — eine Abfrage, die zwei von fünfzig Spalten braucht, liest genau diese zwei und überspringt den Rest, und eine Spalte mit ähnlichen Werten lässt sich weit besser komprimieren als eine Zeile mit lauter verschiedenen.

Werte innerhalb einer Spalte ähneln sich — Datumsangaben sehen aus wie Datumsangaben, Ländercodes wiederholen sich, Beträge liegen in ähnlicher Größenordnung —, und genau diese Ähnlichkeit ist es, wovon Kompression lebt. Parquet kodiert dazu geschickt vor: Eine Spalte mit wenigen unterschiedlichen Werten wird zu einem Wörterbuch mit kleinen Ganzzahlen, eine Folge identischer Werte wird zu einem Zähler.

Das Ergebnis ist routinemäßig fünf- bis zehnmal kleiner als dieselben Daten als CSV, bei breiten Tabellen mit sich wiederholenden Spalten gelegentlich weit mehr. Das spart schlicht Speicherplatz und, wichtiger, die Übertragungszeit bei jedem Zugriff.

Eine CSV-Datei kennt gar keine Typen, also rät jedes lesende Programm — und genau dabei verschwinden führende Nullen und werden Kennnummern zu Datumsangaben. Parquet legt den Typ jeder Spalte im eigenen Schema fest: das hier ist eine 64-Bit-Ganzzahl, das eine Zeichenkette, das ein Zeitstempel mit Zeitzone, das eine Dezimalzahl mit dieser Genauigkeit.

Die Daten kommen also so an, wie sie gemeint waren. Nichts wird geraten, nichts hängt von einer Ländereinstellung ab, und eine Spalte mit Postleitzahlen bleibt eine Spalte mit Postleitzahlen. Für alles, was zwischen Systemen wandert, ist das ein größerer praktischer Vorteil als die Dateigröße.

Parquet ist in Zeilengruppen gegliedert, und jede trägt Statistiken je Spalte: Minimum, Maximum, Anzahl der Nullwerte. Eine Abfrage, die nach einem Datumsbereich filtert, kann diese Statistiken lesen, feststellen, dass eine ganze Zeilengruppe außerhalb liegt, und sie überspringen, ohne überhaupt etwas zu entpacken.

Deshalb kann eine Abfrage über einen großen Parquet-Datensatz erheblich schneller sein als dieselbe Abfrage über CSV — über das bloße Lesen weniger Spalten hinaus. Das erklärt auch, warum das Aufteilen eines Datensatzes nach Datum in eine Ordnerstruktur, ein Ordner pro Tag, so gut funktioniert: Die Auswertung überspringt ganze Dateien, bevor sie überhaupt beginnt.

Für einen einzelnen Datensatz lesen. Eine Zeile zu rekonstruieren bedeutet, aus jeder Spalte einen Wert zu holen — genau das Zugriffsmuster, für das die Anordnung nicht gebaut ist. Parquet ist ein Analyseformat, keine Datenbank.

Für Anhängen. Eine Datei wird als Ganzes geschrieben, ihre Statistiken und der Dateifuß werden erst am Ende berechnet, also bedeutet eine zusätzliche Zeile ein Neuschreiben oder eine weitere Datei. Streamende Daten landen deshalb in vielen kleinen Dateien und werden später zusammengefasst — normaler Alltag in einem Data Lake, ärgerlich, wenn niemand damit gerechnet hat.

Und dafür, sie sich einfach anzusehen. Es ist binär — ein Texteditor zeigt nichts Brauchbares, das Betrachten braucht ein Werkzeug.

Die Hürde ist niedriger, als man denkt. DuckDB liest eine Parquet-Datei mit einer einzigen SQL-Abfrage direkt ein und ist in Sekunden installiert. Python mit pandas oder Polars liest sie in einer Zeile ein. Mehrere kostenlose Desktop-Betrachter zeigen sie wie eine Tabellenkalkulation.

Die Umwandlung nach CSV ist der andere Weg, und der richtige, wenn eine Kollegin die Daten in einer Tabellenkalkulation braucht — mit dem Verständnis, dass die Typen dann wieder erraten werden müssen und die Datei mehrfach größer wird. Die Parquet-Datei bleibt die Quelle, die CSV wird für die anfragende Person daraus erzeugt.

Beim Lesen wird jede Spalte auf einen einfachen Wert normalisiert: 64-Bit-Ganzzahlen werden zu Zahlen oder, jenseits von 2^53, zu Zeichenketten, ein Datum wird zu einer ISO-Zeitangabe, binäre Werte werden zu kleingeschriebenem Hexadezimalcode, alles Verschachtelte wird zu JSON-Text. Beim Schreiben wird der Typ je Spalte neu erraten und nur in vier physische Typen übersetzt — boolesch, 32-Bit-Ganzzahl, Fließkommazahl doppelter Genauigkeit, Zeichenkette. Ein einziger nicht-numerischer Wert macht die ganze Spalte zu Text, und Ganzzahlen außerhalb des 32-Bit-Bereichs werden zu Fließkommazahlen statt zu 64-Bit-Ganzzahlen, weil eine 64-Bit-Genauigkeit vorgetäuscht würde, die nicht mehr zutrifft.

Eine Parquet-Datei, die über unseren Konverter erst zu einem anderen Format und dann zurück zu Parquet wandert, behält dadurch nicht dasselbe Schema — Zahlen können ihre Breite wechseln, verschachtelte Strukturen werden zu Text. Wer ein Schema exakt erhalten will, kopiert die Datei, statt sie umzuwandeln und zurückzuwandeln. Alles läuft im Browser bis 100 MB je Datei, ohne dass die Daten die eigene Festplatte verlassen.