目次
一、Apache Flink架构组件栈
1.1 概述
1.2 架构图
1.3 架构分层组件阐明
1.3.1 物理部署层
1.3.2 Runtime 焦点层
1.3.3 API & Libraries层
二、Flink运行时架构
2.1 概述
2.2 架构图
2.3 架构角色和组件
2.3.1 Flink Clients客户端
2.3.2 JobManager
2.3.2.1 ResourceManager
2.3.2.2 Dispatcher
2.3.2.3 JobMaster
2.3.3 TaskManager
2.3.3.1 Tasks 和算子链
2.3.3.2 Task Slots 和资源
三、Flink 三种提交作业模式对比
3.1 概述
3.2 Flink Session 集群
3.4 Flink Application 集群
一、Apache Flink架构组件栈
1.1 概述
在Flink的整个软件架构体系中，同样遵循这分层的架构计划理念，在降低体系耦合度的同时，也为上层用户构建Flink应用提供了丰富且友好的接口。
1.2 架构图
上图是Flink基本组件栈，从上图可以看出整个Flink的架构体系可以分为三层，从下往上依次是物理部署层、Runtime 焦点层、API&Libraries层。
1.3 架构分层组件阐明
1.3.1 物理部署层
该层主要涉及Flink的部署模式，目前Flink支持多种部署模式：本地Local、集群（Standalone/Yarn）、Kubernetes，Flink能够通过该层支撑不同平台的部署，用户可以根据必要来选择对应的部署模式，目前在企业中使用最多的是基于Yarn举行部署，也就是Flink On Yarn。
1.3.2 Runtime 焦点层
该层主要负责对上层不同接口提供基础服务，也是Flink分布式计算框架的焦点实现层，支持分布式Stream作业的实行、JobGraph到ExecutionGraph的映射转换、任务调理等，将DataStream和DataSet转成统一可实行的Task Oparator，达到在流式引擎下同时处置惩罚批量计算和流式计算的目的。
1.3.3 API & Libraries层
作为分布式计算框架，Flink同时提供了支撑流计算和批计算接口，未来批计算接口会被弃用，在Flink1.15 版本中批计算接口已经标志为Legacy（已逾期），后续版本建议使用Flink流计算接口，基于此接口之上抽象出不同应用范例的组件库，比方：FlinkML 机器学习库、FlinkCEP 复杂事件处置惩罚库、Flink Gelly 图处置惩罚库、SQL&Table 库。DataSet API 和DataStream API 两者都提供给用户丰富的数据处置惩罚高级API，比方：Map、FlatMap操纵等，同时也提供了比力底层的Process Function API ,用户可以直接操纵状态和时间等底层数据。
二、Flink运行时架构
2.1 概述
Flink整个体系主要由两个组件组成，分别为JobManager和TaskManager，Flink架构也遵循Master-Slave架构计划原则，JobManager为Master节点，TaskManager为Worker（Slave）节点。所有组件之间的通信都是借助于Akka Framework，包括任务的状态以及Checkpoint触发等信息。
2.2 架构图
2.3 架构角色和组件
2.3.1 Flink Clients客户端
Flink客户端负责将任务提交到集群，与JobManager构建Akka连接，然后将任务提交到JobManager，通过和JobManager之间举行交互获取任务实行状态。Flink客户端Clients不是Flink步伐运行时的一部门，作用是向JobManager准备和发送dataflow，之后，客户端可以断开（detached mode）连接或者保持连接(attached mode)。客户端提交任务可以采用CLI方式或者通过使用Flink WebUI提交，也可以在应用步伐中指定JobManager的RPC网络端口构建ExecutionEnvironment提交Flink应用。
2.3.2 JobManager
JobManager负责整个Flink集群任务的调理以及资源的管理，从客户端中获取提交的应用，然后根据集群中TaskManager上TaskSlot的使用情况，为提交的应用分配相应的TaskSlots资源并命令TaskManger启动从客户端中获取的应用。
JobManager相当于整个集群的Master节点，Flink HA 集群中可以有多个JobManager，但整个集群中有且仅有一个活泼的JobManager，其他的都是StandBy。
JobManager和TaskManager之间通过Actor System举行通信，获取任务实行的情况并通过Actor System将应用的任务实行情况发送给客户端。同时在任务实行过程中，Flink JobManager会触发Checkpoints操纵，每个TaskManager节点收到Checkpoint触发指令后，完成Checkpoint操纵，所有的Checkpoint协调过程都是在Flink JobManager中完成。
当任务完成后，Flink会将任务实行的信息反馈给客户端，而且开释掉TaskManager中的资源以供下一次提交任务使用。
JobManager由三个不同的组件组成：
2.3.2.1 ResourceManager
这里说的ResourceManager不是Yarn资源管理中的ResourceManager，而是Flink中的ResourceManager，其主要负责Flink集群资源分配、管理和接纳。在Flink中这里说的资源主要是TaskManager节点上的Task Slot计算资源，Flink中每个提交的任务最终会转换成task，每个task必要发送到TaskManager 上的slot中实行（slot是资源调理最小的单位），Flink为不同的情况和资源提供者（比方：Yarn/Kubernetes和Standalone）实现了对应的ResourceManager，这些ResourceManager负责申请启动TaskManager获取Slot资源。
在Standalone集群中，集群启动会同时启动TaskManager，不支持提交任务时启动TaskManager（没有Per-Job任务提交模式），ResourceManager只能分配可用TaskManager的slots，而不支持自行启动新的TaskManager，而基于其他资源调理框架实行任务时，当ResourceManager管理对应的TaskManager没有充足的slot，会申请启动新的TaskManager进程。
2.3.2.2 Dispatcher
Dispatcher提供了一个REST接口，用来提交Flink应用步伐实行，比方CLI客户端或Flink Web UI提交的任务最终都会发送至Dispatcher组件，由Dispatcher组件对JobGraph举行分发和实行，并为每个提交的作业启动一个新的 JobMaster，它还运行 Flink WebUI 用来提供作业实行信息。
2.3.2.3 JobMaster
JobMaster负责管理整个任务的生命周期，负责将Dispatcher提交上来的JobGraph转换成ExecutionGraph（实行图）结构，通过内部调理步伐对ExecutionGraph实行图举行调理和实行，最终向TaskManager中提交和运行Task实例，同时监控各个Task的运行状态，直到整个作业中所有的Task都实行完毕。
JobManager和ResourceManager组件一样，JobManager组件自己也是RPC服务，具备通信能力，可以与ResourceManager举行RPC通信申请任务的计算资源，资源申请到位后，就会将对应Task任务发送到TaskManager上实行，当Flink Task任务实行完毕后，JobMaster服务会关闭，同时开释任务占用的计算资源。所以JobMaster与对应的Flink job是逐一对应的。
2.3.3 TaskManager
TaskManager负责向整个集群提供Slot计算资源，同时管理了JobMaster提交的Task任务。TaskManager会提供JobManager从ResourceManager中申请和分配的Slot计算资源，JobMaster最终会根据分配到的Slot计算资源将Task提交到TaskManager上运行。另外，TaskManager还可缓存数据，TaskManager之间可以举行DataStream数据的互换。
一个Flink集群中至少有一个TaskManager，在TaskManager中资源调理的最小单位是 task slot ,一个TaskManger中的task Slot个数决定了当前TaskManger最高支持的并发task个数，一个task Slot中可以实行多个算子。
可以看出，Flink的任务运行其实是采用多线程的方式，这和MapReduce多JVM进程的方式有很大的区别Fink能够极大提高CPU使用效率，在多个任务和Task之间通过TaskSlot方式共享体系资源，每个TaskManager中通过管理多个TaskSlot资源池举行对资源举行有用管理。
2.3.3.1 Tasks 和算子链
对于分布式实行，Flink 将算子的 subtasks 链接成 tasks 。每个 task 由一个线程实行。将算子链接成 task 是个有用的优化：它减少线程间切换、缓冲的开销，而且减少延迟的同时增加团体吞吐量。
下图中样例数据流用 5 个 subtask 实行，因此有 5 个并行线程：
2.3.3.2 Task Slots 和资源
每个 worker（TaskManager）都是一个 JVM 进程，可以在单独的线程中实行一个或多个 subtask。为了控制一个 TaskManager 中接受多少个 task，就有了所谓的 task slots（至少一个）。
每个 task slot代表 TaskManager 中资源的固定子集。比方，具有 3 个 slot 的 TaskManager，会将其托管内存 1/3 用于每个 slot。分配资源意味着 subtask 不会与其他作业的 subtask 竞争托管内存，而是具有肯定数量的保存托管内存。注意此处没有 CPU 隔离；当前 slot 仅分离 task 的托管内存。
通过调解 task slot 的数量，用户可以定义 subtask 如何互相隔离。每个 TaskManager 有一个 slot，这意味着每个 task 组都在单独的 JVM 中运行（比方，可以在单独的容器中启动）。具有多个 slot 意味着更多 subtask 共享同一 JVM。同一 JVM 中的 task 共享 TCP 连接（通过多路复用）和心跳信息。它们还可以共享数据集和数据结构，从而减少了每个 task 的开销。
默认情况下，Flink 允许 subtask 共享 slot，即便它们是不同的 task 的 subtask，只要是来自于同一作业即可。效果就是一个 slot 可以持有整个作业管道。允许slot 共享有两个主要长处：
- Flink 集群所需的 task slot 和作业中使用的最大并行度恰好一样。无需计算步伐总共包含多少个 task（具有不同并行度）。
- 容易获得更好的资源利用。如果没有 slot 共享，非密集 subtask（ source/map() ）将阻塞和密集型 subtask（ window ） 一样多的资源。通过 slot 共享，我们示例中的基本并行度从 2 增加到 6，可以充实利用分配的资源，同时确保繁重的 subtask 在 TaskManager 之间公中分配。
三、Flink 三种提交作业模式对比
3.1 概述
Flink 应用步伐是从其 main() 方法产生的一个或多个 Flink 作业的任何用户步伐。这些作业的实行可以在本地 JVM（LocalEnvironment）中举行，或具有多台机器的集群的长途设置（RemoteEnvironment）中举行。对于每个步伐，ExecutionEnvironment 提供了一些方法来控制作业实行（比方设置并行度）并与外界交互。
Flink 应用步伐的作业可以被提交到长期运行的 Flink Session 集群、专用的 Flink Job 集群 或 Flink Application 集群。这些选项之间的差别主要与集群的生命周期和资源隔离保证有关。
3.2 Flink Session 集群
- 集群生命周期 ：在 Flink Session 集群中，客户端连接到一个预先存在的、长期运行的集群，该集群可以接受多个作业提交。即使所有作业完成后，集群（和 JobManager）仍将继续运行直到手动制止 session 为止。因此，Flink Session 集群的寿命不受任何 Flink 作业寿命的约束。
- 资源隔离 ：TaskManager slot 由 ResourceManager 在提交作业时分配，并在作业完成时开释。由于所有作业都共享同一集群，因此在集群资源方面存在一些竞争 — 比方提交工作阶段的网络带宽。此共享设置的局限性在于，如果 TaskManager 瓦解，则在此 TaskManager 上运行 task 的所有作业都将失败；类似的，如果 JobManager 上发生一些致命错误，它将影响集群中正在运行的所有作业。
- 其他注意事项：拥有一个预先存在的集群可以节省大量时间申请资源和启动 TaskManager。有种场景很紧张，作业实行时间短而且启动时间长会对端到端的用户体验产生负面的影响 — 就像对简短查询的交互式分析一样，希望作业可以使用现有资源快速实行计算。
提示：Flink Session 集群也被称为 *session 模式*下的 Flink 集群。
3.3 Flink Job 集群
- 集群生命周期 ：在 Flink Job 集群中，可用的集群管理器（比方 YARN）用于为每个提交的作业启动一个集群，而且该集群仅可用于该作业。在这里，客户端起首从集群管理器请求资源启动 JobManager，然后将作业提交给在这个进程中运行的 Dispatcher。然后根据作业的资源请求惰性的分配 TaskManager。一旦作业完成，Flink Job 集群将被拆除。
- 资源隔离 ：JobManager 中的致命错误仅影响在 Flink Job 集群中运行的一个作业。
- 其他注意事项：由于 ResourceManager 必须应用并等待外部资源管理组件来启动 TaskManager 进程和分配资源，因此 Flink Job 集群更适合长期运行、具有高稳定性要求且对较长的启动时间不敏感的大型作业。
提示：Flink Job 集群也被称为 job (or per-job) 模式下的 Flink 集群。而且Kubernetes 不支持 Flink Job 集群。
3.4 Flink Application 集群
- 集群生命周期：Flink Application 集群是专用的 Flink 集群，仅从 Flink 应用步伐实行作业，而且 main()方法在集群上而不是客户端上运行。提交作业是一个单步调过程：无需先启动 Flink 集群，然后将作业提交到现有的 session 集群；相反，将应用步伐逻辑和依赖打包成一个可实行的作业 JAR 中，而且集群入口（ApplicationClusterEntryPoint）负责调用 main()方法来提取 JobGraph。比方，这允许你像在 Kubernetes 上部署任何其他应用步伐一样部署 Flink 应用步伐。因此，Flink Application 集群的寿命与 Flink 应用步伐的寿命有关。
- 资源隔离 ：在 Flink Application 集群中，ResourceManager 和 Dispatcher 作用于单个的 Flink 应用步伐，相比于 Flink Session 集群，它提供了更好的隔离。
提示：Flink Job 集群可以看做是 Flink Application 集群”客户端运行“的替换方案。
本日Flink相关内容的介绍就分享到这里，可以关注Flink专栏《Flink》，后续不定期分享相关技术文章。如果帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
