XLSX naar Parquet omzetten

Elk ander doel voor een werkmap slaat het ene record na het andere op. Parquet slaat het ene veld na het andere op: alle vijftigduizend orderdata samen, dan alle steden, dan alle bedragen. Dat is geen opmaakvoorkeur, het is de hele reden dat het formaat bestaat.

Dat merk je zodra je bevraagt: een vraag die twee van de tweehonderd velden leest, raakt maar twee kolommen aan bytes in plaats van elke rij, en een kolom met herhaalde waarden comprimeert veel harder dan diezelfde waarden verspreid over rijen.

Het type wordt afgeleid uit de waarden zelf, want een rekenblad draagt geen schema. Elke kolom wordt volledig doorgenomen: zijn alle niet-lege waarden booleans, dan wordt de kolom BOOLEAN; zijn het allemaal gehele getallen binnen 32-bits bereik, dan INT32; anders DOUBLE; al het overige wordt tekst.

De inferentie leest de hele kolom in plaats van te steekproeven, wat langzamer is en niet op die specifieke manier fout kan gaan — een lading die op een testbestand werkte en in productie faalt, komt meestal doordat de eerste duizend rijen schoon waren en rij veertigduizend niet.

Een kolom postcodes die begint met vijfduizend numerieke waarden en dan SW1A 1AA bevat, wordt een tekstkolom, en de numerieke waarden komen ook als tekst mee.

Het verleidelijke alternatief — het type van de eerste rij nemen en alles wat daarvan afwijkt op null zetten — levert een bestand op dat geldig lijkt en stiekem waarden heeft verwijderd. Een tekstkolom is zichtbaar en in één expressie om te zetten naar het juiste type.

Parquet kent een 64-bits geheel getal en dat wordt hier niet gebruikt. De waarden komen uit het rekenblad als JavaScript-getallen, met 53 bits precisie voor gehele getallen, dus alles al voorbij die grens is voordat de schrijver het ziet.

INT64 schrijven zou een exactheid beloven die het getal niet meer heeft. DOUBLE is de eerlijke verklaring van wat werkelijk bekend is. Heb je identificatienummers voorbij negen biljard, sla ze dan als tekst op in het rekenblad.

Op een blad van vijftigduizend rijen en zes kolommen kwam het Parquet-bestand uit op ongeveer 301 KB, tegenover circa 4,3 MB als .xlsx en 1,8 MB als tabgescheiden tekst.

Het verschil is niet alleen compressie. Herhaalde waarden in een kolomopslag worden eenmaal bewaard en via kleine verwijzingen hergebruikt, wat verklaart waarom een kolom met stad- of productcodes bijna niets kost.

Wat een rekenblad in een datumcel opslaat is een getal plus een weergaveopmaak. De omzetting schrijft het getal, dus 1 januari 2024 wordt 45292, geteld vanaf eind december 1899, en de kolom wordt getypeerd als een geheel getal.

Er zit dus geen kalenderbetekenis in de uitvoer, en een queryengine behandelt de kolom als wat ze is: een geheel getal. De kalender toepassen is een simpele uitdrukking op het moment van bevragen.

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

Het eerste om te doen na het laden is de afgeleide typen bekijken in plaats van de eerste tien rijen. Een kolom die je numeriek verwachtte en als tekst terugkomt, vertelt iets waars over het rekenblad.

De omzetting leest het eerste blad van de werkmap. Parquet houdt één tabel met één schema, dus een werkmap met meerdere bladen kan niet in één bestand worden weergegeven zonder een samenvoeging te verzinnen die niemand vroeg.

Zet voor een werkmap waar meerdere bladen ertoe doen elk blad apart om en laat de queryengine ze weer samenvoegen — precies waarvoor die engines zijn gebouwd.

Beide helften draaien in de browser: de rekenbladlezer en de Parquet-schrijver zijn bibliotheken die deze pagina op aanvraag laadt, en geen enkel verzoek draagt de werkmap ergens naartoe.

De limiet is geheugen, geen abonnementsniveau. Het blad wordt in rijen ingelezen, naar kolommen getransponeerd en weggeschreven, dus de hele tabel bestaat tegelijk; tientallen megabytes gaat probleemloos.