Parquet naar CSV omzetten

De andere kant op is duidelijk een omzetting: tekst wordt getypeerde kolommen, en iedereen verwacht het resultaat te checken. Deze richting voelt als een export — de data komt eruit, er wordt niets gecomprimeerd, er wordt niets afgeleid — en die indruk klopt op één specifieke en dure manier niet.

Parquet draagt een schema. Elke kolom heeft een verklaard type, vastgelegd in een voettekst, en een queryengine leest die voettekst voordat hij een rij leest. Een CSV draagt een koprij met namen en verder niets. De omzetting brengt de waarden dus intact over en gooit alles weg wat het bestand over hen wist, en het volgende gereedschap dat het leest raadt de typen opnieuw — waarschijnlijk anders dan wat het Parquet-bestand daadwerkelijk verklaarde.

Booleans komen aan als `true` en `false`. Gehele getallen en getallen met komma worden in decimale vorm geschreven. Tekenreeksen worden geschreven zoals ze waren, alleen aangehaald waar de waarde een komma, een dubbele aanhaling of een regeleinde bevat. Nulls worden lege velden.

Niets daarvan is terug te draaien naar het oorspronkelijke schema. Een kolom die Parquet als een 32-bits geheel getal verklaarde en een die het als een double verklaarde zien er allebei uit als cijfers met een optionele punt, en een boolean-kolom en een tekstkolom met het woord "true" worden ononderscheidbaar. Gaat de CSV ergens heen met een eigen schema, haal de kolomtypen dan eerst uit het Parquet-bestand — `DESCRIBE` in DuckDB drukt ze in één regel af — en schrijf ze in de laaddefinitie in plaats van het volgende gereedschap te laten raden.

Een tijdstempelkolom wordt geschreven als een ISO 8601-tekenreeks, dus een waarde komt eruit als `2024-03-11T09:30:00.000Z`. Dat is het beste beschikbare antwoord in een formaat zonder datumtype: het is ondubbelzinnig over welk getal de maand is, het sorteert correct als platte tekst, en elke database en taal parseert het zonder een formaat te hoeven opgeven.

Het blijft tekst. Een datumkolom in de CSV reageert niet op datumrekenkunde tot wat hem leest verteld wordt dat de kolom een datum is, en een spreadsheet die het bestand opent past zijn eigen interpretatie toe. Gaat het naar een database, dan is de kolom bij het laden als tijdstempel verklaren één regel en behoudt het de betekenis; gaat het naar een mens, dan leest de ISO-vorm tenminste overal hetzelfde.

Parquet heeft een 64-bits geheeltalig type, en JavaScript — waarmee de omzetting draait — vertegenwoordigt gehele getallen exact alleen tot 53 bits. Een waarde daarboven kan niet als getal worden gedragen zonder precisie te verliezen.

In plaats van af te ronden, schrijft de omzetting het als tekst. Een orderreferentie of een snowflake-identifier verschijnt dus in de CSV met elk cijfer intact, en een kolom die veilige en onveilige waarden mengt zal sommige items als getal en andere als tekenreeks hebben, wat er in een CSV toch identiek uitziet. Het alternatief — afronden — geeft een bestand waar een identifier één af is, wat er precies als een geldige identifier uitziet en het soort fout is dat meerdere systemen overleeft voordat iemand het merkt.

Parquet houdt geneste data van huis uit vast: een kolom kan een lijst tekenreeksen zijn, een struct met benoemde leden, of een map. Een CSV-cel houdt één scalar en heeft geen syntaxis voor iets anders.

De omzetting schrijft die waarden als JSON in het veld, dus een lijstkolom komt aan als `["a","b"]` in één cel, aangehaald omdat de JSON komma's bevat. Dat is terug te draaien als wat het bestand leest de JSON parseert, en het is behoorlijk onhandig als de bestemming een spreadsheet of een importscherm is. Binaire kolommen krijgen vergelijkbare behandeling om dezelfde reden: een bytearray zonder tekstannotatie wordt geschreven als kleine letter hexadecimaal, wat tenminste omkeerbaar is en overduidelijk geen proza. Heeft het bestand geneste kolommen en is de bestemming een mens, plat ze dan of laat ze weg in een query voordat je omzet, in plaats van een CSV vol ingebedde JSON te sturen.

Reken op meerdere keren de omvang, soms veel meer. Parquet schrijft waarden in binaire vorm, comprimeert elke kolom apart, en slaat een kolom met herhaalde waarden eenmaal op als woordenboek met kleine verwijzingen erin. Een CSV heeft daar niets van: elke waarde wordt uitgeschreven als tekens, op elke rij, ongecomprimeerd.

De kolommen die het hardst inklapten bij binnenkomst zetten het hardst uit bij vertrek. Een landcode herhaald over een miljoen rijen kostte bijna niets in het Parquet-bestand en kost een miljoen kopieën in de CSV. Goed om te weten voordat je het resultaat probeert te mailen, en goed om te onthouden dat de CSV gzippen een groot deel van het verschil terugwint als de bestemming dat accepteert.

De CSV is UTF-8 zonder byte-order-mark en met een gewone regeleinde tussen rijen. Dat is correct voor scripts, importeurs en versiebeheer, en het is wat geaccentueerde namen als mojibake laat verschijnen als het bestand door dubbelklikken wordt geopend op Windows, want Excel valt terug op de systeemcodepagina zonder een markering.

Importeren via Gegevens, Gegevens ophalen, Uit tekst/CSV en UTF-8 kiezen vermijdt dat, en geeft je de kans om identifierkolommen tegelijk als tekst te markeren — wat telt, want Excel past anders zijn eigen numerieke omzetting toe op de kolommen wiens typen net weggegooid werden. Is de bestemming werkelijk een spreadsheet, dan haalt het Parquet-bestand omzetten naar XLSX in plaats daarvan de coderingskwestie weg en behoudt het de typen.

De lezer materialiseert elke rij voordat er iets geschreven wordt, dus staat de hele tabel op één moment in het geheugen. Tientallen megabytes Parquet is comfortabel; bedenk dat dit een gecomprimeerd formaat is, dus een bescheiden bestand kan uitzetten naar veel tekst en het plafond komt eerder dan de bestandsomvang doet vermoeden.

Voor een groot extract is DuckDB het juiste gereedschap, dat het Parquet-bestand leest en een CSV schrijft in één statement zonder een van beide vast te houden. Het laat je ook de kolommen kiezen die je echt nodig hebt, wat meestal toch het betere antwoord is — de meeste verzoeken om "de data als CSV" blijken verzoeken om zes kolommen ervan.

De Parquet-lezer is een bibliotheek die op verzoek door deze pagina wordt geladen en het schrijven is gewoon JavaScript, dus draagt geen verzoek het bestand ergens naartoe. Dat telt hier meer dan bij de meeste paren: een Parquet-bestand is normaal een artefact uit het midden van een dataplatform, dat wil zeggen de versie vóór de maskering en de aggregatie.

Er is geen wachtrij, geen account en geen rijgrens buiten je eigen geheugen. Het enige dat bepaalt of de omzetting werkt, is of de uitgezette tabel past, wat je kunt schatten uit het rijaantal in de voettekst.

Heeft de ontvanger enige moderne datagereedschap, stuur dan het origineel. DuckDB, pandas, Polars, R met arrow, Spark en elk datawarehouse lezen Parquet rechtstreeks, en dat bewaart de typen, houdt het bestand klein en verwijdert een hele stap waarin iets fout kan gaan.

Zet om naar CSV wanneer de ontvanger het echt niet kan — een collega van finance met een spreadsheet, een auditverzoek dat het formaat noemt, een uploadscherm met een vaste lijst. Die situaties zijn echt en gewoon, en deze omzetting is ervoor. Wat het niet moet worden is een gewoonte: elke CSV gemaakt uit een Parquet-bestand is een kopie die vergeten is wat hij bevat.