CSV naar Parquet omzetten

Alles wat een CSV over zichzelf weet, is een koprij met namen. Het kan niet zeggen dat amount een decimaal getal is, dat is_active een booleaanse waarde is, of dat customer_id nooit als rekenwaarde gebruikt mag worden. Elke tool die het bestand leest, moet dat opnieuw uitzoeken, en elke tool doet dat net anders.

Een Parquet-bestand eindigt met een footer met het schema, het aantal rijen en per-kolom metadata. Een query-engine leest eerst de footer, een paar kilobyte aan het eind van het bestand, en kent de kolomnamen en typen voordat er ook maar één rij is gelezen.

Drie dingen gebeuren met elke kolom, en ze stapelen op. Waarden worden in binaire vorm geschreven in plaats van als decimale tekst, dus een getal dat in de CSV elf tekens kostte, kost nu vier bytes. Elke kolom wordt daarna apart gecomprimeerd — welke codec de schrijfbibliotheek daarvoor standaard kiest, is geen instelling die deze pagina blootlegt. En een kolom met veel herhaling wordt woordenboek-gecodeerd: de unieke waarden staan één keer in een woordenboekpagina, en de kolom zelf wordt een lijst kleine verwijzingen daarnaartoe.

Het woordenboek wordt per kolom toegepast, en alleen waar het loont: de schrijver bekijkt de eerste duizend waarden en gebruikt een woordenboek als hoogstens de helft daarvan uniek is. Dat pakt precies kolommen als land, status of productcode, en slaat een kolom met unieke vrije tekst over.

De rijen worden in groepen geschreven in plaats van als één blok, tussen de duizend en honderdduizend rijen per groep, met pagina’s daarbinnen van maximaal een megabyte. Elk kolomdeel binnen een groep draagt statistieken, en die statistieken maken van een scan een overslag.

Een query die op een datumbereik filtert, leest de footer, ziet dat een rijgroep volledig buiten het bereik valt, en leest die groep helemaal niet. Een query die twee van de veertig kolommen noemt, leest alleen die twee kolommen. Geen van beide is onder welke omstandigheden dan ook mogelijk bij een CSV.

Het type wordt afgeleid uit de waarden, want de bron heeft niets te declareren. Elke kolom wordt volledig gelezen: allemaal booleans wordt BOOLEAN, allemaal gehele getallen binnen het 32-bit bereik wordt INT32, getallen die niet allemaal geheel of klein genoeg zijn worden DOUBLE, en de rest wordt tekst. Lege waarden tellen niet mee, dus een numerieke kolom met gaten blijft numeriek.

Eén afwijkende waarde maakt de hele kolom tekst, en dat is bewust: het type nemen van de eerste rij zou een kolom die met getallen begint als geheel getal wegschrijven en elke latere niet-numerieke waarde stilzwijgend tot niets maken. Een tekstkolom is zichtbaar, in één stap om te zetten, en verliest nooit iets.

De omzetting leest de CSV met typeafleiding, dus 007 is al het getal 7 tegen de tijd dat de schrijver een kolomtype kiest, en de resulterende INT32-kolom is een getrouw verslag van een waarde die al fout was. Parquet krijgt daar regelmatig de schuld van en verdient dat niet — het verlies gebeurt bij het tekst-inlezen, dezelfde stap die elke andere CSV-lezer ook doet.

De risicokolommen zijn die waar rekenen zinloos zou zijn — postcodes, artikelnummers, telefoonnummers, alles met voorloopnullen. Staat de export onder jouw controle, exporteer die kolommen dan met aanhalingstekens of een voorvoegsel, dan komen ze als tekst intact aan.

Bij een tabel van vijftigduizend rijen en zes kolommen — een id, een productcode, een stad, een aantal, een prijs en een vlag — mat de Parquet-uitvoer 301 KB. Dezelfde data als tabgescheiden tekst was ongeveer 1,8 MB.

Dat is ruwweg een factor zes, een redelijke verwachting voor operationele data met herhaalde codes en categorieën. Een bestand vol unieke vrije tekst doet het aanzienlijk slechter, omdat noch het woordenboek noch de binaire codering daar veel aan heeft.

Er is geen configuratie nodig. DuckDB leest het bestand rechtstreeks in een FROM-clausule, pandas leest het in één aanroep, en Spark behandelt het als een native tabelformaat. Het bestand begint en eindigt met de vier bytes PAR1.

Kijk na het inladen eerst naar het afgeleide schema, niet naar de eerste tien rijen. Een kolom die je numeriek verwachtte en als tekst aankwam, vertelt je iets waars over de CSV, en dat is nu veel goedkoper te ontdekken dan nadat het bestand met drie andere is samengevoegd en in een datawarehouse is gekopieerd.

De hele tabel staat in het geheugen: de CSV wordt in rijen gelezen, de rijen worden getransponeerd naar kolommen, en de kolommen worden geschreven. Tientallen megabytes gaat zonder moeite, honderden is waar een tabblad begint te kraken — een reëel plafond, geen abonnementsgrens, want er wordt niets geüpload.

Voor een echt grote export is DuckDB het juiste instrument: het leest de CSV van schijf en schrijft Parquet in één statement zonder het bestand ooit volledig in het geheugen te houden. Deze pagina is voor het bestand dat past, en dat is de meerderheid.

Beide kanten draaien op deze pagina: de CSV-parser en de Parquet-schrijver zijn bibliotheken die op verzoek geladen worden, en geen enkel verzoek stuurt het bestand ergens naartoe. Een CSV op weg naar een dataplatform is heel vaak het minst geredigeerde artefact in de hele pijplijn — de ruwe dump vóór de joins en de maskering.

Het scheelt ook een hele laag overleg: er is geen wachtrij, geen maximaal aantal rijen en geen account, dus de enige vraag is of het bestand in het geheugen past, en dat zie je zo.

Parquet is een slechte bestemming voor alles wat een mens moet lezen. Het is binair, niet te bewerken, en een collega zonder de juiste tooling kan het helemaal niet openen. Moet het bestand naar een persoon in plaats van een systeem, stuur dan de CSV of een spreadsheet.

Het is ook het verkeerde doel voor een lading die één keer gebeurt en daarna wordt weggegooid: de schrijfkosten leveren niets op als het bestand nooit meer bevraagd wordt. Kies Parquet als dezelfde data herhaaldelijk gescand, gefilterd, samengevoegd en bewaard wordt.