这是我参与「第四届青训营 」笔记创作活动的第4天
流式计算中的Window机制
一、概述
1.1 流式计算 VS 批式计算
数据价值：实时性越高，数据价值越高
1.2 批处理
批处理模型典型的数仓架构为T+1架构，就是数据计算时天级别的，当天只能看到前一天的计算结果。
通常使用的计算引擎为Hive或Spark，计算的时候数据是ready的，输入和输出都是确定性的。
1.3 处理时间窗口
实时计算：处理时间窗口
数据实时流动，实时计算，窗口结束直接发送结果，不需要周期调度任务。
1.4 处理时间VS事件时间
处理时间：数据在流式计算系统中真正处理时所在机器的当前时间
事件时间：数据产生的时间，比如客户端，传感器，后端代码等上报数据时的时间。
1.5 事件时间窗口
实时计算：时间时间窗口
数据实时进入到真实事件发生的窗口中进行计算，可以有效地处理数据延迟和乱序。
1.6 Watermark
小结：
- 批式计算一般是T+1数仓架构
- 数据实时性越高，数据的价值越高
- 实时计算分为处理时间和事件时间
- 事件时间需要Watermark配合来处理乱序
二、Watermark
2.1 什么是Watermark
表示系统认为的当前真实的事件时间
2.2 如何产生Watermark
2.3 如何传递Watermark
2.4 典型问题
Per-partition VS per-submask watermask
前者：早期版本的机制，典型问题是如果一个source subtask消费多个partition那么多个数据之间的读取可能会加剧乱序成都。
后者：新版本引入了基于每个partition单独的watermark生成机制，这种机制可以有效避免。
部分 partition/subtask断流
根据上边提到的watermark传递机制，下游subtask会将上游所有subtask的watermark值的最小值作为自身的watermark值。如果上游有一个subtask的watermark不更新了，那么下游的watermark都不会更新
解决办法：Idle source
当某个subtask的断流超过idle超时时间，将当前的subtask设置为idle，并下发一个idle的状态给下游，下游计算自身watermark的时候可以忽略锅被标记成idle的subtask
迟到数据处理
因为watermark表示当前事件发生的真实时间，那么晚于watermark的数据到来时候，系统会认为这种数据是迟到的数据。
算子自身来决定如何处理迟到数据
- Window聚合，默认丢弃
- 双流join，如果是outer join泽认为它不能join任何数据
- CEP 默认丢弃
三、Window
3.1 Window分类
- Tumble Window 滚动窗口
- Sliding Window 滑动窗口
- Session Window 会话窗口
- 全局Window
- Count Window
- 累计窗口
- ······
3.2 Window使用
3.3 滚动窗口
窗口划分：
- 每个key单独划分
- 每条数据只会属于一个窗口
窗口触发：Window结束时间到达的时候一次性触发
3.4 滑动窗口
窗口划分：
- 每个key单独划分
- 每条数据可能会属于多个窗口
窗口触发：Window结束时间到达的时候一次性触发
3.5 会话窗口
窗口划分：
- 每个key单独划分
- 每条数据会单独划分为一个窗口，如果window之间有交集，则会对窗口进行合并merge
窗口触发：Window结束时间到达的时候一次性触发
