第4章 时间与窗口

流式处理系统长期以来一直应用在提供低延迟、不准确/近似结果的场景里，通常结合批处理系统来提供最终正确的结果，两者组合即Lambda架构。

Lambda架构的基本思想是，在批处理系统旁边运行一个流处理系统，它们都执行基本相同的计算。流式处理系统提供低延迟、不准确的结果（由于使用近似算法，或者因为流系统本身不提供严格正确性），所以每过一段时间，批处理系统持续滚动处理并计算出正确的结果，修正流处理系统的计算结果。Lambda最初是由Twitter的Nathan Marz（Apache Storm创始人）提出的，相当成功。然而维护Lambda系统却是一件麻烦事：需要构建、配置和维护两套不同类型的集群，然后再将两者的计算结果合并。

设计良好的流处理系统实际上是批处理的功能超集，因此建立一个全面的流处理系统，把批处理视作流处理的特例即可，Flink的设计就是基于此。

流处理取代Lambada架构的历史时刻就要来了，在此之前，需要解决两个问题。

1. 正确性——流计算需要与批处理一样计算准确

强一致性是正确处理的前提，对于流处理系统来说，想超越批处理系统，这是基本要求。除非真的不关心结果准确与否，否则应避免使用不能提供强一致性的流处理系统。

如果想了解流处理系统中如何实现强一致性，可以参考MillWheel:Fault-Tolerant Stream Processing at Internet Scale和Discretized Streams:Fault-Tolerant Streaming Computation at Scale两篇论文，在此不再详细阐述。

2. 时间推理工具——批流统一的关键

对于乱序无界的数据流，数据产生的时间和数据真正被处理的时间之间的偏差很大，用于推理时间的工具至关重要。越来越多的现代数据集体现了这个特点，现有的批处理系统（以及大多数流处理系统）缺乏必要的工具来应对这个问题。

在谷歌的Dataflow编程模型的论文The Dataflow Model:A Practical Approach to Balancing Correctness,Latency,and Cost in Massive-Scale,Unbounded,Out-of-Order Data Processing中，介绍了其流批一体计算中的核心设计，其中重点是Window窗口。在论文中，批处理本质是处理有限不变的数据集，流处理本质是处理无限持续产生的数据集，所以批本质上来说是流的一种特例，那么窗口就是流和批统一的桥梁，对流上的数据进行窗口切分，每一个窗口一旦到了计算的时刻，就可以被看成一个不可变的数据集，在触发计算之前，窗口的数据可能会持续地改变，因此对窗口的数据进行计算就是批处理。