Flink体系架构和应用部署方式

目录
概述
Flink集群架构组件
Client
JobManager
TaskManagers
算子、Task和Subtask三者关系
概念
算子和Task的关系
Task和SubTask的关系
算子和SubTask的关系
样例
Task Slots和资源的关系
Flink应用程序部署
Flink Session 集群
Flink Job 集群
Flink Application 集群

---

概述

Flink傲立于分布式体系的前沿，它的执行流应用程序能力深受瞩目，而这一切结果的背后，离不开对盘算资源的精妙分配与高效管理。作为一款卓越的分布式体系，Flink深知盘算资源对于其性能与效率的至关紧张性。
尤为值得一提的是，Flink展现了卓越的兼容性，它无缝集成了诸如Hadoop YARN、Apache Mesos以及Kubernetes等一系列广受欢迎的集群资源管理器。这不光意味着Flink能够轻松驾御这些主流平台，实现资源的机动调度与优化，还进一步拓宽了其应用场景。除此之外，Flink同样具备强大的机动性，它既可以作为独立的集群自主运行，又能以库的情势嵌入到其他体系中，满足多样化的使用需求。
综上所述，Flink不光是一款功能强大的分布式体系，更是一个能够与多种集群资源管理器紧密协作、机动顺应各种场景的杰出代表。
本文概述了 Flink 的架构，而且形貌了其紧张组件如何举行交互以及Flink应用程序的几种部署方式和从故障中恢复的机制。
Flink集群架构组件

Flink的运行时架构精妙而高效，其核心由两大类型的进程协同工作，共同支持起流/批处理任务的稳定运行。这两个关键组件分别是：一个高瞻远瞩的JobManager，以及一个或多个勤勤奋恳的TaskManager。

JobManager与TaskManager的启动方式机动多样，既可以直接在物理或虚拟呆板上以standalone集群的情势独立启动，也可以在容器化环境中优雅地运行，甚至还能借助YARN、Kubernetes、Mesos等强大的资源管理框架举行动态管理与启动。一旦TaskManager成功启动，它会自动连接到JobManager，宣告自身的可用性，并随时准备接收由JobManager分配的工作负载。这种筹划不光提升了资源的使用率，还确保了作业调度与执行的机动性与高效性。
Client

在Flink的运作体系中，Client并不直接参与运行时的数据处理或程序执行流程，而是扮演着数据流的准备者与发送者的角色。Client的紧张职责是构建并配置数据流，随后将其提交给JobManager以启动处理流程。这一提交过程完成后，Client可以选择两种模式举行操纵：在分离模式下，Client会与集群断开连接，释放资源并允许用户举行其他任务；而在附加模式下，Client则保持与集群的连接，连续接收并展示作业的执行状态与报告。
Client的启动方式机动多样，既可以作为Java/Scala程序的一部分被触发执行，让开发者能够在代码中直接配置并提交作业；也可以通过命令行界面（如执行./bin/flink run ...命令）来运行，为不认识编程的用户提供了便捷的提交途径。无论接纳哪种方式，Client都以其独特的功能，为Flink作业的顺利启动与监控提供了有力支持。
JobManager

JobManager在Flink应用程序的分布式执行过程中扮演着至关紧张的协调者角色。它负责决定task（或task集合）的调度时机，监控task的完成环境并对执行失败做出及时相应。此外，JobManager还负责协调checkpoint的创建，以确保数据的一致性与可恢复性，并在作业失败时引导从先前状态举行恢复。通过这些职责的履行，JobManager确保了Flink应用程序能够高效、可靠地运行。JobManager紧张由下面的三个不同的组件组成：

• ResourceManager: ResourceManager在Flink集群中扮演着资源管理的核心角色，它负责资源的供应、接纳以及分配任务。它管理的核心资源单位是task slots（TaskManager末节会介绍），这些slots是Flink集群举行资源调度的基础。为了满足不同环境和资源提供者的需求，Flink为YARN、Mesos、Kubernetes以及standalone部署等场景分别实现了特定的ResourceManager。值得注意的是，在standalone模式下，ResourceManager的功能受限于仅能对已存在的TaskManager的slots举行分配，而无法自主启动新的TaskManager实例。
  
• Dispatcher：Dispatcher通过一个REST接口接收Flink应用程序的执行哀求，并为每个提交的Flink应用程序实例化一个新的JobMaster以启动执行。此外，它还承载着Flink的Web用户界面（WebUI），该界面为用户提供Flink应用程序执行状态的及时信息。
  
• JobMaster：JobMaster的职责是监督并管理单个JobGraph的执行流程。在Flink集群的运行环境中，能够并行处理多个Flink应用程序，而每个Flink应用程序都配备有专属的JobMaster来负责其执行管理。
  

始终至少有一个 JobManager。高可用（HA）设置中大概有多个 JobManager，此中一个始终是 leader，其他的则是 slave。
TaskManagers

TaskManager（也称为 worker）执行作业流的 task，而且缓存和交换数据流。
必须始终至少有一个 TaskManager。在 TaskManager 中资源调度的最小单位是 task slot。TaskManager 中 task slot 的数量表示并发处理 task 的数量。请注意一个 task slot 中可以执行多个算子。其紧张包含以下的一些组件：

• TaskSlotTable: 管理TaskSlot的组件，负责添加和获取Task、申请和释放Slot等操纵。
  
• ResourceManager：TaskManager向ResourceManager申请插槽资源，ResourceManager负责资源的提供、接纳、分配和管理。
  
• HeartbeatManager：包含JobManagerHeartbeatManager和ResourceManagerHeartbeatManager，负责检测与JobManager和ResourceManager的心跳连接，以确保通讯的顺畅和集群的稳定性。
  
• BlobService：提供BLOB（Binary Large Object）的存储服务，包括可恢复的PermanentBlobService和不可恢复的TransientBlobService。BLOB底层存储支持多种实现，如HDFS、S3、FTP等。
  

算子、Task和Subtask三者关系

概念

• 算子（Operator）
  

• 
  
  
  
  • 算子表示一种数据流的转换操纵，它用于对输入流举行转换并天生一个新的数据流作为输出。
    
  • 算子可以执行各种数据处理操纵，如过滤、映射、聚合、连接、排序等。
    
  • Flink提供了很多内置的算子，如map、filter、keyBy等，同时也允许用户自定义算子以满足特定的需求。
    
  
  

• Task
  

• 
  
  
  
  • 在Flink中，Task是作业（Job）拆解后（Dataflow Graph）的最小执行单元，它负责执行详细的盘算逻辑。
    
  • 一般环境下，每个Task对应着作业中特定运算步骤的一个实例，比如map、filter、join等操纵。
    
  • 在发生Operator Chain环境下，一个Task大概包含多个算子的操纵逻辑。
    
  
  

• SubTask
  

• 
  
  
  
  • Subtask是Flink中任务的最小执行单元，它是Task的一个并行实例。
    
  • 当一个算子（Operator）设置了一个大于1的并行度时，该算子会被拆分成多个Subtasks，这些Subtasks分布在不同的Task Slots中并行执行。
    
  • Subtask是Flink举行资源分配和调度的根本单位。
    
  
  

算子和Task的关系

• 在没有Operator Chain的环境下，一个算子通常对应一个Task。但是，当多个算子被链接在一起时（通过Flink的算子链机制），它们大概会在同一个Task中执行，以减少中间数据的交换开销。
  
• 在现实应用中，一个Task大概包含多个算子的操纵逻辑，这些算子在Task内部以流水线的方式执行。
  

Task和SubTask的关系

• 在没有并行度设置或并行度为1的环境下，一个Task通常只包含一个Subtask。
  
• 当并行度大于1时，一个Task会被拆分成多个Subtasks，这些Subtasks在Flink集群中并行执行。
  
• 需要注意的是，虽然多个Subtasks并行执行，但它们都属于同一个Task，并共享该Task的盘算逻辑和状态。
  

算子和SubTask的关系

SubTask是算子的执行实例。
样例

下图中样例数据流用 5 个 subtask 执行，因此有 5 个并行线程。

Task Slots和资源的关系

每个 TaskManager（工作管理器）作为一个独立的 JVM 进程运行，能够在其内部的独立线程上并发执行一个或多个Subtask。为了管理一个 TaskManager 能够承载的任务数量，引入了所谓的任务槽（Task Slots）概念，每个 TaskManager 至少配备一个任务槽。
每个任务槽（Task Slot）象征着TaskManager内部一组固定的资源分配单元。举例来说，一个配置了3个任务槽的TaskManager，会将其所管理的托管内存均分为三份，每份分配给一个任务槽。这种资源分配确保了子任务（Subtask）在运行时不会与其他作业的子任务争夺托管内存资源，因为每个子任务都被分配了肯定数量的专用托管内存。需要指出的是，这里并未实现CPU资源的隔离；当前的Task Slot仅仅是在TaskManager的托管内存层面为任务分别了界限。
通过调整 Task Slot 的数量，用户可以定义 Subtask 如何相互隔离。每个 TaskManager 有一个 Slot，这意味着每个 Task 组都在单独的 JVM 中运行（比方，可以在单独的容器中启动）。具有多个 Slot 意味着更多 Subtask 共享同一 JVM。同一 JVM 中的 Task 共享 TCP 连接（通过多路复用）和心跳信息。它们还可以共享数据集和数据布局，从而减少了每个 Task 的开销。

默认环境下，Flink 允许 Subtask 共享 Slot，即便它们是不同的 Task 的 Subtask，只要是来自于同一作业即可。结果就是一个 Slot 可以持有整个作业Subtask执行的管道。允许Slot紧张有以下两个紧张的有点：

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

Flink应用程序部署

Flink 应用程序，作为源自其 main() 方法的用户程序，能够孕育出一个或多个 Flink 作业。这些作业的执行舞台既可以是本地的 JVM（即 LocalEnvironment），也能够扩展到由多台呆板构成的远程集群环境（即 RemoteEnvironment）。对于每一份精心编写的程序，ExecutionEnvironment提供了丰富的方法来控制作业的执行细节，比如设定并行度、Checkpoint时间隔断等，并提供了一些方法能够与外界举行交互。
Flink 应用程序的作业具备多种部署选项，它们可以投递至连续运行的 Flink Session 集群、专享的 Flink Job 集群，或是 Flink Application 集群中执行。这些部署方式的核心差异，紧张在于它们对集群生命周期的管理以及所提供的资源隔离保障各不相同。
Flink Session 集群

• 集群生命周期：在Flink Session集群中，客户端与一个已经存在并连续运行的集群建立连接，这个集群具备接收多个作业提交的能力。即便所有提交的作业都已完成其执行，集群（包括此中的JobManager）仍会保持运行状态，除非用户手动终止这个session。这意味着，Flink Session集群的运行时间并不依赖于任何单一作业的寿命，而是由用户的操纵来决定。
  
• 资源隔离：TaskManager的slot是由ResourceManager在作业提交时动态分配的，并在作业结束后被释放回体系。由于多个作业共同使用一个集群，因此在集群资源（如网络带宽等）的分配上会存在肯定的竞争。这种共享资源的模式存在一个局限性：假如某个TaskManager发生故障，那么在该TaskManager上运行的所有任务所属的作业都会受到影响并失败；同样地，假如JobManager遭遇严峻错误，那么整个集群中正在运行的所有作业都将受到波及。
  
• 应用场景：预先存在的集群能够显著提升资源申请与TaskManager启动的效率。对于那些作业执行时间短但启动时间长的环境，其对端到端用户体验的负面影响尤为显著，特别是在交互式分析场景中，用户期望的是能够快速使用现有资源完成盘算任务。拥有一个始终在线的集群，可以确保这些短作业能够迅速获得所需资源并高效执行，从而提升用户体验。
  

Flink Job 集群

• 集群生命周期：在Flink Job集群模式下，我们使用集群管理器（比方YARN）来为每个提交的作业单独启动一个集群，这个集群是专属于该作业的。流程是如许的：客户端起首会向集群管理器哀求资源，用以启动JobManager；随后，作业会被提交给在这个新启动的JobManager进程中运行的Dispatcher。接着，根据作业的现实资源需求，TaskManager会被惰性地分配。当作业执行完毕后，整个Flink Job集群会被自动拆除和整理。
  
• 资源隔离：JobManager 中的致命错误仅影响在 Flink Job 集群中运行的一个作业。
  
• 应用场景：由于 ResourceManager 必须应用并等候外部资源管理组件来启动 TaskManager 进程和分配资源，因此 Flink Job 集群更得当恒久运行、具有高稳定性要求且对较长的启动时间不敏感的大型作业。
  

Flink Application 集群

• 集群生命周期：Flink Application 集群是一种专门为运行 Flink 应用程序而筹划的集群，它直接从应用程序执行作业，且其 main() 方法是在集群环境中执行，而非客户端。在作业提交过程中，无需预先启动 Flink 集群，再将作业部署到已存在的session集群中；这一过程被简化为一步：将应用程序逻辑及其依赖项打包为一个可执行的 JAR 文件，随后由集群的入口点（即 ApplicationClusterEntryPoint）负责启动 main() 方法，从而天生并运行 JobGraph。这种模式使得 Flink 应用程序的部署变得非常机动，比方，可以像在其他平台（如 Kubernetes）上部署平凡应用程序一样举行部署。因此，Flink Application 集群的生命周期与其承载的 Flink 应用程序的生命周期紧密相连。
  
• 资源隔离：在 Flink Application 集群中，ResourceManager 和 Dispatcher 作用于单个的 Flink 应用程序，相比于 Flink Session 集群，它提供了更好的隔离。
  
• 应用场景：Flink Job 集群可以看做是 Flink Application 集群”客户端运行“的替代方案。因此其应用场景和Flink Job集群的应用场景相似。
  

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