先日のImpala Cookbookの非公式日本語版の続きです。先日は「クラスタのサイジングと推奨ハードウェアImpalaのメモリ使用量」でした。本日は「Impalaのベンチマーク」です。
ベンチマークも取り方によっては全く意味がありません。また、本番環境で動作させるのと全く違うワークロードのベンチマークも、本来期待しているのとはかけ離れた結果がでるかもしれませんね。
例によって駆け足で日本語化してるので、間違いがあればコメントに書き込むかTwitterでメンションしてください。
原文:
[1] The Impala Cookbook http://www.slideshare.net/cloudera/the-impala-cookbook-42530186
ベンチマーク
- どのようにImpalaが機能し、どうスケールし、現在のシステムとどう比較するのかを理解する
- クエリのスループットと同様にクエリのレスポンス時間を計測する
Impalaをベンチマークする – ワークロードの準備
- ビジネスの要件と関連がある（あるいは満たす）べきである
- select * from big_tbl limit 10 は実行しない – これは無意味
- クエリの形式は指示されるべきではない
- 意味を持ったベンチマークを遂行するために、クエリやスキーマの変更の準備をすべきである
- スキーマ/クエリを調整する！
- プロダクション環境で実行する予定のクエリに近づけておく
- 結果をディスクに書き込まなければならない場合、ディスクに書き込み、結果はクライアントに渡してはいけない
- 全てのデータをクライアントにストリームしない（つまり、データの抽出）
- 速いクライアントを使用する：ベンチマークをしているのはサーバーでありクライアントではない。従って遅いクライアントをボトルネックにしてはならない
ベンチマーク – 罠を避ける
- 小さなデータセットと単純なクエリから開始するのは簡単。小さなクラスタで巨大なデータセットに複雑なクエリを実行しようと試みるのは効果がない
- 小さすぎるデータセットではクラスタ全体を使用しない。少なくともディスクあたりひとつのブロックを持たせる
- ベンチマークを行っている際はアドミッションコントロールは無効化する！
ベンチマーク – ハードウェアを準備する
- 可能な限り本番のハードウェアと似たものにすべきである
- 推奨: 少なくとも10ノードで、それぞれが128GBのメモリを搭載
- 注意：クラスタが小さすぎる（例えば3ノード）の場合、スケーラビリティの効果の確認とm潜在的なボトルネックの識別は非常に困難
ベンチマーク – 単一クエリの応答時間を計測する
- （簡単で使用が簡単な）Impalaシェルを -B オプションで使用する。これは見やすい形式の出力を無効化するので、クライアントがボトルネックにならない
- impala-shell -B -q “<your query>”
- バッファキャッシュの効果をシミュレートするために、結果を計測する前にバッファキャッシュをウォームアップするため、何回かクエリを実行する
- バッファキャッシュなしの効果をシミュレートするために、echo 1 > /proc/sys/vm/drop_caches を実行し、バッファキャッシュをクリアする
ベンチマーク – クエリのスループットを計測する
- JDBCを使用してベンチマークを実行する
- 入力パラメータ: 接続するホストのリスト、ワークロードのクエリ、ベンチマークの期間、並列接続数
- 各接続で接続するホストを選択し、指定した期間でクエリを実行し続ける
- QPSをレポートする
- QPSが増えなくなるまで接続数を増やし続ける – それがシステムのQPSになる
ベンチマーク – 一般的なパフォーマンスの注記
- Hiveとのパフォーマンス – Impalaは常に速いだろう。そうでなければベンチマークの何かが間違っている
- Impala vs Hive-on-Tez/Spark SQLのベンチマーク:
- あなた自身で実行するための TPC-DS ツールキット
コメント