流处理基础概念 - 窗口与时间

比起批处理，流处理对窗口（Window）和时间概念更为敏感。在批处理场景下，数据已经按照某个时间维度被分批次地存储了。一些公司经常将用户行为日志按天存储，一些开放数据集都会说明数据采集的时间始末。因此，对于批处理任务，处理一个数据集，其实就是对该数据集对应的时间窗口内的数据进行处理。在流处理场景下，数据以源源不断的流的形式存在，数据一直在产生，没有始末。我们要对数据进行处理时，往往需要明确一个时间窗口，比如，数据在“每秒”“每小时”“每天”的维度下的一些特性。窗口将数据流切分成多个数据块，很多数据分析都是在窗口上进行操作，比如连接、聚合以及其他时间相关的操作。

这里有三种 3 种常见的窗口形式：滚动窗口、滑动窗口、会话窗口。

• 滚动窗口（Tumbling Window）模式一般定义一个固定的窗口长度，长度是一个时间间隔，比如小时级的窗口或分钟级的窗口。窗口像车轮一样，滚动向前，任意两个窗口之间不会包含同样的数据。

• 滑动窗口（Sliding Window）模式也设有一个固定的窗口长度。假如我们想每分钟开启一个窗口，统计 10 分钟内的股票价格波动，就使用滑动窗口模式。当窗口的长度大于滑动的间隔，可能会导致两个窗口之间包含同样的事件。其实，滚动窗口模式是滑动窗口模式的一个特例，滚动窗口模式中滑动的间隔正好等于窗口的大小。

• 会话窗口（Session Window）模式的窗口长度不固定，而是通过一个间隔来确定窗口，这个间隔被称为会话间隔（Session Gap）。当两个事件之间的间隔大于会话间隔，则两个事件被划分到不同的窗口中；当事件之间的间隔小于会话间隔，则两个事件被划分到同一窗口。

会话（Session）本身是一个用户交互概念，常常出现在互联网应用上，一般指用户在某 App 或某网站上短期内产生的一系列行为。比如，用户在手机淘宝上短时间大量的搜索和点击的行为，这系列行为事件组成了一个会话。接着可能因为一些其他因素，用户暂停了与 App 的交互，过一会用户又使用 App，经过一系列搜索、点击、与客服沟通，最终下单。

“时间”是平时生活中最常用的概念之一，在流处理中需要额外注意它，因为时间的语义不仅与窗口有关，也与事件乱序、触发计算等各类流处理问题有关。常见的时间语义如下。

• Event Time：事件实际发生的时间。

• Processing Time：事件被流处理引擎处理的时间。

对于一个事件，自其发生起，Event Time 就已经确定不会改变。因各类延迟、流处理引擎各个模块先后处理顺序等因素，不同节点、系统内不同模块、同一数据不同次处理都会产生不同的 Processing Time。

虽然使用 Event Time 更准确，但问题在于，因为各种不可控因素，事件上报会有延迟，那么最多要等待多长时间呢？从服务器的角度来看，在事件到达之前，我们也无法确定是否有事件发生了延迟，如何设置等待时间是一个很难的问题。

Watermark 是一种折中解决方案，它假设某个时间点上，不会有比这个时间点更晚的上报数据。当流处理引擎接收到一个 Watermark 后，它会假定之后不会再接收到这个时间窗口的内容，然后会触发对当前时间窗口的计算。比如，一种 Watermark 策略等待延迟上报的时间非常短，这样能保证低延迟，但是会导致错误率上升。在实际应用中，Watermark 设计为多长非常有挑战性。还是以手机游戏为例，系统不知道玩家这次掉线的原因是什么，可能是在穿越隧道，可能是有事退出了该游戏，还有可能是坐飞机进入飞行模式。

那既然 Event Time 似乎可以解决一切问题，为什么还要使用 Processing Time？为了处理延迟上报或事件乱序，需要使用一些机制来等待，这样会导致延迟提高。某些场景可能对准确性要求不高，但是对实时性要求更高，在这些场景下使用 Processing Time 就更合适一些。