web-dev-qa-db-ja.com

寄木細工vs ORC vs ORC with Snappy

Hiveで利用可能なストレージ形式でいくつかのテストを実行し、ParquetとORCを主要なオプションとして使用しています。 ORCはデフォルトの圧縮で1回、Snappyで1回含まれています。

私は、ParquetがORCと比較して時間/空間の複雑さにおいて優れていると述べている多くのドキュメントを読みましたが、私のテストは、私が経験したドキュメントと反対です。

データの詳細に従います。

Table A- Text File Format- 2.5GB

Table B - ORC - 652MB

Table C - ORC with Snappy - 802MB

Table D - Parquet - 1.9 GB

私のテーブルの圧縮に関する限り、寄木細工は最悪でした。

上記の表を使用したテストでは、次の結果が得られました。

行カウント操作

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

列操作の合計

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

列操作の平均

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

where句を使用して特定の範囲から4列を選択する

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

つまり、ORCはParquetよりも高速ですか？または、クエリの応答時間と圧縮率を向上させるためにできることはありますか？

ありがとう！

hadoophiveparquetsnappyorc
77
Rahul

私は、これらの形式の両方に独自の利点があると言います。

高度にネストされたデータがある場合、寄木細工はGoogle Dremelのようにその要素をツリーとして保存するため、より良いかもしれません（ こちらを参照 =）。
ファイル構造がフラット化されている場合、Apache ORCの方が優れている可能性があります。

私の知る限り、寄木細工はまだインデックスをサポートしていません。 ORCには軽量のインデックスが付属し、Hive 0.14から追加のブルームフィルターが追加されました。これは、特に合計操作に関して、クエリの応答時間を短縮するのに役立ちます。

Parquetのデフォルトの圧縮はSNAPPYです。テーブルA-B-CとDは同じデータセットを保持していますか？ 「はい」の場合、1.9 GBにしか圧縮されないため、怪しいものがあるように見えます

43
PhanThomas

あなたはこれを見ている：

  • Hiveにはベクトル化されたORCリーダーがありますが、ベクトル化された寄木細工のリーダーはありません。

  • Sparkには、ベクトル化された寄木張りのリーダーがあり、ベクトル化されたORCリーダーはありません。

  • Sparkは寄木細工で最高のパフォーマンスを発揮し、HiveはORCで最高のパフォーマンスを発揮します。

SparkでORCとParquetを実行すると、同様の違いがあります。

ベクトル化とは、行がバッチでデコードされることを意味し、メモリの局所性とキャッシュ使用率を劇的に改善します。

（Hive 2.0およびSpark 2.1時点で正しい）

40
jonathanChap

さまざまなユースケースで、さまざまなファイル形式（Avro、JSON、ORC、およびParquet）を比較するベンチマークを行いました。

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

データはすべて公開されており、ベンチマークコードはすべて次のオープンソースです。

https://github.com/Apache/orc/tree/branch-1.4/Java/bench

5
Owen O'Malley

ParquetとORCには、それぞれ長所と短所があります。しかし、私は単純な経験則に単純に従おうとしています-「データのネストと列の数」。 Google Dremelに従うと、寄木細工がどのように設計されているかがわかります。データを保存するために階層ツリーのような構造を使用します。ツリーが深くネストするほど。

ただし、ORCはフラット化されたファイルストア用に設計されています。したがって、データがより少ない列でフラット化されている場合は、ORCを使用できます。そうでない場合は、寄せ木張りが適しています。フラット化されたデータの圧縮は、ORCで驚くほど機能します。

大きなフラットファイルでベンチマークを行い、spark Dataframeに変換し、寄木細工とORC形式の両方でS​​に保存し、** 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.

すぐに、ネストされたデータのベンチマークを行い、結果をここで更新します。

4
james.bondu