Convertire TSV in Parquet

Molto output scientifico e analitico è separato da tab per convenzione piuttosto che per scelta: matrici di espressione, riepiloghi di varianti, tabelle di annotazione, log di strumenti, export di piattaforme pubblicitarie. Il tab fu scelto perché le colonne descrittive sono piene di virgole e punto e virgola.

È un formato scarso contro cui calcolare ripetutamente. Ogni lettura analizza ogni byte, ogni strumento ri-deriva i tipi di colonna e li deriva leggermente in modo diverso, e una tabella che verrà filtrata cento volte paga il costo di analisi cento volte. Convertire una volta in un file colonnare tipizzato sposta quel lavoro all’inizio.

Una colonna Parquet contiene un tipo per tutti i suoi valori. Lo scrittore qui legge l’intera colonna prima di decidere, e la regola è deliberatamente severa: se ogni valore non vuoto è un booleano la colonna è BOOLEAN, se sono tutti interi nell’intervallo a 32 bit è INT32, se sono tutti numeri è DOUBLE, e se un singolo valore non è nessuno di questi l’intera colonna è una stringa.

Le tabelle di analisi sono piene di valori che non sono nessuno di questi. NA è la convenzione R e appare in quasi ogni tabella toccata da R. Un punto singolo è la convenzione VCF e GTF per un campo mancante. Uno qualunque di questi in qualunque riga trasforma una colonna di dieci milioni di numeri in una colonna di dieci milioni di stringhe.

L’alternativa allettante è tipizzare la colonna dalla prima riga, o dalle prime mille, e scrivere come null qualunque cosa disaccordi. La maggior parte degli strumenti fa esattamente questo. Produce un file valido, che carica senza avviso, e ha silenziosamente cancellato ogni riga dove appariva il marcatore.

Nessuno lo scopre finché un conteggio non torna corto, e a quel punto il file è di solito già stato unito ad altri tre. Una colonna stringa è rumorosa: si vede appena guardate lo schema, può essere convertita in un’espressione, e la conversione vi dirà precisamente quali valori non potevano essere convertiti.

Serve un comando. cut -f7 table.tsv | sort -u | head -50 stampa i valori distinti della settima colonna, e il marcatore sarà ovvio tra loro. Farlo su ogni colonna di una tabella larga è un ciclo; farlo sulle tre colonne su cui filtrate davvero di solito basta.

La correzione è nella sorgente, non nel convertitore: sostituite il marcatore con un campo genuinamente vuoto. I null sono esclusi dall’inferenza di tipo, quindi una colonna di numeri con vuoti reali passa come colonna numerica con null dentro.

Le tabelle larghe sono dove il layout colonnare guadagna di più. Una matrice di espressione con una riga per gene e una colonna per campione è memorizzata una colonna dopo l’altra piuttosto che una riga dopo l’altra — quindi una query che nomina quattro colonne legge quattro colonne di byte e non tocca il resto.

Contro un file separato da tab la stessa query deve leggere ogni byte di ogni riga per trovare i campi che vuole, perché l’unico modo per localizzare il diciassettesimo campo di una riga è contare diciassette tab. Quella differenza non diminuisce con la crescita della tabella; si allarga.

Lo scrittore emette INT32 solo dove ogni valore nella colonna sta nell’intervallo a 32 bit. Oltre, la colonna diventa DOUBLE piuttosto che INT64, il che sorprende chi sa che Parquet ha un tipo intero a 64 bit.

La ragione è onestà su ciò che è arrivato. I valori passano attraverso numeri JavaScript in ingresso, che portano 53 bit di precisione intera, quindi una coordinata genomica oltre quel punto è già stata arrotondata prima che lo scrittore la veda. Dichiararla INT64 prometterebbe un’esattezza che il valore non ha più.

Il footer del file contiene i nomi delle colonne come scritti dalla riga di intestazione, il tipo di ciascuna, e il conteggio righe, e i dati stessi sono scritti in gruppi di righe tra mille e centomila con statistiche per colonna allegate. Ogni colonna è compressa da sola con Snappy.

Per una tabella di analisi è lì che va la dimensione. Una colonna cromosoma, un identificatore campione, un filamento, una categoria — ognuna ha una manciata di valori distinti ripetuti su milioni di righe, e ciascuna collassa a quasi nulla. Una colonna di misurazioni continue no.

DuckDB legge il file sul posto: una clausola FROM che nomina il percorso basta, nessun passo di importazione e nessuna definizione tabella. DESCRIBE SELECT * FROM "table.parquet" stampa lo schema dedotto, la prima cosa da guardare.

pandas lo legge in una chiamata e Spark lo tratta come formato tabella nativo. In tutti e tre, la mossa corretta dopo una sorpresa è interrogare i valori incriminati piuttosto che convertire alla cieca — una conversione forzata annullerà qualunque cosa non stia, esattamente il fallimento che lo scrittore ha rifiutato di commettere per vostro conto.

Entrambe le metà girano su questa pagina: il parser separato da tab è JavaScript ordinario e lo scrittore Parquet è una libreria caricata su richiesta. Nulla viene caricato, il che conta per un set di risultati non pubblicato o misurazioni non vostre da distribuire.

L’intera tabella viene tenuta in memoria mentre viene trasposta in colonne, quindi decine di megabyte convertono senza cerimonie e centinaia è dove una scheda browser comincia a faticare. Una matrice multi-gigabyte appartiene a DuckDB.

Tenetelo se una persona o uno script deve leggerlo come testo. Parquet è binario, non modificabile, e il registro registra il suo supporto come discontinuo — un collaboratore senza gli strumenti giusti non può aprirlo affatto.

Tenetelo anche se il file è un artefatto pubblicato. Le tabelle separate da tab sono ciò che riviste, repository e dataset pubblici accettano, e saranno ancora leggibili senza dipendenze fra vent’anni. Convertite in Parquet per la copia di lavoro.