Flink调度策略优化：Task均衡

一、背景：

flink任务部署使用基于k8s的standalone集群，先在容器上部署flink集群再提交flink任务，其中flink任务的提交与taskmanager的创建、注册是同时进行的。

二、问题

如果集群有35个taskmanager，140个slot，其中一个Vertex的并行度<140，属于该vertex的task在taskmanager上分布不均，导致节点负载不均衡。
如下所示，

• 该flink拓扑拥有5个vertex，其中两个vertex并行度为140，其他三个并行度根据kafka分区数设置为：10、30、35。任务最大并行度为140，任务资源配置为：35个【4core 8gb】的taskManager节点。
  

• 通过web ui可发现，即使配置了cluster.evenly-spread-out-slots：true，另外三个vertex的task依然会被调度到同个taskmanager上。
  

三、优化方式

1. 问题分析

• 上诉问题可以简化为：

假设一个任务拓扑逻辑为：Vertex A(p=2)->Vertex B(p=4)->Vertex C(p=2)。
基于slot共享和本地数据传输优先的划分策略，划分为四个ExecutionSlotSharingGroup：{A1,B1,C1}、{A2,B2,C2}、{B3}、{B4},
如果资源配置将每个Taskmanager划分为2个Slot，就可能出现以下分配：

	Slot1	Slot2
TaskManager1	{A1,B1,C1}	{A2,B2,C2}
TaskManager2	{B3}	{B4}

当前Slot划分是平均划分内存，对cpu没有做限制。上诉分配会导致节点负载不均衡，若A、C Task计算资源耗费较多，TaskManager1将会成为计算的瓶颈，理想情况下我们希望分配方式是：

	Slot1	Slot2
TaskManager1	{A1,B1,C1}	{B3}
TaskManager2	{A2,B2,C2}	{B4}

2. 优化

修改策略

1. 为ExecutionSlotSharingGroup申请slot时先对其按包含Task个数排序，优先调度Task个数多的分组
2. 延缓任务调度，等注册TaskManager个数足够大ExecutionSlotSharingGroup平均分配再为其申请Slot

效果

• 优化后task调度情况：同个vertex的多个task均匀调度到不同的taskmanager节点上
  
  

四、性能对比

1. CPU负载对比

• 优化前: 节点间CPU负载较为分散，部分节点长时间处于100%高负载状态

• 优化后: 节点间CPU负载较为集中，节点不会长时间处于100%负载状态
  

1.2 再补充个CPU使用率对比

从拓扑图可知任务存在200/480两种不同并行度的task，通过均衡task sharegroup，实现各tm节点的cpu负载均衡，以便我们后续压缩tm的资源配额。

2. 数据积压情况

优化后数据积压量比之前少一半，同资源情况下处理能力更佳，数据延迟更低。

• 优化前:
  
• 优化后:
  

六、思考

1. Task均衡

对于拓扑：Vertex A(p=3)->Vertex B(p=4)->Vertex C(p=1)。将会按以下分配

	Slot1	Slot2
TaskManager1	{A1,B1,C1}	{A3,B3}
TaskManager2	{A2,B2}	{B4}

Vertex B->Vertex C存在四条数据传输通道(B1->C1)、（B2->C1）、（B3->C1）、（B4->C1）,对于非forward的连接，无论subtask分配到哪个group中，至少都存在三条通道需要跨节点通讯。
那么如果在分组的时候就先对task做一次均衡： {A1,B1}、{A3,B3}、{A2,B2}、{B4,C1}，后面无论怎么调度都会均衡。 但当task num% slot num ！= 0的时候，仍存在task在单tm聚集的情况。

2. 延迟调度的改进

在flink生成执行计划时期根据拓扑逻辑生成延迟的策略，减少用户操作感知