摘要：本文整顿自阿里云开发工程师，Apache Flink Contributor 钟旭阳，在 Flink Forward Asia 2022 生产实践的分享。本篇内容次要分为四个局部：
- 历史背景
- 框架简介
- 案例介绍
- 将来布局
点击查看原文视频 & 演讲 PPT
一、历史背景
批作业在算子理论解决数据时，能够提前感知到要解决的这部分数据有多大。从而能够依据数据量的大小，抉择适合的资源解决数据。但流作业是一种 long-running 的作业，它的特点是流量会随着工夫进行变动。
咱们没有方法在流作业刚启动时，就预估到将来的流量有多少，须要多少资源。没有一份初始的通用资源配置能够实用于一个流作业的所有场景。
并且，在通常状况下，用户须要保护许多的 Flink 作业，其中会有很多逻辑简单、节点很多的作业。如果靠每个用户手工配置这些作业的资源配置，这一过程是比拟繁琐的。对于每个用户来说，也是不太事实的。
同时，因为 Flink SQL 的宽泛推广，用户只须要关怀本人的业务逻辑，就可能应用 Flink 的能力。但也正是因为 Flink SQL 易用性，让用户不足对 Flink 外部实现细节的理解，调优老本会比拟高。
综合以上的种种问题，给作业资源配置和调优带来肯定的艰难。
如果一份作业设置了不太正当的资源配置，在资源配置设置较高时，会减少业务的老本。从作业上看，资源的利用率会更低。在资源配置设置比拟低的时候，会使整个作业的解决能力有余，导致作业呈现吞吐比拟低，提早攀升的状况。在资源严重不足时，还会导致呈现 Failover 的状况大大增加，从而影响整个作业的安稳运行。
咱们冀望作业主动调优的指标比较简单，即配置一份在保障作业无提早的前提下，尽可能的进步作业整体的吞吐量，进步作业的资源利用率，让资源不再成为作业的瓶颈。
二、框架简介
在 2016 年，咱们反对应用资源配置、文件配置的形式，为作业设置一些资源。过后作业以 DataStream 作业和 TableApi 作业为主。
咱们通过提前预编译的形式，将每个节点的初始资源配置进行输入。让用户依据这份初始的资源配置，进行批改。而后，在提交作业运行时，通过参数，带上这份最新的配置，就能够让这份新配置失效。然而，因为作业资源寄存在文件当中，咱们很难将须要批改的节点，和理论应用运行的节点，建设起对应的关系。
对于大作业来说，它们的资源文件过于简单。比方我须要调节 50 个节点中某个 AGG 的算子，然而该作业中 AGG 算子一共有四、五个。很难确认哪一个 AGG 算子，才是咱们须要调整的那个算子。
因而，在 2017 年咱们对其进行了改良，反对了可视化的配置。用户能够通过可视化的拓扑图，来批改指定的节点资源。它的益处是，映射关系会更加的清晰，用户批改起来会更加的简略不便。
随着 SQL 作业的广泛应用，在这个版本里咱们也减少了对 SQL 作业的调优反对，来补救社区不反对细粒度设置 SQL 作业每个算子资源配置的有余。但这个版本依然存在一些问题，比方大作业的拓扑图依然很简单，用户定位工作瓶颈时，须要屡次运行作业，一直地重试调节可能有问题的节点。
在 2018 年，咱们反对了半自动配置 AutoConf。它的特点是，可能联合作业的历史运行状况，通过一系列的算法，计算出此次启动时，须要多少举荐资源。然而它的毛病也很显著，针对无历史运行记录的作业，第一份配置通常是比拟激进的，须要用户通过多轮迭代启停能力最终确定一份比拟正当的资源配置。
在 2019 年，咱们反对了全自动的配置 AutoScale。它可能在作业运行时动静自适应的批改资源配置。这个版本根本不须要用户干涉，它可能很好的反对改并存、改内存等批改资源配置的能力。但这个版本仍然存在一些问题，因为 AutoScale 是运行在 JM 外部的，因而人造不反对一些相似动静启停、查看运行历史记录等等的运维需要，在 JM 异样时，调优也无奈持续工作，同时也不反对批改拓扑等策略，版本升级比拟依赖 Flink 本身的版本。
在 2020 年，推出了独立部署的调优服务 Autopilot。相比于它的前身，Autopilot 的调优服务会更加易用。用户能够在界面手动看到的调优历史，明确的晓得 Autopilot 依据作业的哪些状况，做过哪些调整。整个流程对用户更加透明化。即便没有开启 Autopilot，也能够为每个用户的作业，提供一些辅助的调用信息，给用户手工调优带来肯定的帮忙。
在 Autopilot 中，咱们反对了更加丰盛的调优策略，例如 JM 的资源优化，动静拆迁 chain 优化作业等。
Autopilot 调优次要调节的资源配置分为以下两种，别离是根底模式和专家模式。
在根底模式中，用户能够对立配置 TM 的 CPU 和内存，以及作业并发度。对于所有算子而言，这些资源都是同构的，TM 数量取决于每个 TM 中，能够有多少的 Slot。根底模式的特点是，配置简略，适宜每个节点资源差别比拟小的作业。
在专家模式中，用户能够独自配置每个算子所须要的 CPU、内存、并发等等，高度定制化，各个算子的资源是异构的。应用专家模式能够更好的进步资源的利用率，满足作业高吞吐的需要，节俭资源。适宜每一个节点资源差别比拟大的作业。
Autopilot 主动调优框架，次要有以下几个特点。
首先，它反对多个类型的 Flink 作业，Flink SQL 作业、DataStream 作业和 Python 作业，都能够应用 Autopilot 的调优能力。
其次，它反对多种运行模式。
在半自动模式下，咱们反对定时调优，让用户指定不同的时间段，抉择不同的资源配置运行。适宜一些突出的流量顶峰场景和低谷场景。
在全自动的模式下，咱们细分了资源剖析模式和主动调优模式。在资源剖析模式下，Autopilot 仅给出倡议，不会主动重启作业，适宜一些不能启停作业的敏感时期，比方大促期间。主动调优模式将依据流量的变动，自适应的扭转作业的资源构造，最大水平的帮用户解决老本问题，比拟适宜日常的作业运行。
Autopilot 调优的基本思路如下。
首先，咱们会从 Flink 上采集以后作业的 Metrics，也会从一些其余的诊断系统，拿到一些作业的运行指标，进行剖析。
而后，通过这些原始的指标剖析，失去一些复合型指标。通过所有的指标生成多个带有资源配置优化计划的调优打算。在执行打算时，从泛滥的资源配置计划中，抉择一份最紧急的或最优的计划，更新作业配置。
在更新作业配置时，会优先查看调优打算是不是满足热更新的要求。如果满足热更新要求，会调用 JM 的 Rest 接口更新作业。如果不满足条件，会用 backup 计划，让作业管理平台启停作业。
在采集剖析 Metric 阶段，除了应用原始的 Metric 信息，例如 CPU 利用率，Slot 利用率，内存利用率，Source 的提早等等，也会生成复合型 Metric。比方以后提早是不是能够 catch up，以后数据的歪斜水平是不是很重大等等，从而生成不同资源配置的调优打算。
常见的调优打算分为以下几种：拆 chain、进步 / 缩小并发度、进步 / 缩小内存、增加 Flink conf 等等。最终，从多项调优打算中，抉择一份最佳的打算执行。
目前，Autopilot 反对两种更新作业的形式。
- 热更新作业配置，它的益处是处理速度更快，重启的老本更低，但目前仅仅反对调节并发度。
- 调用治理平台，重启作业的 API。它的益处是能够反对所有的调优场景，来做一个最终的 backup。
如上图所示，是作业平台启停流程和作业热更新流程。咱们以批改并发度为例，在作业平台启停流程时，咱们须要将原作业进行，而后提交新的作业。期待新的作业在 K8s 等平台上重新部署和运行。在整个流程中，作业断流的工夫较长，批改带来的代价会比拟高。
右图是作业热更新流程。咱们通过 Rest 接管一份更新申请。而后，在 Job Master 里，基于以后作业批改生成新的作业，而后再进行老的作业，最终部署一份新的作业。相较于作业平台，热更新节俭了启动初始化 Master 节点的工夫，比作业平台启停，起停的老本更低。
上图是 100 并发度作业扩缩容断流工夫比照，在扩容到 150 并发度时，作业平台启动须要破费 40 秒左右，热更新重启只须要 1.5 秒左右。
在缩容到 50 并发度时，作为平台重启须要 30 秒左右，热更新重启仅须要破费 0.4 秒。
从这张图能够看到，热更新重启比调优作业平台重启，在重启工夫上有更加显著的劣势。从而可能最大限度的升高用户作业断流的危险，缩小批改资源配置的老本。
潮汐流量是指流量的顶峰和低谷，时间段具备周期性和可预见性。以电商平台每年的双十一流动为例，双十一时的配置和平时闲时的配置差别比拟大。直播平台白天的配置，和早晨的配置差别也比拟大。在这种流量顶峰低谷的时间段比拟显著，并且时间段比拟固定的场景，利用定时策略会更加的简略高效。
定时策略次要针对主动调优无奈笼罩的场景。在利用主动调优时，如果流量频繁抖动的化，最终会导致作业一直进行调用，从而使作业一直重启。
在流量变动比较慢的时候，因为作业在一段时间内，Autopilot 只感知到以后最高的流量。因而，可能会呈现无奈一次调优到位的状况，须要通过很屡次迭代才会达到比拟好的成果。
定时策略就是为了解决以上问题。它可能容许用户针对作业的业务特点，设置作业的最佳资源状态。在流量抖动比拟频繁时，不会重启作业。当用户有一份流量在顶峰或低谷时须要用多少资源配置的先验常识时，可能用定时调优一次性的将作业调到一个比拟好的状态，也可能避开一些作业的敏感时期。
上图是定时调优的基本思路。Autopilot 在外部保护了多个资源配置的日历，当某个工夫点须要触发定时策略，会选用该工夫点的资源配置，更新作业配置。
这里的更新同样能够分为热更新和作业管理平台进行重启。Autopilot 也会主动查看新增或更新的定时策略工夫是否和已有的定时策略工夫抵触。
三、案例介绍
上图是作业 Slot 解决能力达到瓶颈的案例，能够看到在左图左边的节点上，该节点每个值都很高，基本上达到了百分百，表明以后 Slot 的利用率很高。如果作业长时间处于这种状态，会引起 Failover，影响作业的稳定性。后面的算子曾经被该算子反压，导致延时会一直减少。
为了解决这个问题，Autopilot 将该算子的并发进步到 320。批改之后，呈现了右图所示的状况，该算子的 Slot 利用率，升高到比拟失常的水准。
上图是一个 TM 内存使用率过低的案例，能够看到用户在一开始申请了 4G 内存，但在理论作业中，TM 只应用了 1G 左右，造成了内存节约。作业老本较高，白白破费了 3G 内存的钱。
Autopilot 辨认到这种状况，将 TM 内存从 4G 升高到 1.6G，帮忙用户升高了作业老本。之所以降到了 1.6G, 是因为 Flink 侧有最低内存设定的限度。如果调优太低，会导致作业间接起不来。
上图是一个业务流量周期变动的案例，能够看到，左上角作业的 TPS 有一个先高、后低、再高的过程。上面局部是，Autopilot 辨认到流量变动，主动调整了作业的并发度。
在流量低谷时，升高了整体并发度，因而须要的数量大大降低。在流量顶峰时，呈现提早，从新进行扩容，保障高流量下作业的安稳运行。最终实现资源的弹性扩缩容，无效升高了资源的应用，节约老本的同时，进步了作业的稳定性。
上图是大促之后主动升高资源，节约老本的案例。在大促期间，作业个别会应用比拟高额的资源。个别状况下，用户无奈晓得大促的流量什么时候完结，什么时候须要将作业资源配置，切换到较低的闲时状态。
如果咱们切换的较早，会导致预判流量失误，造成较大的流量冲击作业，导致作业不稳固。如果切换较晚，会节约适量的资源。Autopilot 辅助业务方在大促完结后，依据流量来安稳、并且疾速升高作业应用的资源，节约老本。
上图是一个设定不同时间段的定时策略案例。咱们能够设定早上 9 点到早晨 7 点，为业务的高峰期。在这段高峰期中，应用 30 并发度。在早晨 7 点到早上 9 点，为业务的低谷期，在这期间用 10 并发度。图中是具体设置资源和设置资源时间段的示意图。
四、将来布局
将来，Autopilot 的次要指标是，进一步帮忙用户降本增效。Autopilot 将从三个角度一直致力。
首先，咱们将致力于进步 Autopilot 的易用性，不便用户应用。咱们将反对插件化的能力，容许用户自定义一些调优能力。比方本人排列组合一些 Metric，设定一些调优策略，来满足本身业务的须要。加强内部集成的能力，开发提供 SDK 和 Open API 接口。
其次，咱们将让 Autopilot 更加智能、更加业余。一个方向是，摸索机器学习的一些策略，依附当初成熟的机器学习算法，提前进行流量预测，并发预测等工作。另一个方向是，联合集群信息和上游依赖作业信息，进行调优。比方在流量顶峰时，在上游的作业被主动调优的同时，上游被依赖的作业也能够趁势进行肯定的主动调优。
最初，Autopilot 的稳定性是咱们一直致力的方向。一方面，咱们会继续的增强热更新的能力，让更多的调优打算反对热更新，减小重启带来的断流等较高的调优老本问题。另一方面，让 Autopilot 笼罩更多的场景来满足不同的作业 Pattern，让其更加全面，比如说 SQL 的写法自身就有问题，UDF 实现形式有问题，有较大的内部 IO、源表 Partition 数导致无奈进一步调高并发度，维表或后果表性能不行等等的诸多问题。
点击查看原文视频 & 演讲 PPT
更多内容
流动举荐
阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
0 元试用 实时计算 Flink 版（5000CU* 小时，3 个月内）
理解流动详情：https://free.aliyun.com/?pipCode=sc