CDH3u5でWebHDFS
いろいろあって待ち望んでいたHadoop CDH3u5がリリースされましたね！
注目するところは人それぞれだろうけど、個人的にはWebHDFSのサポートが入ったのが大変嬉しい。前にCDH4で試したりはしていたけどCDH4に移行するのもいろいろアレそうだし、と思っていたのでWebHDFSサポートの入るCDH3u5をマジで待ってた。のでさっそくちょっと確認して、すぐ置き換えてみた。
なおCDH3u5にはHttpFsは入ってないようだ。これはちょっと残念。
- 移行前: CDH3u2 + Hoop
- 移行後: CDH3u5 + WebHDFS
設定変更点
WebHDFSを有効にするため、およびHoop/WebHDFSでappendを有効にするために hdfs-site.xml に以下の設定を加えた。
<property> <name>dfs.webhdfs.enabled</name> <value>true</value> </property> <property> <name>dfs.support.append</name> <value>true</value> </property> <property> <name>dfs.support.broken.append</name> <value>true</value> </property>
dfs.support.append および dfs.support.broken.append はCDH3u4以降で必要になっているはず。WebHDFSはCDH3u5から。WebHDFSでappendするにも dfs.support.broken.append は必要になる。
これをくっつけて stop-dfs および start-dfs すればよい。WebHDFSの場合は書き込み操作は直接 DataNode に対してアクセスが飛ぶので、DataNode単独できちんと上記の設定が有効になるよう読み込まれている必要があることに注意。DFSClientやNameNodeを経由しないからこの注意が必要になる。
クライアント
WebHDFSクライアントはたぶんまだ世の中にあんまり無い、けどPerlとRubyにはクライアントライブラリがあるぞ！
あとはFluentdからなら fluent-plugin-webhdfs が使える。
性能について
まだ限界まで負荷がかかるようなことをしてみてないんだけど、通常時の書き込みを見てる限り以下のような状況。
- Hoop Server を立てていたNameNodeの通信量が激減
- DataNode側の通信量・CPU使用率のiowaitなどはほぼ変化なし
- ただしわずかに SoftIRQ の値の上昇が見られるようになった(2〜4%程度)
- クライアント側から確認できていた書き込み先への通信エラーがなくなった
Hoop Serverのように1ヶ所を必ず経由する通信パターンに較べてWebHDFSだと通信負荷がバラけるのは当然のことだけど、やっぱりその影響は大きいかな。
もうひとつ実際には重要なこととして、Tomcatで動くHoop ServerとJettyで動くWebHDFSハンドラ、という違いはあると思う。*3
WebHDFSはHadoop DataNodeが前から動かしているWebコンソールと同じところで処理される。これはJettyで動作しているもので、実際にWebHDFSを叩いてみるとHTTPヘッダにもJetty云々な行がある。
データを継続的に書き込むような通信パターンだとデータ(ペイロード)の受信時間が長く、Tomcatのように同期的に処理するアーキテクチャのサーバだと並列度が高くなるならそのぶんだけスレッド数を増やすしかない。スレッド数を増やせばそのぶんだけコンテキストスイッチのコストがかさむ。スレッド数が足りなければクライアントは接続に失敗する。
その点Jettyは非同期I/Oをサポートしたアプリケーションサーバなので、Network I/OならびにDisk I/O待ちの間は他の接続の相手にCPUを使える*4。それなりに多くの通信の並列処理も得意なはずだから、特に大きいサイズのデータについての通信処理ではTomcatに較べて状況が改善するのは納得できる。
数日これで様子見て、特別問題がなければそのままWebHDFSを使い続ける予定。さてどうかな。
