Dataflow 模型 11 年复盘：物理对了，接口错了

2026 年 VLDB Test of Time 奖颁给了 2015 年的《The Dataflow Model》论文。作者们借此写了一份自我评分：《The Dataflow Model Revisited》（VLDB vol 19），标题副题是"当你意识到自己一直在解决的所有问题都是数据库问题时的那种感觉"。

一句话结论

"我们物理弄对了，接口搞错了。" 事件时间优先、不要等无界数据变完整、一致性不可妥协——这三个判断经住了时间考验；但窗口/触发器/撤回这些用户接口设计，回头看都答错了问题。

当时赌对了什么

• 事件时间 vs 处理时间：事件发生时刻与系统观测时刻的区分，是流处理的基石；
• 无界数据的完整性是幻象：不要等数据"完整"再计算；
• 一致性不可妥协：跨 batch 与 streaming 引擎自由权衡正确性/延迟/成本。

模型本身获得了广泛采纳：Google Cloud Dataflow、Apache Flink 直接构建其上，Kafka Streams、Spark Structured Streaming、Hazelcast Jet、Samza High Level Streams、RisingWave、BigQuery Continuous Queries 都有它的指纹。

遗憾在哪里

• 窗口（windowing）本该更简单：它只是另一个分组维度，不该成为一致性模型的基础；
• 触发器与撤回（triggers/retractions）老化得很差：每个都是对一个"用户本不该被问到的问题"的精巧回答；
• 最大的失察：数据库文献早已握有正确工具几十年——关系算子与代数、增量视图维护、物化视图、标点语义——当时未被承认，也从未被社区发展到逻辑终点。

作者还坦白了一个框架边界：Dataflow 模型从来不是通用流式模型，它始终聚焦流式分析（streaming analytics）；流式作为更广学科的经验教训需要另行讨论。

十年总教训

"我们都盯着流式的细节，其中很多细节确实重要——但分析问题的真正解法，是让流式几乎完全消失。" 把流式问题还原成数据库问题，是这篇复盘给出的方向。原文开放获取（PDF 全文）：The Dataflow Model Revisited - VLDB