原文链接：

http://www.whitewood.me/2018/03/21/%E6%B5%81%E5%BC%8F%E8%AE%A1%E7%AE%97%E7%9A%84windowing/

整理：大数据肌肉猿(BigData-BigMuscle)

作为对流式数据流进行stateful统计的基础，window函数是各流式计算框架必不可少的特性。然而目前业界并没有对windowing作出标准的定义和分类，不同计算框架提供的windowing方法各有不同，同一术语在不同框架的含义也不一致，这给流式计算造成了不必要的学习成本。因此本文试图从工作积累出发并结合个人理解，总结出较为全面的windowing概念以及常见策略。

windowing概念

因为实时数据流是永不停歇的，我们无法获取所有的数据并产出一个最终的结果。更重要的是很多情况下我们更关心的是最近的状态，而不是从实时数据流启动至今的统计数据。所以我们将数据流切分为一个个片段，即计算窗口，比如最近5分钟或最近100条消息，然后在每个窗口的基础上进行统计，这种计算方式就是windowing。总而言之，windowing是将无边界的实时数据流划分为计算窗口的统计手段。通常window函数会配合groupby函数一起使用，即作用于grouped stream上。

windowing策略

Windowing策略从对象指标上分为3种，即基于时间(time window)，基于计数(count window)以及基于会话(session window)，其中基于时间和基于的windowing又可以分为滚动窗口(tumbling window)和滑动窗口(sliding window)。其中与时间相关的windowing，计算间隔(step)与统计窗口(window)的关系如下:

window分类(count-based和time-based相似)

时间窗口

时间窗口顾名思义是根据时间来划分窗口，然而这里的时间是有所讲究的，总体来讲可以分为以下三种：

• 事件时间(event time)：消息所代表事件的业务时间，依赖于数据本身

• 消化时间(ingestion time)：消息到达计算引擎的时间

• 处理时间(processing time)：消息被实际处理的时间

根据业务需求不同用户可以灵活采用时间口径。事件时间最为有用但处理最为复杂，因为消息有可能乱序到达甚至迟到，所以我们不能保证在合理的时间窗口内收集到所有的事件。处理时间容易处理一些，因为消息窗口起始结束时间都由服务端控制，但对业务的价值比较小。

滚动时间窗口

滚动窗口是最为简单的windowing策略，实际上离线计算从某种程度上就属于滚动窗口。滚动窗口的特点是计算间隔与统计窗口相等，任意两次计算的数据没有重叠部分(non-overlapping)，因此每次计算只需要考虑前一次计算间隔对应的数据，不需要维持跨计算间隔的数据或状态。

滑动时间窗口

滑动窗口的概念借鉴自TCP，一般统计窗口大于计算间隔，因此连续的两次计算间有重叠(overlapping)，一条记录会出现在ceil(统计窗口/计算间隔)个统计窗口里。从图上来看就像统计窗口随着数据流滑动，每次滑动的步长就是计算间隔。实时计算中很大部分指标都应用了滑动窗口，例如监控中常见的qps/tps或者搜索引擎近24小时的热搜关键词。实际上滚动窗口也是滑动窗口的一个特例。

计数窗口

滚动计数窗口与滑动计数机制类似于上文两种窗口，区别仅在于用于划分边界的指标不是时间而是当前未处理的记录数。计数窗口不如时间窗口直观，但更适合数据量较小或在时间上分布不均匀的数据流。比如广告系统可能一天会展示10000次某个广告，不过时间并不固定而是通过用户画像判断是否应该展示，这时最近1000次展示的购买率则比最近1小时的购买率更有意义。

会话窗口

会话窗口是比较特殊的一类windowing策略，它基于时间间隔来划分窗口。会话窗口没有固定的大小或起始结束时间，而是动态地打开和关闭窗口。当收到消息时判断当前是否有会话，若有则并入当前会话，否则新建一个会话，一个会话超过一定时长没有新的消息则会关闭。其中值得注意的地方是由于会话的判断基于时间，这里也涉及到上文所说的三种时间的区别。如果基于处理时间，那么消息一定有序的，但如果基于事件时间和消化时间，消息可能是乱序的，这样可能遇到已经关闭的窗口被重新打开，甚至和下一个窗口合并的情况，具体决定于处理迟到记录的策略。

总结

尽管不同计算引擎的提供的window API有所差异，但其背后的策略都是相似的。在享受window函数带来的便捷的同时，更重要的是考虑如何持续化和恢复计算状态，会不会带来数据丢失或数据重复的潜在问题。