编程语言
首页 > 编程语言> > Flink源码学习笔记(2) 基于Yarn的自动伸缩容实现

Flink源码学习笔记(2) 基于Yarn的自动伸缩容实现

作者:互联网

封面图片不要使用微信打开文章,可以使用手机/电脑浏览器

1.背景介绍

随着实时计算技术在之家内部的逐步推广,Flink 任务数及计算量都在持续增长,集群规模的也在逐步增大,本着降本提效的理念,我们研发了 Flink 任务伸缩容功能:

  1. 提供自动伸缩容功能,可自动调节 Flink 任务占用的资源,让计算资源分配趋于合理化。一方面避免用户为任务配置过多资源,造成资源浪费;另一方面,降低用户在调节资源方面的运维成本。

  2. 提供手动伸缩容功能,降低调节资源过程对业务的影响。伸缩容操作本质是先申请资源,待资源准备就绪后,才执行 Recover 操作,和重启任务相比,可以将业务受影响的时间从分钟级降低到秒级。

目前支持自动调节并行度以及 TaskManager 的 CPU、内存,用户可以在平台上定义个性化的自动伸缩容的策略:

image-20220101213537486

2.设计思路

以伸缩容 CPU/内存为例,大致思路如下:

步骤一:向 ResourceManager 申请 Container ,并为新 Contianer 打标记

注意:新的 TaskManager Container 请求是通过 SlotPool 向 ResourceManager 请求的,这一步需要在 SlotPool 中维护新的资源配置(CPU:2核,内存:2 GB),且需要支持回滚机制(如果这次伸缩容失败资源设置回滚到 CPU:1核,内存:1 GB)

image-20211126213015465

 

步骤二: 停掉任务,删除ExecutionGraph

image-20211126213047377

 

步骤三: 释放掉旧TaskManager,重新构建ExecutionGraph并在标记的TaskManager上从保存点恢复

image-20211126214530059

步骤四:将这次伸缩容的资源设置持久化到Zookeeper和HDFS

如果 JobManager 挂掉那么之前伸缩容的资源配置都会丢失。所以需要将伸缩容后的资源配置保存在 Zookeeper,HDFS 上 (数据存在 Flink 基于 HDFS 的 BlobServer 中,在 Zookeeper 会中保存 BlobServer 的key,节点在HA的根目录),在 JobManager 被重新拉起时可以从最近一次伸缩容请求恢复。

image-20211126214856445

 

3.架构设计

我们在 JobManager 中添加了一个新的组件 RescaleCoordinator ,使用HA维护其生命周期,且与 Dispatcher 之间彼此通过 RPC通信。

image-20211126231755508

因为新 Container 是提前申请好的,这样就省去了申请 Container 的时间,同时也避免了因为资源不够申请不到slot的问题。

并行度的伸缩容 与CPU/内存类似,不同点:需要在发起新调度前修改JobGraph的并行度来实现修改并行度

4.自动伸缩容策略

类型原因
并行度 存在消费 Kafka 延迟,且 CPU 使用率较低,很可能是 IO 密集型任务,可以增加并行度扩容;存在空闲 slot,则执行缩容避免资源浪费
CPU 根据 CPU 使用率来判定需要扩容或缩容
内存 根据内存使用率及 GC 情况判定需要扩容或缩容

 

5. 后续规划

1.利用离线/实时错峰特点提高服务器资源利用率

由于离线任务一般跑在半夜,导致离线集群半夜比较繁忙,白天空闲,而实时任务恰好相反。我们准备支持基于时间的策略,白天在指定时间将任务资源调高,晚上再将资源还给离线任务,以提高服务器资源利用率。

2.细粒度的扩缩容

我们目前伸缩容都是调节所有 TaskManager 的 CPU/内存,后续想调研下只调节某几个 TaskManager 的可行性。

 

标签:伸缩,Flink,Yarn,TaskManager,源码,内存,并行度,CPU
来源: https://www.cnblogs.com/wgcn/p/15858539.html