スパークパフォーマンス個別レコード参照

Question

私はSpark SQLとHive on Tez間の既存の内部Hiveテーブルのクエリを比較するパフォーマンステストを実施しています。テスト中、Sparkは、TezのHiveよりも速く、または高速のクエリ実行時間を示していました。これらの結果は、そこの多くの例と一致しています。ただし、個々のレコードレベルでキーベースの選択を伴うクエリでは例外が1つありました。この例では、SparkはTezのHiveよりも大幅に遅かった。

インターネットでこのトピックを調査したところ、満足のいく回答が見つからず、この例をSOコミュニティに提示して、これが環境やデータに関連する個別の一回限りのケースか、スパークに関連するパターン。

スパーク1.6.1 スパークカンファレンス：エグゼキュータ2、履行メモリ32G、執行コア4

データはZLIBで圧縮ORCファイルの種類として格納される内部ハイブ表です。圧縮ファイルの合計サイズは約2.2 GBです。

ここにクエリコードがあります。

#Python API  
#orc with zlib key based select 
dforczslt = sqlContext.sql("SELECT * FROM dev.perf_test_orc_zlib WHERE test_id= 12345678987654321") 
dforczslt.show() 

このクエリを完了するまでの合計時間は400秒以上でしたが、Hive on Tezでは約6秒でした。私はまた、SQLコンテキスト設定を介して述語プッシュダウンを使用しようとしましたが、これにより顕著なパフォーマンスの向上は生じませんでした。また、この同じテストがParquetを使用して実行されたとき、照会時間はHiveと同等であった。私は、RDDS v.Dataframesなどを使用するなど、クエリのパフォーマンスを向上させるためのソリューションが他にもあると確信していますが、SparkがORCファイルとどのようにやりとりしているかを理解しています。

私が上に挙げた話し合いのポイントの周りに追加の説明を与えることができるかどうか教えてください。

Answer 1

次の手順は、Spark SQLクエリのパフォーマンスを向上させるのに役立ちます。

一般に、HiveはHadoopクラスタ全体のメモリを占有します。これは、実行ファイルのメモリ（ここでは2 * 32 = 64 GB）よりも大幅に大きくなります。ノードのメモリサイズは？

また、ハイブクエリによって生成されたマップ/リダクションジョブの数と比較すると、実行者の数は少ないようです（2）。実行者の数を2の倍数に増やすと、パフォーマンスが向上する可能性があります。

SparkSQLとDataframeでは、手動で管理されるメモリ（タングステン）を使用した最適化実行が、デフォルトで有効になり、コード評価 の式評価が有効になりました。 spark.sql.tungsten.enabledがまだ有効になっていない場合にtrueに設定することで、この機能を有効にすることができます。

ORC形式の列の性質は、不要な列の読み取りを避けるのに役立ちます。ただし、問合せにWHERE句がある場合でも不要な行を読み取っていますが、filter.ORC述語プッシュダウンを使用すると、組み込み索引のパフォーマンスが向上します。ここでは、ORC述語プッシュダウンはデフォルトでSpark SQLで無効になっており、明示的に有効にする必要があります。

sqlContext.setConf("spark.sql.orc.filterPushdown", "true") 

もしあれば、より多くの研究を行い、潜在的なパフォーマンスブロッカーを見つけることをお勧めします。