Convertire Parquet in TSV

È un contenitore binario. head su uno stampa i quattro byte PAR1 e poi una schermata di rumore, grep non trova nulla di affidabile perché i valori sono compressi e codificati a dizionario, e wc -l riporta un numero senza relazione con il conteggio righe. Il file è progettato per essere letto da un motore, e se la macchina non ne ha uno il file è opaco.

È la situazione per cui esiste questa conversione: un estratto Parquet su un server, un portatile senza diritti di amministratore, un container senza nulla installato, o un file che qualcuno ha inviato con una domanda a cui bisogna rispondere nei prossimi due minuti.

I valori in un estratto dati sono pieni di virgole — indirizzi, nomi di prodotto, testo libero, numeri scritti in una localizzazione europea. Un file separato da virgole deve avvolgerli tutti tra virgolette, e ogni consumatore del file deve implementare correttamente virgolettatura, virgolette con escape e a capo incorporati.

I tab sono quasi assenti da quel tipo di dati, quindi il delimitatore e il contenuto smettono di competere. Dopo questa conversione cut -f3 trova la terza colonna, awk -F"\t" la trova, sort -t$'\t' -k2 ordina sulla seconda. Nulla deve essere analizzato; le cose devono solo essere divise.

Un tab dentro un valore è l’eccezione. Più raro in dati usciti da un file Parquet che da un foglio di calcolo, ma succede — i campi di testo libero portano qualunque cosa vi sia stata incollata originariamente. Quando succede, il convertitore scrive quel campo avvolto tra virgolette doppie, perché l’alternativa è una riga che silenziosamente cresce di una colonna.

Quell’output è corretto e un vero parser lo gestisce. cut -f no: conta i caratteri tab e non ha mai sentito parlare di una virgoletta, quindi da quella riga in poi vede un campo di troppo. Se una pipeline produce risultati disallineati su una manciata di righe su un milione, grep -c '"' output.tsv vi dirà in un secondo se è questa la causa.

Una colonna di marca temporale viene scritta come stringa ISO 8601 — 2024-03-11T09:30:00.000Z — l’unica risposta sensata in un formato senza tipo data. Ha una proprietà che conta molto in una shell: si ordina cronologicamente sotto un ordinamento lessicale semplice, perché i campi vanno dal più al meno significativo.

sort -k4 su una colonna di date fa quindi ciò che intendevate, uniq -c sui primi dieci caratteri conta righe per giorno, e un filtro per intervallo è un confronto di stringhe. Nulla di tutto ciò funziona su una data formattata per localizzazione, e nulla funziona su un numero epoch senza aritmetica.

Parquet contiene liste, struct e mappe nativamente. Una riga di testo no, quindi una colonna annidata viene scritta come JSON dentro il suo campo: una lista arriva come ["a","b"], uno struct come un oggetto con i nomi dei suoi membri.

È deliberatamente il formato che qualcos’altro può leggere. cut -f5 output.tsv | jq ".[0]" estrae il primo elemento di ogni lista, e l’annidamento sopravvive al viaggio invece di essere appiattito in colonne di cui poi dovreste capire i nomi. Le colonne binarie senza annotazione testuale vengono scritte come esadecimale minuscolo per una ragione simile: è reversibile, non contiene delimitatori.

Un null viene scritto come campo vuoto. Ogni riga mantiene lo stesso numero di tab, quindi il file resta rettangolare e gli strumenti posizionali restano allineati, il comportamento di cui avete bisogno.

Cancella anche una distinzione a cui il file sorgente teneva. Parquet registra la nullability per colonna e distingue un null da una stringa vuota; nell’output entrambi sono gli stessi zero caratteri tra due tab. Se state contando valori mancanti, ottenete il conteggio dalla sorgente con un motore di query piuttosto che dal testo.

Tutto ciò che il file Parquet sapeva delle sue colonne — il tipo di ciascuna, il conteggio righe, le statistiche per colonna — vive in un footer, e nulla di ciò sopravvive in un file separato da tab. L’output ha una riga di intestazione con i nomi e dopo sono solo caratteri.

Se avete un modo per leggere lo schema, leggetelo prima di convertire e annotatelo. DESCRIBE SELECT * FROM "file.parquet" in DuckDB lo stampa in un’istruzione. Dove non avete nulla, il testo stesso è l’unica prova disponibile.

Parquet è compresso e codificato a dizionario, quindi il testo a cui si espande è di routine diverse volte la dimensione del file e spesso molto di più. Una colonna di codici di stato ripetuti costa quasi nulla nella sorgente e costa una copia intera per riga nell’output.

Vale la pena stimarlo prima di convertire un file che non avete guardato, perché la tabella espansa viene tenuta in memoria durante la conversione. Un estratto da cento megabyte può produrre molto più di cento megabyte di testo.

Il lettore Parquet è una libreria caricata su richiesta da questa pagina e la scrittura è JavaScript ordinario. Nessuna richiesta porta il file, quindi un estratto dal mezzo di una piattaforma dati — di solito la versione non aggregata, non mascherata — non diventa una copia sul server di qualcun altro.

Non c’è coda né account, e il tetto è 100 MB per file. Per un file abbastanza grande da essere un problema, la risposta è un motore di query piuttosto che un convertitore più grande.

Se potete installare qualcosa, installate DuckDB. Legge il file Parquet sul posto senza passo di importazione, stampa lo schema in un’istruzione, risponde alla domanda che avevate davvero con una clausola WHERE.

Questa conversione è per quando non potete: una macchina bloccata, il portatile di un collega, un file arrivato per email, una domanda da cinque minuti che non giustifica una configurazione. È anche la scelta giusta quando la destinazione è genuinamente una pipeline di testo.