Impalaのパフォーマンスについての記事

Impalaのパフォーマンス

https://haifengl.wordpress.com/2014/09/03/big-data-analytics-bigquery-impala-and-drill/
でGoogle Dremel、Google BigQuery、Cloudera Impala、Apache Drill(とHive、Tez)の話が出ています。とは言っても、タイトルにあるにも関わらず、残念ながらDrillの話はほとんど書かれていません。先日のHadoop Conference Japan 2014でも多くのHadoop on SQLのプレゼンが紹介されていましたが、これだけ選択肢が増えてきている現状では、後発でのメリットを強く打ち出せないと、選択するのが難しくなってきますね。
さてImpalaですが、ImpalaはなぜHiveよりもパフォーマンスが高いのかについての特徴が掲載されていたので、抜粋して訳してみました。(誤訳があればご指摘下さい)

  • ネイティブなクエリエンジンとして、ImpalaはMapReduce/Tezジョブのオーバーヘッドを回避している。MapReduceのプログラムはフルキャパシティで全てのノードが実行する前に、いくらか時間がかかるということが知られている。Hiveでは、全てのクエリはこの「Cold Start」の問題に苦しめられている。対照的にImpalaデーモンはブート時に開始され、故にクエリの実行の準備が常にできている
  • Hadoopは開始時のオーバーヘッドのペナルティを減らすため、JVMのインスタンスを再利用する。しかしながら、これは別の問題も生んでしまう。ビッグデータの処理では多くのメモリが好ましい。例えば、Impalaの推奨物理メモリは128GB以上である。前述のベンチマークでのノードは384GBのメモリを積んでいる。このような大きなヒープは、再利用されるJVMのインスタンスのガベージコレクションの大きな課題となる。全てを止める(stop-of-the-world)GCの一時停止はクエリに高い遅延が加わる可能性がある。C++のネイティブコードで書かれたImpalaの実行エンジンはこの問題を回避する。Impalaは、キャッシュ管理で良好なジョブの実行も行うかもしれない。
  • Impalaのプロセスはマルチスレッド化されている。重要なことに、プランのフラグメントをスキャンする部分もSSE4.2の命令を使用してマルチスレッド化されている。I/Oとんえっとワークシステムも高度にマルチスレッド化されている。従って、全ての単一のImpalaノードは高いレベルでのローカルの並列性により、より効率よく実行する
  • Impalaのクエリの実行はできる限りパイプライン化されている。集約の場合、コーディネーターは、結果を返すために、事前集約フラグメントが開始するとすぐに最終の集約を開始する。対照的に、MapReduceでは全てのMapperが完了するれば、ソートとReduceが開始できる。Tezは、まだ現在パイプライン化された実行をサポートしていない
  • MapReduceは全ての中間データをマテリアライズ(具現化)する一方、Impalaはエグゼキューター間で中間結果をストリームする。Tezはファイル、TCPなどを含んだ異なる入出力型が可能。しかし、Hiveは不必要なディスク書き込みを回避するため、まだこの機能を使用していない
  • 。。。(疲れたので略:原文をご覧下さい)

以上、ご参考になれば幸いです。

オライリーのImpala本

ところで、O’Reillyでプレリリースされている「Getting Started with Impala」、本日購入しました。無償で公開されている日本語版の「Cloudera Impala」と比べると、やはり細かい内容まで書かれています。最新のImpala 1.4でサポートされたDECIMAL型の話も出ているので、Impalaを使う方は(正式版が公開されたら)購入されても良いと思います。

コメント