一、背景：
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生成执行计划时期根据拓扑逻辑生成延迟的策略，减少用户操作感知。
如果这个文章对你有帮助，不要忘记 「在看」 「点赞」 「收藏」 三连啊喂！
2022年全网首发|大数据专家级技能模型与学习指南(胜天半子篇)
Flink CDC我吃定了耶稣也留不住他！| Flink CDC线上问题小盘点
1059
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
