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