这是我参与「第四届青训营 」笔记创作活动的第4天
1. 概述
1.1. 流式计算 VS 批式计算
数据价值：实时性越高，数据价值越高
1.2. 批处理
批处理典型的数仓架构为 T+1 架构，即数据计算天级别的，当天只能看到前一天的计算结果。
通常使用的计算引擎为 Hive 或者 Spark 等。计算的时候，数据是完全ready的，输入和输出都是确定的。
小时级批计算
1.3. 处理时间窗口
实时计算：处理时间窗口
数据实时流动，实时计算，窗口结束直接发送结果，不需要周期调动任务
1.4. 处理时间 VS 事件时间
处理时间：数据在流式处理系统中真正处理时所在机器的当前时间；
事件时间：数据产生的时间，比如客户端、传感器、后端代码等上报数据的时间；
1.5. 事件时间窗口
实时计算：事件时间窗口
数据实时进入到真实事件发生的窗口中进行计算，可以有效地处理数据的延迟和乱序
1.6. Watermark
- 在数据中插入一些watermark，来表示当前真实的时间
- 在数据存在乱序的时候，watermark就比较重要了，它可以用来在乱序容忍和实时性之间做一个平衡
2. Watermark
2.1. 什么是Watermark
系统认为的当前真实的事件事件
2.2.如何产生Watermark
SQL
DataStream
2.3. 如何传递Watermark
上游传输过来的watermark的最小值为当前算子的watermark
2.4. 如何通过Flink UI 来观察 Watermark
2.5. 典型问题一
Per-partition VS Per-subtask watermark 生成
Per-subtask watermark 生成：
早期版本都是这种机制，典型的问题是一个source subtask消费多个partition，那么多个partition之间的数据读取可能会加剧乱序程度
Per-partition 生成：
新版本引入了基于每一个partition单独的watermark生成机制，这种机制可以有效的避免上面的问题
2.6. 典型问题二
部分partition/subtask断流
根据上面提到的watermark传递机制，下游subtask会将上游所有subtask的watermark值的最小值作为自身的watermark值，如果上游有一个subtask的watermark值不更新了，则下游的watermark值都不更新
解决方案：Idle source
当某个subtask断流的时间超过配置的idle超时时间，将当前的subtask设置为idle，并下发一个idle的状态给下游。下游在计算自身的watermark的时候，可以忽略掉当前是idle的那些subtask
2.7. 典型问题三
迟到数据处理
因为watermark表示当前事件发生的真实时间，那晚于watermark的数据到来时，系统会认为这种数据是迟到的数据
算子自身来决定如何处理吃掉的数据：
- Window聚合，默认会丢弃迟到数据
- 双流join，如果是outer join，则可以认为他不能join到任何数据
- CEP，默认丢弃
3. Window
3.1. Window-基本功能
3.1.1. Window分类
典型的Window：
- Tumble Window（滚动窗口）
- Sliding Window（滑动窗口）
- Session Window（会话窗口）
其他Window：
- 全局Window
- Count Window
- 累计窗口
- ...
3.1.2. Window使用
SQL API
DataStream API
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
这种方式需要设置一个迟到的时间，设置之后，窗口正常计算结束后，不会马上清理状态，而是会多保留Allow lateness这么点时间，在这段时间内如果还有数据到来，则继续之前的状态进行计算
适用于：DataStream、SQL
- SideOutput（侧流输出）
这种方式需要给迟到数据打一个tag，然后在DataStream上根据这个tag获取迟到数据流，然后业务层面自行选择进行处理
适用于：DataStream
3.1.7. 增量 VS 全量计算
增量计算
- 每条数据到来，直接进行计算，window只储存计算结果，比如计算sum，状态中只需储存sum的结果，不需要保存每条数据
- 典型的reduce、aggregate等函数都是增量函数
- SQL中的聚合只有增量计算
全量计算
- 每条数据到来，都会存储到window的state中，等到window触发计算时，将所有数据拿出来一起计算
- 典型的process函数是全量计算
3.1.8. EMIT触发
什么叫EMIT
通常来讲，window都是在结束的时候才能输出结果，比如1h的tumble window，只有在一小时结束的时候才能统一输出结果
如果窗口比较大，比如1h或者1天，甚至于更大的话，那计算结果输出的延迟就比较高，失去了实时计算的意义
EMIt的输出指的是，在window没有结束的时候，提前把window计算的结果输出出来
怎么实现
在DataStream中可以自定义Trigger来实现，Trigger的结果可以是：
- CONTINUE
- FIRE（触发计算，但是不清理）
- PURGE
- FIRE_ADN_PURGE
SQL也可以使用，通过配置：
- table.exec.emit.early-fire.nabled=true
- table.exec.emit.early-fire.delay={time}
3.2 Window高级优化
3.2.1. Mini-Batch 优化
3.2.2. 倾斜优化-local-global
3.2.3. Distinc 计算状态复用
3.2.4. Pane优化
4. 案例分析
4.1. 利用Flink SQL 计算抖音的日活曲线
问题：所有数据都需要在一个subtask中计算完成，无法并行
通过两阶段聚合来把数据打散，完成第一轮聚合，第二轮聚合只需要对各个分桶的结果进行就和即可
4.2. 利用Flink SQL计算大数据任务的资源使用
问题描述：
大数据任务（特指离线任务），运行时通常会有多个container启动并运行，每个container在运行结束的时候，YARN会负责将他的资源使用（CPU、内存）情况上报，一般大数据任务运行时间从几分钟到几小时不等
需求：
根据YARN上报的各个container的信息，在任务结束的时候，尽快的计算出一个任务运行所消耗的总的资源。
假设前两个container结束时间差不超过10min
典型的可以通过会话窗口来将数据划分到一个窗口中，然后再将结果求和即可
