ふむ、並列プログラミングは少し扱ったことがあるけど、なかなかおもしろい。特にこの人の話は、自分なりに消化されてるから、わかりやすい。
- 近況
http://www.dodgson.org/omo/t/?date=20060127
内容としては、論文以上のことは言われなかったらしいけど、使っている人の感触って重要だよね。ちょっとずつ、コメント。
まず MR のマスタープロセスは途中経過や統計情報を HTML として(?)出力してくれる. そのスクリーションショットがスライドにあった. 進捗などがけっこうグラフィカルに表示される. こういうフィードバックの仕組みは開発生産性に影響しそうだ. (Tapestry の作者がいうところの "Feedback" 原則. )
この原則は重要。cgi開発でも、pythonのエラー補足をhtmlに出力してくれるcgitbモジュールが役に立った。リアルタイムに途中経過や統計情報をHTMLで確認できるっていうのはそういう意味で、汎用性が高く、とっつきやすい。（このテクニックは覚えておこう）
MR は CPU intensive な仕事より I/O intensive なプログラム向いている. つまり実際に Google の仕事は I/O intensive なのだろう. だから入力の分割の仕方が性能に大きく影響するという. 小さくすることで並列度をあげるだけでなく,GFS と相性の良い切り方というのがあるらしい. MR はチューニングのために細かくパラメタを指定することができる. これも I/O insentive な問題ならではという気がする. CPU insentive な問題はまずコードを見直すもんね. これは聞いたわけではないけれど, 高速化はパラメタの調整が主で, コアな問題以外はコードレベルのチューンをあまりしなそうな気がする. あまり効かなそう. 実際, MR は python binding もあるというから,規模でスケールすることや生産性の方が局所的な速度の改善よりも重要だという認識なのだろう. Map や Reduce はそれら単体で資産化されているようなので,python ではそれを組み合わせる感じで使うのかもしれない. 知らんけど.
なるほど、２万台超えるPC扱えたらそりゃI/O intensiveな仕事に向くか。Python bindingが実装されているっていうのは目の付け所がいいなー。PythonとC++とのバインディングはすげー楽だから、MapReduce->Pythonインターフェース->C++資産という流れはまっとうな気がする。
個々の MR プログラムは基本的に Map して Reduce したらおしまいになる. 複数の処理をストリーム風に処理したい場合は最初のプログラムの出力を次のプログラムに渡すことで行う. たとえばあるインデクサは 24 個の MR プログラムから構成されているという.UNIX のシェルやパイプを連想する. あるプログラム同士は直列に, 別のもの同士は並列に実行する, というケースもあるらしい. そうした連携を実現するための, UNIX の shell に相当する仕組みが必要にはならないのだろうか. と質問したら, まあ何かがあるというようなことだった. なんなのかは知らないけれど... 色々妄想したくなる一方で, ファイル名を引き渡すだけの素朴な仕組みで十分にも思える. コードを書く部分だけではなく, それをどんな感じで動かしているのかにも興味がわく.。
この部分の隠蔽の技法って、階層の違いはあるにせよある程度、Cellでも当てはまるだろうなー。
ジョブっていうのは、シェルレベルでパイプとファイル名で管理するのが一番直感的だし。それだけど管理は厳しいけど、Pythonのスレッドがそれの管理やってくれてC++で実装できたら、なんか普通に使える気がする。現場を知らないからなー。
こうやってWebに記録を残しておいてくれるのはいろいろ考えることができて、非常にありがたいです。