这是我参与「第四届青训营」笔记创作活动的第4天。
课程目录
1.概述
2.Watermark
3.Window
4.案例分析
1.概述
1.1 流式计算vs批式计算
数据价值：实时性越高，数据价值越高。
| 特性 | 批式计算 | 流式计算 |
|---|---|---|
| 数据存储 | HDFS、Hive | Kafka、Pulsar |
| 数据时效性 | 天级别 | 分钟级别 |
| 准确性 | 精准 | 精准和时效性之间取舍 |
| 典型计算引擎 | Hive、Spark、Flink | Flink |
| 计算模型 | Exactly-Once | At Least Once/Exactly Once |
| 资源模型 | 定时调度 | 长期特有 |
| 主要场景 | 离线天级别数据报表 | 实时数仓、实时营销、实时风控 |
1.2 批处理
- 批处理典型的数仓架构：T+1架构
- 通常使用的计算引擎为Hive或者Spark
小时级批计算
1.3 处理时间窗口
- 实时计算：处理时间窗口
- 数据实时流动，实时计算，窗口结束直接发送结果，不需要周期调度任务。
1.4 处理时间vs事件时间
- 处理时间：数据在流式计算系统中真正处理时所在机器的当前时间
- 事件时间：数据产生的时间，比如客户端、传感器、后端代码等上报数据时的时间
1.5 事件时间窗口
实时计算：事件时间窗口
1.6 Watermark
在数据中插入一些watermark，来表示当前的真实时间。
在数据存在乱序的时候，watermark就比较重要了，它可以用来在乱序1容忍和实时性之间做一个平衡。
1.总结
- 批式计算一般是T+1的数仓架构
- 数据实时性越高，数据的价值越高
- 实时计算分为处理时间和事件时间
- 事件时间需要Watermark配合来处理乱序
2.Watermark
2.1 什么是Watermark
表示系统认为的当前真实的事件时间
2.2 如何产生Watermark
SQL
DataStream
2.3 如何传递Watermark
2.4 如何通过Flink UI观察Watermark
2.5 典型问题一
Per-partition VS per-subtask watermark生成
2.6 典型问题二
部分partition/subtask断流
解决方案：ldle source
2.7 典型问题三
迟到数据处理
因为watermark表示当前事件发生的真实时间，那晚于watermark的数据到来时，系统会认为这种数据是迟到的数据。
算子自身来决定如何处理迟到数据：
- Window聚合，默认会丢弃迟到数据
- 双流join，如果是outer join,则可以认为它不能join到任何数据
- CEP,默认丢弃
2.总结
- 含义：表示系统认为的当前真实时间
- 生成：可以通过Watermark Generator来生成
- 传递：取上游所有subtask的最小值
- 部分数据断流：ldle Source
- 迟到数据处理：Window算子是丢弃；join算子认为跟之前的数据无法join到
3.Window
3.1 Window-基本功能
3.1.1 Window分类
典型的Window
- Tumble Window（滚动窗口）
- Sliding Window（滑动窗口）
- Session Window（会话窗口）
其他Window
- 全局Window
- Count Window
- 累计窗口
3.1.2 Window使用
3.1.3 滚动窗口
窗口划分
- 每个key单独划分
- 每条数据只会属于一个窗口
窗口触发
Window结束时间到达的时候一次性触发
3.1.4 滑动窗口
窗口划分
- 每个key单独划分
- 每条数据可能会属于多个窗口
窗口触发
Window结束时间到达的时候一次性触发
3.1.5 会话窗口
窗口划分
- 每个key单独划分
- 每条数据会单独划分一个窗口，如果window之间有交集，则会对窗口进行merge
窗口触发
Window结束时间到达的时候一次性触发
3.1.6 迟到数据处理
如何定义迟到
一条数据到来后，会用WindowAssigner给他划分一个window，一般时间窗口是一个时间区间，比如（10：00，11：00），如果划分出来window end比当前的watermark值还小的话，说明这个窗口已经触发了计算了，这条数据会被认为是迟到数据。
什么情况下会产生迟到数据
只有事件时间下才会有迟到的数据
迟到数据默认处理：丢弃
- Allow lateness
- SideOutput（侧输出流）
3.1.7 增量vs全量计算
增量计算
- 每条数据到来，直接进行计算，window只存储计算结果，比如计算sum，状态中只需要存储sum的结果，不需要保存每条数据。
- 典型的reduce、aggregate等函数都是增量计算
- SQL中的聚合只有增量计算
全量计算
- 每条数据到来，会存储到window的state中。等到window触发计算的时候，将所有数据非出来一起计算。
- 典型的process函数就是全量计算
3.1.8 EMIT触发
EMIT输出指的是，在window没有结束的时候，提前把window计算的部分结果输出出来。
在DataStream里面可以通过自定义Trigger来实现，Trigger的结果可以是：
- CONTINUE
- FIRE（触发计算，但是不清理）
- PURGE
- FIRE_AMD_PURGE
SQL也可以使用，通过配置：
table.exec.emit.early-fire.enabled=true
table.exec.emit.early-fire.delay=(time)
3.1 小结
- 三种窗口的定义
- 迟到的数据处理
- 增量计算和全量计算模型
- EMIT触发提前输出窗口的结果
3.2 Window-高级优化
3.2.1 Mini-batch优化
3.2.2 倾斜优化-local-global
3.2.3 Distict计算状态复合
3.2.4 Pane优化
3.总结
- Mini-batch优化解决频繁访问状态的问题
- local-global优化解决倾斜问题
- Distinct状态复用降低状态量
- Pane优化降低滑动窗口的状态存储量
4.案例分析
4.1 使用Flink SQL计算抖音的日活曲线
问题：所有数据都需要在一个subtask中完成窗口计算，无法并行。
通过两阶段聚合来把数据打散，完成第一轮聚合，第二轮聚合只需要对各个分桶的结果求和即可。
4.2 使用Flink SQL计算大数据任务的资源使用
问题描述:
大数据任务(特指离线任务)运行时通常会有多个container启动并运行，每个container在运行结束的时候，YARN会负责将它的资源使用(CPU、内存)情况上报。一般大数据任务运行时间从几分钟到几小时不等。
需求:
根据YARN上报的各个container的信息，在任务结束的时候，尽快的计算出一个任务运行所消耗的总的资源。 假设前后两个container结束时间差不超过10min。
典型的可以通过会话窗口来将数据划分到一个window中，然后再将结果求和即可。
