赞
踩
Flink的运行时架构中,最重要的就是两大组件:作业管理器(JobManger)和任务管理器(TaskManager)。对于一个提交执行的作业,JobManager是真正意义上的“管理者”(Master),负责管理调度,所以在不考虑高可用的情况下只能有一个;而TaskManager是“工作者”(Worker、Slave),负责执行任务处理数据,所以可以有一个或多个。Flink的作业提交和任务处理时的系统如下图所示。
上图中的客户端并不是处理系统的一部分,它只负责作业的提交。具体来说,就是调用程序的main方法,将代码转换成“数据流图”(Dataflow Graph),并最终生成作业图(JobGraph),一并发送给JobManager。提交之后,任务的执行其实就跟客户端没有关系了,我们可以在客户端选择断开与JobManager的连接, 也可以继续保持连接。
TaskManager启动之后,JobManager会与它建立连接,并将作业图(JobGraph)转换成可执行的“执行图”(ExecutionGraph)分发给可用的TaskManager,然后就由TaskManager具体执行任务。接下来,我们就具体介绍一下JobManger和TaskManager在整个过程中扮演的角色。
JobManager是一个Flink集群中任务管理和调度的核心,是控制应用执行的主进程。也就是说,每个应用都应该被唯一的JobManager所控制执行。当然,在高可用(HA)的场景下,可能会出现多个JobManager;这时只有一个是正在运行的领导节点(leader),其他都是备用节点(standby)。
JobManger又包含3个不同的组件,下面我们一一讲解。
JobMaster是JobManager中最核心的组件,负责处理单独的作业(Job)。所以JobMaster 和具体的Job是一一对应的,多个Job可以同时运行在一个Flink集群中, 每个Job都有一个自己的JobMaster。需要注意在早期版本的Flink中,没有JobMaster的概念;而JobManager 的概念范围较小,实际指的就是现在所说的JobMaster。
在作业提交时,JobMaster会先接收到要执行的应用。这里所说“应用”一般是客户端提交来的,包括:Jar包,数据流图(dataflow graph),和作业图(JobGraph)。
JobMaster会把JobGraph转换成一个物理层面的数据流图,这个图被叫作“执行图”(ExecutionGraph),它包含了所有可以并发执行的任务。JobMaster会向资源管理器(ResourceManager)发出请求,申请执行任务必要的资源。一旦它获取到了足够的资源,就会将执行图分发到真正运行它们的TaskManager上。
而在运行过程中,JobMaster会负责所有需要中央协调的操作,比如说检查点(checkpoints)的协调。
ResourceManager主要负责资源的分配和管理,在Flink 集群中只有一个。所谓“资源”,主要是指TaskManager的任务槽(task slots)。任务槽就是Flink集群中的资源调配单元,包含了机器用来执行计算的一组CPU和内存资源。每一个任务(Task)都需要分配到一个slot上执行。
Dispatcher主要负责提供一个REST接口,用来提交应用,并且负责为每一个新提交的作业启动一个新的JobMaster 组件。Dispatcher也会启动一个Web UI,用来方便地展示和监控作业执行的信息。Dispatcher在架构中并不是必需的,在不同的部署模式下可能会被忽略掉。
TaskManager是Flink中的工作进程,数据流的具体计算就是它来做的,所以也被称为“Worker”。Flink集群中必须至少有一个TaskManager;当然由于分布式计算的考虑,通常会有多个TaskManager运行,每一个TaskManager都包含了一定数量的任务槽(task slots)。Slot 是资源调度的最小单位,slot的数量限制了TaskManager能够并行处理的任务数量。
启动之后,TaskManager会向资源管理器注册它的slots;收到资源管理器的指令后,TaskManager就会将一个或者多个槽位提供给JobMaster调用,JobMaster就可以分配任务来执行了。
在执行过程中,TaskManager可以缓冲数据,还可以跟其他运行同一应用的TaskManager 交换数据。
Flink的提交流程,随着部署模式、资源管理平台的不同,会有不同的变化。这里我们从一个高层级的视角,来做一下抽象提炼,看一看作业提交时宏观上各组件是怎样交互协作的。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。