Dataflow Model論文を11年後に自己採点：著者らが認める「間違い」と「見落とし」
The Dataflow Model Revisited
11年前に発表されたDataflow Model論文が、VLDB Test of Time Awardを受賞したのを機に、著者らが自らの業績を振り返る。イベント時間の優先、完全性を待つことの無意味さ、強い一貫性の主張といった核となる部分は今も有効だが、ウィンドウ処理とトリガーの扱い、ストリーム中心の世界観には誤りがあったと認める。ストリームとテーブルは同じオブジェクトの異なるアクセス手段であり、真の解決策はデータベースの手法（SQL、インクリメンタルビュー更新、明示的な鮮度契約付きマテリアライズドビュー）にあったと論じる。バッチとストリーミングの対立はほぼ意味論的なものであり、低遅延要求はOLTP/OLAPの境界に沿って二極化したと分析する。
私たちはストリーミングの仕組みに注力しすぎて、データベースコミュニティが始めたものの完了させなかったこと、すなわち分析ストリーミングの複雑さをほぼ完全に消し去ることを仕上げられなかった。
- janpeuker
私はかつてDataflow/Apache Beamに非常に夢中で、論文を机の上に印刷して置いていただけでなく、本も持っていました。イベント時間と処理時間の区別、そして完全性に頼らないことに関しては、彼らが正しいことに同意します。そして、それが受け入れ難いことであった理由を深く掘り下げている点が大好きです。非有界ストリームのトリガーについて考えると今でも頭が痛くなりますが、テーブル中心のモデルに到達できて嬉しく思います。それでも、Spannerからいくつかのアイデアを取り入れて、データベースをメッセージバスとして使ったり、行ごとの一貫性情報を持たせたり、つまりデータベース内CQRSのようなものがあったら良かったのにな、と今でも思います。素晴らしい論文です。
- scott_s
私はストリーミング分野で10年間、研究開発に従事してきました（参照: https://scholar.google.com/citations?user=Rdf5OIYAAAAJ&hl=en）。ストリーミングから離れ、大規模データウェアハウスの一般的な問題に移った後、私も同じ結論に達しました。つまり、すべての分析にはSQLをデフォルトにすべきであり、データベースのレンズが分析のためのストリーミングを考える最良の方法である、ということです。
それでも、ストリームプログラミングモデルは非常に興味深く強力だと思います。しかし、かつてはそれらが、高スループット・低レイテンシの大規模並列システムをエレガントにプログラムする方法として、いつか主流になるだろうと考えていました。しかし、それは実現していませんし、今後もそうなるとは思いません。人々は既存のプログラミング言語とモデルでやりくりしており、それで十分のようです。