ツイートやブログコメントの解析プラットフォーム企業である「BackType」の技術ブログ記事です。BackTypeでは30TBものソーシャルデータをHadoopで処理しています。また、Hadoopを利用したプロダクトをいくつか開発しオープンソースにして公開しており、Hadoopをヘビーに活用している企業の一つと言えるでしょう。しかし、深く利用しているがゆえに不満点も多いようで、Hadoopに関する問題点のいくつかを挙げています。
まず、非常に重要な設定について、何もドキュメント化されていないことを指摘しています。具体的には、HFDSのDataNodeへの上限接続数を表す設定項目「dfs.datanode.max.xcievers」について、デフォルト値が256と非常に低く設定されているため、すぐにエラーが発生しています。しかし、公式ドキュメントには、いったい何の設定を表すのかや、どのような値に設定すべきかについての記述がありません。しかも「xcievers」という単語自体が「receivers」のミススペルであり、そのまま利用されているのが現状です。
2つ目に挙げる問題は不適切なメモリ使用量についてです。十分にメモリを割り当てているにもかかわらずreduceタスクにてメモリ割り当てエラー「Cannot allocate memory」が発生することがあります。これはHadoopがシェルを実行する際にプロセスをフォークするのですが、子プロセスが親プロセスと同じサイズのメモリを確保しようとするためで、もしHadoopが1GBを使用しているとシェル実行時には一時的に2GBになってしまいます。この問題については、各マシンのスワップ領域を十分に割り当てることで対策できます。
最後に挙げる問題はプロセス管理についてで、時折プロセスのkillに失敗して「ゾンビタスク」として残り、無駄にメモリを消費して本来のタスクの邪魔をしてしまうことがあります。これはHadoopのプロセスがTask
Trackerよりタスクそのものを重要視しており、ゾンビプロセスが発生しても除去できないためです。この問題についてはHadoopの設計のまずさを批判しており、Hadoopはユーザのコードを信頼せずTaskTrackerが管理できるようにし、何かしらの問題が起きてもクラスタに影響を与えないようにすべき、との見解を示しています。ゾンビタスクの発生はメモリエラー時によく起きるようで、スワップ領域を増やすことで軽減できます。
それぞれの問題について補足しておきますと、xcieversの値については、もともとHadoopの各デフォルト値は初期導入者向けに設定されており、少規模のクラスタを想定して低めにしていたようです。執筆時点（2011年5月）ではまだリリースされていませんが、バージョン0.22以降より「dfs.datanode.max.receiver.threads」という名前に変更され、デフォルト値は4096に増えています。あとの2つの問題についても、まだ具体的な解決策は見えていないものの問題自体は認識されています。特に3つ目についてはMapReduceの再設計という大きなタスクとして取り組んでいるので長い道のりになりそうです。
URL：http://tech.backtype.com/the-dark-side-of-hadoop
