这是我参与「第四届青训营 」笔记创作活动的第3天
01 概述
1.1 流式计算vs批式计算
数据价值：实时性越高，数据价值越高
1.2 批处理
批处理模型典型的数仓架构为T+1架构，即数据计算时天级别的，当天只能看到前一天的计算结果
通常使用的计算引擎为Hive或者Spark等，计算的时候，数据是完全ready的，输入和输出都是确定性的
小时级批计算
1.3 处理时间窗口
实时计算：处理时间窗口
数据实时流动，实时计算，窗口结束直接发送结果，不需要周期调度任务
1.4 处理时间vs事件时间
处理时间：数据在流式计算系统中真正处理时所在机器的当前时间
事件事件：数据产生的时间，比如客户端、传感器、后端代码等上报数据时的时间
1.5 事件时间窗口
实时计算：事件时间窗口
数据实时进入到真实事件发生的窗口中进行计算，可以有效的处理数据延迟和乱序
1.6 Watermark
在数据中插入一些Watermark，来表示当前的真实时间
在数据存在乱序的时候，Watermark就比较重要了，它可以用来在乱序容忍和实时性之间做一个平衡
小结：
1、批式计算一般是T+1的数仓架构
2、数据实时性越高，数据的价值越高
3、实时计算分为处理时间和事件时间
4、事件时间需要Watermark配合来处理乱序
02 Watermark
2.1 什么是Watermark？
表示系统认为的当前真实的事件时间
2.2 如何产生Watermark？
SQL:
CREATE TABLE Orders(
user BIGINT,
product STRING,
order_time TIMESTAMP(3),
WATERMARK FOR order_time AS order_time - INTERVAL '5' SECOND
) WITH (...);
DataStream:
WatermarkStrategy
.<Tuple2<Long,String>>forBoundedOutOfOrderness(Duration.ofSecond(20))
.withTimestampAssigner((event,timestamp) -> event.f0);
2.3 如何传递Watermark？
2.4 如何通过Flink UI观察Watermark？
2.5 典型问题一
Per-partition vs per-subtask watermark生成
Per-subtask watermark生成
早期版本都是这种机制，典型的问题是如果一个source subtask消费多个partition，那么多个partition之间的数据读取可能会加剧乱序程度
Per-partition watermark生成
新版本引入了基于每个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，默认丢弃
小结：
1、含义：表示系统认为的当前真实的事件事件
2、生成：可以通过Watermark Generator来生成
3、传递：取上游所有subtask最小值
4、部分数据断流：Idle Source
5、迟到数据处理：Window算子是否丢弃；Join算子认为跟之前的数据无法join到
03 Window
3.1 Window - 基本功能
Window分类
典型的Window：
1、Tumble Window（滚动窗口）
2、Sliding Window（滑动窗口）
3、Session Window（会话窗口）
其它Window：
1、全局Window
2、Count Window
3、累计窗口
4、...
Window使用
滚动窗口
窗口划分：
1、每个key单独划分
2、每条数据只会属于一个窗口
窗口触发：
Window结束时间到达的时候一次性触发
滑动窗口
窗口划分：
1、每个key单独划分
2、每条数据可能会属于多个窗口
窗口触发：
Window结束时间到达的时候一次性触发
会话窗口
窗口划分：
1、每个key单独划分
2、每条数据会单独划分为一个窗口，如果window之间有交集，则会对窗口进行merge
窗口触发：
window结束时间到达的时候一次性触发
迟到数据处理
怎么定义迟到？
一条数据到来后，会用WindowAssigner给它划分一个window，一般时间窗口是一个时间区间，比如[10:00,11:00),如果划分出来的window end 比当前的watermark值还小，说明这个窗口已经触发了计算了，这条数据会被认为是迟到数据
什么情况下会产生迟到数据？
只有事件时间下才会有迟到的数据
迟到数据默认处理？
丢弃
1、Allow lateness
这种方式需要设置一个允许迟到的时间，设置之后，窗口正常计算结束后，不会马上清理状态，而是会多保留allowLatenness这么长时间，在这段时间内如果还有数据到来，则继续之前的状态进行计算
适用于：DataStream、SQL
2、SlideOutput（侧输出流）
这种方式需要对迟到数据打一个tag，然后在DataStream上根据这个tag获取到迟到数据流，然后业务层面自行选择进行处理
适用于：DataStream
增量vs全量计算
增量计算：
每条数据到来，直接进行计算，window只存储计算结果。比如计算sum，状态中只需要存储sum的结果，不需要保存每条数据
典型的reduce、aggregate等函数都是增量计算
SQL中的聚合只有增量计算
全量计算：
每条数据到来，会存储到window的state中。等到window触发计算的时候，将所有数据拿出来一起计算
典型的process函数就是全量计算
EMIT触发
什么叫EMIT？
EMIT输出指的是在window没有结束的时候，提前把window计算的部分结果输出出来
通常来讲，window都是在结束的时候才能输出结果，比如1h的tumble window，只有在1小时结束的时候才能统一输出结果
如果窗口比较大，比如1h或者1天，甚至更大，那计算结果输出的延迟就比较高，失去了实时计算的意义
怎么实现？
在DataStream里面可以通过自定义Trigger来实现，Trigger的结果儿科医师：
·CONTINUE
·FIRE（触发计算，但是不清理）
·PURGE
·FIRE_AND_PURGE
SQL也可以使用，通过配置：
·table.exec.emit.early-fire.enabled=true
·table.exec.emit.early-fire.delay={time}
小结：
1、三种（滚动、滑动、会话）窗口的定义
2、迟到数据处理：AllowLateness、SideOutput
3、增量计算和全量计算模型
4、EMIT触发提前输出窗口的结果
3.2 Window - 高级优化
Mini-batch 优化
倾斜优化 - local-global
Distinct 计算状态复用
Pane 优化
小结:
1、Mini-batch优化解决频繁访问状态得到问题
2、local-global优化解决倾斜问题
3、Distinct状态复用降低状态量
4、Pane优化降低滑动窗口的状态存储量
04 案例分析
4.1 需求一：使用Flink SQL 计算抖音的日活曲线
问题：所有数据都需要在一个subtask中完成窗口计算，无法并行
通过两阶段聚合来把数据大三，完成第一轮聚合，第二轮聚合只需要对各个分桶的结果求和即可
4.2 需求二：使用Flink SQL计算大数据任务的资源使用
问题描述：
大数据任务（特指离线任务）运行时通常会有多个container启动并运行，每个container在运行结束的时候，YARN会负责将它的资源使用（CPU、内存）情况上报。一般大数据任务运行时间从几分钟到几小时不等
需求：
根据YARN上报的各个container的信息，在任务结束的时候，尽快计算出一个任务运行所消耗的总的资源
假设前后两个container结束时间差不超过10min
典型的可以通过会话窗口来将数据划分到一个window中，然后再将结果求和即可
05 总结：
1、第一部分介绍了流式计算基本概念以及和批式计算的区别
2、第二部分介绍了watermark的含义、如何生成、如何传递以及如何处理部分partition断流的问题
3、第三部分介绍了三种基本的window定义以及迟到数据处理、增量计算vs全量计算、EMIT输出;同时也介绍了local-global优化、mini-batch优化、distinct状态优化、滑动窗口的pane的优化等
4、两个案例介绍滚动窗口、会话窗口以及两阶段聚合解决倾斜问题