DryadとDAGのメモ

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

業務DAGからの設計手法がいいな、と思うのは、下がHadoopでもDryadでも行けるってことだと思う。その上ユーザーさんにわかりやすい。ただし、簡単ではなく、非常に「考えることが必要」で、やってて面白い。とにかく設計として、もの凄く萌える。#hadoop #dryad

【ヽ´ん`】 @dev_momen

Why does Dryad use a DAG? http://blogs.msdn.com/b/dryad/archive/2010/07/23/why-does-dryad-use-a-dag.aspx

【ヽ´ん`】 @dev_momen

ここまで具体的なサンプルが出たのは初めて？(・∀・) A DryadLINQ Tool Kit for Information Retrieval http://bit.ly/cHGBn2

Suguru ARAKAWA @ashigeru

@okachimachiorz1 そのParallelってOozie使えばいいじゃんとかいう流れで片付けられそうな内容ですねぇ

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

来てますねこれ。PageRankですか・・・・ふむふむふむ・・・RT @nsharp_2ch: ここまで具体的なサンプルが出たのは初めて？(・∀・)A DryadLINQ Tool Kit for Information Retrievalhttp://bit.ly/cHGBn2

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@ashigeru PigもHiveも内部でDAG使ってるぜ、みたいなコンテクストだったので。Oozeの注目度は高いですけど、これじゃ無理説も出てくるとおもいますぜ。先生ｗ。

Suguru ARAKAWA @ashigeru

@okachimachiorz1 無理説は本運用レベルだとすでに出てるんじゃないすかねw でもこれ、経験的にはこの層での一般化をやり過ぎると帯に短い作りになりますぜ

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

多層化前提だと思いますね～。ただ原理主義者は一層の力技主張が歴史の教えるところ。 @ashigeru 無理説は本運用レベルだとすでに出てるんじゃないすかねw でもこれ、経験的にはこの層での一般化をやり過ぎると帯に短い作りになりますぜ

【ヽ´ん`】 @dev_momen

DryadLINQのサンプルでTidyFSが使われてますね･･･。(´･ω･`) http://research.microsoft.com/en-us/projects/tidyfs/

Suguru ARAKAWA @ashigeru

@okachimachiorz1 時期的に、生MRとの相互運用が必須項目とされてる時期じゃないかなと思います。Oozieも主体は生MRっぽいですし。どこでスイッチが切り替わるかは楽しみですw

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

これが来るのか・・・http://bit.ly/8XQZzY やはりG様、Hadoop、Dryadの三つどもえですかね。

【ヽ´ん`】 @dev_momen

スライドが公開されてる。 Big Data for Science Workshop http://salsahpc.indiana.edu/tutorial/index.html

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@ashigeru 生MRが死ぬのは多分、Dryadの登場が引き金でしょう。これは絶対に流れを加速させる。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

昨日もちょっと話ながら思ったけど、分散ストレージの第二フェーズが来るような気がしている。んで、直近のポイントはMRをどう回すか？ってところかな～、別にMRでなくてもいいけど、データに対して、処理を透過的に飛ばす仕組みが必要で、その仕組みと分散ストレージの相性の問題。

Suguru ARAKAWA @ashigeru

@okachimachiorz1 Hadoopに限った話かもですが、LTEがもう少し見えないと汎用であれ系はきついんじゃないかとも。たぶんFSの議論にもつながるのだと思いますが。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@ashigeru 多分、SQLもどきってイラネっていう割り切りが必要でｗ。俺的には全然おｋですがｗ。きっとそのうち、うじゃうじゃそういう人はたくさん出てくるわけで。当然FSの話もそこの流れで・・多分Oracleがつぶれる。RDBMS「しか」つかえない人が、揶揄されるというお話。

Suguru ARAKAWA @ashigeru

@okachimachiorz1 SQLは上物なので、中間表現のASGの層をPig/Hiveで整備しましょう、って流れなんですかね。目の前にDryadがあれば正しい選択ですが、多層化の話とか混ぜると帯に短し、になりうると言う感じですね

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@ashigeru 正解じゃないですかね。ASGのtierでPig/Hiveの整理。多層化は、えっと、論理的にも実装的にも分離する感じかな～。最上位層とASGは互いに独立しているイメージで、・・多層化という言い方は語弊があるね。

E. Nakai @enakai00

.@okachimachiorz1 @ashigeru 統計解析用途は、最初は、生MRをある粒度で特化させて限定して、パーツとして組み合わせるモデルになる気がしてます。業務系は個別の要素が多くて限定が難しいので、Pigあたりの層で汎化するフレームワークが現実的？？

Suguru ARAKAWA @ashigeru

@okachimachiorz1 正確には、静的プラナーと動的プラナーを併用する感じで。切り分けが難しいですが。

Suguru ARAKAWA @ashigeru

@enakai00 統計解析でも、Pig使っちゃいませんかね？スピードだけが問題なら、時間の問題とか考えてます

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@enakai00 むしろ逆で、統計の方が汎用的かな～、と思います。業務屋的にはロジック層は同じ物をリピート的にたくさん作っている感覚ですね。もちろんそれぞれの業種・業務で違いますが、そのレイヤーまでいくと、ほぼレゴブロック状態ですね。pigみたいのは一切不要ですね。

E. Nakai @enakai00

@okachimachiorz1 となると、そこのレゴブロックの単位で見た時に①MRで分散できる処理②MRで分散させる意味があるほどのデータ量、の２条件をみたすブロックがどれほどあるかがMR適用判断の分かれ目ですか。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@enakai00 えっと、MRだけではprimitive過ぎるので、複数のMRを組み合わせて「ある処理単位」をつくります。アプリ屋からみるとこの処理単位がもっともprimitiveになります。これを組み合わせてレゴブロックの「ブロック」をつくるイメージですね。（続

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

@enakai00 続)そのブロックを組みあわせて一つのDAGのvertexをつくる感じになります。データ量については、そもそも業務量的に分散非同期が前提のデータ量を扱う業務ドメインにシステム全体を適用するので、判断もなにもなくて、使うしかないｗって感じですね。