Impala Cookbook （非公式）日本語版 (3)　クラスタのサイジングと推奨ハードウェア

昨日のImpala Cookbookの非公式日本語版の続きです。昨日は「Impalaのメモリ使用量」でした。本日は「クラスタのサイジングと推奨ハードウェア」です。
Impala 2.0からメモリが足りない場合にディスクにスピルすることができるようになっていますが、果たしてどのぐらいメモリを積めば良いのでしょう？
例によって駆け足で日本語化してるので、間違いがあればコメントに書き込むかTwitterでメンションしてください。
原文:
[1] The Impala Cookbook http://www.slideshare.net/cloudera/the-impala-cookbook-42530186

Part 2 – 実用上の問題

クラスタのサイジングと推奨ハードウェア

推奨ハードウェア

• 最適な価格／パフォーマンスには128GB以上
• HDD(スピンドル) vs SSD
  • HDDはより費用効果が高い
  • ほとんどのワークロードではCPUの制約を受ける。SSDは改善にはならない
• 10GBネットワーク

クラスタのサイジング – 目的とキー

• 目的:
  • 推奨クラスタサイズとは、クラスタの計画されている存続期間に渡り、定められたSLAで要求されるワークロードで実行しなければならない
• キー:
  • ワークロード – 機能要件を定義する
  • SLA – パフォーマンス要件を定義する
  • 計画されている存続期間 – 時間とともに状況はどう変わっていくか

クラスタのサイジング – SLA

• クエリのスループット
  • このクラスタでは１秒間にいくつのクエリを実行しなければならないのか
  • これはより意味のある「計算能力」の測定
• クエリの応答時間
  • どのぐらい早くクエリを実行する必要があるか？
  • 一般的には常に複数のクエリが並列に実行されているので、単一のクエリの応答時間はあまり意味を持たない
  • ウェブUIに影響を与えるようないくつかのユースケースでは、非常に短い応答時間が必要になる
• 時間とともにより多くの人がにクエリを実行していく？これは高いクエリのスループットだということを意味している

クラスタのサイジング – ワークロード

• ワークロードから以下を知りたいでしょう:
  • どのぐらいのメモリが必要なのか？
  • どのぐらいの計算能力が必要なのか？（すなわち、どのぐらいワークロードが複雑なのか）
  • どのぐらいのIOバンド幅が必要なのか？
• 大規模なクラスタ、より多くの合計メモリ、CPU、ディスクIOバンド幅

クラスタのサイジング – 推奨メモリ

• どのぐらいのメモリが必要なのか？
  • いくらかの大量なgroup byがある？
    • ノードごとのメモリ >= 異なるグループの数 * 行のサイズ + (異なるグループの数 * 行のサイズ) / ノード数
    • 異なるグループの数 (number of distinct group): 見当がつかない; 大雑把に見積もる
    • 行のサイズ (Row size): クエリに含まれる列の数 * 列の幅
    • 列の幅は、intは4byte、bigintは8byte、など。Stringの列ではいくらか大雑把に扱う
    • クラスタのサイズを増やすことは、ノードごとのメモリ要求を大幅に減らすのには役立たない

クラスタのサイジング – ワークロードの複雑さ（続き）

※原文では(Cont’d)となっているが、資料が１枚漏れている？

• （高度）ワークロードの分析に深く踏み込む準備ができている場合…
  • 一般的に、以下の虜リレーとを想定することができる:
    • scan node 秒間〜40m行
    • join node 秒間コアあたり 〜10m行
    • agg node 秒間コアあたり 〜5m行
• サンプルクエリから、ジョイン/集約の数がわかる。入力行の数を知りパーティンションプルーニングの効果を見積もる
• 上記の処理レートを使用して、強化した結びつきを導きだせる

クラスタのサイジング- まとめ

• クラスタのサイジングはSLAとワークロードに依存する。両方を知っている必要がある！
• 大きなジョイン／集約のメモリ要件
  • クラスタでのメモリの合計 >= 展開、フィルタリング、射影後のジョインにある２番目に大きなテーブル
  • ノードあたりのメモリ >= 異なるグループの数 * 行サイズ + (異なるグループの数 * 行サイズ）/ノード数