[参赛项目] Morphling - Flink 流作业的动态资源预测与快速调整

[yancanmao]

项目简述

Morphling: Flink 流作业的动态资源预测与快速调整

背景

由于流处理作业是长期执行，并且流数据本身会有数据抖动 -- 输入速率会动态的上升或者下降，静态配置的流作业会比可避免的会出现超负载或者过低负载运行，导致流作业的表现不能达到性能需求（SLO）或者不能有效的利用分配的资源。因此基于当前流数据处理行为能够预测合理的资源并且进行快速动态资源分配是非常重要的。已有的系统比如Ververica的autopilot提供了能够基于CPU utilization或者backpressure并且设置threshold的方式来检测并自动的进行资源分配，虽然这样的方式简单快捷并且工作稳定，但是不能有效的利用已有的流数据处理的信息来预测出合理的资源分配，因此可能需要进行多次动态资源配置来达到合理的流处理状态。并且基于重新部署流作业的机制来实现动态资源分配开销较大耗时较长（资源重申请和状态恢复），从而使得流作业有较长时间处于暂停工作的状态。

目标

我们提议在Flink上实现一个可以根据流数据处理的metrics准确预测资源分配并能快速动态资源分配的流作业控制器，这样的控制器可以动态控制流作业并且让流处理运行更高效并且更加节省资源。

实施方案

我们的项目将主要实现一个可以根据metrics预测资源分配并及通过弹性伸缩部分任务的方式进行高效动态资源分配的流处理控制器，我们将在基于Flink实现以下三个模块：

1. Metrics Manager: 我们认为能够准确预测资源分配最重要的一点是能够预测出Stream task的最大运行速率，也就是在不影响latency的情况下的最大throughput，从而当流数据输入速率上升或下降的时候我们可以判断出最合适的stream task的数量来处理数据。因此我们会在Flink中封装一个Metrics Manager去收集并测量出不同stream task的最大运行速率，主要是通过理论测量模型：在一个window时间内 处理数据个数/有效处理时间 估算出来的，然后通过我们的控制模型去做决策并预测资源分配。特别的，对于分布式metrics的存取，我们可以通过pravega实现，
2. Control policy: 我们将设计一个控制策略（control policy）来对当前的输入速率以及整个pipeline中每个stream task的最大运行速率进行建模分析，从而能够做正确的Scaling决策，并且预测出不同operator的合理资源分配，也就是并行度。
3. Scaling: 我们将基于Flink的checkpoint机制通过部分任务更新的方式来实现Scaling，这种方法可以在保持当前的资源分配和状态的情况下，只对部分任务进行暂停更新和资源重分配，因此可以缩短scaling的时间并降低资源冲申请和状态恢复的开销。

我们将使用WordCount作为benchmark来测试这样的控制器的使用效果。

成员介绍

团队：SANE

成员:
毛言粲（天池ID: Yancanmao），新加坡国立大学博士三年级学生，研究方向：分布式流数据处理
向海林（天池ID: Hailinx），shopee新加坡研发工程师，工作内容：k8s资源调度
杨依涵 （天池ID：），新加坡国立大学博士二年级学生，研究方向：Linux Kernel任务调度，分布式系统。

[ChenShuai1981]

autopilot适合于大状态作业吗？因为作业本身恢复就比较慢。另外对于流量比较大的作业，频繁重启也会造成数据处理延迟。如果能针对这些情况调节autopilot灵敏度就好了。后续项目会开源吗？

[yancanmao]

autopilot适合于大状态作业吗？因为作业本身恢复就比较慢。另外对于流量比较大的作业，频繁重启也会造成数据处理延迟。如果能针对这些情况调节autopilot灵敏度就好了。后续项目会开源吗？

Autopilot本身提供的一套Control policy不太能准确的预测出最优的资源分配，主要是Scaling的判断没有有效的利用整个pipeline上下游的信息，因此需要多次scaling来达到最优/稳定的资源分配，我们的模型Morphling可以利用上下游的metrics建模分析预测需要的资源数量，然后调用Scaling机制，这样可以降低Scaling的次数，尽快收敛到最优资源分配。

就Scaling本身而言：
ververica的autopilot 默认使用的是kill-and-restart的方法，对于state较大的作业，restart的过程会比较慢。
我们这里提出的是一种partial-pause-and-resume的机制，也就是只对需要更新的作业中的stream task进行更新，因此执行速度会快很多，也避免了重启的overhead。

目前这还是一个prototype，我们会在比赛结束之后开源demo的代码。

[WilliamSong112]

请问这部分代码开源了吗

[yancanmao]

请问这部分代码开源了吗

You can refer tohttps://github.com/yancanmao/Morphling. We do not have readme inside, so you may need to read by yourself...Good luck.

[ChenShuai1981]

It seems the above link is broken '404 Not Found'.

[yancanmao]

It seems the above link is broken '404 Not Found'.

Sorry, have created a public repo.

[lycbug666]

请问这部分代码开源了吗

You can refer tohttps://github.com/yancanmao/Morphling. We do not have readme inside, so you may need to read by yourself...Good luck.

请问入口在哪里？可以大概介绍下用法么？

[yancanmao]

请问这部分代码开源了吗

You can refer tohttps://github.com/yancanmao/Morphling. We do not have readme inside, so you may need to read by yourself...Good luck.

请问入口在哪里？可以大概介绍下用法么？

这里有一些大概的用法，我们可能还会继续深入做一些科研项目。。

源码入口

我们的源码主要都封装在了Flink-runtime 和 Flink-streaming-java里（目前还是一个prototype），如果是看源码的话，我们有两个入口，Controller是从MorphlingController.java运行的，Metrics是从MetricsManager出发的。

用法

用途上，我们expose了几个配置在flink-conf.yaml中，默认情况下，我们的实验是在一个single operator的word count上做的。
其中，可以替换config来跑对应的stream job。
model.vertex 可以设置需要做Scaling的operator，我们的prototype暂时只对一个operator做scaling。（有一些其他的config可以暂时不用管）

系统架构

这里有一张我们以前的系统架构图，希望可以提供一定的参考，这里StreamSwitch可以替换成Morphling。

[legend91325]

show 下代码？