まだ続いてみるYARN+Capacity Scheduler。
プロパティの説明だけではわかりづらいので、
簡単な説明をつけた管理画面のキャプチャを貼ります。
ジョブが無い状態
NodeManagerのリスト
defaultキューでジョブが開始直後
defaultキューのみでフル稼働
bigdataキューで新しいジョブが開始直後
2つのジョブが可能な限り稼働する様子
前回、基本上限値を超える柔軟性は 1container分と書きましたが、これを見る限りは 2container分 超えて稼働していたようです。
基本上限値を変動させてキャパシティオーバーを発生させてみましたが、どうやら基本上限値が低いほど柔軟度が上がり、基本上限値が高いほど柔軟度が低くなるようです。とはいえ、今のところ基本上限値の 125% までしか確認できていないので、柔軟度があまり高くならない設計であることは間違いなさそうです。
基本上限値を変動させてキャパシティオーバーを発生させてみましたが、どうやら基本上限値が低いほど柔軟度が上がり、基本上限値が高いほど柔軟度が低くなるようです。とはいえ、今のところ基本上限値の 125% までしか確認できていないので、柔軟度があまり高くならない設計であることは間違いなさそうです。
Mapが終わってReduceだけになった様子
とまぁこんな感じですが、前回書いた通り capacity-scheduler.xml の反映は動的にできるので、設定を変えたりジョブの実行中にでもバンバン変更して色々試すのがよいかと存じます。
個人的にはこの管理画面は少々気に入ったのですが、ここの見た目にチカラを入れている時間があるならまず先にNameNodeの管理画面のCSSをだな・・・と思ったり。
動作としては問題ないので、あとはゴリゴリ使って調整するのと、
できれば同じデータとHiveクエリを使ってMRv1との処理速度を比較してみたいものですが、そもそもリソース調整方法が違うのでやってもあまり意味無い予感。