Successfully reported this slideshow.
Your SlideShare is downloading. ×

Asakusaの今後の方向性

Advertisement

More Related Content

Advertisement

Related Books

Free with a 30 day trial from Scribd

See all

Asakusaの今後の方向性

  1. 1. Asakusaの今後の方向性<br />
  2. 2. まずはAsakusaの構成要素<br />AsakusaDSL<br />開発手法と表裏一体<br />Ashigelcompiler<br />最適化<br />中間表現<br />ThunderGate<br />パフォーマンス<br />
  3. 3. AsakusaDSL<br />AsakusaDSL<br />開発手法と表裏一体<br />現状の問題点<br />メタフロー記述ができない<br />例)伝票処理<br />各伝票処理で基本的なフローは同じだが微妙に違うことがある<br />仕入伝票、返品伝票、在庫移動伝票、廃棄伝票<br />すべての伝票で例えば商品マスターチェックを行っている・・・<br />が、現状では似たようなコードが各所で書かれている。実際にコピペで実装というケースもある<br />同じような処理は可能限り一箇所で記述した方がよい<br />
  4. 4. メタフロー化<br />汎化するフローレベルの問題<br />処理単位での汎化とPart単位での汎化が競合した場合<br />基本的に再帰的に考えれば良い<br />インターフェイスが合っていれば、特に問題はないはず<br />FlowpartA<br />処理A<br />処理B<br />Flowpart単位での汎化<br />Flow単位での汎化<br />FlowpartA1<br />処理A1<br />
  5. 5. メタフロー化<br />そもそもフローの汎用化とかどう考えるか?<br />というかそもそもデータフローをどう考えるのか?<br />まずデータフローのカテゴライズ<br />TX->TX<br />例)確定前請求データ->確定後請求データ<br />結構ある<br />Ms->TX<br />例)取引先M->請求データ<br />結構ある<br />TX->Ms<br />例)納品データ->商品M登録データ作成<br />割と特殊<br />Ms<br />Process<br />TX<br />TX<br />
  6. 6. 制限はあるか?<br />引数の型paramは上限にしてほしいかも<br />戻り値がバラバラは無理かも<br /> @Update<br />public <P extends PModel> void updateProjection(P model) {<br />model.setProjectiveMember(100); }<br />@MasterJoinUpdate<br /> public <P extends PKey & PValue><br /> void branchProjection(<br /> @Key(group = "key") P mst,<br /> @Key(group = "key") TxDatatx) {<br />tx.setValue(mst.getValue());<br />}<br />データを変形するタイプ<br />Update~Join・Sort<br />データを生成するタイプ<br />Convert<br />イメージ的にはこんな感じか<br />Ms<br />Process<br />TX<br />TX<br />但し、出力が一意に決まればいけるかも<br />
  7. 7. Ashigelcompiler<br />Ashigelcompiler<br />最適化<br />Unification<br />複数jobの同時実行の最適化<br />例えば同じデータに対して違うjobを走らせる場合<br />シーケンスに処理をするのではなく、同時に処理をしたい<br />そのときに最適化をしておきたい・・・<br />だけじゃなくて、統合できる計算があれば、事前に統合してしまうというレベルまでやるそうです。もっと広い意味でUnify<br />中間表現<br />DSLの複数ホスト言語対応<br />今だとJavaだけ<br />Scala<br />Tuple表現やデータフロー表現はリッチ<br />Ruby<br />よくわからんが書きやすい気がする<br />「他のアプリケーションに組み込みことが容易になる」<br />
  8. 8. ThunderGate<br />ThunderGate<br />パフォーマンス<br />データの展開のスピードを上げたい<br />ThunderGateは展開は早い<br />戻りがまだ遅い->HDFSサイドに状態を管理する機能が無いため<br />展開:雷門側で必要なものだけ理解して送る<br />ThunderGate<br />MySQL<br />HDFS<br />回収:HDFSは頭が悪いので全部戻もどす<br />
  9. 9. ThunderGate<br />ThunderGateとHbaseの統合<br />要するにHDFSがあんまり頭が良くない<br />FSなので仕方がない<br />Hbaseと統合して行く、とか考え中<br />展開:雷門側で必要なものだけ理解して送る<br />HDFS<br />Hbase<br />ThunderGate<br />MySQL<br />回収:必要なものだけ回収<br />

×