Quali sono i vantaggi e gli svantaggi del formato del parquet rispetto ad altri formati?


137

Le caratteristiche di Apache Parquet sono:

  • Autodescrittivi
  • Formato colonnare
  • Indipendente dalla lingua

Rispetto ad Avro, Sequence Files, RC File ecc. Voglio una panoramica dei formati. Ho già letto: Come Impala funziona con i formati di file Hadoop , fornisce alcune informazioni sui formati, ma vorrei sapere come viene eseguito l'accesso ai dati e la memorizzazione dei dati in ciascuno di questi formati. In che modo il parquet ha un vantaggio rispetto agli altri?


2
Un bel riassunto può essere trovato in questa presentazione: link
Dominik,

@ ani-menon Il link è morto.
Sajjad Hossain,

@SajjadHossain aggiornato.
Ani Menon,

Risposte:


283

Penso che la principale differenza che posso descrivere sia legata ai formati orientati ai record rispetto alle colonne. I formati orientati ai record sono ciò a cui siamo tutti abituati: file di testo, formati delimitati come CSV, TSV. AVRO è leggermente più freddo di quelli perché può cambiare lo schema nel tempo, ad esempio aggiungendo o rimuovendo colonne da un record. Altri trucchi di vari formati (in particolare la compressione inclusa) implicano se un formato può essere diviso, ovvero puoi leggere un blocco di record da qualsiasi parte del set di dati e sapere ancora che è schema? Ma ecco maggiori dettagli sui formati colonnari come Parquet.

Parquet e altri formati colonnari gestiscono una situazione Hadoop comune in modo molto efficiente. È comune avere tabelle (set di dati) con molte più colonne di quelle che ci si aspetterebbe in un database relazionale ben progettato - un centinaio di duecento colonne non è insolito. Questo perché spesso usiamo Hadoop come luogo per denormalizzare i dati da formati relazionali - sì, ottieni molti valori ripetuti e molte tabelle tutte appiattite in una sola. Ma diventa molto più facile interrogare poiché tutti i join sono stati elaborati. Vi sono altri vantaggi come la conservazione dei dati sullo stato nel tempo. Quindi comunque è comune avere un carico di colonne in una tabella.

Diciamo che ci sono 132 colonne, e alcune di esse sono campi di testo davvero lunghi, ognuna diversa da una all'altra e consuma forse 10K per record.

Mentre interrogare queste tabelle è facile con il punto di vista SQL, è comune che tu voglia ottenere una serie di record basati solo su alcune di quelle centinaia di colonne. Ad esempio, potresti desiderare tutti i record di febbraio e marzo per i clienti con vendite> $ 500.

Per fare ciò in un formato di riga, la query dovrebbe scansionare ogni record del set di dati. Leggi la prima riga, analizza il record in campi (colonne) e ottieni la data e le colonne delle vendite, includilo nel tuo risultato se soddisfa la condizione. Ripetere. Se hai 10 anni (120 mesi) di storia, stai leggendo ogni singolo disco solo per trovare 2 di quei mesi. Naturalmente questa è una grande opportunità per usare una partizione per anno e mese, ma anche così, stai leggendo e analizzando 10K di ogni record / riga per quei due mesi solo per scoprire se le vendite del cliente sono> $ 500.

In un formato colonnare, ogni colonna (campo) di un record viene memorizzata con altre del suo genere, distribuite su molti blocchi diversi sul disco: colonne per anno insieme, colonne per mese insieme, colonne per il manuale del dipendente del cliente (o altro testo lungo) e tutti gli altri che rendono tali record così grandi tutti nel loro posto separato sul disco, e ovviamente colonne per le vendite insieme. Bene, data e mesi sono numeri, così come le vendite: sono solo pochi byte. Non sarebbe bello se dovessimo leggere solo pochi byte per ogni record per determinare quali record corrispondessero alla nostra query? Archiviazione colonnare in soccorso!

Anche senza partizioni, scansionare i piccoli campi necessari per soddisfare la nostra query è super veloce: sono tutti in ordine per record e hanno tutte le stesse dimensioni, quindi il disco cerca molto meno dati controllando i record inclusi. Non c'è bisogno di leggere il manuale del dipendente e altri campi di testo lunghi: ignorali. Quindi, raggruppando le colonne tra loro, anziché le righe, puoi quasi sempre scansionare meno dati. Vincere!

Ma aspetta, migliora. Se la tua query avesse bisogno solo di conoscere quei valori e alcuni altri (diciamo 10 delle 132 colonne) e non si interessasse a quella colonna del manuale del dipendente, una volta che avesse scelto i record giusti per restituirla, ora dovrebbe solo andare torna alle 10 colonne necessarie per rendere i risultati, ignorando gli altri 122 dei 132 nel nostro set di dati. Ancora una volta, saltiamo molte letture.

(Nota: per questo motivo, i formati colonnari sono una scelta pessima quando si eseguono trasformazioni diritte, ad esempio, se si uniscono tutte e due le tabelle in un unico grande set di risultati che si sta salvando come nuova tabella, i sorgenti verranno comunque scansionati completamente, quindi non ci sono molti vantaggi nelle prestazioni di lettura e, poiché i formati colonnari devono ricordare di più su dove si trovano le cose, usano più memoria di un formato di riga simile).

Un altro vantaggio del colonnare: i dati sono distribuiti in tutto. Per ottenere un singolo record, puoi avere 132 lavoratori ciascuno che leggono (e scrivono) dati da / a 132 luoghi diversi su 132 blocchi di dati. Yay per la parallelizzazione!

E ora per il copertoncino: gli algoritmi di compressione funzionano molto meglio quando riescono a trovare schemi ripetitivi. Potresti comprimere AABBBBBBCCCCCCCCCCCCCCCCcome 2A6B16Cma ABCABCBCBCBCCCCCCCCCCCCCCnon diventare così piccolo (beh, in realtà, in questo caso lo farebbe, ma fidati di me :-)). Quindi, ancora una volta, meno lettura. E anche scrivere.

Quindi leggiamo molti meno dati per rispondere a domande comuni, è potenzialmente più veloce da leggere e scrivere in parallelo e la compressione tende a funzionare molto meglio.

Colonnare è fantastico quando il tuo lato di input è grande e il tuo output è un sottoinsieme filtrato: da grande a piccolo è fantastico. Non altrettanto vantaggioso quando input e output sono più o meno gli stessi.

Ma nel nostro caso, Impala ha risposto alle nostre vecchie query Hive che sono state eseguite in 5, 10, 20 o 30 minuti e si è conclusa la maggior parte in pochi secondi o un minuto.

Spero che questo aiuti a rispondere almeno in parte alla tua domanda!


7
Eccellente. Grazie. È un riassunto molto utile che manca a molti documenti di progetto di Apache. Tu dici: "piccoli campi ... sono tutti in ordine per record". Supponiamo che io abbia una semplice tabella di userid: long e age: int, e voglio trovare tutti gli utenti tra una certa età. Qui ho due colonne. Devo specificare quando è l'indice per l'ordinamento o TUTTE le colonne sono indicizzabili in modo efficiente?
user48956

1
Cosa succede se uso il parquet per una multiproprietà? Diverse colonne (100+), ciascuna colonna dati del sensore con frequenza diversa (da 100Hz a 0,25 Hz). Sarebbe una decisione intelligente?
Guilhermecgs,

53

Avro è un formato di archiviazione basato su righe per Hadoop.

Parquet è un formato di archiviazione basato su colonne per Hadoop.

Se il tuo caso d'uso in genere esegue la scansione o recupera tutti i campi in una riga in ogni query, Avro è di solito la scelta migliore.

Se il tuo set di dati ha molte colonne e il tuo caso d'uso in genere comporta l'utilizzo di un sottoinsieme di quelle colonne anziché di interi record, Parquet è ottimizzato per quel tipo di lavoro.

fonte


26

La risposta di Tom è abbastanza dettagliata ed esaustiva, ma potresti anche essere interessato a questo semplice studio su Parquet vs Avro fatto presso Allstate Insurance, riassunto qui:

"Complessivamente, Parquet ha mostrato risultati simili o migliori su ogni test [rispetto ad Avro]. Le differenze di prestazioni della query sui set di dati più grandi a favore di Parquet sono in parte dovute ai risultati di compressione; durante la query del set di dati ampio, Spark ha dovuto leggere 3,5x meno dati per Parquet di Avro. Avro non ha funzionato bene durante l'elaborazione dell'intero set di dati, come sospettato. "

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.