MapReduce 勉強中

http://labs.google.com/papers/mapreduce.html

Wikipedia はスルー。ちょっと疲れたのでスライドで。

概要：

• map(in_key, in_value) -> list(out_key, intermediate_value)
• 中間ファイルは (worker, out_key) 毎に別ファイルぽい。(out_key)毎の中間ファイルにしてatomic append なんてことをすると fault tolerance が崩れるかな？
  
• reduce(out_key, list(intermediate_value)) ->list(out_value)
  
•  out_key のファイルを読んで、実行するだけ。

• Fault tolerance
• worker failure ... detect via heartbeat. re-execute
• まあ、map も reduce もやり直せばよし。
  
• master failure ... あまりない
• Slow workers のせいで遅くなったりする。
• Weird things: processor caches disabled (!!) だって ;-)
• バックアップタスクを起動する。(Near end of phase)
• GFS chunks の replica のあるマシン(または同じラック)上で処理するようにスケジュール
• 64MB にあうように map する。データ構造をあわせておく必要ありかな。
• BigTable ならその辺は考慮済みか。
• Bad recoreds
• SEGV signal handler から　UDP で master に通知
• 3rd party libでもOK
• 1800 Machines
• 4GB mem, Dual 2GHz Xeons with Hyper-threading @ 2004
• Dual 160GB IDE
• GbE, Bisection bandwidth approx. 100Gbps
• Result
• start overhead
• 1800 machines read 1TB data at 31TB @ peak.
• Experience
• 故障とか遅いマシンの面倒を見てくれる！
• simple な code. MapReduce の組み合わせ。
• Fun to use!!
  

メモ：

• shuffle ... read する順をかえてるってだけかな。
  

感想：

• BigTable の論文を読むと、BigTable 用みたいなイメージがあったが、BigTableなしでもOK。chunk へのデータのアラインとか考えると、直接GFSをさわるのは面倒そうではある。
• GFS とセットでの運用で真価を発揮。まあこの辺は勉強するまでもないか。
• 結局肝は、故障とかトラブルを隠蔽できるところにあるのかな。
• Fun to use!!
• まあ、サーバーセンターが一つのマシンに見たてたくなる気分が少しわかる、、、かな。