复杂 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，就可能出现以下分配：

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

2. 优化

修改策略

1. 为ExecutionSlotSharingGroup申请slot时先对其按包含Task个数排序，优先调度Task个数多的分组

2. 延缓任务调度，等注册TaskManager个数足够大ExecutionSlotSharingGroup平均分配再为其申请Slot

效果

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

四、性能对比

1. CPU 负载对比

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

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

再补充个 CPU 使用率对比

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

2. 数据积压情况

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

• 优化前:

• 优化后：

六、思考

1. Task 均衡

对于拓扑：Vertex A(p=3)->Vertex B(p=4)->Vertex C(p=1)。

将会按以下分配：

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 生成执行计划时期根据拓扑逻辑生成延迟的策略，减少用户操作感知。

本文源自：“大数据技术与架构”公众号