04-流式计算中的Window机制 | 青训营笔记
这是我参与「第四届青训营 」笔记创作活动的第2天
01-概述
简述流式计算的基本概念，与批式计算相比的难点和挑战
数据价值：实时性越高，信息越多，数据价值越高。
批处理模型典型的数仓架构为 T + 1 架构，即数据计算时天级别的，当天只能看到前一天的计算结果。数据是存在延迟的。
通常使用的计算引擎为Hive或者Spark等。计算的时候，数据是完全ready的，输入和输出都是确定性的。
实时计算：处理时间窗口。数据实时流动，实时计算，窗口结束直接发送结果，不需要周期调度任务。
流式系统中有两种很重要的时间概念：
- 处理时间：数据在流式计算系统中真正处理时所在机器的当前时间。
- 事件时间：数据产生的时间，比如客户端、传感器、后端代码等上报数据时的时间。
实时计算一般基于事件时间窗口：数据实时进入到真实事件发生的窗口中进行计算，这样可以有效的处理数据延迟和乱序。
02-Watermark
Watermark的含义、生成方法、传递机制，以及一些典型场景的问题和优化
Watermark表示系统认为的当前真实的事件时间。
Per-subtask watermark生成
早期版本都是这种机制。典型的问题是如果一个source subtask消费多个partition，那么多个partition之间的数据读取可能会加剧乱序程度。
Per-partition watermark生成
新版本引入了基于每个partition单独的watermark生成机制，这种机制可以有效避免上面的问题。
根据上面提到的watermark传递机制，下游subtask会将上游所有subtask的watermark值的最小值作为自身的watermark值。如果上游有一个subtask的watermark不更新了，则下游的watermark都不更新。【watermark长时间停滞】
解决方案：Idle source
当某个subtask断流超过配置的idle超时时间时，将当前subtask置为idle,并下发一个idle的状态给下游。下游在计算自身watermark的时候，可以忽略掉当前是idle的那些subtask。
因为watermark表示当前事件发生的真实时间，那晚于watermark的数据到来时，系统会认为这种数据是迟到的数据。
03-Window
Window基本功能和高级优化
Tumble Window(滚动窗口)
每个key单独划分，每条数据只属于一个窗口，Window结束时间到达的时候一次性触发。
Sliding Window(滑动窗口)
每个key单独划分，每条数据可能会属于多个窗口，Window结束时间到达的时候一次性触发
Session Window(会话窗口)
每个key单独划分，每条数据会单独划分为一个窗口，如果window之间有交集，则会对窗口进行merge。Window结束时间到达的时候一次性触发。
如果一条数据到来之后发现被分配窗口的右区间比当前的watermark值还小，说明窗口已经触发了计算，被认为是迟到的数据。并且只有事件时间下才会有迟到的数据。迟到数据默认处理。
3.1 迟到数据处理
Allow lateness
这种方式需要设置一个允许迟到的时间。设置之后，窗口正常计算结束后，不会马上清理状态，而是会多保留allowLateness这么长时间，在这段时间内如果还有数据到来，则继续之前的状态进行计算。
SideOutput
这种方式需要对迟到数据打一个tag，然后在DataStream上根据这个tag获取到迟到数据流，然后业务层面自行选择进行处理
增量计算
每条数据到来，直接进行计算，window只存储计算结果比如计算sum,状态中只需要存储sum的结果，不需要保存每条数据。
典型的reduce、aggregates等函数都是增量计算
SQL中的聚合只有增量计算
全量计算
每条数据到来，会存储到window的state中。等到window触发计算的时候，将所有数据拿出来起计算
典型的process函数就是全量计算
Emit触发
通常来讲，Window都是在结束的时候才能输出结果，比如1h的tumble window，只有在1个小时结束的时候才能统一输出结果。如果窗口比较大，比如1h或者1天，甚至于更大的话，那计算结果输出的延迟就比较高，失去了实时计算的意义。
EMIT输出指的是，在Window没有结束的时候，提前把window计算的部分结果输出出来。
3.2 Mini-batch优化
- Mini-batch优化解决频繁访问状态的问题
- local-global优化解决倾除斜问题
- Distinct状态复用降低状态量
- Pane优化降低滑动窗口的状态存储量
04-案例分析
抖音DAU实时曲线计算 大数据任务资源使用实时统计分析