这是我参与「第四届青训营」笔记创作活动的第三天。
Flink流批一体和Exactly-Once前半
Scheduler层
pipeline region
Shuffle Service层
-
基于文件的 Pull Based Shuffle：Spark，MR
-
基于Pipeline的 Push Based Shuffle：Flink，Storm，Presto
流和批Shuffle差异：
-
Shuffle数据生命周期：Shuffle与task在流作业中绑定，在批作业中解耦
-
Shuffle数据存储介质：流处理Shuffle数据存储在内存
-
Shuffle的部署方式：流作业Shuffle服务与计算节点部署在一起
Netty Shuffle Service，支持pipeline和blocking的shuffle，Flink默认
Remote Shuffle Service，支持pipeline和blocking的shuffle，常用于blocking shuffle
字节内部批处理使用cloud shuffle service
Shuffle策略存在不同，但本质上是对数据进行Re-Partition，架构是统一的。
OLAP
延迟约1~10秒，但要求高并发查询，
OLAP被认为是特殊的批式计算，而Flink下批式数据被视作特殊的流式数据
Flink OLAP架构
-
Client
-
Gateway
-
Session Cluster
Flink应对OLAP的优化方向
架构层面：JM与RM在同一个线程启动，无法对JM进行水平扩展；Gateway与Session Cluster相互独立，无法统一管理。
作业管理：JM处理调度作业时负责功能多，单作业处理时间长，内存占用多；TM初始化对时间、CPU资源消耗高。
资源管理：资源申请及释放链路过长；JM管理slot资源，感知不到TM维度的资源分布
其他：作业心跳与Failover机制，并不合适AP这种秒级或毫秒级计算场景;AP目前使用Batch算子进行计算，这些算子初始化（申请内存等）比较耗时;
Exactly-Once 在Flink中的实现
数据&动态表
在流上定义动态表
查询的到的表也是动态的，Continuous Query
At-Least-Once 数据一定被消费但可能重复消费
Exactly-Once 数据一定被消费且只被消费一次
Exactly-Once与Checkpoint
Chandy-Lamport算法
source算子收到JM发送的Checkpoint Barrier表示状态快照制作的开始
后续算子在保存状态后向下游继续发送Checkpoint Barrier并告知JM状态记录已完成并继续工作
算子会等到所有的上游算子的Checkpoint Barrier到达后开始状态快照的制作
