[参赛项目] Flink任务自动伸缩服务
onyourhead opened this issue · comments
项目简述
通过自动伸缩服务来解决Flink任务背压问题或者资源利用率低的问题，实现资源合理利用。
背景
在用户使用Flink运行实时流任务时，当上游流量有周期性或者其本身波动存在随机性的时候，此时已经启动的任务其算子并行度和集群物理资源用量可能不足以支持当前流量，会出现严重背压和频繁GC的情况，导致上游数据积压、处理延迟增大、Checkpoint耗时增加的情况发生。当流量减小时，系统资源的占用又可能会回到非常低的水平，具体可能表现再CPU平均负载和内存占用都处于相对较低的位置，大量资源处于闲置状态，非常浪费。
目标
在任务出现背压或者资源闲置的情况下，一般都需要用户自行手动介入，去分析任务瓶颈点，去调整相应算子并行度，或者去调整集群中TaskManager的CPU、内存规格，然后再去重启任务。这种模式问题在于其总是需要人为去分析去调整，人是很难做到7*24小时自动值守的，而且分析任务加上调整任务基本上已经是在收到任务出现严重背压的报警后了，处理效率相对滞后，可能等到任务调整完，已经造成一定损失了。
所以，如果能够做到自动化地分析任务，并进行相应的资源伸缩来应对突发的流量波峰和持续的流量低谷，那么对于解放人力、降本增效将有巨大的作用。
实施方案
我们将Flink任务的自动伸缩分为四步走战略。
- 任务监测。我们将建立一套基于Flink Metric的监测系统，实时收集任务的Metric，其中主要包括背压、GC、CPU、内存等指标。这些指标将采集到Pravega，并成为任务是否“健康”的判断依据。
- 状态判断。拿到任务的各种监测数据后，这时候需要有一套算法去判断任务的状态，评判其是否“健康”，是需要伸还是缩。系统默认的将是一套更加缓和的规则，用户自定义的将是一套允许更加激进更细粒度的管控逻辑（比如有些场景对用户来说任务处理速率低于指定值即为不正常，而无论背压与否）。
- 目标资源计算。我们知道了任务的状态后，就马上需要有一个针对任务具体情况的资源计算算法。任务的调优将主要从算子并行度和物理资源的横向、纵向伸缩方面去进行。算子并行度的伸缩主要是从任务角度去调节。物理资源的横纵伸缩则需要k8s HPA/VPA一类的服务来支撑。总之，我们将给出一个合理的任务伸缩目标。这部分我们将用Flink实时任务来支持，“用Flink来优化Flink”。
- 任务伸缩。基于我们已经计算出的资源分配，我们将对集群以及任务进行重新调度，任务将被从最近的Checkpoint恢复。这部分会使用到Flink1.13最新推出的Reactive模式来做实现。当然，对于某些场景下，Source无法伸缩的情况我们也会做相应优化修改。
长远规划
在状态判断和目标资源计算这块，初步使用规则Pattern来做。但规则永远是滞后于任务本身的发展的，在未来，我们期待引入机器学习来根据历史上的任务监测数据去训练模型，去对任务的状态做超前预测，对调整规则做更合理的计算，期望在自动调优达到更好的效果。
成员介绍
阿里云天池昵称：giao桑故乡的樱花开了
Hi ，Can I join the team。 wechat:13521869069
Hi ，Can I join the team。 wechat:lcg3234111
有代码能看么
最近也在做这方面的项目，可以请教吗？
目前还没开源，后续整理下可能会放到GitHub上 在 2022年1月14日 @.> 写道： 有代码能看么 — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.Message ID: @.>
有大致时间点么
你好，请问有开源代码吗