Parquet naar TSV omzetten

Het is een binaire container. head erop print de vier bytes PAR1 en dan een scherm vol ruis, grep vindt niets betrouwbaars want de waarden zijn gecomprimeerd en woordenboekgecodeerd, en wc -l geeft een getal zonder relatie tot het aantal rijen. Het bestand is bedoeld om door een engine gelezen te worden.

Dat is precies de situatie waarvoor deze omzetting bestaat: een Parquet-export op een server, een laptop zonder beheerdersrechten, een container zonder iets geïnstalleerd. Er regels van maken is de snelste route om er überhaupt iets over te kunnen zeggen.

Waarden in een data-export zitten vol komma’s — adressen, productnamen, vrije tekst, getallen in Europese notatie. Een kommagescheiden bestand moet dat allemaal tussen aanhalingstekens zetten, en elke gebruiker van het bestand moet quoting correct implementeren voor hij een kolomgrens kan vinden.

Tabs komen in dat soort data vrijwel nooit voor, dus concurreren scheidingsteken en inhoud niet meer met elkaar. Na deze omzetting vindt cut -f3 de derde kolom, awk -F"\t" ook. Niets hoeft geparseerd te worden; er hoeft alleen gesplitst te worden.

Een tab binnen een waarde is de uitzondering. Zeldzamer in data uit een Parquet-bestand dan uit een spreadsheet, maar het komt voor — vrijetekstvelden dragen wat er ooit in geplakt werd. Gebeurt dat, dan schrijft de omzetter dat veld tussen dubbele aanhalingstekens, want het alternatief is een rij die stilzwijgend een kolom te veel krijgt.

Die uitvoer is correct en een echte parser verwerkt het goed. cut -f niet: het telt tabtekens en kent geen aanhalingsteken, dus vanaf die rij ziet het één veld te veel. Geeft een pijplijn scheve resultaten op een handjevol van een miljoen rijen, dan verklapt grep -c '"' output.tsv in een seconde of dit de oorzaak is.

Een tijdstempelkolom wordt geschreven als een ISO 8601-tekst — 2024-03-11T09:30:00.000Z — het enige zinnige antwoord in een formaat zonder datumtype. Het heeft een eigenschap die in een shell veel uitmaakt: het sorteert chronologisch onder een gewone lexicale sortering.

sort -k4 op een datumkolom doet dus wat je bedoelde, uniq -c op de eerste tien tekens telt rijen per dag. Geen van beide werkt op een landspecifiek geformatteerde datum, en geen van beide werkt op een epoch-getal zonder rekenwerk.

Parquet bevat native lijsten, structs en maps. Een tekstregel niet, dus een geneste kolom wordt als JSON binnen zijn veld geschreven: een lijst komt aan als ["a","b"], een struct als een object met zijn ledennamen.

Dat is bewust een vorm die iets anders kan lezen. cut -f5 output.tsv | jq ".[0]" haalt het eerste element van elke lijst, en de nesting overleeft de overtocht. Binaire kolommen zonder tekstannotatie worden lowercase hexadecimaal geschreven: omkeerbaar, geen scheidingsteken erin, en niemand verwart het met proza.

Een null wordt geschreven als een leeg veld. Elke rij behoudt hetzelfde aantal tabs, dus het bestand blijft rechthoekig en positionele tools blijven uitgelijnd.

Het wist ook een onderscheid dat het bronbestand zorgvuldig maakte. Parquet legt nulbaarheid per kolom vast en onderscheidt een null van een lege string; in de uitvoer zijn beide hetzelfde: nul tekens tussen twee tabs. Tel je ontbrekende waarden, haal die telling dan uit de bron met een query-engine.

Alles wat het Parquet-bestand over zijn kolommen wist — het type van elk, het aantal rijen, statistieken per kolom — leeft in een footer, en niets daarvan overleeft in een tabgescheiden bestand. De uitvoer heeft een koprij met namen en daarna zijn het alleen tekens.

Kun je het schema ergens vandaan lezen, doe dat dan voor het omzetten en schrijf het op. DESCRIBE SELECT * FROM "file.parquet" in DuckDB print het in één statement.

Parquet is gecomprimeerd en woordenboekgecodeerd, dus de tekst waartoe het uitzet, is routinematig meerdere malen de bestandsgrootte. Een kolom met herhaalde statuscodes kost in de bron bijna niets en kost in de uitvoer een volledige kopie per rij.

Dat is de moeite van vooraf inschatten waard, want de uitgezette tabel wordt tijdens de omzetting in het geheugen gehouden. Een export van honderd megabyte kan veel meer dan honderd megabyte tekst opleveren.

De Parquet-lezer is een bibliotheek die op verzoek in deze pagina geladen wordt, en het schrijven is gewone JavaScript. Geen verzoek draagt het bestand mee, dus een export uit het midden van een dataplatform — meestal de ongeaggregeerde, ongemaskeerde versie — wordt geen kopie op andermans server.

Er is geen wachtrij en geen account, en het plafond is 100 MB per bestand. Voor een bestand groot genoeg om een probleem te zijn, is een query-engine het betere antwoord.

Kun je iets installeren, installeer dan DuckDB. Het leest het Parquet-bestand ter plekke zonder importstap, print het schema in één statement, beantwoordt de vraag die je echt had met een WHERE-clausule, en materialiseert nooit de hele tabel.

Deze omzetting is voor als dat niet kan: een afgesloten machine, andermans laptop, een bestand per e-mail, een vraag van vijf minuten die geen installatie rechtvaardigt. Ook juist als de bestemming echt een tekstpijplijn is — een bestaand awk-script, een diff tegen gisterens export.