CDH 5.7のApache Impala (インキュベーション中): Apache Hadoop上でのBIワークロードのパフォーマンスが4倍に

投稿: Devadutta Ghat、Marcel Kornacker、Mostafa Mokhtar、Henry Robinson:2016年6月1日
カテゴリー:CDH Impalaパフォーマンス

CDH 5.7でリリースされたImpala 2.5において、パフォーマンスの大幅な向上と要求が高かった機能へ対応を実現

Impalaは、公開当初よりハイパフォーマンスな分析クエリエンジンとして実績を積み上げてきました。既に2013年の最初のリリース時点で、従来のDBMSの2倍のパフォーマンスを発揮していましたが、リリースを重ねる度に、Impalaの分析データベースアーキテクチャーと、その他のSQL-on-Apache Hadoopとの間でのパフォーマンスの差は開く一方でした。以下に示すように、Impala 2.5での著しいパフォーマンス向上によって、(また今後のロードマップを見ても)その差は更に広がろうとしています。

Impala 2.3とImpala 2.5の比較結果概要は以下のとおりです:

  • TPC-DSクエリのパフォーマンスが、平均3倍向上
  • TPC-Hクエリのパフォーマンスは、フラットなテーブルで2倍、ネストされたテーブルで1.71倍に向上

Impala2.5とImpala2.3処理速度比概要
(数値は高いほど良い)

スクリーンショット 2016-05-10 04.57.20

図1: Impala 2.5とImpala 2.3のTPC-DSおよびTPC-Hでのパフォーマンス比較
(ワークロードの詳細は付録参照)

次に、新リリースにおけるパフォーマンスの向上と、その他の重要な機能について詳しく見てみましょう。
(新機能一覧は、こちらのリリースノートを参照)

ランタイムフィルターと動的パーティション・プルーニング

SQLクエリを最適化する重要な手段の1つに、実行プランツリーのリーフノード(子のないノード)にある行数を減らすという対応があります。Impala 2.5のランタイムフィルターは、クエリ実行中にフィルター処理を行ない、フィルターリングされた結果を「上流」から「下流」のオペレータに引き渡します。これでスキャナに限らず、上流のオペレータの処理負荷についても低減することができます。パーティションの列にこれを適用すると、ランタイムフィルターによって、Impalaがパーティショニングされたテーブルにあるタプルのスキャンを開始する前に、自動的にパーティションがプルーン(除外)され、クエリ実行によるI/O負荷を大幅に減らすことができます(このランタイム時のフィルターリングを特に「動的パーティション・プルーニング」と呼びます)。

TPC-Hの結果
(数値は低いほど良い)

スクリーンショット 2016-05-10 04.57.29

図2: ランタイムフィルターを使用することで、Impala 2.5は、2.3に比べTPC-Hベンチマーククエリ(1TBデータセット使用)で2.2倍、TPC-H Q17で23倍のパフォーマンスを実現します。

ランタイムフィルターと動的パーティション・プルーリングの詳細については、こちらの資料をご覧ください。

クエリの高速起動

これまでのリリースでは、クエリが処理を始めると同時にセンダー(sender)が起動されたらレシーバー(receiver)はいつでもデータを受け取れるようImpalaは実行プランツリーを1“レベル”の枝分け (fragment) をしていました。この方式では、特に多くの枝を持つ(あるいは大規模なクラスタにおける)複雑なクエリの場合、その起動までに長い時間を要します。Impala 2.5では、順次で枝分けを行うのではなく、クエリ起動ロジックによってどんな順序でも枝分けが可能となり、並列度を上げてクエリ起動のレイテンシを低く抑えることができます。

図3は、クエリ起動時間に対するパフォーマンス向上を示したもので、クエリ実行全体として速度向上が見られます。

クエリ起動時間(低いほど良い)と枝分かれ数(大きいほど複雑)

スクリーンショット 2016-05-10 04.57.43

図3: Impala 2.3と比較して、Impala 2.5のクエリ起動時間は各段に早くなっています。

カーディナリティ推定とJoin Orderの改善

Impala 2.5では、指数バックオフ (exponential back-off) によって、相関関係による断定 (correlated predicates) を緩和することで、より確実なカーディナリティ推定を実現します。さらに、JOINのカーディナリティ推定も改善されています。このようにjoin order selection(ブロードキャスト対シャッフル)の改善もあり、TPC-H Q8のような複雑な分析クエリでも、8倍のパフォーマンス向上を達成しています。

LLVMコード生成の対象拡大

Impala 2.5では、LLVMのコード生成対象を、SORTとTop-Nにも広げ、DECIMALに対する演算も可能になりました。SORTやTop-Nは、多くのサードパーティBIツールで、Impalaと連携するために一般的に使用されている機能で、これらのコード生成機能の拡張は、すぐにエンドユーザにメリットをもたらすものです。

Top-Nクエリ時間(小さいほど良い)

スクリーンショット 2016-05-10 04.57.53

図4:Top-N のコード生成に対するこのベンチマーククエリでは、Impala 2.5は1.72倍の効率を発揮しました。

LLVMのコード生成に関する詳細はこちらから

カタログの改善: メタデータの差分更新

Impala 2.5では、いくつかのカタログに関する改善が行われ、DDL/DML処理で全テーブルのメタデータを再ロードする形ではなく、テーブルのメタデータの差分だけを更新するようになりました。Impala 2.5では、変更のないファイルに対するファイル/ブロックメタデータの再ロードを避けるため「使用済み(dirty)」なパーティションのメタデータだけを再ロードし、HDFSのディスクリプタを再使用することで、DDL/DML処理のレイテンシを大幅に低下させることができるようになりました(最大4倍)。

INSERT…SELECTのパフォーマンス ALTER TABLE…SET LOCATIONのパフォーマンス

スクリーンショット 2016-05-10 04.58.01

図5: Impala 2.5のカタログ更新ストレステストでは、Impala 2.3に比べ平均4倍のパフォーマンスが得られました。

アドミッションコントロールの機能改善

Impalaは、バージョン1.4からアドミッションコントロール機能を提供しており、オーバーロードを避け、同時処理クエリの数に応じて最大のスループットが得られるよう、ワークロードの量をユーザが制御できる形態になっています。Impala 2.5からは、メモリベースのアドミッションコントロールが可能となり、Cloudera Managerから直接設定やモニタができるようになりました。アドミッションコントロールの管理に関する詳細は、こちらの資料をご参照ください。

拡張性と信頼性の向上

Clouderaのエンジニアリングの経年の最重点項目の1つに、拡張性と信頼性の向上があります。Impala 2.5では、この目標に向けた大きな前進が図られています。Impala 2.5 は、Impala専用に新しく社内で作成したクエリジェネレータを用いて、厳しいストレステスト、拡張テスト、フォールト・インジェクション(故意にエラーを発生させて問題を発見するテスト)、パフォーマンステストを行なった上でリリースされています。

分散アグリゲーション

Impalaのアグリゲーションは、プリアグリゲーションとマージという2つのフェーズに分けて処理されます。グルーピングする値に多くの入力行が存在する場合、プリアグリゲーションすることでネットワークトラフィックを大幅に低減できますが、逆に非効率を招く場合や、メモリの制約からディスクに追い出される可能性もあります。Impala 2.5のアグリゲーション機能は、はじめにアグリゲーションフェーズを実行し、小さなサイズの中間データを渡した方が効率的なのか、それとも、次のフェーズに中間データをそのまま渡し、そこでアグリゲーションする方が効率的なのかを実行時に決定するよう改善されました。これにより、Impala 2.5では、アグリゲーションの処理パフォーマンスは25% 向上し、メモリ消費も50% 以上削減されました。さらに、ストリーミング プリアグリゲーションもディスクに追い出されないようになっています。

分散アグリゲーション(低いほど良い) アグリゲーションのメモリ消費量(低いほど良い)

スクリーンショット 2016-05-10 04.58.09

図6:Impala 2.5では、一部のアグリゲーションでは最大25% の速度向上が見られます。

DECIMAL演算処理の向上

Impala 1.4から、DECIMALデータタイプに固定小数点の値が使えるようになり、一般的に数値を正確に表現し、丸め誤差を避けることが重要となる金額の表現などに使用されています。Impala 2.5では、ネイティブなコード生成を自動的に行うことで、DECIMALフィールドを含むアグリゲーションのパフォーマンスを向上させています。

図7に示す通り、DECIMALを含むアグリゲーションに対するImpala 2.5のベンチマーククエリの結果は、Impala 2.3の3倍以上のパフォーマンスを示しています。Impala2.5によって、DECIMALとFLOAT/DOUBLEの間にあったパフォーマンスの差を縮め、より高速に精度の高い処理を実行することができます。

DECIMAL計算処理(低いほど良い)

スクリーンショット 2016-05-10 04.58.18

図7: Impala 2.5は2.3に比べ、DECIMALに関連するアグリゲーションのパフォーマンスが3倍以上向上しています。

この機能の詳細はこちらの資料をご参照ください。

メタデータ限定クエリ

Impala 2.5では、min()、max()、ndv() の処理速度向上に加え、distinctキーワードを持つアグリゲーション機能については、パーティションキーのスキャンでテーブルにアクセスしないようにメタデータを使用して、パーティション化されたテーブルのパーティションキーの列だけにアクセスすることで、パフォーマンスの向上を図っています。こうした機能は、サードパーティのBIツールで一般的に使用されており、多くのエンドユーザにパフォーマンス向上のメリットをもたらすでしょう。

メタデータ限定クエリ(低いほど良い)

スクリーンショット 2016-05-10 04.58.25

図8: Impala2.5では、メタデータ限定クエリによって大幅なパフォーマンス向上が図られています。

まとめ

BIや分析を手掛けるユーザにとって、インタラクティブクエリのレイテンシが非常に重要な要素であることから、Impalaのチームでも常にパフォーマンスを最重点事項としています。1年足らず前に2015年~2016年のロードマップを作成しましたが、ここで説明したようなパフォーマンスの改善は、計画達成に向けた大きな前進と言えます。これは、コミュニティのロードマップに刻まれたパフォーマンス最適化(マルチコアJOINやアグリゲーション)のための、今第一歩に過ぎませんが、Impalaのパフォーマンスを20倍以上にするというゴールも視野に入ってきました。

Impalaのこのビジョンの成功をもたらすよう、皆様のご協力(コントリビューション)を歓迎いたします!

Devadutta Ghatは、Clouderaのシニアプロダクトマネージャーです。
Marcel Kornackerは、ClouderaのテックリードでImpalaの創設者です。
Mostafa Mokhtarは、Clouderaのソフトウェアエンジニアです。
Henry Robinsonは、Clouderaのソフトウェアエンジニアです。

付録

TPC-DSおよびTPC-Hベンチマーク詳細:

  • 15TBのデータセットを対象にした24の未変更TPC-DSクエリ {3, 7, 8, 19, 25, 27, 34, 42, 43, 46, 47, 52, 53, 55, 59, 61, 63, 68, 73, 79, 88, 89, 96, 98}
  • 15TBのデータセットを対象にした、22のTPC-Hクエリ
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.