复杂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节点

复杂Flink任务Task均衡调度和优化措施_第1张图片

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

复杂Flink任务Task均衡调度和优化措施_第2张图片

三、优化方式

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,就可能出现以下分配:

复杂Flink任务Task均衡调度和优化措施_第3张图片

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

复杂Flink任务Task均衡调度和优化措施_第4张图片

2. 优化

修改策略

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

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

效果

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

复杂Flink任务Task均衡调度和优化措施_第5张图片

四、性能对比

1. CPU负载对比

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

复杂Flink任务Task均衡调度和优化措施_第6张图片

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

复杂Flink任务Task均衡调度和优化措施_第7张图片

再补充个CPU使用率对比

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

复杂Flink任务Task均衡调度和优化措施_第8张图片

2. 数据积压情况

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

  • 优化前:

复杂Flink任务Task均衡调度和优化措施_第9张图片

  • 优化后:

复杂Flink任务Task均衡调度和优化措施_第10张图片

六、思考

1. Task均衡

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

将会按以下分配:

复杂Flink任务Task均衡调度和优化措施_第11张图片

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

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

你可能感兴趣的:(大数据)