業務DAGの分割と循環について

御徒町@Serializable @okachimachiorz

@ashigeru 多層DAGの記述は、やっぱり中間層から作った方よいと思いますた。DAGを一定の範囲でDAGコンポネント化(業務TX)して、下位実装は2ステージ・コンパイルで展開する。ステージ1はMRの上位アルゴリズムへ展開。ステージ2はMRへの展開。(続

御徒町@Serializable @okachimachiorz

@ashigeru 最上位はコンポネントを「組み上げて」SCMレベル（レベル１程度）の業務フローを作る。んで、その最上位レベルと下位実装を同時にjobコントローラに食わせて、実行・運用・監視プロセスを走らせる。（続

御徒町@Serializable @okachimachiorz

@ashigeru 基本的にはSOAではなく、SCAレベルの設計を基本にして、業務プロセスの分割コンポネント化を行って、再利用性と品質を上げる。とにかく実装者の見通しをよくすることに注力する仕組みにしたい。

御徒町@Serializable @okachimachiorz

@ashigeru 第一世代では、「DAGコンポネント」の再利用、”統合”は発見的に行う感じでおｋ。第二世代では、最適化・統合自動化はコンパイラが実施する。っていうか、普通にDryadいきますよ、ってことでFA。

御徒町@Serializable @okachimachiorz

DAGをどう記述すればよいか、というのは隣接行列で記述すればいい、と言う話じゃないか、とか。

御徒町@Serializable @okachimachiorz

DSLをデザインするときは、オッカムの剃刀を使うこと。最小原理は、それなりに真実。

Suguru ARAKAWA @ashigeru

@okachimachiorz とりあえず1枚目: http://ashigeru.com/memo/adag2.png

Suguru ARAKAWA @ashigeru

@okachimachiorz 多分先ほどの図とSCAレベル設計が相性いいのではないかなと

Suguru ARAKAWA @ashigeru

@okachimachiorz Dryadはどのタイミングで出てくるか楽しみですね。あれは統合とかそういうのも考慮されてるものなんですか？

Suguru ARAKAWA @ashigeru

@okachimachiorz http://ashigeru.com/memo/adag3.png このケースってどういうセマンティクスですかね？

御徒町@Serializable @okachimachiorz

@ashigeru まず最初に循環するほうだけど、これは上位のTXの切り方がわるい。業務TXがこういう場合は、間違いなく上下を2つに分割する方が正しい。アトミック合成でなくて分割の方だと思う。あとは、仮にそれに気づかない場合にどう検出するかはやり方があるはず。

御徒町@Serializable @okachimachiorz

@ashigeru Dryadが統合をサポートしているかどうかは知りません><。・・・が、できていないと意味ないっす。手書き上等は勘弁してくれｗ。

御徒町@Serializable @okachimachiorz

@ashigeru んで多層になっている方の図は、いい感じですね。これだとSCA的にはマッチします。多分、世の中はこの方向で行くと思いますです。

Suguru ARAKAWA @ashigeru

@okachimachiorz Src/Sink#1が同じストレージでUpdate処理の場合って、分割するとセマンティクス変わっちゃいませんかね？ってか、もともとTx#1, #2で矛盾があるからそれが正しいのだと思いますけど。

Suguru ARAKAWA @ashigeru

@okachimachiorz もともと、多層になったDAGを描いてたときにCyclicグラフを意図せずに構築できることに気づいたんですよ…。Checkpointだと気づきにくいですけど、アトミック処理で考えると、気づかずにDAGを崩す方法が増えてるっぽいですね

御徒町@Serializable @okachimachiorz

@ashigeru うんにゃ。単純に前半MR終了と後半MR開始にそれぞれSource・Sinkをいれんといかんと思う。業務TX的には、ちゃんと4種類あるケースはある。セマンティクスは最初のTXのとらえ方がおかしい、とおもう。

御徒町@Serializable @okachimachiorz

@ashigeru 下位はDAGだけど，上位はCycleは普通にあると思う。ので、各vertexの開始条件、停止条件が大事。んで、大事なことだけど、Oozeの弱点ね。ここ。気づいてないひとおおいけど。

Suguru ARAKAWA @ashigeru

@okachimachiorz 前半MRと後半MRってのは…#1->#3, #2->#4 のことですか？ここでflushして部分的に確定させればセマンティクスは崩れないですけど、なんとなくそれってTx合成しても同じような

Suguru ARAKAWA @ashigeru

@okachimachiorz Cyclicを許すなら、部分閉路をいかに小さくできるか、ってのが課題になりそうな感じです。

御徒町@Serializable @okachimachiorz

@ashigeru あってます。>flushの話。んで、合成と違うのは、途中のreentrantが許されることができるってこと。#1>#3>#2>#4って普通にいる。分割すればOkだけど、下だと条件がかかる（でないと循環でアウト）

御徒町@Serializable @okachimachiorz

@ashigeru んーっていうか、上位DAGの状態監視が要るってことだと思う。2回、回って抜けるってのはあるからね。下位では判断できない。だから、前のtweetのように、job監視は上位と下位と両方の構造を渡さないとだめ。

Suguru ARAKAWA @ashigeru

@okachimachiorz あざす、了解です＞途中のreentrantを許す。でもこれ、MR#4の最中にSrc#1が破壊されるとセマンティクス変わりませんか？と思ったけど、MR#4の最中にSrc#1が変わってもそのパスは原子性保証してないから関係ないですね。失礼しました

御徒町@Serializable @okachimachiorz

YES RT @ashigeru あざす、了解です＞途中のreentrantを許す。でもこれ、MR#4の最中にSrc#1が破壊されるとセマンティクス変わりませんか？と思ったけど、MR#4の最中にSrc#1が変わってもそのパスは原子性保証してないから関係ないですね。

Suguru ARAKAWA @ashigeru

@okachimachiorz ですね＞上位DAGの状態監視。どちらかというと「統合」のときに問題になると思ってて、Cyclicな部分は自身の閉路の中でしか統合できないはず、って感じです。アンローリングできるならまた別ですが。

御徒町@Serializable @okachimachiorz

@ashigeru うん。合ってると思うけど、閉路で解決するより、多分上位で解決した方が、「なんか起きたときにトレース」しやすいと思うよ。分割統治ですな。