Dataflow 模型复盘：我们做错了什么
The Dataflow Model Revisited
十一年的时光，让我们有机会重新审视 Dataflow Model 这篇经典论文。当初我们提出无界、乱序数据是常态，必须放弃等待数据完整，这一核心观点经受住了时间的考验。然而，我们也承认在分析接口的设计上走了弯路：过度强调 windowing 和 triggering 的复杂性，却忽略了用户真正需要的简单性。我们曾过于沉迷于流式处理的机械细节，而未能完成数据库社区未竟的事业——让分析流的复杂性完全消失。如今看来，流与表本质上是同一对象的不同表现形式，真正的演进方向是 SQL、增量视图维护以及带有明确新鲜度契约的物化视图。这场关于批处理与流处理的辩论，很大程度上只是语义之争。
我们过于关注流式处理的机械细节，却没能完成数据库社区已开始却从未完成的工作：让分析流式的复杂性几乎完全消失。
- janpeuker
我以前对 Dataflow/Apache Beam 极其着迷，甚至把论文打印出来放在桌上，还买了那本书。我认同他们关于事件时间（Event time）与处理时间（Processing time）的区分，以及“永远不要依赖完整性”的观点，我也很喜欢他们深入探讨了为什么这一点如此难以接受。想到无界流触发器（unbounded stream triggers），我到现在脑子还疼，所以很高兴我们最终转向了以表为中心（table-centric）的模型。不过我依然觉得，如果能从 Spanner 借鉴一些思路，比如把数据库当作消息总线，或者为每一行提供一致性信息，本质上实现一种数据库内的 CQRS，那该多好。这是一篇很棒的论文。
- scott_s
我在流式计算领域工作了十年，从事研发工作（参见：https://scholar.google.com/citations?user=Rdf5OIYAAAAJ&hl=en）。后来我离开了专门的流式计算领域，转而关注大型数据仓库中的一般性问题，我也得出了同样的结论：对于所有分析任务，默认使用 SQL，而用数据库的视角来思考流式分析是最好的方式。
我依然认为流式编程模型非常有趣且强大。但我过去曾认为，它们最终会成为一种主流方式，用于优雅地构建高吞吐、低延迟的大规模并行系统。但事实并非如此，我也不再认为未来会是这样。人们用现有的编程语言和模型也能应付自如，这似乎已经足够了。