共计 4318 个字符，预计需要花费 11 分钟才能阅读完成。
摘要：本文整顿自阿里云高级技术专家朱翥，在 FFA 核心技术专场的分享。本篇内容是对于在过来的一年中，Apache Flink 对运行时的作业执行管控进行的一些改良。
这些改良，让 Flink 能够更好的利用运行时的信息，来灵便的管制作业的执行，从而使得 Flink 批处理作业的执行能够更加的稳固、更有效率，并且更容易运维。
具体内容次要分为两个局部：
- 自适应执行打算
- 同源实例的并行执行
点击查看直播回放 & 演讲 PPT
一、自适应执行打算
咱们先看一下，Flink 是如何形容作业的执行打算的。以这个 DataStream 作业为例，Flink 会基于它学生成一个 StreamGraph。这是一个有向无环图，图中的节点对应着计算逻辑，图中的边则对应着数据的散发形式。
Flink 会依据节点的并行度以及他们之间的连边形式，把一些计算节点进行链接合并，最终造成 JobGraph，从而升高计算节点间的数据传输开销。这个操作的目标是，是为了升高计算节点之间的数据传输开销。StreamGraph 和 JobGraph 都是在编译阶段生成的。JobGraph 会提交给 Flink Job Manager，从而启动和执行作业。
在执行作业前，Flink 会生成 ExecutionGraph。这个 ExecutionGraph 是依据 JobGraph 中的节点并行度，开展生成的。咱们晓得，Flink 是一个分布式计算框架。而 ExecutionGraph 的每一个节点，都对应着一个须要部署到 TaskManager 上进行执行的工作，每一条边都对应着工作的输出和输入。所以说，它是作业的物理执行打算。
这个物理执行打算，形容了工作的计算逻辑、所需资源和并行度，同时也形容工作产出数据的划分形式，此外还形容了工作对数据的依赖关系以及数据传输方式。
通过它，Flink 就能晓得如何创立和调度作业的所有工作，从而实现作业的执行。
然而，如后面所说，它是在作业运行前就曾经确定的，是动态的。而 Flink 难以在作业执行前，预判什么样的打算参数更正当。所以，这些执行打算参数，只能依赖用户提前指定，也就是须要手动调优。
然而，对于批作业，因为其分阶段执行的个性，在执行一个阶段前，实践上 Flink 是能够取得很多有用的信息的，比方其生产的数据量大小、这些数据的分布模式、以后的可用资源等等。
基于这些信息，咱们能够让 Flink 对执行打算动静的进行调优，从而取得更好的执行效率。并且，因为 Flink 能够主动的进行这些调优，也能够让用户从手动调优中解放出来。
这就是 Flink 批处理作业的自适应执行打算。
为了反对自适应执行打算，最外围的一点，是须要一个能够动静调整的执行拓扑。所以，咱们革新了 ExecutionGraph，使其反对渐进式构建。
具体的来说，就是让 ExecutionGraph 一开始只蕴含 Source 节点，随着执行的推动，再逐步的退出后续的节点和连边。
这样，Flink 就有机会对尚未退出的执行节点和连边进行调整。
但在这个中央，咱们遭逢了一个妨碍。因为在原来的作业执行中，上游节点执行是依赖于上游节点的并行度的。具体来说，是因为上游在产出数据时，会依据上游并行度，对数据进行划分（sub-partition）；这样，每个上游工作就能够间接生产其对应的那一个数据分区。然而，在动静执行打算的场景下，上游节点的并行度是不确定的。
为了解决这个问题，咱们革新了节点数据的划分逻辑，使其不再依据上游节点的并行度，而是依据其最大并行度进行划分。同时，咱们也革新了节点生产数据的逻辑，使其不再只生产繁多分区，而是能够生产一组间断的数据分区（sub-partition range）。
通过这样的形式，上游节点执行得以和上游节点的并行度解耦，动静执行拓扑也得以实现。
在反对了动静执行拓扑后，咱们引入了 Adaptive Batch Scheduler 来反对自适应执行打算。
与原有调度器不同的中央在于，Adaptive Batch Scheduler 会基于动静执行拓扑进行作业管控，继续收集运行时的信息，定制后续的执行打算。Flink 会基于执行打算，动静生成执行节点和连边，以此来更新执行拓扑。
在上述框架下，咱们为 Flink 减少了主动决定并行度的能力。用户只须要配置心愿单个执行节点解决的数据量，Flink 就能够依据该阶段须要解决的数据量，主动推导该阶段的节点并行度。
相比起传统的为每个作业独自配置并行度，主动决定并行度有这些长处：一是配置简略，无需为每个作业独自配置，一项配置能够实用于很多作业；二是能够主动的适配每天变动的数据量，当数据量较大时，作业并行度能够大一些，从而保障作业的产出工夫；三是能够细粒度的调整作业的并行度，进步资源利用率。
然而主动决定并行度，数据可能散布不均。为了解决这个问题，咱们在主动决定并行度的根底上，进行了主动平衡下发数据的改良。
这个改良会采集 sub-partition 粒度的数据量，并以此来决定执行节点的并行度，以及每个执行节点应该生产哪些分区数据。从而尽可能让上游各执行节点生产的数据，靠近用户配置的预期值。
相比起主动决定并行度，这样的形式岂但让上游数据量更平衡，而且可能缓解数据歪斜的影响。这个性能正在开发中，会随着 Flink 1.17 公布。
以上就是咱们以后曾经或是行将在 Flink 中实现的自适应执行打算的改良。
不过，自适应执行打算还有更大的改良空间，比方依据 join 算子理论生产的数据量，动静决定应该用 hash join 还是 broadcast join；反对选择性执行工作，在满足特定条件下，为作业退出额定的执行分支；在 Sink 输入后果达标时提前结束作业。
此外，咱们也在思考 SQL 的动静优化能力。
以后，SQL 的查问优化是在作业编译时进行的；其只能通过 Source 的 Meta 信息，对数据量进行估算，容易导致优化后果不精确。如果能够向 SQL planner 反馈运行时信息，来动静的优化执行打算，就能够失去更好的执行成果。
二、同源实例的并行执行
接下来，讲一讲同源实例的并行执行。
同源实例是指，属于同一个执行节点的执行实例。执行拓扑是由执行节点组成，各节点会创立执行实例，将其部署到 TaskManager 上进行执行。
以后，每个执行节点在某一时刻只能有一个执行实例，只有当该实例失败 (或被勾销) 后，节点才会创立一个新的执行实例。这也意味着，同源执行实例只能串行执行。
驱动咱们更改这一现状的，是来自预测执行的需要。
在生产中，热点机器是无奈防止的，混部集群、密集回刷，都可能导致一台机器的负载高、IO 忙碌。其上执行的数据处理工作可能异样迟缓，导致批作业产出工夫难以失去保障。
预测执行，是一种曾经失去广泛的认可、用来解决这类问题的办法。
其基本思路是，为热点机器上的慢工作创立新的执行实例，并部署在失常的机器节点上。这些预测执行实例和对应的原始实例，具备雷同的输出和产出。其中，最先实现的实例会被抵赖，其余相应实例会被勾销。
因而，为了反对预测执行，Flink 必须反对多个同源实例并行执行。为了反对同源实例并行执行，咱们进行了下列改良。
首先，咱们从新梳理了执行节点的状态。
以后，执行节点的状态和其以后惟一执行实例是一一对应的。然而，如果一个节点能够同时存在多个执行实例，这样的映射形式就会呈现问题。
为此，咱们从新定义了执行节点与执行实例的状态映射，取执行实例中最靠近 FINISH 状态的状态作为执行节点的状态。这样既能够兼容单执行实例场景，也能反对多个同源实例并行执行的场景。
其次，咱们保障了 Source 的同源执行实例，总是会读取到雷同的数据。
大体上来说，就是咱们在框架层为每个 Source 执行节点减少一个列表，来保护调配给它的数据分片。该节点的所有执行实例都会共享这一个列表，只是会各自保护一个不同的下标，来记录其解决到的数据分片进度。
这样的改变的益处是，大部分现有 Source 不须要额定的批改，就能够进行预测执行。只有当 Source 应用了自定义事件的状况下，它们才须要实现一个额定的接口，用以保障各个事件能够被分发给正确的执行实例。
在接下来的 Flink 1.17 中，咱们也会反对 Sink 的同源执行实例并行执行。
其关键点在于防止不同 Sink 之间的执行抵触，特地是要防止因而产生的数据不统一，因为 Sink 是须要向内部零碎进行写入的。
因为 Sink 的写入逻辑暗藏在各个 Sink 的实现中，咱们无奈像 Source 一样在框架层对立防止写入抵触。所以咱们向 Sink 层裸露了执行实例标识（attemptNumber），使 Sink 能够自行防止抵触。
同时为了平安起见，咱们默认不会容许 Sink 的同源执行实例并行执行，除非 Sink 显式申明反对同源执行实例并行执行。
在此基础上，咱们为 Flink 引入了预测执行机制。次要包含三个外围组件。
首先是慢工作检测器。它会定期进行检测，综合工作解决的数据量，以及其执行时长，评判工作是否是慢工作。当发现慢工作时，它会告诉给批处理调度器。
其次是批处理调度器。在收到慢工作告诉时，它会告诉黑名单处理器，对慢工作所在的机器进行加黑。并且，只有慢工作同源执行的实例数量，没有超过用户配置下限，它会为其拉起并部署新的执行实例。当任意执行实例胜利实现时，调度器会勾销掉其余的同源执行实例。
最初是黑名单处理器。Flink 能够利用其加黑机器。当机器节点被加黑后，后续的工作不会被部署到该机器。为了反对预测执行，咱们反对了软加黑的形式，即加黑机器上曾经存在的工作，能够继续执行而不会因为加黑被勾销掉。
除此之外，工作人员对外部 UI 进行改良，不便展现以后运行中的所有同源执行实例，用户能够更好的判断预测执行的执行后果。
此外，咱们对 WebUI 也进行了改良，使其可能展现以后运行中，或是作业完结时的所有同源执行实例，用户能够更好的判断预测执行的执行后果。此外，UI 也能展现被加黑的 Slot 和 TaskManager。
须要阐明的是，尽管出发点是反对批作业的预测执行。同源执行实例的并行执行，也为流作业的工作平滑迁徙提供了可能。
当流作业有工作落在慢机器上时，咱们也可能先为其事后拉起一个同源执行实例，待该实例的部署和初始化实现后，通过间接切换数据连边，能够达成低断流的工作迁徙。配合慢工作检测、黑名单等能力，咱们甚至能让 Flink 主动的进行慢工作迁徙。
点击查看直播回放 & 演讲 PPT
更多内容
流动举荐
阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
99 元试用 实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/produc…
