流批一体| 青训营笔记
这是我参与「第四届青训营 」笔记创作活动的的第9天
流批一体的Scheduler层
Scheduler主要负责将作业的DAG转化为在分布式环境中可以执行的Task
由图上流程来看,DAGScheduler主要是将一些逻辑执行图中的DAG图转化为物理执行的逻辑图并做相关调度。
在1.12之前的Flink版本中,Flink支持以下两种调度模式:
-
EAGER模式
-
12个task会一起调度,集群需要有足够的资源
-
-
例子:
- 假设这样的一个作业,A算子只有两个并发B算子各有两个并发C算子,对应四个并发D算子
- a和b之间就是点对点的连接——b到c,是两个并发,因此C算子是四个并发,因此B1算子的数据就平均分到C1和C2;B2算子数据就平均分到C3和C4算子。
- 这里可能会有一个聚合的操作 假设有一个聚合的操作,即会有一个KeyBy的操作的这种写法
- 对于数据,C1产出的数据会根据需要按照KEY的哈希值分到D1/D2/D3/D4。可以认为是通过哈希值去做下一个分发。
-
-
LAZY的调度
- 最小调度一个task即可,集群有1个slot资源可以运行
-
最新的Flink调度机制:
- 由Pipeline 的数据交换方式连接的Task构成为一个 Pipeline Region;
- 本质上,不管是流作业还是批作业,都是按照Pipeline Region粒度来申请资源和调度任务。
- 回到那个案例:
- ALL_EDGES_BLOCKING: 所有Task之间的数据交换都是BLOCKING模式; 分为12个pipeline region; ALL_EDGES_PIPELINED: 所有Task之间的数据交换都是PIPELINE模式; 分为1个pipeline region;
流批一体的Shuffle Service层
-
Shuffle:在分布式计算中,用来连接上下游数据交互的过程叫做 Shuffle。 实际上,分布式计算中所有涉及到上下游衔接的过程,都可以理解为Shuffle。
-
-
针对不同的分布式计算框架,Shuffle通常有几种不同的实现:
- 基于文件的Pull Based Shuffle,比如 Spark或MP,它的特点是具有较高的容错性,适合较大规模的批处理作业,由于是基于文件的,它的容错性和稳定性会更好一些。
- 基于Pipeline的Push Based Shuffle,比如Flink、Storm、Presto等,它的特点是低延迟和高性能,但是因为shuffe数据没有存储下来,如果是batch 任务的话,就需要进行重跑恢复;
-
流和批Shuffle之间的差异:
- Shuffle数据的生命周期:流作业的Shuffle数据与Task是绑定的,而批作业的 Shufile 数据与Task是解耦的;
- Shuffle数据存储介质:流作业的生命周期比较短、而且流作业为了实时性,Shuffle通常存储在内存中,批作业因为数据量比较大以及容错的需求,一般会存储在磁盘里;
- Shuffle 的部署方式:流作业 Shuffle服务和计算节点部署在一起,可以减少网络开销,从而减少latency,而批作业则不同。
-
Flink对于流和批提供两种类型的Shuffle,虽然Streaming和Batch Shuffile在具体的策略上存在一定的差异,但本质上都是为了对数据进行Re-Partition,因此不同的Shufle之间是存在一定的共性的。
-
所以Flink 的目标是提供一套统一的Shuffle架构,既可以满足不同 Shuffie在策略上的定制,同时还能避免在共性需求上进行重复开发。
-
在Streaming和OLAP场景
- 为了性能的需要,通常会使用基于Pipeline的Shuffle模式
-
在Batch场景
- 一般会选取 Blocking 的 Shuffle模式
-
为了统一Flink在 Streaming和 Batch模式下的Shuffle架构,Flink 实现了一个 Pluggable 的 ShuffleService框架,抽象出一些公共模块。
-
-
对于Shuffle Service,Flink开源社区已经支持:
- Netty Shuffle Service:既支持pipeline 又支持 blocking,Flink默认的shuffle Service策略
- Remote Shuffle Service:既支持pipeline 又支持 blocking,不过对于pipeline模式,走remote反而会性能下降,主要是有用在batch的 blocking场景,字节内部是基于CSS来实现的RSS。

浙公网安备 33010602011771号