流计算中的 Window 计算|青训营笔记
这是我参与「第四届青训营 」笔记创作活动的的第3天
1概述
1.1批处理
典型数仓架构T+1架构，数据计算是天时的 常用计算引擎为hive或者spark等，
1.2处理时间窗口
窗口结束直接发生结果，不需要周期调度任务
1.3处理时间VS事件时间
数据在流计算处理时机器所在的机器当前时间 数据产生时间，例如后端上报数据的时间
2.watermark
表示系统认为的当前真实的事件时间 watermark传递机制，（上游subtack的watermark不更新的情况）提出Idle source解决方案 迟到数据处理：晚于watermark的数据到来时间（处理方式：Window聚合、双流join、CEP）
3.Window
- 典型的Window： Tumble Window（滚动）、Sliding Window（滑动） 、Session Window（会话）
- 其他window：全局 window、累计 window 、……
滚动窗口
- 窗口划分：每个key单独划分、每条数据只会属于一个窗口
- 窗口触发：Window结束时间到达的时候一次性触发
滑动窗口
- 窗口划分：每个key单独划分、每条数据可能会属于多个窗口
- 窗口触发：Window结束时间到达的时候一次性触发
会话窗口
- 窗口划分：每个key单独划分、每条数据会单独划分为一个窗口，如果window之间有交集，则会对窗口进行merge
- 窗口触发：Window结束时间到达的时候一次性触发
3.1 迟到数据处理
- Allow lateness 这种方式就是设置一个允许迟到的时间
- SideOutput （侧输出流） 给迟到数据打一个tag，然后在DataStream上根据Tag选择进行处理
3.2 增量计算VS全量计算
- 增量计算：每条啥时间到来直接计算（典型的reduce 、aggregate等函数都是增量计算），SQL中聚合也只有增量计算
- 全量计算：每条数据到来，存储在Window的state，等触发window触发计算时，再拿出来计算（典型的process函数就是全量计算）
- EMIT触发：在Window没有结束的时候提取把Window计算的部分结果输出出来
3.3Window优化
- MIni-batch优化解决频繁访问状态的问题
- Local-global优化解决倾斜问题
- Distict状态复用降低状态量
- pane优化降低滑动窗口的状态存储量
4.案例分析
需求一：使用FlinkSQL计算抖音的日活曲线
使用滚动窗口、EMIT的输出
table.exec.emit.early-fire.enabled=true
table.exec.emit.early-fire.delay=5min
问题：所有数据都需要在一个substack中完成窗口计算，无法并行
通过两阶段聚合把数据打散，完成第一轮聚合，第二轮集合只需要对各个分桶的结果求和即可
table.exec.emit.early-fire.enabled=true
table.exec.emit.early-fire.delay=5min
table.exec.window.allow-retract-input=ture
需求二
问题描述： 大数据任务（离线）运行时通常会有多个container启动并运行，每个container在运行结束的时候。Yarn会负责将它的资源使用（CPU\内存）情况上报，一般大数据任务运行时间从几分钟到几小时不等
需求： 根据Yarn上报的各个container的信息，在任务结束的时候，尽快的计算出一个任务运行时所消耗的总的资源，假设两个container结束时间差不超过10min
典型的可以通过会话窗口将数据划分到一个window中，然后再将结果求和即可
Q&A 学习思路：去社区做一些了解，做小实验验证自己的理解，一步步完成项目二流式计算系统的开发（不难）
