Convertire CSV in Parquet

Tutto ciò che un CSV sa di sé è una riga di intestazione, e una riga di intestazione è un elenco di nomi. Non può dire che `amount` è un decimale, che `is_active` è un booleano, o che `customer_id` non dovrebbe mai essere trattato come aritmetica. Ogni strumento che legge il file deve capirlo di nuovo, e ogni strumento lo capisce in modo leggermente diverso, che è perché lo stesso estratto si carica in tre modi in tre posti.

Un file Parquet finisce con un footer che contiene lo schema, il numero di righe, e metadati per colonna. Un motore di query legge prima il footer, che sono pochi kilobyte alla fine del file, e può dirvi i nomi delle colonne e i tipi prima di toccare qualsiasi dato. Questa è una proprietà strutturale piuttosto che una comodità: è ciò che rende il formato sicuro da consegnare a qualcuno che non era lì quando è stato scritto.

Tre cose accadono a ogni colonna lungo il percorso e si compongono. I valori sono scritti nella loro forma binaria invece che come testo decimale, quindi un numero che occupava undici caratteri nel CSV ne prende quattro byte. Ogni colonna è poi compressa da sola con Snappy, che è il codec predefinito qui. E una colonna i cui valori si ripetono è codificata a dizionario: i valori distinti sono scritti una volta in una pagina di dizionario, e la colonna stessa diventa un elenco di piccoli riferimenti interi ad esso.

Il dizionario è applicato per colonna e solo dove conviene. Il writer campiona i primi mille valori e usa un dizionario quando al massimo la metà di essi sono distinti, il che cattura le colonne che vi aspettereste (paese, stato, codice prodotto, valuta) e salta una colonna di testo libero unico dove un dizionario sarebbe più grande dei dati. Ecco perché il risparmio su un estratto operativo è enorme e il risparmio su una tabella di frasi distinte è modesto, e vale la pena sapere quale delle due cose sia il vostro file prima di prevedere il risultato.

Le righe sono scritte in gruppi invece che come un blocco unico, tra mille e centomila righe ciascuno, con pagine al loro interno limitate a un megabyte. Ogni blocco di colonna all’interno di un gruppo porta statistiche, e quelle statistiche sono ciò che trasforma una scansione in un salto.

L’effetto è quello che le persone intendono quando dicono che Parquet è più veloce. Una query che filtra su un intervallo di date legge il footer, vede che un row group contiene valori interamente fuori dall’intervallo, e non legge mai quel gruppo. Una query che nomina due colonne su quaranta legge i byte di due colonne invece di ogni riga. Nessuna delle due è disponibile su un CSV in nessuna circostanza, perché un CSV deve essere letto dall’inizio per scoprire dove si trovi qualcosa.

Il tipo è inferito dai valori piuttosto che dichiarato, dato che la sorgente non ha nulla da dichiarare. Ogni colonna è letta per intero: tutti booleani diventa BOOLEAN, tutti numeri interi all’interno dell’intervallo a 32 bit diventa INT32, numeri che non sono tutti interi o non sono abbastanza piccoli diventano DOUBLE, e qualsiasi altra cosa diventa una stringa. I null non partecipano, quindi una colonna numerica con dei vuoti resta numerica.

Un valore disperso rende l’intera colonna testo, e questo è deliberato piuttosto che una limitazione. Prendere il tipo dalla prima riga scriverebbe una colonna che inizia con numeri come colonna intera e trasformerebbe ogni valore non numerico successivo in un null, producendo un file che si carica senza lamentele e ha silenziosamente cancellato righe. Una colonna stringa è visibile, casttabile in un’espressione, e non perde mai nulla. Se una colonna arriva come testo e vi aspettavate numeri, interrogare i valori che falliscono il cast vi mostrerà una manciata di righe con una nota a piè di pagina, un totale o la parola «none» in esse, ciascuna delle quali è un fatto vero sull’estratto.

La conversione legge il CSV con inferenza di tipo, quindi `007` è il numero 7 nel momento in cui il writer sta scegliendo un tipo di colonna, e la colonna INT32 risultante è un record fedele di un valore che era già sbagliato. Parquet riceve la colpa di questo regolarmente e non la merita: la perdita accade nella fase di analisi del testo, che è la stessa fase che ogni altro reader CSV esegue.

Le colonne a rischio sono quelle in cui l’aritmetica sarebbe priva di significato: codici postali, numeri di parte, numeri di telefono, riferimenti di conto, qualsiasi cosa con padding di zeri. Se l’estratto è sotto il vostro controllo, esportate quelle colonne quotate o con un prefisso e arrivano come stringhe intatte. Se non lo è, controllate la colonna nell’output prima che il file sia scritto ovunque di durevole, perché l’intero punto del passaggio a Parquet è che il file smette di essere ri-derivato.

Su una tabella di cinquantamila righe e sei colonne (un identificatore, un codice prodotto, una città, una quantità, un prezzo e un flag) l’output Parquet misurato 301 KB. Gli stessi dati scritti come testo separato da tabulazione erano circa 1,8 MB, e un CSV di essi differisce da quello solo per quale byte separa i campi e per le virgolette attorno ai valori che contengono virgole.

Questa è circa una riduzione di sei volte, ed è un’aspettativa ragionevole per dati operativi con codici e categorie ripetuti. Un file dominato da testo libero unico farà molto peggio, perché né il dizionario né la codifica binaria hanno molto con cui lavorare lì. Entrambe le cifre assumono nessuna compressione sul CSV; un CSV gzippato chiude parte del divario, al costo di essere non interrogabile finché non è decompresso per intero.

Nessuna configurazione è richiesta. DuckDB legge il file direttamente in una clausola FROM, pandas lo legge in una singola chiamata, e Spark lo tratta come un formato di tabella nativo. Il file inizia e finisce con i quattro byte PAR1, che è come ciascuno di essi lo riconosce prima di leggere il footer.

La prima cosa da guardare dopo il caricamento è lo schema inferito piuttosto che le prime dieci righe. Una colonna che vi aspettavate fosse numerica e che è arrivata come testo vi sta dicendo qualcosa di vero sul CSV, ed è molto più economico apprenderlo ora che dopo che il file è stato unito ad altri tre e copiato in un warehouse. Il cast sulla strada verso una tabella è un’espressione per colonna; il cast alla cieca è come le righe da cui eravate protetti dal perderle vengono perse comunque.

L’intera tabella è tenuta in memoria: il CSV è analizzato in righe, le righe sono trasposte in colonne, e le colonne sono scritte. Decine di megabyte si convertono senza cerimonie e le centinaia sono dove una scheda comincia a sforzarsi, che è un tetto reale e non un livello di piano: non c’è caricamento e nulla da pagare.

Per un estratto genuinamente grande lo strumento appropriato è DuckDB, che leggerà il CSV dal disco e scriverà Parquet in un’unica istruzione senza mai tenere il file. Dirlo chiaramente è più utile che lasciare che una conversione da due gigabyte fallisca a due terzi del percorso. Questa pagina è per il file che ci sta, che è la maggior parte di essi, e per il caso in cui installare qualcosa non è un’opzione.

Entrambe le metà girano su questa pagina: il parser CSV e il writer Parquet sono librerie caricate su richiesta, e nessuna richiesta porta il file da nessuna parte. Un CSV in rotta verso una piattaforma dati è molto spesso l’artefatto meno redatto dell’intera pipeline (il dump grezzo prima dei join e del mascheramento) e caricarlo su un convertitore è esattamente il passaggio che una policy di protezione dei dati esiste per prevenire.

Rimuove anche un livello dalla conversazione. Non c’è coda, nessun conteggio massimo di righe e nessun account, quindi l’unica domanda è se il file sta in memoria, cosa a cui potete rispondere guardandolo.

Parquet è una destinazione povera per qualsiasi cosa una persona debba leggere. È binario, non è editabile, e un collega senza gli strumenti giusti non può aprirlo affatto: il registro registra il suo supporto come disomogeneo per esattamente questa ragione. Se il file va a un essere umano piuttosto che a un motore, inviate il CSV o un foglio di calcolo.

È anche il bersaglio sbagliato per un caricamento che accade una volta e viene poi gettato via: il costo di scrittura non compra nulla se il file non viene mai più interrogato, e un caricatore in blocco che legge testo delimitato direttamente sarà più veloce end to end. Scegliete Parquet quando gli stessi dati saranno scansionati ripetutamente, filtrati, uniti e conservati, che è esattamente quando le colonne tipizzate e i row group saltati cominciano a ripagarsi.