这是我参与「第四届青训营 」笔记创作活动的第4天
1. 概述
1.1 流式计算vs批式计算
| 特性 | 批式计算 | 流式计算 |
|---|---|---|
| 数据存储 | HDFS、Hive | Kafka、Pulsar |
| 数据时效性 | 天级别 | 分钟级别 |
| 准确性 | 精准 | 精准和时效性之间取得 |
| 典型计算引擎 | Hive、Spark、Flink | Flink |
| 计算模型 | Exactly-once | At Least Once/Exactly Once |
| 资源模型 | 定时调度 | 长期持有 |
| 主要场景 | 离线天级别数据报表 | 实时数仓、实时营销、实时风控 |
1.2 批处理
- T+1架构：数据计算是天级别的，当天只能看到前一天的计算结果
- 小时级批计算
- 如何做到更实时？
1.3 处理时间窗口
- 实时计算：处理时间窗口
- 数据实时流动，实时计算；数据进来，直接计算，窗口结束直接发送结果
2. Watermark
1. Watermark：当前系统认为的事件时间所在的真实时间，核心本质可以理解成一个延迟触发机制。在 Flink 的窗口处理过程中，如果确定全部数据到达，就可以对 Window 的所有数据做 窗口计算操作（如汇总、分组等），如果数据没有全部到达，则继续等待该窗口中的数据全 部到达才开始处理。这种情况下就需要用到水位线（WaterMarks）机制，它能够衡量数据处 理进度（表达数据到达的完整性），保证事件数据（全部）到达 Flink 系统，或者在乱序及延迟到达时，也能够像预期一样计算出正确并且连续的结果。
2. Watermark的生成方式：当任何 Event 进入到 Flink 系统时，会根据当前最大事件时间产生 Watermarks 时间戳，通常在接收到source的数据后，应该立即生成watermark，然后watermark随着数据流向传输。
3. Watermark的计算：Watermark =进入Flink 的最大的事件时间(mxtEventTime)-指定的延迟时间(t)
4. Whatermark触发窗口函数：如果有窗口的停止时间等于或者小于 maxEventTime - t(当时的warkmark)，那么这个窗口被触发执行。
3. Window
3.1 窗口分类
TUMBLE Window （滚动窗口）
HOP Window （滑动窗口）
SESSION Window （会话窗口）
3.2 迟到数据处理
根据上面说到的watermark原理，watermark驱动某个窗口触发输出之后，这个窗口如果后面又来了数据，那这种情况就属于是迟到的数据了。（注意，不是数据的时间晚于watermark就算是迟到，而是它所属的窗口已经被触发了，才算迟到）。
对于迟到的数据，我们现在有两种处理方式：
- 使用side output方式，把迟到的数据转变成一个单独的流，再由用户自己来决定如何处理这部分数据
- 直接drop掉
注意：side output只有在DataStream的窗口中才可以用，在SQL中目前还没有这种语义，所以暂时只有drop这一个策略。
3.3 量计算 VS 全量计算
- 增量计算：每条数据到来后，直接参与计算（但是还不需要输出结果）
- 全量计算：每条数据到来后，先放到一个buffer中，这个buffer会存储到状态里，直到窗口触发输出的时候，才把所有数据拿出来统一进行计算
3.4 EMIT触发
正常的窗口都是窗口结束的时候才会进行输出,EMIT触发就是在这种情况下，可以提前把窗口内容输出出来的一种机制。比如我们可以配置一个1天的窗口，每隔5s输出一次它的最新结果，那这样下游就可以更快的获取到窗口计算的结果了。
这种emit的场景就是一个典型的retract的场景，发送的结果类似于+[1], -[1], +[2], -[2], +[4]。这样才能保证window的输出的最终结果是符合语义的。
4.案例分析
4.1 案例一：计算实时抖音DAU曲线
DAU(Daily Active User)：指的是每天的去重活跃用户数
输出：每个5s更新一下当前的DAU数值，最终获得一天内的DAU变化曲线
滚动窗口+EMIT 使用倾斜优化。
两段聚合：第一轮将数据打散，根据uid分桶再求和，第二轮对各个分桶的结果求和
4.2 案例二：计算大数据任务的资源使用
通过会话窗口将数据划分到一个window中，然后将结果求和。
参考：【大数据专场 学习资料二】第四届字节跳动青训营 - 掘金 (juejin.cn)
总结
- Mini-batch优化解决频繁访问状态的问题；
- local-global优化解决倾斜问题；
- Pane优化降低滑动窗口的状态储存量；
