Gfarm - Cafe Babe

産総研の首藤さんに，グリッド関係ではMapReduce+GFSのような計算とデータの協調的な分散に関する研究をやっていないのか？と聞いたところ，Gfarmというグリッド用の分散ファイルシステムを紹介してくれた．

http://datafarm.apgrid.org/index.ja.html

これも大規模ファイルに対するものだが，GFSとの大きな違いは，GFSがチャンクと呼ばれる固定ブロック単位で分散格納するのに対して，Gfarmはファイル単位で格納すること．つまり，Gfarmが前提とするのは，GFSのような細粒度分散並列処理ではなく，単一プログラムが複数ファイルを処理するような粗粒度分散処理のようだ．このために複数のスレッドないしはプロセスが単一ファイルに書き込む場合には，ファイルを排他的にロックすることになる．

追記：首藤さんによると，これはv2の新しい設計で，まだ配布されていないとのことである．

これは，広域分散を対象としたグリッドコンピューティングと，データセンタ内に閉じた計算機クラスタの分散並列計算の対象の性質の違いによるのだろう．広域細粒度分散は非常に効率が悪いし，POSIXに準拠することにしたのも，プログラミングを容易にすると思われる．

追記：GFSとGfarmは，同様にデータインテンシブ・コンピューティングを目指しているのだが，アプローチが違ってきたのは，対象とするデータの性質と処理の性質が違うからと思われる．

たとえば，GFSが対象とするテキスト処理で言えば，次のような特徴がある．

大容量のデータに，細粒度の独立性が存在していること．たとえば，Webから収集してきた多量のHTMLファイルやログファイルは，各部で独立に処理できる．データの部分間の依存性が強い（←たぶん，Gfarmが目指すような大量データ処理はこちら）場合は，そうはいかない．
データの部分に関する処理が比較的遅い，または高速化できないこと．たとえば，Webロボットのサーバに対する収集速度は負荷が集中しないようにするためには上げるわけにはいかない．そこで，大量のスレッドを複数台のマシンに分散させて収集して，全体としてスループットを上げるようなことがおこなわれる．また，各ファイルのテキストの解析に形態素解析などを用いてしまうと，どうしても遅くなる．そこで，細粒度並列化でスループットを向上させることになる．

注意すべきは，これは目的指向で設計されていることを示すだけで，（目的が達成されているならば）どちらが良い，悪いというものではない．結局，「何でもできる＝全部中途半端」なのだから．