Flink调度策略优化:Task均衡

Flink调度策略优化:Task均衡,第1张

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

Slot1Slot2TaskManager1{A1,B1,C1}{A2,B2,C2}TaskManager2{B3}{B4}

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

Slot1Slot2TaskManager1{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%负载状态

2. 数据积压情况

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

  • 优化前:
  • 优化后:
六、思考 1. Task均衡

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

Slot1Slot2TaskManager1{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},后面无论怎么调度都会均衡。

2. 延迟调度的改进

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

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5072933.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-11-16
下一篇 2022-11-16

发表评论

登录后才能评论

评论列表(0条)

保存