流计算中的 Window 计算 | 青训营笔记

这是我参与「第四届青训营」笔记创作活动的的第6天

批式计算与流式计算对比：

批式计算一般是T+1的数仓结构；
数据实时性越高，数据的价值越高；
实时计算分为处理时间和事件时间；
事件时间需要Watermark配合来处理乱序。

Watermark

Watermark定义：当前系统认为的事件时间所在的真实时间。

Watermark产生：，可以通过Watermark Generator来生成，一般是从数据的事件时间来产生，产生策略可以灵活多样，最常见的包括使用当前事件时间的时间减去一个固定的delay，来表示可以可以容忍多长时间的乱序。

Watermark传递：这个类似于上节课中介绍的Checkpoint的制作过程，传递就类似于Checkpoint的barrier，上下游task之间有数据传输关系的，上游就会将watermark传递给下游；下游收到多个上游传递过来的watermark后，默认会取其中最小值来作为自身的watermark，同时它也会将自己watermark传递给它的下游。经过整个传递过程，最终系统中每一个计算单元就都会实时的知道自身当前的watermark是多少。

部分数据断流：Idle Source

迟到数据处理：Window算子是丢弃；Join算子认为跟之前的数据无法join到

Window

Window的基本功能：

3.1 Window分类：

典型的Window：

Tumble Window（滚动窗口）
Sliding Window（滑动窗口）
Session Window（会话窗口） Flink 中的窗口划分是key级别的。

其他Window：

全局Window
Count Window
累计窗口
......

3.2 Window使用：

API 抽象程度分层，抽象程度越高，用户的使用成本越低，但表达程度越有限。窗口划分：

每个key单独划分
每条数据只会属于一个窗口窗口触发： Window结束时间到达的时候一次性触发

TUMBLE Window （滚动窗口）

这是最常见的窗口类型，就是根据数据的时间（可以是处理时间，也可以是事件时间）划分到它所属的窗口中windowStart = timestamp - timestamp % windowSize，这条数据所属的window就是[windowStart, windowStart + windowSize)

窗口的触发，是时间大于等于window end的时候，触发对应的window的输出（计算有可能提前就增量计算好了），目前的实现是给每个window都注册一个timer，通过处理时间或者事件时间的timer来触发window的输出。

HOP Window （滑动窗口）

了解了上面的TUMBLE窗口的基本原理后，HOP窗口就容易理解了。上面的TUMBLE窗口是每条数据只会落在一个窗口中。在HOP窗口中，每条数据是可能会属于多个窗口的（具体属于多少，取决于窗口定义的大小和滑动），比如下图中假设滑动是1h的话，那窗口大小就是2h，这种情况每条数据会属于两个窗口。除了这一点之外，其它的基本跟HOP窗口是类似的，比如也是key级别划分窗口，也是靠timer进行窗口触发输出。

SESSION Window （会话窗口）

会话窗口跟上面两种窗口区别比较大，上面两个窗口的划分，都是根据当前数据的时间就可以直接确定它所属的窗口。会话窗口的话，是一个动态merge的过程。一般会设置一个会话的最大的gap，比如10min。

那某个key下面来第一条数据的时候，它的window就是 [event_time, event_time + gap)，当这个key后面来了另一条数据的时候，它会立即产生一个窗口，如果这个窗口跟之前的窗口有overlap的话，则会将两个窗口进行一个merge，变成一个更大的窗口，此时需要将之前定义的timer取消，再注册一个新的timer。

所以会话窗口要求所有的聚合函数都必须有实现merge。