寄木細工vsORC 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が寄木細工より速いことを意味しますか？または、クエリの応答時間と圧縮率を改善するためにできることはありますか？

ありがとう！

これらのフォーマットには両方とも独自の利点があると思います。

寄木細工は、Google Dremelのように要素をツリーとして格納するため、高度にネストされたデータがある場合に適している可能性があります（ここを参照）。
ファイル構造がフラット化されている場合は、ApacheORCの方が適している可能性があります。

そして、私が知る限り、寄木細工はまだインデックスをサポートしていません。ORCには軽量のインデックスが付属しており、Hive 0.14以降、追加のブルームフィルターが追加されています。これは、特に合計演算に関して、クエリの応答時間を改善するのに役立つ可能性があります。

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

あなたはこれを見ています：

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

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

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

ORCとParquetwith Sparkを実行すると、同様の違いが見られます。

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

（Hive2.0およびSpark2.1の時点で正しい）

ParquetとORCには、それぞれ長所と短所があります。しかし、私は単純な経験則、つまり「データはどの程度ネストされており、列はいくつあるか」に従うようにしています。Google Dremelをフォローすると、寄木細工のデザインがどのように設計されているかがわかります。それらは、データを格納するために階層ツリーのような構造を使用します。入れ子が多いほど、ツリーが深くなります。

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

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

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

さまざまなユースケースでさまざまなファイル形式（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

どちらにも利点があります。私たちはHiveとImpalaと一緒にParquetを使用していますが、Parquetに対するORCのいくつかの利点を指摘したいと思います。長時間実行されるクエリ中に、HiveがORCテーブルGCを呼び出す頻度が約10分の1になります。多くのプロジェクトにとっては何の役にも立たないかもしれませんが、他のプロジェクトにとっては重要かもしれません。

また、テーブルから数列だけを選択する必要がある場合、ORCの所要時間ははるかに短くなります。他のいくつかのクエリ、特に結合を使用する場合も、Parquetでは使用できないベクトル化されたクエリの実行により、時間がかかりません。

また、ORC圧縮は少しランダムな場合がありますが、Parquet圧縮の方がはるかに一貫性があります。ORCテーブルに多数の数値列がある場合のように見えます-圧縮もされません。zlibとsnappy圧縮の両方に影響します