Flink资源调度模型

作者：王刚，腾讯CSIG高级工程师

Flink 资源模型 / 调度设计

背景知识

首先，我们来简单回顾一下 Flink 作业的运行时模型，然后再来探讨在这种运行模型下，Flink 的资源模型和调度架构的设计和实现。

我们引用官网非常经典的一张图，来说明一个 Flink 流作业简化后的运行视图。

Tasks 和 Operator Chains （部分译自官网）

我们知道，一个 Flink 作业可以看做是由 Operators 组成的 DAG，一个 Operator 代表对数据流的进行的某个数据变化操作（ Sources 和 Sinks 也是代表数据流流入和数据流流出的特殊Operator ）。在实际的分布式运行中，Flink 会把符合聚合规则的相邻 Operator 的 SubTask 聚合成 Tasks，每一个 Task 都会被单独的线程执行。这种把多个 Operator 的 SubTask 聚合成 Tasks 优化通常非常有效：能有效减少线程间切换（相比单独的每个operator的每个subtask占用一个线程）、数据缓存的成本，从而在降低数据处理延迟的同时增加系统的吞吐。

下图代表了数据流在 Operator Chain 之后，会实际产生 5 个 SubTask，相应的需要 5 个并发线程来处理该数据流。

在此，我们简要的区分下 Task 和 SubTask 的异同:

Task	Task 是 Flink Runtime 的运行的基本单元，Task 封装了一个 Operator 或 Operator Chain 的某一并行实例
SubTask	一个 SubTask 是负责处理某一数据流的一部分的 Task，SubTask 术语强调对于同一个 Operator 或 Operator Chain 这里有多个并行的 Tasks。

所以，一个 Flink 的作业，最终会转化为一个个 Task 在集群上运行。我们接下来从 Task 运行维度分析，一层层来看 Flink 的资源模型设计。

资源模型

首先，我们介绍 Flink 基本的几个运行时概念。

Flink Job：

Flink程序提交到Flink Cluster运行后，会生成一个或者多个Flink jobs。根据上文的介绍，我们知道一个Flink job其实是数据流变换的运行时抽象