TSV naar Parquet omzetten

Veel wetenschappelijke en analytische output is tab-gescheiden uit gewoonte: expressiematrices, variant-tabellen, annotatiebestanden, instrumentlogs. De tab werd gekozen omdat de beschrijvende kolommen vol komma’s en puntkomma’s zitten.

Het is een slecht formaat om herhaaldelijk tegen te rekenen: elke lezing ontleedt elke byte opnieuw, en elk gereedschap leidt de kolomtypes net iets anders af. Eenmalig omzetten naar een getypeerd kolombestand verplaatst dat werk naar voren.

Een Parquet-kolom heeft één type voor al zijn waarden. De schrijver leest de hele kolom voordat hij beslist, en de regel is bewust streng: is elke waarde een geheel getal binnen het 32-bitsbereik, dan wordt het INT32; is er ook maar één waarde die geen getal is, dan wordt de hele kolom tekst.

Analysetabellen zitten vol met precies zulke waarden. NA is de R-conventie, een kale punt is de VCF- en GTF-conventie voor een ontbrekend veld. Eén van die waarden waar dan ook in een kolom van tien miljoen getallen maakt er een kolom tekst van.

De verleidelijke oplossing is de kolom typeren op basis van de eerste rijen en al wat afwijkt als null schrijven. De meeste tools doen precies dat, en het levert een bestand op dat geldig lijkt en stilzwijgend elke rij met de sentinel heeft weggegooid.

Een tekstkolom is luid: hij valt meteen op zodra je het schema bekijkt, en de cast vertelt precies welke waarden niet pasten. Weigeren om te gokken kost een cast en bespaart een fout die achteraf zeer moeilijk te vinden is.

Eén commando volstaat: cut -f7 tabel.tsv | sort -u | head -50 toont de unieke waarden van de zevende kolom, en de sentinel valt meteen op.

De oplossing zit in de bron, niet in de converter: vervang de markering door een echt leeg veld. Nulls doen niet mee in de typeafleiding, dus een kolom getallen met echte hiaten komt door als numerieke kolom met nulls erin.

Brede tabellen zijn waar de kolomgeoriënteerde opslag het meeste oplevert. Een expressiematrix met een rij per gen en een kolom per monster wordt kolom na kolom opgeslagen, dus een query die vier kolommen noemt leest ook maar vier kolommen aan bytes.

Tegen een tab-gescheiden bestand moet dezelfde query elke byte van elke rij lezen om de gevraagde velden te vinden, want de enige manier om het zeventiende veld te vinden is zeventien tabs te tellen.

De schrijver geeft INT32 alleen waar elke waarde in de kolom binnen het 32-bitsbereik past. Daarboven wordt de kolom DOUBLE in plaats van INT64.

Waarden passeren onderweg via JavaScript-getallen, die 53 bits precisie voor gehele getallen dragen, dus een genomische coördinaat voorbij dat punt is al afgerond voordat de schrijver hem ziet. INT64 declareren zou een nauwkeurigheid beloven die de waarde niet meer heeft.

De voettekst van het bestand bevat de kolomnamen zoals de kopregel ze schreef, het type van elk, en het rijaantal, met de data geschreven in rijgroepen met per-kolomstatistieken. Elke kolom wordt apart gecomprimeerd, met de standaardcodec van de schrijfbibliotheek.

Een kolom met herhalende waarden — een chromosoomkolom, een sample-ID, een categorie — comprimeert bijna tot niets doordat de waarde als woordenboek wordt opgeslagen met kleine verwijzingen erin. Een kolom met continue metingen doet dat niet.

DuckDB leest het bestand ter plaatse: een FROM-clausule met het pad volstaat. DESCRIBE SELECT * FROM "tabel.parquet" toont het afgeleide schema — het eerste om naar te kijken en de snelste manier om een kolom te vinden die als tekst binnenkwam.

pandas leest het in één aanroep en Spark behandelt het als een tabel van huis uit. In alle drie is het bevragen van de afwijkende waarden beter dan blind casten, want een cast maakt null wat niet past.

Beide helften draaien op deze pagina: de tab-gescheiden parser is gewoon JavaScript en de Parquet-schrijver is een bibliotheek die op aanvraag geladen wordt. Er wordt niets geüpload, wat telt bij een ongepubliceerde resultatenset of een embargo.

De hele tabel staat in het geheugen terwijl hij naar kolommen wordt omgezet, dus tientallen megabytes gaat zonder omhaal en enkele honderden is waar een browsertab begint te haperen. Een tabel van meerdere gigabytes hoort in DuckDB.

Houd het aan als iemand het als tekst moet lezen. Parquet is binair, niet bewerkbaar, en de registry noteert de ondersteuning ervoor als wisselvallig — een collega zonder de juiste tooling kan het helemaal niet openen.

Houd het ook aan als het bestand een gepubliceerd artefact is. Tab-gescheiden tabellen zijn wat tijdschriften en repositories accepteren en blijven leesbaar zonder afhankelijkheid. Zet om naar Parquet voor de werkkopie die je herhaaldelijk filtert.