CSV vs Parquet: quando conviene davvero convertire

Due formati, due obiettivi di progetto

Si tende a trattare CSV e Parquet come la versione vecchia e quella nuova della stessa cosa. Sono nati per compiti diversi, e la maggior parte delle conversioni sbagliate nasce dal dimenticarlo.

Il CSV è testo semplice con un record per riga e valori separati da un delimitatore. L'RFC 4180, pubblicata nel 2005, descrive le convenzioni più diffuse ed è un documento informativo, non uno standard rigido. Questa elasticità è il motivo per cui il CSV è ovunque: qualsiasi programma può leggerlo e scriverlo, e una persona può aprirlo in un editor di testo. È anche all'origine dei problemi: non c'è uno schema, non ci sono tipi né compressione, e nulla garantisce delimitatore, virgolette o codifica.

Apache Parquet è un formato binario a colonne nato all'inizio degli anni 2010 per i carichi di lavoro analitici. Invece di memorizzare riga dopo riga, conserva insieme i valori di ciascuna colonna, raggruppati in row group. Il file contiene il proprio schema con i tipi di dato, comprime ogni colonna separatamente e mantiene in un footer statistiche come i valori minimo e massimo.

Perché le colonne si comprimono e si leggono meglio

I valori di una colonna hanno lo stesso tipo e tendono ad assomigliarsi: un codice paese ripetuto milioni di volte, timestamp che crescono con regolarità, un campo di stato con cinque valori possibili. Parquet sfrutta questa regolarità con codifiche come la dictionary encoding e la run-length encoding, e poi applica sopra un codec generico come Snappy, Gzip o Zstandard.

Lo stesso schema aiuta in lettura. Un motore che ha bisogno di due colonne su quaranta può leggere solo quelle due, e può saltare interi row group i cui valori minimo e massimo escludono una corrispondenza. Un lettore CSV non ha questa possibilità: per trovare il valore di una colonna deve scorrere e analizzare ogni riga.

Cosa si guadagna convertendo

• File più piccoli quando i dati sono ripetitivi. Colonne categoriche, date e identificatori a bassa cardinalità si riducono molto. Colonne di identificatori casuali o di numeri in virgola mobile ad alta precisione si riducono molto meno.
• Query analitiche più veloci, perché i motori leggono solo le colonne e i row group che servono.
• Tipi preservati. Interi, decimali e timestamp restano ciò che sono, quindi un CAP scritto come 00123 non è più in balìa di un foglio di calcolo che lo trasforma in 123.
• Uno schema che viaggia con i dati, così la persona successiva non deve indovinare cosa significhi ogni colonna.

Cosa si perde

• La leggibilità diretta. Non puoi aprire un file Parquet in un editor di testo né con un doppio clic in un foglio di calcolo.
• Le aggiunte economiche. I file Parquet sono scritti per row group e non sono pensati per essere modificati sul posto, quindi aggiungere una riga significa scrivere un nuovo file.
• La semplicità per i file piccoli. Footer e metadati hanno un costo fisso, che può rendere un piccolo file Parquet più grande del CSV di partenza.
• La compatibilità. Alcuni strumenti aziendali e sistemi più vecchi accettano solo CSV.

Una guida alla decisione

Converti in Parquet quando il file è grande, quando lo leggi ripetutamente e di solito ti servono solo alcune colonne, quando più pipeline lo condividono e hanno bisogno di tipi coerenti, o quando resterà a lungo in uno storage a oggetti. Mantieni il CSV quando il file è piccolo, quando le persone lo modificano a mano, quando lo invii a qualcuno che deve solo aprirlo, quando il sistema di destinazione accetta solo CSV, o quando il lavoro è occasionale.

Come misurarlo sui tuoi dati

I risultati di compressione dipendono interamente dai dati, quindi qualsiasi rapporto universale letto online va preso con sospetto. Una risposta affidabile richiede pochi minuti con il tuo file:

1. Profila prima il CSV. Un profiler dei dati mostra tipi di colonna, conteggio dei null e numero di valori distinti, e ti dice quali colonne si comprimeranno bene.
2. Converti il file in Parquet con un convertitore da CSV a Parquet.
3. Confronta le dimensioni dei due file e annota quali colonne ti aspettavi si riducessero.
4. Leggi lo schema del risultato. L'inferenza dei tipi può sbagliare, e identificatori con zeri iniziali, codici numerici lunghi e date in formati misti sono le vittime abituali. Correggi la sorgente o le impostazioni di conversione se una colonna ha il tipo sbagliato.
5. Ispeziona i metadati: numero di row group, codec di compressione e statistiche per colonna. Spiegano la dimensione ottenuta.
6. Riconverti il file Parquet in CSV e confrontalo con l'originale. Conserva l'originale finché il giro completo non coincide.

Ognuno di questi passaggi si può fare nel browser senza caricare il file, cosa importante se i dati sono riservati. Gli strumenti collegati qui sotto coprono ciascuno di essi.

Errori comuni nella conversione

• Fidarsi ciecamente dell'inferenza dei tipi. Una colonna che sembra numerica nelle prime mille righe può contenere testo più avanti, e il convertitore può fallire oppure ripiegare sulle stringhe.
• Convertire tanti file minuscoli uno alla volta. Parquet dà il meglio con file più grandi, quindi unisci prima le piccole esportazioni CSV e scrivi meno file, più grandi.
• Buttare via la sorgente. Considera il CSV come archivio finché non hai verificato il file Parquet, e annota le impostazioni di conversione usate.
• Ignorare i fusi orari. Un timestamp scritto senza offset in un CSV è ambiguo, e convertirlo obbliga a una scelta. Falla in modo esplicito, invece di lasciarla a un valore predefinito.

Perché non c'è un rapporto di compressione

Non ho citato un dato come "Parquet è dieci volte più piccolo". Per alcuni dataset vale, per altri il guadagno è modesto, e per i file minuscoli il risultato può essere peggiore. Se un formato deve stare al centro della tua pipeline, dedica dieci minuti a provarlo su un campione rappresentativo prima di impegnarti.