Flink 运行架构

Flink 运行时由两种类型的进程组成：一个 JobManager 和若干个 TaskManager 组成！

JobManager

JobManager： 具有许多与协调 Flink 应用程序的分布式执行有关的责任，比如：决定何时调度下一个（组）task、对完成的 task 或执行失败时做出反应、协调 checkpoint、失败恢复等。

在集群中，需要保证 JobManager 至少存在一个。高可用（HA）模式中，为避免单点故障，有可能由多个 JobManager，其中仅有一个 leader，其他则是 standby。

该进程由三部分组成：

ResourceManager：

• 负责 Flink 集群中的资源提供、回收、分配，管理 task slots（资源调度的单位）。Flink 为不同的环境和资源提供者（YARN、Mesos、Kubernets、standalone）实现了对应的 ResourceManager。

  standalone 模式中，ResourceManager 只能分配可用的 TaskManager 的 slots，而不能实现启动新的 TaskManager！

Dispatcher：

• 可跨作业运行，提供了一个 REST接口，用来提交 Fink 应用程序执行，并为每个提交的作业启动一个新的 JobMaster。当一个引用被提交时，Dispatcher 就会将应用交给一个 JobManager。由于是 REST接口，Dispatcher 可以作为集群的一个 HTTP 接入点。这样就免受防火墙的阻挡。它还运行 Flink WenUI 用来展示和监控作业的执行信息。

  Dispatcher 在架构中不是刚需，取决于应用的提交方式！

JobMaster：

• 负责管理单个 JobGraph 的执行。Flink 集群中可以同时运行多个 Job，每个 Job 都有自己的 JobMaster。

TaskManager

TaskManager： 也称为 worker，负责执行作业流的 task，并缓存和交换数据流。在 TaskManager 中调度资源的最小的单位时 task slot，TaskManager 中 task slot 的数据量表示并发处理的 task 的数量。

作业启动后，TaskManager 会向资源管理器注册它的 slot，收到资源管理器的指令后，TaskManager 就会将一个或多个 slot 提供给 JobManager 调用，JobManager 向 slot 分配任务，执行过程中，一个 TaskManager 可以同其他 TaskManager 运行同一应用程序的 TaskManager 交换数据。

在集群中，需要保证 JobManager 至少存在一个。

任务调度原理

客户端不是运行时和程序执行的一部分，但它用于准备并发送 dataflow(JobGraph)给 Master(JobManager)，然后，客户端断开连接或者维持连接以 等待接收计算结果。

当 Flink 集群启动后，首先会启动一个 JobManger 和一个或多个的 TaskManager。由 Client 提交任务给 JobManager，JobManager 再调度任务到各个 TaskManager 去执行，然后 TaskManager 将心跳和统计信息汇报给 JobManager。 TaskManager 之间以流的形式进行数据的传输。上述三者均为独立的 JVM 进程。

Client 为提交 Job 的客户端，可以是运行在任何机器上（与 JobManager 环境 连通即可）。提交 Job 后，Client 可以结束进程（Streaming 的任务），也可以不 结束并等待结果返回。

JobManager 主要负责调度 Job 并协调 Task 做 checkpoint，职责上很像 Storm 的 Nimbus。从 Client 处接收到 Job 和 JAR 包等资源后，会生成优化后的 执行计划，并以 Task 的单元调度到各个 TaskManager 去执行。

TaskManager 在启动的时候就设置好了槽位数（Slot），每个 slot 能启动一个 Task，Task 为线程。从JobManager 处接收需要部署的 Task，部署启动后，与自己的上游建立 Netty 连接，接收数据并处理。

Tasks and Operator Chains

对于分布式执行，Flink 将 operator subtask 链在一起形成 task。每个任务由一个线程执行。将 operator 链接成 task 能够减少线程到线程切换和缓冲的开销，并在降低延迟的同时提高了整体吞吐量。

下图中的示例数据流使用五个子任务执行，因此使用五个并行线程。

Task Slots and Resources

Flink 中，每个 worker（TaskManager）都是一个 JVM 进程，可以在单独的线程中执行一个或多个 subtask。为了控制一个 TaskManager 中接受多少个 task，就有了所谓的 task slots（worker 中至少一个）。

Sub-Task 是负责处理数据流 Partition 的 Task，其强调的是同一个 Operator 或者 Operator Chain 具有多个并行的 Task 。

每个 task slot 代表 TaskManager 中资源的固定子集。例如，具有 3 个 slot 的 TaskManager，每个 slot 将托管（占用） TaskManager 内存的 1/3 。资源划分后，subtask 就不会与其他作业的 subtask 竞争托管内存，而是使用仅其托管的内存部分。通过调整 task slot 的数量，用户可以定义 subtask 如何互相隔离。

注意此处没有 CPU 隔离；当前 slot 仅用于分离 task 的受管理的内存！

如果每个 TaskManager 只有一个 slot，这意味着每个 task group 都在单独的 JVM 中运行（例如，可以在单独的容器中启动）。如果一个 TaskManager 具有多个 slot 意味着更多 subtask 共享同一 JVM。同一 JVM 中的 task 共享 TCP 连接（通过多路复用）和心跳信息。它们还可以共享数据集和数据结构，从而减少了每个 task 的开销。

默认情况下，对于同一个作业，Flink 允许 subtask 共享 slot，即便它们是不同的 task 的 subtask。结果就是一个 slot 可以持有整个作业管道。

Apache Flink 的一种常见应用场景是 ETL（抽取、转换、加载）管道任务。从一个或多个数据源获取数据，进行一些转换操作和信息补充，将结果存储起来。

允许 slot 共享有两个主要优点：

• Flink 集群所需的 task slot 和作业中使用的最大并行度恰好一样。无需计算程序总共包含多少个 task（具有不同并行度）。
• 资源利用更加高效。如果没有 slot 共享，非密集 subtask（source/map()）将阻塞和密集型 subtask（window） 一样多的资源。通过 slot 共享，我们示例中的基本并行度从 2 增加到 6，可以充分利用分配的资源，同时确保繁重的 subtask 在 TaskManager 之间公平分配。

 

---

❤️ END ❤️