Parquet in TSV umwandeln

Ein Root-Server bei einem deutschen Hoster, ohne grafische Oberfläche, mit einem minimalen Werkzeugkasten aus grep, awk und cut, und darauf liegt plötzlich eine Parquet-Datei — ein Auszug aus einem SAP-BW-System, ein Dump aus einer Data-Lake-Pipeline, eine Datei, die jemand per SCP hinterlassen hat. DuckDB ist auf diesem Server nicht installiert, eine Installation ist aus guten Gründen nicht ohne Weiteres genehmigt, und die Frage, die gerade zählt, lässt sich in den nächsten zwei Minuten beantworten oder gar nicht.

Genau für diese Situation ist diese Umwandlung gedacht: Zeilen, die sich mit den Bordmitteln jeder Linux-Distribution lesen lassen, ohne Installationsrechte und ohne Wartezeit auf eine Freigabe.

Es ist ein binärer Behälter. `head` zeigt die vier Byte PAR1 und danach eine Bildschirmseite Rauschen, `grep` findet zuverlässig nichts, weil die Werte komprimiert und wörterbuchcodiert sind, und `wc -l` liefert eine Zahl ohne jeden Bezug zur tatsächlichen Zeilenanzahl. Die Datei ist für eine Engine gebaut, und steht auf der Maschine keine, bleibt sie undurchsichtig.

Das ist die Situation, für die diese Umwandlung gedacht ist: ein Parquet-Auszug auf einem Server, ein Laptop ohne Adminrechte, ein Container mit nichts Installiertem, oder eine Datei, zu der jemand innerhalb der nächsten zwei Minuten eine Antwort braucht. Sie in Zeilen zu verwandeln, ist der schnellste Weg, überhaupt irgendetwas über sie sagen zu können.

Werte in einem Datenexport sind voller Kommas — Adressen, Produktbezeichnungen, Freitext, Zahlen in deutscher Schreibweise mit Komma statt Punkt. Eine kommagetrennte Datei muss all das in Anführungszeichen einschließen, und jeder Konsument der Datei muss Anführungszeichen, maskierte Anführungszeichen und eingebettete Zeilenumbrüche korrekt erkennen, bevor er überhaupt eine Spaltengrenze findet.

Tabulatoren fehlen in solchen Daten praktisch immer, sodass Trennzeichen und Inhalt sich nicht mehr in die Quere kommen. Nach dieser Umwandlung findet `cut -f3` die dritte Spalte, `awk -F"\t"` findet sie ebenso, und `sort -t$'\t' -k2` sortiert nach der zweiten. Nichts muss geparst werden, es muss nur getrennt werden — genau darin liegt der ganze Unterschied in der Zuverlässigkeit zwischen den beiden Trennzeichen.

Ein Tabulator innerhalb eines Werts ist die Ausnahme. Er kommt in Daten aus einer Parquet-Datei seltener vor als in Daten aus einer Tabellenkalkulation, aber er kommt vor — Freitextfelder enthalten, was ursprünglich hineinkopiert wurde. Trifft das zu, schreibt die Umwandlung dieses Feld in Anführungszeichen, weil die Alternative eine Zeile wäre, die still um eine Spalte wächst.

Diese Ausgabe ist korrekt, und ein echter Parser verarbeitet sie richtig. `cut -f` tut das nicht: Es zählt Tabulatorzeichen und kennt kein Anführungszeichen, sieht also ab dieser Zeile ein Feld zu viel, und alles danach verschiebt sich um eins. Liefert eine Pipeline bei einer Handvoll von einer Million Zeilen versetzte Ergebnisse, verrät `grep -c '"' ergebnis.tsv` in einer Sekunde, ob das der Grund ist.

Eine Zeitstempel-Spalte wird als ISO-8601-Zeichenkette geschrieben — `2024-03-11T09:30:00.000Z` —, die einzig sinnvolle Antwort in einem Format ohne Datumstyp. Sie hat eine Eigenschaft, die in einer Shell viel wert ist: Sie sortiert unter einer reinen lexikalischen Sortierung chronologisch richtig, weil die Bestandteile von der höchsten zur niedrigsten Wertigkeit stehen.

`sort -k4` auf einer Datumsspalte tut also, was man erwartet, `uniq -c` auf den ersten zehn Zeichen zählt Zeilen je Tag, und ein Zeitraumfilter wird zum reinen Zeichenkettenvergleich. Nichts davon funktioniert bei einem lokal formatierten Datum, und nichts davon funktioniert bei einer Epochenzahl ohne Rechnung dazwischen.

Parquet hält Listen, Strukturen und Zuordnungen nativ. Eine Textzeile kann das nicht, also wird eine verschachtelte Spalte als JSON innerhalb ihres Feldes geschrieben: eine Liste kommt als `["a","b"]` an, eine Struktur als Objekt mit ihren Feldnamen.

Das ist bewusst die Form, die etwas anderes lesen kann. `cut -f5 ergebnis.tsv | jq '.[0]'` holt das erste Element jeder Liste, und die Verschachtelung übersteht die Fahrt, statt in Spalten aufgelöst zu werden, deren Namen man hinterher erst herausfinden müsste. Binärspalten ohne Textannotation werden aus verwandtem Grund als kleingeschriebenes Hexadezimal geschrieben: umkehrbar, ohne Trennzeichen im Wert, und niemand hält es für Fließtext.

Ein Null-Wert wird als leeres Feld geschrieben. Jede Zeile behält dieselbe Anzahl Tabulatoren, die Datei bleibt also rechteckig, und positionsbasierte Werkzeuge bleiben ausgerichtet — das ist das gewünschte Verhalten.

Es verwischt dabei aber einen Unterschied, auf den die Quelldatei geachtet hat. Parquet vermerkt Nullbarkeit je Spalte und unterscheidet einen Null-Wert von einer leeren Zeichenkette; in der Ausgabe sind beide dieselben null Zeichen zwischen zwei Tabulatoren. Wer fehlende Werte zählt, zählt mit `awk -F"\t" '$3==""'` beide zusammen, und kein Shell-Befehl trennt sie danach wieder. Wo das zählt, gehört die Zahl aus der Quelle mit einer Abfrage-Engine geholt, nicht aus dem Text geschätzt.

Alles, was die Parquet-Datei über ihre Spalten wusste — der Typ jeder einzelnen, die Zeilenzahl, die Statistik je Spalte — liegt in einem Footer, und nichts davon überlebt in einer tabulatorgetrennten Datei. Die Ausgabe hat eine Kopfzeile mit Namen, danach sind es nur noch Zeichen.

Gibt es irgendeinen Weg, das Schema zu lesen, sollte das vor der Umwandlung geschehen, und das Ergebnis notiert werden. `DESCRIBE SELECT * FROM 'datei.parquet'` gibt es in DuckDB mit einer Anweisung aus. Bleibt gar nichts anderes übrig, ist der Text selbst der einzige Beleg, und ein paar unterschiedliche Werte je Spalte mit `cut -f2 | sort -u | head` zu prüfen, ist sinnvoller, als eine Ziffernspalte einfach für eine Mengenangabe zu halten.

Parquet ist komprimiert und wörterbuchcodiert, der entstehende Text ist deshalb regelmäßig um ein Vielfaches größer als die Ausgangsdatei, häufig deutlich mehr. Eine Spalte mit wiederkehrenden Statuscodes kostet in der Quelle fast nichts und in der Ausgabe eine vollständige Kopie pro Zeile.

Das lohnt sich vorab abzuschätzen, weil die aufgeblähte Tabelle während der Umwandlung im Arbeitsspeicher liegt. Ein hundert Megabyte großer Auszug kann deutlich mehr als hundert Megabyte Text ergeben, und die Grenze kommt früher, als die Dateigröße auf der Platte vermuten lässt.

Der Parquet-Leser ist eine Programmbibliothek, die diese Seite bei Bedarf nachlädt, und das Schreiben geschieht in reinem JavaScript. Keine Anfrage trägt die Datei irgendwohin, sodass ein Auszug aus der Mitte einer Datenplattform — meist die unaggregierte, nicht maskierte Version — nicht erst zur Kopie auf einem fremden Server wird, nur um gelesen zu werden.

Es gibt keine Warteschlange und kein Konto, und die Grenze liegt bei 100 MB je Datei. Für eine Datei jenseits dieser Größe ist eine Abfrage-Engine die bessere Antwort — nicht nur größer im Limit, sondern auch, weil sie erlaubt, nur die gerade interessierenden Spalten zu lesen.

Die TSV-Datei enthält die Zeilen, die im Parquet-Footer als vorhanden vermerkt sind — sie bestätigt aber nicht, dass diese Zeilenzahl mit dem übereinstimmt, was ein vorgelagertes System ursprünglich geschrieben hat. Eine Prüfsumme oder ein Abgleich gegen die Quelle gehört nicht zu dieser Umwandlung, und wer das für eine Übergabe braucht, muss es getrennt herstellen, etwa mit `wc -l` gegen eine bekannte erwartete Zeilenzahl.

Ebenso wenig sagt die Ausgabe etwas über die Herkunft der Datei aus — ob sie aus einer Testumgebung oder aus der Produktion stammt, steht in keinem Feld, das diese Umwandlung mitschreibt. Diese Angaben gehören, wo sie wichtig sind, in den Dateinamen oder in eine Begleitnotiz.

Lässt sich auf der Maschine überhaupt etwas installieren, ist DuckDB die bessere Wahl. Es liest die Parquet-Datei ohne Importschritt an Ort und Stelle, gibt das Schema mit einer Anweisung aus, beantwortet die eigentliche Frage mit einer WHERE-Klausel und materialisiert nie die ganze Tabelle. Die Umwandlung in Text ist dann in jeder Hinsicht die schlechtere Option.

Diese Seite ist für den Fall gedacht, in dem genau das nicht geht: ein abgeschotteter Server, ein Kollegen-Laptop ohne Rechte, eine Datei, die per E-Mail ankam, eine Fünf-Minuten-Frage, die keine Einrichtung rechtfertigt. Und sie ist die richtige Wahl, wenn das Ziel tatsächlich eine Textpipeline ist — ein bestehendes awk-Skript, ein Diff gegen den gestrigen Export, eine Einfügung in etwas, das tabulatorgetrennte Eingabe erwartet.