【Flink-1.17-教程】-【三】Flink 运行架构、Flink 核心概念【并行度、算子链、任务槽】、Flink 作业提交流程

1）系统架构

1.1.系统成员组成

1、作业管理器（JobManager）

JobManager 是一个 Flink 集群中任务管理和调度的核心，是控制应用执行的主进程。也就是说，每个应用都应该被唯一的 JobManager 所控制执行。JobManger 又包含 3 个不同的组件。

（1）JobMaster

JobMaster 是 JobManager 中最核心的组件，负责处理单独的作业（Job）。所以 JobMaster和具体的 Job 是一一对应的，多个 Job 可以同时运行在一个 Flink 集群中, 每个 Job 都有一个自己的 JobMaster。需要注意在早期版本的 Flink 中，没有 JobMaster 的概念；而 JobManager的概念范围较小，实际指的就是现在所说的 JobMaster。

在作业提交时，JobMaster 会先接收到要执行的应用。JobMaster 会把 JobGraph 转换成一个物理层面的数据流图，这个图被叫作“执行图”（ExecutionGraph），它包含了所有可以并发执行的任务。JobMaster 会向资源管理器（ResourceManager）发出请求，申请执行任务必要的资源。一旦它获取到了足够的资源，就会将执行图分发到真正运行它们的 TaskManager上。

而在运行过程中 ， JobMaster 会负责所有需要中央协调的操作 ， 比如说检查点（checkpoints）的协调。

（2）资源管理器（ResourceManager）

ResourceManager 主要负责资源的分配和管理，在 Flink 集群中只有一个。所谓“资源”，主要是指 TaskManager 的任务槽（task slots）。任务槽就是 Flink 集群中的资源调配单元，包含了机器用来执行计算的一组 CPU 和内存资源。每一个任务（Task）都需要分配到一个 slot上执行。

这里注意要把 Flink 内置的 ResourceManager 和其他资源管理平台（比如 YARN）的ResourceManager 区分开。

（3）分发器（Dispatcher）

Dispatcher 主要负责提供一个 REST 接口，用来提交应用，并且负责为每一个新提交的作业启动一个新的 JobMaster 组件。Dispatcher 也会启动一个 Web UI，用来方便地展示和监控作业执行的信息。Dispatcher 在架构中并不是必需的，在不同的部署模式下可能会被忽略掉。

2、任务管理器（TaskManager）

TaskManager 是 Flink 中的工作进程，数据流的具体计算就是它来做的。Flink 集群中必须至少有一个 TaskManager；每一个 TaskManager 都包含了一定数量的任务槽（task slots）。

Slot 是资源调度的最小单位，slot 的数量限制了 TaskManager 能够并行处理的任务数量。

启动之后，TaskManager 会向资源管理器注册它的 slots；收到资源管理器的指令后，TaskManager 就会将一个或者多个槽位提供给 JobMaster 调用，JobMaster 就可以分配任务来执行了。

在执行过程中，TaskManager 可以缓冲数据，还可以跟其他运行同一应用的 TaskManager
交换数据。

1.2.作业提交流程

1、提交 job，执行运行程序的脚本（flink run）后，会生启动一个客户端进程。

2、客户端进程中会解析一些参数，如：-c（全类名）

3、对解析完成的参数进行封装，然后通过内部的 Actor 通信系统（基于 RPC）提交、或取消（flink cancel）、或更新，将任务发送给 JobManager。

4、JobManager 自身也会有一个 Actor 通信系统，通过 Actor 通信系统拿到任务后。

5、分发器启动，并提交具体应用给作业管理者 JobMaster（JobManager 是进程，JobMaster 是线程）。

6、JobMaster 根据作业参数情况向资源管理器请求资源（slot）。

7、资源管理器通过 Actor 通信系统，向 TaskManager 申请资源（task slot）

8、TaskManager 提供资源（task slot）给到 JobMaster，也就是通知 JobMaster 可以提供任务给 TaskManager 了。

9、JobMaster 将任务分发到各个 task slot 中，开始执行任务。

10、JobManager 将状态更新、计算结果返回给客户端。

注意：一个 job 对应一个 JobMaster（多线程），分发器和资源管理器只有一个。

2）核心概念

2.1. 并行度（Parallelism）

2.1.1.并行子任务和并行度

当要处理的数据量非常大时，我们可以把一个算子操作，“复制”多份到多个节点，数据来了之后就可以到其中任意一个执行。这样一来，一个算子任务就被拆分成了多个并行的“子任务”（subtasks），再将它们分发到不同节点，就真正实现了并行计算。

在 Flink 执行过程中，每一个算子（operator）可以包含一个或多个子任务（operatorsubtask），这些子任务在不同的线程、不同的物理机或不同的容器中完全独立地执行。

一个特定算子的子任务（subtask）的个数被称之为其并行度（parallelism）。这样，包含并行子任务的数据流，就是并行数据流，它需要多个分区（stream partition）来分配并行任务。一般情况下，一个流程序的并行度，可以认为就是其所有算子中最大的并行度。一个程序中，不同的算子可能具有不同的并行度。

例如：如上图所示，当前数据流中有 source、map、window、sink 四个算子，其中 sink算子的并行度为 1，其他算子的并行度都为 2。所以这段流处理程序的并行度就是 2。

2.1.2.并行度的设置

在 Flink 中，可以用不同的方法来设置并行度，它们的有效范围和优先级别也是不同的。

算子 > env > 提交时指定 > 默认配置文件

1、代码中设置

我们在代码中，可以很简单地在算子后跟着调用 setParallelism()方法，来设置当前算子的并行度：

stream.map(word -> Tuple2.of(word, 1L)).setParallelism(2);

这种方式设置的并行度，只针对当前算子有效。

另外，我们也可以直接调用执行环境的 setParallelism()方法，全局设定并行度：

env.setParallelism(2);

这样代码中所有算子，默认的并行度就都为 2 了。我们一般不会在程序中设置全局并行度，因为如果在程序中对全局并行度进行硬编码，会导致无法动态扩容。

这里要注意的是，由于 keyBy 不是算子，所以无法对 keyBy 设置并行度。

2、提交应用时设置

在使用 flink run 命令提交应用时，可以增加-p 参数来指定当前应用程序执行的并行度，它的作用类似于执行环境的全局设置：

bin/flink run –p 2 –c com.atguigu.wc.SocketStreamWordCount ./FlinkTutorial-1.0-SNAPSHOT.jar

如果我们直接在 Web UI 上提交作业，也可以在对应输入框中直接添加并行度。

3、配置文件中设置

我们还可以直接在集群的配置文件 flink-conf.yaml 中直接更改默认并行度：

parallelism.default: 2

这个设置对于整个集群上提交的所有作业有效，初始值为 1。无论在代码中设置、还是提交时的-p 参数，都不是必须的；所以在没有指定并行度的时候，就会采用配置文件中的集群默认并行度。在开发环境中，没有配置文件，默认并行度就是当前机器的 CPU 核心数。

2.2. 算子链（Operator Chain）

2.1.1.算子间的数据传输

一个数据流在算子之间传输数据的形式可以是一对一（one-to-one）的直通（forwarding）模式，也可以是打乱的重分区（redistributing）模式，具体是哪一种形式，取决于算子的种类。

（1）一对一（One-to-one，forwarding）

这种模式下，数据流维护着分区以及元素的顺序。比如图中的 source 和 map 算子，source 算子读取数据之后，可以直接发送给 map 算子做处理，它们之间不需要重新分区，也不需要调整数据的顺序。这就意味着 map 算子的子任务，看到的元素个数和顺序跟 source 算子的子任务产生的完全一样，保证着 “ 一对一 ” 的关系。map、filter、flatMap 等算子都是这种 one-to-one 的对应关系。这种关系类似于 Spark 中的窄依赖。

（2）重分区（Redistributing）

在这种模式下，数据流的分区会发生改变。比如图中的 map 和后面的 keyBy/window 算子之间，以及 keyBy/window 算子和 Sink 算子之间，都是这样的关系。每一个算子的子任务，会根据数据传输的策略，把数据发送到不同的下游目标任务。这些传输方式都会引起重分区的过程，这一过程类似于 Spark 中的 shuffle。

2.1.2.合并算子链

在 Flink 中，并行度相同的一对一（one to one）算子操作，可以直接链接在一起形成一个“大”的任务（task），这样原来的算子就成为了真正任务里的一部分，如下图所示。每个 task 会被一个线程执行。这样的技术被称为“算子链”（Operator Chain）

上图中 Source 和 map 之间满足了算子链的要求，所以可以直接合并在一起，形成了一个任务；因为并行度为 2，所以合并后的任务也有两个并行子任务。这样，这个数据流图所表示的作业最终会有 5 个任务，由 5 个线程并行执行。

将算子链接成 task 是非常有效的优化：可以减少线程之间的切换和基于缓存区的数据交换，在减少时延的同时提升吞吐量。

Flink 默认会按照算子链的原则进行链接合并，如果我们想要禁止合并或者自行定义，也可以在代码中对算子做一些特定的设置：

// 禁用算子链
.map(word -> Tuple2.of(word, 1L)).disableChaining();
// 从当前算子开始新链
.map(word -> Tuple2.of(word, 1L)).startNewChain()

2.2.3.总结

1、算子之间的传输关系：

（1）一对一

（2）重分区

2、算子串在一起的条件：

（1）一对一

（2）并行度相同

3、关于算子链的 api：

（1）全局禁用算子链：env.disableOperatorChaining();

（2）某个算子不参与链化： 算子A.disableChaining()，算子A不会与 前面 和 后面的 算子 串在一起

（3）从某个算子开启新链条：算子A.startNewChain()，算子A不与前面串在一起，从A开始正常链化

注意：

① 如果两个可以形成 one-to-one 的算子的计算重量非常庞大，那么可以禁用算子链，让两个算子单独进行处理。

② 调试阶段可以禁用算子链，方便查看哪个步骤有问题。

2.3.任务槽（Task Slots）

2.3.1.任务槽（Task Slots）

Flink 中每一个 TaskManager 都是一个 JVM 进程，它可以启动多个独立的线程，来并行执行多个子任务（subtask）。

很显然，TaskManager 的计算资源是有限的，并行的任务越多，每个线程的资源就会越少。那一个 TaskManager 到底能并行处理多少个任务呢？为了控制并发量，我们需要在 TaskManager 上对每个任务运行所占用的资源做出明确的划分，这就是所谓的任务槽（task slots）。

每个任务槽（task slot）其实表示了 TaskManager 拥有计算资源的一个固定大小的子集。这些资源就是用来独立执行一个子任务的。

2.3.2.任务槽数量的设置

在 Flink 的 /opt/module/flink-1.17.0/conf/flink-conf.yaml 配置文件中 ， 可以设置 TaskManager 的 slot 数量，默认是 1 个 slot。

taskmanager.numberOfTaskSlots: 8

需要注意的是，slot 目前仅仅用来隔离内存，不会涉及 CPU 的隔离。在具体应用时，可以将 slot 数量配置为机器的 CPU 核心数，尽量避免不同任务之间对 CPU 的竞争。这也是开发环境默认并行度设为机器 CPU 数量的原因。

在开启并行度和 slot 的情况下，同一个算子的子任务，不会分配在一个 slot 中。

2.3.3.任务对任务槽的共享

默认情况下，Flink 是允许子任务共享 slot 的。如果我们保持 sink 任务并行度为 1 不变，而作业提交时设置全局并行度为 6，那么前两个任务节点就会各自有 6 个并行子任务，整个流处理程序则有 13 个子任务。如上图所示，只要属于同一个作业，那么对于不同任务节点（算子）的并行子任务，就可以放到同一个 slot 上执行。所以对于第一个任务节点 source→map，它的 6 个并行子任务必须分到不同的 slot 上，而第二个任务节点 keyBy/window/apply的并行子任务却可以和第一个任务节点共享 slot。

当我们将资源密集型和非密集型的任务同时放到一个 slot 中，它们就可以自行分配对资源占用的比例，从而保证最重的活平均分配给所有的 TaskManager。slot 共享另一个好处就是允许我们保存完整的作业管道。这样一来，即使某个TaskManager 出现故障宕机，其他节点也可以完全不受影响，作业的任务可以继续执行。

当然，Flink 默认是允许 slot 共享的，如果希望某个算子对应的任务完全独占一个 slot，或者只有某一部分算子共享 slot，我们也可以通过设置 “ slot 共享组 ” 手动指定：

.map(word -> Tuple2.of(word, 1L)).slotSharingGroup("1");

这样，只有属于同一个 slot 共享组的子任务，才会开启 slot 共享；不同组之间的任务是完全隔离的，必须分配到不同的 slot 上。在这种场景下，总共需要的 slot 数量，就是各个 slot 共享组最大并行度的总和。

2.3.4.任务槽和并行度的关系

1、任务槽和并行度都跟程序的并行执行有关，但两者是完全不同的概念。简单来说任务槽是静态的概念 ，是指 TaskManager 具有的并发执行能力 ， 可以通过参数 taskmanager.numberOfTaskSlots 进行配置；

2、而并行度是动态概念，也就是 TaskManager 运行程序时实际使用的并发能力，可以通过参数 parallelism.default 进行配置。

举例说明：
假设一共有 3 个 TaskManager，每一个 TaskManager 中的 slot 数量设置为 3 个，那么一共有 9 个 task slot，表示集群最多能并行执行 9 个同一算子的子任务。

而我们定义 word count 程序的处理操作是四个转换算子：source → flatmap → reduce → sink，当所有算子并行度相同时，容易看出 source 和 flatmap 可以合并算子链，于是最终有三个任务节点。

通过这个例子也可以明确地看到，整个流处理程序的并行度，就应该是所有算子并行度中最大的那个，这代表了运行程序需要的 slot 数量。

2.3.5.总结

1、slot 特点

（1）均分隔离内存，不隔离cpu

（2）可以共享：同一个job中，不同算子的子任务才可以共享同一个 slot，同时在运行的前提是，属于同一个 slot 共享组，默认都是 “ default ”

2、slot 数量与并行度的关系

（1）slot 是一种静态的概念，表示最大的并发上限；并行度是一种动态的概念，表示实际运行占用了几个 slot。

（2）要求： slot 数量 >= job 并行度（算子最大并行度），job 才能运行。

否则报错信息如下：

注意：

① 如果是 yarn 模式，动态申请 slot 的数量。

② session 模式下申请的 TM 数量 = job 并行度 / 每个 TM 的 slot 数，向上取整

如果并行度为：10, slot 数量为：3
10/3,向上取整，申请4个tm

3）作业提交流程

3.1.Standalone 会话模式作业提交流程

1、提交 job，执行运行程序的脚本（flink run）后，会生启动一个客户端进程。

2、客户端进程中会解析一些参数，如：-c（全类名）

3、生成逻辑流图（StreamGraph），通过 Operator Chain 对算子优化后，生成作业流图（JobGraph）

4、对解析完成的参数进行封装，然后通过内部的 Actor 通信系统（基于 RPC）提交、或取消（flink cancel）、或更新，将任务发送给 JobManager。

5、JobManager 自身也会有一个 Actor 通信系统，通过 Actor 通信系统拿到任务后。

6、分发器启动，拿到任务的同时拿到作业流图（JobGraph），并提交具体应用和作业流图（JobGraph）给作业管理者 JobMaster（JobManager 是进程，JobMaster 是线程）。

7、JobMaster 将作业流图（JobGraph）转换变成执行图（ExecutionGraph），这一过程中会将并行度展开，并根据作业参数情况向资源管理器请求资源（slot）。

8、资源管理器通过 Actor 通信系统，向 TaskManager 申请资源（task slot）

9、TaskManager 提供资源（task slot）给到 JobMaster，也就是通知 JobMaster 可以提供任务给 TaskManager 了。

10、JobMaster 通过执行图将（ExecutionGraph）任务分发到各个 task slot 中，开始执行任务。

11、生成物理流图（PhysicalGraph）（通俗来讲就是任务执行后的效果）

12、JobManager 将状态更新、计算结果返回给客户端。

注意：一个 job 对应一个 JobMaster（多线程），分发器和资源管理器只有一个。

3.2.逻辑流图、作业图、执行图、物理流图

我们已经彻底了解了由代码生成任务的过程，现在来做个梳理总结。

逻辑流图（StreamGraph）→ 作业图（JobGraph）→ 执行图（ExecutionGraph）→ 物理图（Physical Graph）。

1、逻辑流图（StreamGraph）

这是根据用户通过 DataStream API 编写的代码生成的最初的 DAG 图，用来表示程序的拓扑结构。这一步一般在客户端完成。

2、作业图（JobGraph）

StreamGraph 经过优化后生成的就是作业图（JobGraph），这是提交给 JobManager 的数据结构，确定了当前作业中所有任务的划分。主要的优化为：将多个符合条件的节点链接在一起合并成一个任务节点，形成算子链，这样可以减少数据交换的消耗。JobGraph 一般也是在客户端生成的，在作业提交时传递给 JobMaster。我们提交作业之后，打开 Flink 自带的 Web UI，点击作业就能看到对应的作业图。

3、执行图（ExecutionGraph）

JobMaster 收到 JobGraph 后，会根据它来生成执行图（ExecutionGraph）。ExecutionGraph 是 JobGraph 的并行化版本，是调度层最核心的数据结构。与 JobGraph 最大的区别就是按照并行度对并行子任务进行了拆分，并明确了任务间数据传输的方式。

4、物理图（Physical Graph）

JobMaster 生成执行图后，会将它分发给 TaskManager；各个 TaskManager 会根据执行图部署任务，最终的物理执行过程也会形成一张“图”，一般就叫作物理图（Physical Graph）。这只是具体执行层面的图，并不是一个具体的数据结构。物理图主要就是在执行图的基础上，进一步确定数据存放的位置和收发的具体方式。有了物理图，TaskManager 就可以对传递来的数据进行处理计算了。

3.3.Yarn 应用模式作业提交流程

1、flink run-application 提交任务后，直接向 Yarn-ResourceManager 发起请求。

2、选择一个节点（NodeManager），启动容器，容器中会生成 ApplicationMaster（其实就是 JobManager）

3、ApplicationMaster 中依然有三个组件，分别是：分发器、资源管理器、JobMaster。

4、ApplicationMaster 启动分发器，分发器启动 JobMaster，JobMaster 向资源管理器请求资源。

5、JobMaster 解析代码，生成逻辑流图（StreamGraph），将算子链优化后生成作业流图（JobGraph），最后将作业流图（JobGraph）的并行度展开生成执行图（ExecutionGraph）

注意：应用模式不同于之前的模式，之前在客户端做的事情现在交给 JobMaster 来做。

6、JobMaster 向资源管理器请求资源，资源管理器向 Yarn-ResourceManager 申请资源（在此过程中资源管理器类似于中间商）

7、Yarn 选择好 NodeManager 后，在对应节点中启动容器（容器中运行 TM 进程）

8、TaskManager 中会生成容器指定的 slot 和自身的 Actor 通信系统。

9、TaskManager 的 Actor 通信系统向 JobMaster 中的资源管理器注册 slot，资源管理器开始分配 slot 给 TaskManager。

10、TaskManager 收到 slot 资源后，JobMaster 根据执行图（ExecutionGraph）将任务分发出去（走网络通信）

11、任务在 TaskManager 执行后生成物理流图（PhysicalGraph）

注意：一个 job 对应一个 JobMaster（多线程），分发器和资源管理器只有一个。