流计算中的 Window 计算｜青训营笔记这是我参与「第四届青训营」笔记创作活动的第4天流式计算VS批式计算特

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

批处理模型典型的数仓架构为T+1架构，即数据计算时天级别的，当天只能看到前一天的计算结果。通常使用的计算引擎为Hive或者Spark等。计算的时候，数据是完全 ready 的，输入和输出都是确定性的。
小时级批处理:将调度级别下降到小时级，每小时一次调度，理论上可以实现更实时的数仓，但是每次周期处理调度外还有申请、释放等过程，比较消耗资源。
数据实时性越高，数据的价值越高。

实时计算分为处理时间和事件时间。

在数据中插入一些 watermark，来表示当前的真实时间。
在数据存在乱序的时候，watermark可以用来在乱序容忍和实时性之间做一个平衡。
Watermark传递机制：下游 subtask 会将上游所有 watermark 值的最小值作为该 subtask 的 watermark 的值。
部分subtask断流：如果上游有一个subtask的watermark不更新了，则下游的watermark都得不到更新而产生断流。
断流解决方案：设置一个idle超时时间，当某个subtask超过配置的超时时间时，会将当前subtask置为idle，并下发一个idle状态给下游，下游在计算自身 watermark 的时候，可以忽略掉当前是idle的那些subtask的watermark，而去计算除状态为idle之外的subtask的watermark。
迟到数据处理：因为watermark表示当前事件发生的真实时间，那晚于watermark的数据到来时，系统会认为这种数据是迟到的数据。算子自身来决定如何处理迟到数据：
- Window聚合，默认会丢弃迟到数据；
- 双流join，如果是outer join，则可以认为它不能join到任何数据；
- CEP，默认丢弃。

滚动窗口：每个key单独划分；每条数据只会属于一个窗口
滑动窗口：每个key单独划分；每条数据可能会属于多个窗口
会话窗口: 每个key单独划分；每条数据会单独划分为一个窗口，如果window之间有交集，则会对窗口进行merge

一条数据到来后，会用WindowAssigner 给它划分一个 window，一般时间窗口是一个时间区间，比如[10：00，11：00），如果划分出来的 window end 比当前的 watermark 值还小，说明这个窗口已经触发了计算了，这条数据会被认为是迟到数据；
只有事件时间下才会有迟到的数据；
迟到数据默认丢弃。
除丢弃外的另外两种处理方法
- Allow lateness：设置一个允许迟到的时间，窗口正常计算结束后，不会马上清理状态，而是会多保留allowLateness这么长时间，在这段时间内如果还有数据到来，则继续之前的状态进行计算。
- SideOutput（侧输出流）：对迟到数据打一个tag，然后在DataStream上根据这个tag获取到迟到数据流，然后业务层面自行选择进行处理。