Impala Cookbook （非公式）日本語版 (4)　Impalaのベンチマーク

先日の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になる

ベンチマーク – 一般的なパフォーマンスの注記

コメント