Parquet vs ORC vs ORC con Snappy

88

Sto eseguendo alcuni test sui formati di archiviazione disponibili con Hive e sto utilizzando Parquet e ORC come opzioni principali. Ho incluso ORC una volta con la compressione predefinita e una volta con Snappy.

Ho letto molti documenti che affermano che Parquet è migliore in termini di complessità tempo / spazio rispetto a ORC ma i miei test sono opposti ai documenti che ho seguito.

Di seguito alcuni dettagli dei miei dati.

Table A- Text File Format- 2.5GB

Table B - ORC - 652MB

Table C - ORC with Snappy - 802MB

Table D - Parquet - 1.9 GB

Il parquet era peggiore per quanto riguarda la compressione per il mio tavolo.

I miei test con le tabelle precedenti hanno prodotto i seguenti risultati.

Operazione di conteggio delle righe

Text Format Cumulative CPU - 123.33 sec

Parquet Format Cumulative CPU - 204.92 sec

ORC Format Cumulative CPU - 119.99 sec 

ORC with SNAPPY Cumulative CPU - 107.05 sec

Somma di un'operazione di colonna

Text Format Cumulative CPU - 127.85 sec   

Parquet Format Cumulative CPU - 255.2 sec   

ORC Format Cumulative CPU - 120.48 sec   

ORC with SNAPPY Cumulative CPU - 98.27 sec

Media di un'operazione di colonna

Text Format Cumulative CPU - 128.79 sec

Parquet Format Cumulative CPU - 211.73 sec    

ORC Format Cumulative CPU - 165.5 sec   

ORC with SNAPPY Cumulative CPU - 135.45 sec

Selezione di 4 colonne da un determinato intervallo utilizzando la clausola where

Text Format Cumulative CPU -  72.48 sec 

Parquet Format Cumulative CPU - 136.4 sec       

ORC Format Cumulative CPU - 96.63 sec 

ORC with SNAPPY Cumulative CPU - 82.05 sec

Ciò significa che ORC è più veloce di Parquet? O c'è qualcosa che posso fare per farlo funzionare meglio con il tempo di risposta alle query e il rapporto di compressione?

Grazie!

hadoop  hive  parquet  snappy  orc 
— Rahul
fonte
1
Potresti condividere un algoritmo generico usato per fare quell'esperimento? Tuttavia, è necessario utilizzare gli stessi dati. Ma condividere tutto il resto per ottenere gli stessi risultati con diversi set di dati potrebbe essere molto utile per darti una risposta migliore o per dimostrare che hai un ottimo punto e per cambiare il mondo per sempre.
— Mestre San
hai dei risultati spark vs tez usando orc vs parquet? da quello che ho visto sembra che tez sia più veloce (3 volte più veloce) quando si usa il formato orc.
— David H
+1 per la tua bella panoramica sul benchmarking. Ad ogni modo, c'è la possibilità che tu possa fornire una versione aggiornata poiché alcuni aspetti tecnici dietro le quinte sono cambiati (ad esempio come discusso nella risposta di @jonathanChap)?
— Markus

Risposte:

52

Direi che entrambi questi formati hanno i loro vantaggi.

Parquet potrebbe essere migliore se hai dati molto nidificati, perché memorizza i suoi elementi come un albero come fa Google Dremel ( vedi qui ).
Apache ORC potrebbe essere migliore se la struttura del file fosse appiattita.

E per quanto ne so il parquet non supporta ancora gli indici. ORC viene fornito con un indice leggero e poiché Hive 0.14 un filtro Bloom aggiuntivo che potrebbe essere utile per il miglior tempo di risposta alle query, soprattutto quando si tratta di operazioni di somma.

La compressione predefinita di Parquet è SNAPPY. Le tabelle A - B - C e D contengono lo stesso set di dati? Se sì, sembra che ci sia qualcosa di losco, quando si comprime solo a 1,9 GB

— PhanThomas
fonte
2
Tabella A - Formato file di testo - Nessuna compressione ......... Tabella B - Formato file ORC con compressione ZLIB ......... Tabella C - ORC con Snappy ....... Tabella D - Parquet con Snappy ..... Ho lavorato su un'altra tabella con ~ 150 colonne e ~ 160 GB di dimensione per verificare come si comportano i formati di file lì. Parquet ha impiegato 35 GB per memorizzare quei 160 GB di dati mentre ORC con snappy ha impiegato 39 GB ... La compressione sembrava molto migliore per Parquet rispetto al test pubblicato in questione, ma le prestazioni erano di nuovo su linee simili .. ORC ha brillato qui con pari prestazioni migliori rispetto alla combinazione ORC + SNAPPY.
— Rahul
1
La struttura dei dati per i miei casi d'uso era più piatta senza alcuna nidificazione. Accetto il tuo commento sull'indicizzazione su Parquet vs ORC e ​​questo fa davvero la differenza. Hai dei risultati da condividere dal confronto delle prestazioni di entrambi? Ciò potrebbe aiutare a calmare la mia coscienza che sto implementando correttamente i formati. :)
— Rahul
Non ho mai testato il mio set di dati su Parquet perché l'indice era un requisito necessario e abbiamo anche una struttura dati piatta senza informazioni nidificate. Quello che ho capito è che, a seconda di dove memorizzi i tuoi file, hai bisogno di una striscia e di una dimensione del file diverse per ottenere i migliori risultati. Quando si archiviano i file in modo permanente su HDFS, è meglio avere file e strisce più grandi. "set mapred.max.split.size = 4096000000" era il parametro che ho usato per influenzare la dimensione del file e ha lasciato la dimensione dello stripe al valore predefinito. Con questa impostazione ho ottenuto circa il 94% di query e un aumento della compressione.
— PhanThomas
Se desideri archiviare i tuoi file su Amazon S3 come cold storage, un file di dimensioni e stripe più piccole mi ha dato risultati molto migliori. ho utilizzato file della dimensione di 40-60 MB contenenti un singolo Stripe.
— PhanThomas
44

Lo vedi perché:

  • Hive ha un lettore ORC vettorializzato ma non un lettore parquet vettorializzato.

  • Spark ha un lettore di parquet vettorializzato e nessun lettore ORC vettorializzato.

  • Spark si comporta meglio con il parquet, hive si comporta meglio con ORC.

Ho riscontrato differenze simili durante l'esecuzione di ORC e ​​Parquet con Spark.

La vettorizzazione significa che le righe vengono decodificate in batch, migliorando notevolmente la località della memoria e l'utilizzo della cache.

(corretto a partire da Hive 2.0 e Spark 2.1)

— jonathanChap
fonte
18
A partire dal 2.3.0, scintilla non dispone di un lettore ORC vettorializzare: issues.apache.org/jira/browse/SPARK-16060
— Steen
6
Hive 2.3.0 ha vettorializzato Parquet Reader - issues.apache.org/jira/browse/HIVE-14815
— ruhong
A partire da Spark 2.3, Spark supporta un lettore ORC vettorializzato spark.apache.org/docs/latest/sql-data-sources-orc.html
— Anurag Sharma
10

Sia Parquet che ORC hanno i loro vantaggi e svantaggi. Ma cerco semplicemente di seguire una semplice regola pratica: "Quanto sono nidificati i tuoi dati e quante colonne ci sono" . Se segui il Google Dremel puoi scoprire come viene progettato il parquet. Utilizzano una struttura ad albero gerarchica per memorizzare i dati. Più la nidificazione è profonda l'albero.

Ma ORC è progettato per un archivio di file appiattito. Quindi, se i tuoi dati sono appiattiti con meno colonne, puoi andare con ORC, altrimenti il ​​parquet andrebbe bene per te. La compressione sui dati appiattiti funziona in modo sorprendente in ORC.

Abbiamo eseguito alcuni benchmark con un file appiattito più grande, lo abbiamo convertito in Spark Dataframe e lo abbiamo archiviato sia in formato parquet che in formato ORC in S3 e abbiamo eseguito query con ** Redshift-Spectrum **.

Size of the file in parquet: ~7.5 GB and took 7 minutes to write
Size of the file in ORC: ~7.1. GB and took 6 minutes to write
Query seems faster in ORC files.

Presto faremo alcuni benchmark per i dati nidificati e aggiorneremo i risultati qui.

— james.bondu
fonte
6

Abbiamo eseguito alcuni benchmark confrontando i diversi formati di file (Avro, JSON, ORC e ​​Parquet) in diversi casi d'uso.

https://www.slideshare.net/oom65/file-format-benchmarks-avro-json-orc-parquet

I dati sono tutti disponibili pubblicamente e il codice di benchmark è tutto open source all'indirizzo:

https://github.com/apache/orc/tree/branch-1.4/java/bench

— Owen O'Malley
fonte
5
Questo è davvero utile, ma dovrebbe esserci un disclaimer che @Owen lavora per Horton Works, che originariamente ha sviluppato il formato di file ORC
— Daniel Kats
1
Grazie! Ma il secondo anello è rotto. Puoi correggerlo o rimuoverlo dalla tua risposta?
— Danilo Gomes
3

Entrambi hanno i loro vantaggi. Usiamo Parquet in collaborazione con Hive e Impala, ma volevamo solo sottolineare alcuni vantaggi di ORC rispetto a Parquet: durante le query a lunga esecuzione, quando Hive interroga le tabelle ORC GC viene chiamato circa 10 volte meno frequentemente . Potrebbe non essere nulla per molti progetti, ma potrebbe essere cruciale per altri.

ORC richiede anche molto meno tempo, quando è necessario selezionare solo poche colonne dalla tabella. Anche alcune altre query, in particolare con i join, richiedono meno tempo a causa dell'esecuzione di query vettorializzate, che non è disponibile per Parquet

Inoltre, la compressione ORC a volte è un po 'casuale, mentre la compressione Parquet è molto più coerente. Sembra che quando la tabella ORC ha molte colonne numeriche, non si comprime anche. Colpisce sia la compressione zlib che quella scattante

— Hasan Ammori
fonte
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.