「分散システム処理モデルに関する動向について」に対する感想ツイート

tagomoris @tagomoris

@frsyuki yep

SKS rep @repeatedly

Dataflowのextactly onceの穴を見つけたい衝動に駆られている

tagomoris @tagomoris

こないだCTOが、日本で採用するときの基準上げすぎるのマジやめてくれない？ って言ってたのを思い出したので、今夜はこれくらいにしようかと思います。でもマジ楽しいですよ。

Taro L. Saito @taroleo

@repeatedly でも勝負のポイントはそこではない気がする

komamitsu @komamitsu_tw

@tagomoris 裏事情バラすな〜

Sadayuki Furuhashi @frsyuki

SQLなどで宣言的に書かれることが多いデータパイプラインを、手続き型のDSLでインクリメンタルかつインタラクティブに作成しながらも、最終的な成果物として宣言的なSQLの列からなるワークフローを生成できるツールを書いたのだけども、もちっと使い所の模索が必要。

Taro L. Saito @taroleo

@tagomoris まぁ最近の皆の発言を聞いてると、Googlerでも入れなさそうなので確かに基準上げすぎですw

SKS rep @repeatedly

@taroleo いやまぁ俺ストリーム処理系作る人間じゃないので，そういうガチなのはモリス・タゴという人に任せます

Sadayuki Furuhashi @frsyuki

どちらかというと副産物として出来上がった、PythonのクラスとJSONやMessagePackにマッピングするするライブラリの方が便利でイケてた。あとReact.JSが楽しい感じ。Dropwizardは、Railsと比較するとシンプルなアプリケーション向きという印象を得た感じ。

成瀬 @nalsh

@frsyuki Arelみたいなのですか

komamitsu @komamitsu_tw

@frsyuki github上にあります？見たい

Sadayuki Furuhashi @frsyuki

@nalsh Arelみたいのです。

tagomoris @tagomoris

@taroleo ちょっと自粛が必要ですかね……でもハイスキルエンジニアを雇いたければこういう空気を見せるのが得策なはず。なやましい。

tagomoris @tagomoris

真ん中についてはそれはそれで考えてます

Sadayuki Furuhashi @frsyuki

Arelみたいのだけども、構築途中の実行計画をJSONにシリアライズできるのがポイントで、実行計画の中に含まれる、他の実行計画に対する依存関係とか、プレースホルダに埋める値（のファクトリ）とかを永続化できて、それらを後で実体化して繰り返し実行できる感じ。

Sadayuki Furuhashi @frsyuki

@komamitsu_tw githubにないですわ…tar.gzにして送ります

tagomoris @tagomoris

ちょっと言葉が悪かった

tagomoris @tagomoris

でもまあTDにはいわゆるWebメディア的なWebアプリを無限に作るみたいな仕事は皆無なので、真ん中に対して求める基準もちょっと違う気はする

Taro L. Saito @taroleo

@frsyuki @nalsh あ、それScalaでやろうとしてたけど先駆者がいるのか

tagomoris @tagomoris

@frsyuki @komamitsu_tw private repositoryでもないのｗ

成瀬 @nalsh

@taroleo @frsyuki github.com/rails/arel です

tagomoris @tagomoris

で、こないだ(昨日か)してた議論は、宣言的DSLにブレイクダウンするワークフローを手続き的DSLで書くアプローチと、手続き的DSLをベースに構成された分散処理プラットフォームの上に宣言的DSLのレイヤを被せるアプローチがあるよね、さて功罪は、というやつでしたね

Sadayuki Furuhashi @frsyuki

実行計画からの実体化は、SQL文（PostgreSQL, SQLite, Presto, HiveQL, etc.）へのコンパイルが基本なのだけども、プラグイン可能で、結果として複数のデータソースにまたがる複雑なワークフローを構築するDSLとして使用できるという目論見。

tagomoris @tagomoris

ワークフローを手続き的DSLで書くとしたら、少なくとも複数の処理をマージして最終的な結果に落としこむための機能が必要だと思うんだけど、得てしてひとつの前処理(というかstage-1)は複数の処理のデータソースになるので、分岐するワークフローをどう書くんだろうというのを疑問には思う

tagomoris @tagomoris

まーこのへんに唯一絶対の解はたぶん無いので、現実的なワークロードのどこにフィットするものを作りたいかという問題意識の差になるだろうと思う