Convertire Parquet in CSV

Andare nell’altra direzione è ovviamente una conversione: il testo diventa colonne tipizzate, e tutti si aspettano di controllare il risultato. Questa direzione sembra un’esportazione — i dati escono, niente viene compresso, niente viene dedotto — e quell’impressione è sbagliata in un modo specifico e costoso.

Il Parquet porta uno schema. Ogni colonna ha un tipo dichiarato, registrato in un footer, e un motore di query legge quel footer prima di leggere una riga. Un CSV porta una riga di intestazione di nomi e nient’altro. Quindi la conversione sposta i valori intatti e butta via tutto ciò che il file sapeva su di loro.

I booleani arrivano come true e false. Gli interi e i numeri in virgola mobile sono scritti nella loro forma decimale. Le stringhe sono scritte come erano, tra virgolette solo dove il valore contiene una virgola, una virgoletta doppia o un ritorno a capo. I null diventano campi vuoti.

Niente di ciò è reversibile nello schema originale. Una colonna che il Parquet dichiarava intero a 32 bit e una che dichiarava double appaiono entrambe come cifre con un punto opzionale, e una colonna booleana e una colonna di testo contenente la parola “true” diventano indistinguibili. Se il CSV finirà caricato da qualche parte con un proprio schema, prendete i tipi di colonna dal file Parquet prima — DESCRIBE in DuckDB li stampa in una riga.

Una colonna timestamp viene scritta come stringa ISO 8601, quindi un valore esce simile a 2024-03-11T09:30:00.000Z. È la migliore risposta disponibile in un formato senza tipo data: non è ambiguo su quale numero sia il mese, ordina correttamente come testo semplice, e ogni database e linguaggio lo analizza senza bisogno di specificare un formato.

Resta comunque testo. Una colonna data nel CSV non risponderà all’aritmetica delle date finché chi la legge non viene informato che la colonna è una data, e un foglio di calcolo che apre il file applicherà la propria interpretazione.

Il Parquet ha un tipo intero a 64 bit, e JavaScript — che è ciò che esegue la conversione — rappresenta esattamente i numeri interi solo fino a 53 bit. Un valore oltre quel punto non può essere portato come numero senza perdere precisione.

Invece di arrotondarlo, la conversione lo scrive come testo. Un riferimento d’ordine o un identificativo snowflake appare quindi nel CSV con ogni cifra intatta, e una colonna che mescola valori sicuri e non sicuri avrà alcune voci che erano numeri e altre che erano stringhe, che in un CSV appaiono comunque identiche.

Il Parquet contiene dati annidati nativamente: una colonna può essere una lista di stringhe, uno struct con membri nominati, o una mappa. Una cella CSV contiene uno scalare singolo e non ha sintassi per nient’altro.

La conversione scrive quei valori come JSON dentro il campo, quindi una colonna lista arriva come ["a","b"] in una cella, tra virgolette perché il JSON contiene virgole. È reversibile se chi legge il file analizza il JSON, ed è profondamente scomodo se la destinazione è un foglio di calcolo o una schermata di importazione.

Aspettatevi diverse volte la dimensione, e a volte molto di più. Il Parquet scrive i valori nella loro forma binaria, comprime ogni colonna separatamente, e memorizza una colonna di valori ripetuti una sola volta come dizionario con piccoli riferimenti. Un CSV non ha nulla di tutto ciò: ogni valore viene scritto come caratteri, su ogni riga, non compresso.

Le colonne che si sono ridotte di più in ingresso sono quelle che si espandono di più in uscita. Un codice paese ripetuto su un milione di righe costava quasi nulla nel file Parquet e costa un milione di copie nel CSV. Vale la pena saperlo prima di provare a inviare il risultato via email.

Il CSV è UTF-8 senza byte order mark e una semplice interruzione di riga fra le righe. È corretto per script, importatori e controllo versione, ed è la cosa che fa apparire i nomi accentati come testo confuso quando il file viene aperto con doppio clic su Windows, perché Excel torna alla code page di sistema quando non c’è marcatore.

Importare tramite Dati, Ottieni Dati, Da Testo/CSV e scegliere UTF-8 evita il problema, e dà l’occasione di marcare le colonne identificative come testo allo stesso tempo. Se la destinazione è davvero un foglio di calcolo, convertire il file Parquet in XLSX invece rimuove la questione della codifica e mantiene i tipi.

Il lettore materializza ogni riga prima che qualcosa venga scritto, quindi l’intera tabella esiste in memoria contemporaneamente. Decine di megabyte di Parquet sono comode; notate che è un formato compresso, quindi un file modesto può espandersi a molto testo e il tetto arriva prima di quanto suggerisca la dimensione del file.

Per un’estrazione grande lo strumento corretto è DuckDB, che leggerà il file Parquet e scriverà un CSV in un’unica istruzione senza tenerli entrambi. Permette anche di selezionare solo le colonne che servono davvero, di solito la risposta migliore comunque.

Il lettore Parquet è una libreria caricata al bisogno da questa pagina e la scrittura è JavaScript ordinario, quindi nessuna richiesta porta il file da nessuna parte. Conta più qui che per la maggior parte delle coppie: un file Parquet è normalmente un artefatto dal centro di una piattaforma dati, cioè la versione prima del mascheramento e dell’aggregazione.

Non c’è coda, non c’è account e nessun limite di righe oltre alla vostra memoria. L’unica cosa che decide se la conversione funziona è se la tabella espansa ci sta, cosa che potete stimare dal conteggio delle righe nel footer.

Se il destinatario ha strumenti dati moderni, inviate l’originale. DuckDB, pandas, Polars, R con arrow, Spark e ogni magazzino dati legge Parquet direttamente, e farlo preserva i tipi, mantiene il file piccolo e rimuove un intero passaggio in cui qualcosa può andare storto.

Convertite in CSV quando il destinatario genuinamente non può — un collega di finanza con un foglio di calcolo, una richiesta di audit che nomina il formato, una schermata di caricamento con una lista fissa. Sono casi reali e comuni, e questa conversione è per loro.