Flink执行过程

大大大大肉包

已于 2022-06-07 21:37:34 修改

阅读量3.7k

点赞数 4

分类专栏： flink 文章标签： flink 大数据 big data

于 2022-06-07 17:45:05 首次发布

本文链接：https://blog.csdn.net/qq_42456324/article/details/125169029

版权

flink 专栏收录该内容

24 篇文章 4 订阅

订阅专栏

作业提交流程

（1） 一般情况下，由客户端（App）通过分发器提供的 REST 接口，将作业提交给JobManager。 
（2）由分发器启动 JobMaster，并将作业（包含 JobGraph）提交给 JobMaster。 
（3）JobMaster 将 JobGraph 解析为可执行的 ExecutionGraph，得到所需的资源数量，然后向资源管理器请求资源（slots）。
（4）资源管理器判断当前是否由足够的可用资源；如果没有，启动新的 TaskManager。 
（5）TaskManager 启动之后，向 ResourceManager 注册自己的可用任务槽（slots）。
（6）资源管理器通知 TaskManager 为新的作业提供slots。
（7）TaskManager 连接到对应的 JobMaster，提供slots。 
（8）JobMaster 将需要执行的任务分发给 TaskManager。 
（9）TaskManager 执行任务，互相之间可以交换数据。

数据流图

所有的 Flink 程序都可以归纳为由三部分构成：Source、Transformation 和 Sink。
Source 表示“源算子”，负责读取数据源。
Transformation 表示“转换算子”，利用各种算子进行处理加工。
Sink 表示“下沉算子”，负责数据的输出。
在运行时，Flink 程序会被映射成所有算子按照逻辑顺序连接在一起的一张图，这被称为“逻辑数据流”（logical dataflow），或者叫“数据流图”（dataflow graph）.

并行度（Parallelism）

        而对于 Flink 这样的流式引擎，数据是连续不断到来的，我们完全可以按照数据流图建立一个“流水线”，前一个操作处理完成，就发往处理下一步操作的节点。在 Flink 执行过程中，每一个算子（operator）可以包含一个或多个子任务（operator subtask），这些子任务在不同的线程、不同的物理机或不同的容器中完全独立地执行。

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

算子链（Operator Chain）

一个数据流在算子之间传输数据的形式可以是一对一（one-to-one）的直通 (forwarding)模式，也可以是打乱的重分区（redistributing）模式，具体是哪一种形式，取决于算子的种类。
（1）一对一（One-to-one，forwarding）
        这种模式下，数据流维护着分区以及元素的顺序。source算子读取数据之后，可以直接发送给 map 算子做处理，它们之间不需要重新分区，也不需要调整数据的顺序。这就意味着 map 算子的子任务，看到的元素个数和顺序跟 source 算子的子任务产生的完全一样，保证着“一对一”的关系。
（2）重分区（Redistributing） 
        在这种模式下，数据流的分区会发生改变。每一个算子的子任务，会根据数据传输的策略，把数据发送到不同的下游目标任务。例如，keyBy()是分组操作，本质上基于键（key）的哈希值（hashCode）进行了重分区；而当并行度改变时，比如从并行度为 2 的 window 算子，要传递到并行度为 1 的 Sink 算子，这时的数据传输方式是再平衡（rebalance），会把数据均匀地向下游子任务分发出去。
合并算子链：
在 Flink 中，并行度相同的一对一（one to one）算子操作，可以直接链接在一起形成一个“大”的任务（task），这样原来的算子就成为了真正任务里的一部分。这样的技术被称为合并算子链。

作业图（JobGraph）与执行图（ExecutionGraph）

Flink 程序直接映射成的数据流图（dataflow graph），也被称为逻辑流图（logicalStreamGraph），因为它们表示的是计算逻辑的高级视图。到具体执行环节时，我们还要考虑并行子任务的分配、数据在任务间的传输，以及合并算子链的优化。为了说明最终应该怎样执行一个流处理程序，Flink 需要将逻辑流图进行解析，转换为物理数据流图。在这个转换过程中，有几个不同的阶段，会生成不同层级的图，其中最重要的就是作业图（JobGraph）和执行图（ExecutionGraph）。
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 的并行化版本，是调度层最核心的数据结构。与 JobGraph 最大的区别就是按照并行度对并行子任务进行了拆分，并明确了任务间数据传输的方式。
4. 物理图（Physical Graph）
JobMaster 生成执行图后， 会将它分发给 TaskManager；各个 TaskManager 会根据执行图
部署任务，最终的物理执行过程也会形成一张“图”，一般就叫作物理图（Physical Graph）。
这只是具体执行层面的图，并不是一个具体的数据结构。

任务（Tasks）和任务槽（Task Slots）

1. 任务槽（Task Slots）

之前已经提到过，Flink 中每一个 worker(也就是 TaskManager)都是一个 JVM 进程，它可以启动多个独立的线程，来并行执行多个子任务（subtask）。
所以如果想要执行 5 个任务，并不一定非要 5 个 TaskManager，我们可以让 TaskManager多线程执行任务。如果可以同时运行 5 个线程，那么只要一个 TaskManager 就可以满足我们之前程序的运行需求了。那一个 TaskManager 到底能并行处理多少个任务呢？为了控制并发量，我们需要在 TaskManager 上对每个任务运行所占用的资源做出明确的划分，这就是所谓的任务槽（task slots）。
每个任务槽（task slot）其实表示了 TaskManager 拥有计算资源的一个固定大小的子集。这些资源就是用来独立执行一个子任务的。

2. 任务槽数量的设置
具体来说，如果一个 TaskManager 只有一个 slot，那将意味着每个任务都会运行在独立的JVM 中（当然，该 JVM 可能是通过一个特定的容器启动的）；而一个 TaskManager 设置多个slot 则意味着多个子任务可以共享同一个 JVM。
它们的区别在于：前者任务之间完全独立运行，隔离级别更高、彼此间的影响可以降到最小；而后者在同一个 JVM 进程中运行的任务，将共享 TCP 连接和心跳消息，也可能共享数据集和数据结构，这就减少了每个任务的运行开销，在降低隔离级别的同时提升了性能。
注意：slot 目前仅仅用来隔离内存，不会涉及 CPU 的隔离。