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

1.背景介绍

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

提供自动伸缩容功能，可自动调节 Flink 任务占用的资源，让计算资源分配趋于合理化。一方面避免用户为任务配置过多资源，造成资源浪费；另一方面，降低用户在调节资源方面的运维成本。
提供手动伸缩容功能，降低调节资源过程对业务的影响。伸缩容操作本质是先申请资源，待资源准备就绪后，才执行 Recover 操作，和重启任务相比，可以将业务受影响的时间从分钟级降低到秒级。

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

2.设计思路

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

步骤一：向 ResourceManager 申请 Container ，并为新 Contianer 打标记

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

步骤二：停掉任务，删除ExecutionGraph

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

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

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

3.架构设计

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

RescaleCoordinator 选上 leader 后，会定期检查是否需要伸缩容。如果需要伸缩容，则向 Dispatcher 通知 JobMaster 开始伸缩容（这里省略掉 JobManagerRunner）；
JobMaster 会向 ResourceManager 请求 TaskManager（这里省略掉 SlotPool 和 SlotManager）；
待所有请求的 TaskManager 就绪，开始将旧的 TaskManager 释放掉，然后基于新的TaskManager重新调度；
最终把这次结果持久化到 Zookeeper 和 HDFS，像上文提到的存到 Zookeeper 和 Flink 基于HDFS的 BlobServer，平台上的 Flink 使用 Zookeeper 和 HDFS 做 HA，所以不会引入其他组件；

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

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

4.自动伸缩容策略

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

5. 后续规划

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

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

2.细粒度的扩缩容

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