TSV in Parquet umwandeln

Ergebnisse aus der Genomsequenzierung — eine Expressionsmatrix mit einer Zeile pro Gen, eine Variantentabelle, ein Annotationsexport aus einer Analysepipeline eines universitären Forschungslabors — kommen praktisch immer tabgetrennt aus dem Sequenzierer oder der Analysesoftware, weil sich diese Konvention seit Jahrzehnten in der bioinformatischen Praxis hält.

Für eine Tabelle, die im Lauf einer Auswertung dutzende Male gefiltert und aggregiert wird, ist das ein teurer Zustand: Jede Abfrage liest jedes Byte neu und leitet die Spaltentypen jedes Mal selbst ab, oft mit leicht abweichendem Ergebnis. Einmalig in ein typisiertes Spaltenformat umzuwandeln, verschiebt diese Arbeit an den Anfang.

Eine Parquet-Spalte hat genau einen Typ für alle ihre Werte. Diese Umwandlung liest die gesamte Spalte, bevor sie entscheidet, und die Regel ist bewusst unnachgiebig: Sind alle nicht leeren Werte boolesch, wird die Spalte BOOLEAN; sind sie alle ganze Zahlen im 32-Bit-Bereich, wird sie INT32; sind sie alle Zahlen, wird sie DOUBLE; passt ein einziger Wert in keine dieser Kategorien, wird die gesamte Spalte zur Zeichenkette.

Genau solche Werte sind in bioinformatischen Tabellen üblich. `NA` ist die R-Konvention und taucht in fast jeder mit R erzeugten Tabelle auf. Ein einzelner Punkt `.` ist die VCF- und GTF-Konvention für ein fehlendes Feld. `-`, `n/a` und `NULL` kommen je nach Analysewerkzeug hinzu. Ein einziges Vorkommen in einer Million Zeilen genügt, damit aus einer numerischen Spalte eine Textspalte wird — und genau deshalb kommt eine erwartet numerische Spalte manchmal als Zeichenkette an.

Die naheliegende Alternative wäre, den Typ aus der ersten Zeile oder den ersten tausend Zeilen abzuleiten und alles, was nicht passt, als null zu schreiben. Die meisten Werkzeuge tun genau das. Das Ergebnis ist eine Datei, die gültig aussieht, ohne Warnung lädt und dabei jede Zeile mit dem Störwert stillschweigend gelöscht hat.

Bemerkt wird das oft erst, wenn eine Zeilenzahl nicht mehr aufgeht, meist nachdem die Datei schon mit drei anderen zusammengeführt wurde. Eine Zeichenkettenspalte fällt dagegen sofort auf, sobald jemand das Schema ansieht, und ein Cast auf einen numerischen Typ zeigt genau, welche Werte nicht passen. Diese Weigerung zu raten kostet einen zusätzlichen Cast-Schritt und erspart eine Fehlerklasse, die im Nachhinein kaum noch zu finden ist.

Ein einzelner Befehl genügt: `cut -f7 tabelle.tsv | sort -u | head -50` zeigt die unterschiedlichen Werte der siebten Spalte, und der Störwert fällt darin meist sofort auf. Das für jede Spalte einer breiten Tabelle zu tun, ist eine Schleife; für die drei Spalten, nach denen tatsächlich gefiltert wird, reicht es meist aus, es dort gezielt zu prüfen.

Die eigentliche Korrektur gehört in die Ausgangsdatei, nicht in die Umwandlung: den Störwert durch ein wirklich leeres Feld ersetzen. Leere Felder fließen nicht in die Typableitung ein, eine Spalte mit echten Lücken kommt dadurch numerisch mit Nullwerten an — genau das, womit ein Abfragewerkzeug oder ein Mittelwert arbeiten kann.

Breite Tabellen sind der Fall, in dem sich das Spaltenformat am meisten auszahlt. Eine Expressionsmatrix mit einer Zeile pro Gen und einer Spalte pro Probe wird spaltenweise gespeichert statt zeilenweise — eine Abfrage, die vier Spalten benennt, liest also nur die Bytes dieser vier Spalten und nichts vom Rest.

Bei einer tabgetrennten Datei muss dieselbe Abfrage jedes Byte jeder Zeile lesen, weil sich das siebzehnte Feld einer Zeile nur durch Zählen der Tabulatoren finden lässt. Dieser Unterschied wird mit wachsender Tabellenbreite nicht kleiner, sondern größer — und genau deshalb zählt bei einer breiten Tabelle auch der Dateifooter mehr: zweitausend Spaltennamen samt Typ lesen zu können, ohne eine einzige Datenzeile anzufassen, ist der Unterschied zwischen einem inspizierbaren Schema und einer Kopfzeile, die man erst mit `head -1 | tr` zerlegen muss.

Die Umwandlung schreibt INT32 nur dort, wo jeder Wert einer Spalte in den 32-Bit-Bereich passt. Darüber hinaus wird die Spalte DOUBLE statt INT64, was überrascht, wer weiß, dass Parquet auch einen 64-Bit-Ganzzahltyp kennt.

Der Grund ist Ehrlichkeit gegenüber dem, was ankommt: Werte laufen als JavaScript-Zahlen durch die Umwandlung, mit 53 Bit ganzzahliger Genauigkeit, eine große genomische Koordinate oder eine lange Kennnummer ist an dieser Stelle also schon gerundet, bevor die Umwandlung sie überhaupt sieht. INT64 zu deklarieren würde eine Genauigkeit versprechen, die nicht mehr vorhanden ist. Enthält eine Spalte eher lange Kennungen als Mengen, bleibt sie am besten als Text in der Ausgangsdatei — ein nicht-numerisches Präfix genügt, und sie kommt unverändert als Zeichenkettenspalte an.

Der Footer enthält die Spaltennamen genau wie in der Kopfzeile geschrieben, den Typ jeder Spalte und die Zeilenzahl, während die Daten selbst spaltenweise in Blöcken abgelegt werden statt zeilenweise wie in der tabgetrennten Quelle. Welches Kompressionsverfahren dabei je Spalte greift, legt die Schreibbibliothek selbst fest und ist von dieser Seite aus nicht einstellbar.

Für eine bioinformatische Tabelle steckt in der Spaltenordnung selbst schon ein Großteil der Ersparnis: Ein Chromosom, eine Probenkennung, ein Strang — jede dieser Spalten hat nur eine Handvoll wiederkehrender Werte über Millionen Zeilen und lässt sich dadurch sehr dicht ablegen. Eine Spalte mit kontinuierlichen Messwerten tut das nicht und macht am Ende den Hauptteil der Dateigröße aus.

DuckDB liest die Datei direkt an ihrem Ort: Eine FROM-Klausel mit dem Pfad genügt, ohne Importschritt und ohne Tabellendefinition. `DESCRIBE SELECT * FROM 'tabelle.parquet'` gibt das abgeleitete Schema aus — der erste Blick, der schnell zeigt, welche Spalte unerwartet als Text ankam.

pandas liest die Datei in einem Aufruf, Spark behandelt sie als natives Tabellenformat. In allen drei Fällen ist der richtige Umgang mit einer Überraschung, die auffälligen Werte gezielt abzufragen statt blind zu casten — ein Cast würde alles zu null machen, was nicht passt, genau die Entscheidung, die die Umwandlung bewusst nicht für einen getroffen hat.

Sowohl der tabgetrennte Parser als auch der Parquet-Schreiber laufen auf dieser Seite, es wird also nichts hochgeladen — für einen noch nicht veröffentlichten Datensatz oder eine Messreihe unter einer Sperrfrist kein Nebenpunkt.

Die gesamte Tabelle liegt während der Umwandlung im Arbeitsspeicher, mehrere Dutzend Megabyte sind unproblematisch, bei einigen Hundert wird ein Browser-Tab spürbar langsamer. Eine Matrix im Gigabyte-Bereich gehört in DuckDB, das eine tabgetrennte Datei direkt von der Festplatte lesen und in einem einzigen Befehl als Parquet schreiben kann, ohne sie vollständig im Speicher zu halten.

Muss eine Person oder ein einfaches Skript die Datei als Text lesen können, bleibt die tabgetrennte Form die richtige Wahl. Parquet ist binär, nicht ohne Weiteres editierbar, und ein Kollege ohne passende Werkzeuge kann es unter Umständen gar nicht öffnen — „erst DuckDB installieren" ist eine schlechte Antwort auf die Bitte, kurz in eine Tabelle zu schauen.

Dasselbe gilt für einen Datensatz, der als veröffentlichtes Material bei einer Zeitschrift oder einem Repositorium hinterlegt wird — tabgetrennte Tabellen sind dort das erwartete Format und werden in zwanzig Jahren noch ohne Abhängigkeiten lesbar sein. Parquet lohnt sich für die Arbeitskopie, die wiederholt gefiltert und zusammengeführt wird; das Original bleibt die Referenz.