Flink运行时架构

一、系统架构

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互换数据。
二、核心概念

2.1  并行度（Parallelism）

1）并行子任务和并行度
当要处置惩罚的数据量非常大时，我们可以把一个算子操纵，“复制”多份到多个节点，数据来了之后就可以到其中任意一个实行。如许一来，一个算子任务就被拆分成了多个并行的“子任务”（subtasks），再将它们分发到差异节点，就真正实现了并行计算。
在Flink实行过程中，每一个算子（operator）可以包含一个或多个子任务（operator subtask），这些子任务在差异的线程、差异的物理机或差异的容器中完全独立地实行。

一个特定算子的子任务（subtask）的个数被称之为其并行度（parallelism）。如许，包含并行子任务的数据流，就是并行数据流，它需要多个分区（stream partition）来分配并行任务。一般情况下，一个流步伐的并行度，可以以为就是其全部算子中最大的并行度。一个步伐中，差异的算子大概具有差异的并行度。
比方：如上图所示，当前数据流中有source、map、window、sink四个算子，其中sink算子的并行度为1，其他算子的并行度都为2。以是这段流处置惩罚步伐的并行度就是2。
2）并行度的设置
在Flink中，可以用差异的方法来设置并行度，它们的有用范围和优先级别也是差异的。
（1）代码中设置
我们在代码中，可以很简单地在算子后跟着调用setParallelism()方法，来设置当前算子的并行度：

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

复制代码

这种方式设置的并行度，只针对当前算子有用。
别的，我们也可以直接调用实行环境的setParallelism()方法，全局设定并行度：

1. env.setParallelism(2);

复制代码

如许代码中全部算子，默认的并行度就都为2了。我们一般不会在步伐中设置全局并行度，由于假如在步伐中对全局并行度进行硬编码，会导致无法动态扩容。
这里要注意的是，由于keyBy不是算子，以是无法对keyBy设置并行度。
（2）提交应用时设置
在利用flink run下令提交应用时，可以增加-p参数来指定当前应用步伐实行的并行度，它的作用类似于实行环境的全局设置：

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

复制代码

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

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

1. parallelism.default: 2

复制代码

这个设置对于整个集群上提交的全部作业有用，初始值为1。无论在代码中设置、照旧提交时的-p参数，都不是必须的；以是在没有指定并行度的时间，就会采用配置文件中的集群默认并行度。在开发环境中，没有配置文件，默认并行度就是当前呆板的CPU核心数。
2.2 算子链（Operator Chain）


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）合并算子链
在Flink中，并行度相同的一对一（one to one）算子操纵，可以直接链接在一起形成一个“大”的任务（task），如许原来的算子就成为了真正任务里的一部分，如下图所示。每个task会被一个线程实行。如许的技能被称为“算子链”（Operator Chain）。

上图中Source和map之间满意了算子链的要求，以是可以直接合并在一起，形成了一个任务；由于并行度为2，以是合并后的任务也有两个并行子任务。如许，这个数据流图所表示的作业终极会有5个任务，由5个线程并行实行。
将算子链接成task黑白常有用的优化：可以淘汰线程之间的切换和基于缓存区的数据互换，在淘汰时延的同时提升吞吐量。
Flink默认会按照算子链的原则进行链接合并，假如我们想要禁止合并或者自行定义，也可以在代码中对算子做一些特定的设置：

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

复制代码

2.3 任务槽（Task Slots）


1）任务槽（Task Slots）
Flink中每一个TaskManager都是一个JVM进程，它可以启动多个独立的线程，来并行实行多个子任务（subtask）。
很显然，TaskManager的计算资源是有限的，并行的任务越多，每个线程的资源就会越少。那一个TaskManager到底能并行处置惩罚多少个任务呢？为了控制并发量，我们需要在TaskManager上对每个任务运行所占用的资源做出明白的划分，这就是所谓的任务槽（task slots）。
每个任务槽（task slot）其实表示了TaskManager拥有计算资源的一个固定巨细的子集。这些资源就是用来独立实行一个子任务的。

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

1. taskmanager.numberOfTaskSlots: 8

复制代码

需要注意的是，slot目前仅仅用来隔离内存，不会涉及CPU的隔离。在具体应用时，可以将slot数量配置为呆板的CPU核心数，尽量制止差异任务之间对CPU的竞争。这也是开发环境默认并行度设为呆板CPU数量的原因。
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共享组”手动指定：

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

复制代码

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

任务槽和并行度都跟步伐的并行实行有关，但两者是完全差异的概念。简单来说任务槽是静态的概念，是指TaskManager具有的并发实行能力，可以通过参数taskmanager.numberOfTaskSlots进行配置；而并行度是动态概念，也就是TaskManager运行步伐时实际利用的并发能力，可以通过参数parallelism.default进行配置。
举例说明：假设一共有3个TaskManager，每一个TaskManager中的slot数量设置为3个，那么一共有9个task slot，表示集群最多能并行实行9个同一算子的子任务。
而我们定义word count步伐的处置惩罚操纵是四个转换算子：
当全部算子并行度相同时，容易看出source和flatmap可以合并算子链，于是终极有三个任务节点。

 

 

通过这个例子也可以明白地看到，整个流处置惩罚步伐的并行度，就应该是全部算子并行度中最大的谁人，这代表了运行步伐需要的slot数量。
三、作业提交换程

3.1 Standalone会话模式作业提交换程

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应用模式作业提交换程

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。