Flink学习笔记（四）Flink运行时架构

4.Flink运行时架构

4.1系统架构

​ Flink 的运行时架构中，最重要的就是两大组件：作业管理器（JobManger）和任务管理器（TaskManager）。对于一个提交执行的作业，JobManager 是真正意义上的“管理者”（Master），负责管理调度，所以在不考虑高可用的情况下只能有一个；而 TaskManager 是“工作者”（Worker、Slave），负责执行任务处理数据，所以可以有一个或多个。

1.整体构成

Flink 的作业提交和任务处理时的系统如下图所示：

​

2.作业管理器（JobManager）

​ JobManager 是一个 Flink 集群中任务管理和调度的核心，是控制应用执行的主进程。也就是说，每个应用都应该被唯一的 JobManager 所控制执行。在高可用（HA）的场景下，可能会出现多个 JobManager；这时只有一个是正在运行的领导节点（leader），其他都是备用节点（standby）。

JobManger 又包含 3 个不同的组件：

（1）JobMaster

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

​ 在作业提交时，JobMaster 会先接收到要执行的应用。这里所说“应用”一般是客户端提交来的，包括：Jar 包，数据流图（dataflow graph），和作业图（JobGraph）。

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

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

（2）资源管理器（ResourceManager）

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

​ 注意 Flink 内置的 ResourceManager 和其他资源管理平台（比如 YARN）的ResourceManager 不同。

​ Flink 的 ResourceManager，针对不同的环境和资源管理平台（比如 Standalone 部署，或者YARN），有不同的具体实现。在 Standalone 部署时，因为 TaskManager 是单独启动的（没有Per-Job 模式），所以 ResourceManager 只能分发可用 TaskManager 的任务槽，不能单独启动新TaskManager。

​ 而在有资源管理平台时，就不受此限制。当新的作业申请资源时，ResourceManager 会将有空闲槽位的 TaskManager 分配给 JobMaster。如果 ResourceManager 没有足够的任务槽，它还可以向资源提供平台发起会话，请求提供启动 TaskManager 进程的容器。另外，ResourceManager 还负责停掉空闲的 TaskManager，释放计算资源。

（3）分发器（Dispatcher）

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

3.任务管理器（TaskManager）

​ TaskManager 是 Flink 中的工作进程，数据流的具体计算就是它来做的，所以也被称为“Worker”。Flink 集群中必须至少有一个 TaskManager；当然由于分布式计算的考虑，通常会有多个 TaskManager 运行，每一个 TaskManager 都包含了一定数量的任务槽（task slots）。Slot是资源调度的最小单位，slot 的数量限制了 TaskManager 能够并行处理的任务数量。

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

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

4.2作业提交流程

总体宏观上抽象

独立模式

在独立模式（Standalone）下，只有会话模式和应用模式两种部署方式。

YARN集群

1. 会话模式

2. 单作业模式

   

4.3 重要概念

4.3.1 数据流图

所有的 Flink 程序都可以归纳为由三部分构成：Source、Transformation 和 Sink。

• Source 表示“源算子”，负责读取数据源。

• Transformation 表示“转换算子”，利用各种算子进行处理加工。

• Sink 表示“下沉算子”，负责数据的输出。

​ 在运行时，Flink 程序会被映射成所有算子按照逻辑顺序连接在一起的一张图，这被称为“逻辑数据流”（logical dataflow），或者叫“数据流图”（dataflow graph）。数据流图类似于任意的有向无环图（DAG），这一点与 Spark 等其他框架是一致的。

4.3.2 并行度

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

​ 并行数据流图：

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

​ 并行度的设置

（1）代码中设置: 在算子后跟着调用 setParallelism()方法

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

（2）提交应用时设置: 在使用 flink run 命令提交应用时，可以增加-p 参数来指定当前应用程序执行的并行度

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

（3）配置文件中设置: 接在集群的配置文件 flink-conf.yaml 中直接更改默认并行度

parallelism.default: 2

优先级：依次递减

注意：，算子的并行度有时会受到自身具体实现的影响。比如之前我们用到的读取 socket 文本流的算子 socketTextStream，它本身就是非并行的 Source 算子，所以无论怎么设置，它在运行时的并行度都是 1。

4.3.3 算子链

1. 算子间的数据传输

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

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

​ 这种模式下，数据流维护着分区以及元素的顺序。比如数据流图中的 source 和 map 算子，source算子读取数据之后，可以直接发送给 map 算子做处理，它们之间不需要重新分区，也不需要调整数据的顺序。

（2）重分区（Redistributing）

​ 在这种模式下，数据流的分区会发生改变。比如数据流图中的 map 和后面的 keyBy/window 算子之间

2. 合并算子链

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

   
   注意:一对一和并行度相同两个条件必须同时具备，才可以合并。

4.3.4 作业图和执行图

​ 由 Flink 程序直接映射成的数据流图（dataflow graph），也被称为逻辑流图（logical StreamGraph），因为它们表示的是计算逻辑的高级视图。到具体执行环节时，我们还要考虑并行子任务的分配、数据在任务间的传输，以及合并算子链的优化。为了说明最终应该怎样执行一个流处理程序，Flink 需要将逻辑流图进行解析，转换为物理数据流图。

​ Flink 中任务调度执行的图，按照生成顺序可以分成四层：

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

（1）逻辑流图（StreamGraph）

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

（2）作业图（JobGraph）

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

（3）执行图（ExecutionGraph）

​ JobMaster 收到 JobGraph 后，会根据它来生成执行图（ExecutionGraph）。ExecutionGraph是 JobGraph 的并行化版本，是调度层最核心的数据结构。

（4）物理图（Physical Graph）

​ JobMaster 生成执行图后， 会将它分发给 TaskManager；各个 TaskManager 会根据执行图部署任务，最终的物理执行过程也会形成一张“图”，一般就叫作物理图（Physical Graph）。

4.3.5 任务和任务槽

1. 任务槽

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

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

   

2. 任务槽数量的设置

   可以通过集群的配置文件来设定 TaskManager 的 slot 数量

   taskmanager.numberOfTaskSlots: 8
   

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

3. 任务对任务槽的共享

   ​ 默认情况下，Flink 是允许子任务共享 slot 的。只要属于同一个作业，那么对于不同任务节点的并行子任务，就可以放到同一个 slot 上执行。

   ​ 每个任务节点的并行子任务一字排开，占据不同的 slot；而不同的任务节点的子任务可以共享 slot。一个 slot 中，可以将程序处理的所有任务都放在这里执行，我们把它叫作保存了整个作业的运行管道（pipeline）。

   ​ 同一个任务节点的并行子任务是不能共享 slot 的，所以允许 slot 共享之后，运行作业所需的 slot 数量正好就是作业中所有算子并行度的最大值。这样一来，我们考虑当前集群需要配置多少 slot 资源时，就不需要再去详细计算一个作业总共包含多少个并行子任务了，只看最大的并行度就够了。

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

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

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

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

   Slot 和并行度确实都跟程序的并行执行有关，但两者是完全不同的概念。简单来说，task slot 是 静 态 的 概 念 ， 是 指 TaskManager 具 有 的 并 发 执 行 能 力 ， 可 以 通 过 参 数 taskmanager.numberOfTaskSlots 进行配置；而并行度（parallelism）是动态概念，也就是 TaskManager 运行程序时实际使用的并发能力，可以通过参数 parallelism.default 进行配置。换 句话说，并行度如果小于等于集群中可用 slot 的总数，程序是可以正常执行的，因为 slot 不一 定要全部占用，有十分力气可以只用八分；而如果并行度大于可用 slot 总数，导致超出了并行 能力上限，那么心有余力不足，程序就只好等待资源管理器分配更多的资源了。

   举例说明：

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

   定义 WordCount 程序的处理操作是四个转换算子： source→ flatMap→ reduce→ sink

   当所有算子并行度相同时，容易看出 source 和 flatMap 可以合并算子链，于是最终有三个 任务节点。

   • 没有任何并行度设置，而配置文件中默认 parallelism.default=1，那么程序运行的 默认并行度为 1，总共有 3 个任务。由于不同算子的任务可以共享任务槽，所以最终占用的 slot 只有 1 个。9 个 slot 只用了 1 个，有 8 个空闲。
   • 如果我们更改默认参数，或者提交作业时设置并行度为 2，那么总共有 6 个任务，共享任 务槽之后会占用 2 个 slot，同样，就有 7 个 slot 空闲，计算资源 没有充分利用。
   • 考 虑到 slot 共享，我们可以直接把并行度设置为 9，这样所有 27 个任务就会完全占用 9 个 slot。 这是当前集群资源下能执行的最大并行度，计算资源得到了充分的利用。

本文介绍了 Flink 的系统架构和不同组件，并针对不同的部署模式详细讲述了作业提交和任务处理的流程。此外，介绍了架构中的一些重要概念，给出了 Flink 任务调度的核心问题，并对分布式流处理架构的设计做了思考分析。