这是我参与「第四届青训营 」笔记创作活动的的第4天，这几天学习了【流计算中的 Window 计算】的内容，重点是watermark、window的迟到数据处理以及实际的应用。
再谈流/批区别
| 流 | 批 |
|---|---|
| 分钟级别 数据价值更高 | 天级别 |
| 架构T+1 | |
| flink | hive spark |
短时间粒度批的批 VS 流 批资源要不停的释放重新申请比较耗费资源
watermark
处理乱序数据的工具
定义：系统认为的当前真实的事件时间(一般来说是timestamp)
传递(选多个输入的最小watermark)
window
- Tumble滚动窗口 数据仅属于一个窗口；windows结束时间到，一次性触发
- Sliding滑动窗口 数据可能属于多个窗口；windo结束时间到，一次性触发
- Session会话窗口 窗口会被合并，后来和先到合并为同一个窗口
迟到定义
一般来说晚于watermark就算迟到，window下更为宽松，若window没有触发，则继续计算。
迟到数据处理
- 丢弃
- allow lateness(实现用到retract：流式计算的更新机制)
不会马上丢弃，继续等待lateness时间 3. sideoutput
迟到数据打标记，向DataStream提供该数据流
增量 VS 全量
增量：直接计算，window存储计算结果
全量：数据全存储，等到window触发再计算
EMIT触发
window一般是触发后才输出结果
EMIT指window未触发，提前输出结果。
window优化
mini-batch
解决问题：频繁访问状态
化为小batch
注：状态要保存(小存内存，大存存储)
local-global
问题： 倾斜（有些key的数据量过大）
实现：再传递给下一层之前，先做预处理，即对同一个key进行聚合
distinct计算状态复用
问题：状态量过多
实现：利用int或double的不同bit来表征，同一个distinct指标的不同条件
pane优化
问题：滑动窗口，同一个数据属于不同的窗口，窗口间重复计算过多
实现：划分为滚动窗口，数据在每个窗口单独计算完，最后聚合
案例
抖音日活曲线
- 滚动窗口+EMIT输出
问题：所有数据在一个subtask当中，不能并行
方案：两阶段，先聚合，后对聚合后桶结果求和
