この前やってて出てきた疑問を、id:mamorukさんに聞いて解決。ありがとうございました。
Mapperの数を指定できなかった件
指定はできるようだ。ただ、オプションに一貫性がないような。。。"-D"の場所を変えると動かなかったり。Mapperの数は指定はできるけど、この数でforceされるわけではないことに注意が必要。
yasuhisa-y@cacao:/work/yasuhisa-y$ hadoop jar /usr/lib/hadoop/contrib/streaming/hadoop-*-streaming.jar -D mapred.map.tasks=100 -input /nldata/jawiki -output word_count_file -numReduceTasks 100 -file "maper.rb" -mapper "maper.rb" -file "reducer.rb" -reducer "reducer.rb"
\C-cしたら殺せ
\C-cしてもJobが詰まったままらしく
hadoop job -kill job-id
とやって明示的に殺さないといけない。
hadoop job -list
で調べられる。知らないで詰まらせててごめんなさい。。。
IterationごとにMap Reduceするようなアルゴリズムについて
例えばEMアルゴリズムとか。一回Reduceしたら、それが次のMapのときの入力となる。Javaで書く時にはなんの問題もないが、Hadoop Streamingを使うような場合だと困る。どういう風にやるのがいいかid:mamorukさんに聞いたところ、outputのディレクトリにsuffixを付けるのが普通なのではないか、ということだった。アルゴリズム中に何回もMap ReduceするようなものはStreamingでやるとかえって面倒なので、その付近は大人しくJavaを使いましょうということか。さらなる詳細はテキストを参照してください(後のChapter)。
Map => Reduceしてもう一回Map Reduce
Word Countのプログラム、(wikipediaクラスの量でも)Reducerが一個だと結構遅いので、Reducerの数を増やすことになると思う。しかし、Reducerの数を100個とかにするとそれをまたまとめないといけない。Rubyとかでやろうと思うと
- 任意の2個のファイルを持ってきて、(sort済みである性質を使って)先頭から見ていってファイルをmergeしていく
を100個に関してやっていけばよい(foldrっぽく)。
しかし、これだとMap Reduce使ってるのに意味ない!!ということでどうしようかと思っていたんだけど、もう一回Map Reduceやるのが常套手段らしい。これだとMap Reduceの御利益を受けられる。
