NDJSON naar Parquet omzetten

Deze pagina is voor iemand met een append-only bestand dat over tijd is gegroeid: velden die pas een derde van de weg verschijnen omdat een deploy ze heeft toegevoegd, en waarden die van type veranderen onder dezelfde sleutel. Dat is anders dan een API-dump met geneste structuur, waarvoor de aparte JSON-naar-Parquet-omzetting bedoeld is.

Schema-drift in een logbestand is precies het soort probleem dat deze omzetting eerlijk moet benoemen in plaats van te verbergen achter een geslaagde omzetting.

Records worden plat geslagen tot kolommen met een punt-gescheiden naam: `gebruiker.naam` voor een genest object, `labels.0` en `labels.1` voor de elementen van een array. Dat is dezelfde platslaglogica als bij CSV, TSV, SQL en XLSX op deze site.

Er komt dus geen letterlijke `[object Object]`-tekst en geen kommagescheiden array-tekst meer voor — die problemen zijn er, sinds de laatste update van deze engine.

Parquet schrijft slechts vier fysieke typen: boolean, geheel getal, kommagetal en tekst. Elke kolom krijgt één type, bepaald over alle waarden in die kolom heen.

Komt in dezelfde kolom ergens een waarde voor die niet numeriek is — een lege string tussen anders numerieke waarden, of een tekstwaarde die per ongeluk in een numeriek veld terechtkwam — dan wordt de hele kolom als tekst geschreven, ook de rijen die er zelf numeriek uitzagen.

Een geheel getal buiten het bereik van een normaal 32-bit geheel getal wordt geschreven als kommagetal, nooit als een groter geheeltalig type. Dat is een bewuste keuze: een 64-bit geheeltalig type zou een exactheid beloven die het schrijfproces niet daadwerkelijk garandeert.

Voor de meeste logvelden — tijdstempels in milliseconden, tellers, ID’s binnen een normaal bereik — is dat geen probleem; bij een zeer groot ID buiten het normale bereik is het de moeite waard het resultaat te controleren.

Op een gegenereerde reeks van 50.000 bestelrecords met zes velden woog het NDJSON-bestand 4,8 MB tegenover 207 KB voor dezelfde data als Parquet — een factor van meer dan twintig. Dat verschil komt uit een gemeten test, niet uit een algemene belofte over Parquet.

De exacte verhouding hangt af van hoeveel herhaling en structuur in de data zit; een logbestand met veel identieke sleutels comprimeert doorgaans sterker dan een bestand met sterk wisselende velden.

De omzetting draait volledig in de browser; het bestand wordt niet naar een server gestuurd. De limiet op het gratis plan is 100 MB per bestand.

Voor een groot logbestand is dat ruim voldoende, gezien hoe compact Parquet als doelformaat is.

Tot honderd NDJSON-bestanden tegelijk kunnen in één sessie worden omgezet, elk met een eigen voortgangsindicator, en het resultaat komt terug als losse Parquet-bestanden of als ZIP.

Bruikbaar wanneer een logrotatiesysteem elke dag een nieuw NDJSON-bestand aflevert dat in hetzelfde formaat moet worden gearchiveerd.

Deze omzetting valideert het schema niet en waarschuwt niet expliciet wanneer een kolom door een enkele afwijkende waarde naar tekst omslaat — dat gebeurt stilzwijgend als onderdeel van het schrijfproces.

Voor een bestand waarvan de datakwaliteit onzeker is, is het de moeite waard om na de omzetting steekproefsgewijs te controleren of kolommen het verwachte type hebben.