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生成执行计划时期根据拓扑逻辑生成延迟的策略,减少用户操作感知。
本文源自:“大数据技术与架构”公众号