Flink提交作业和执行任务,需要以下几个关键组件:
客户端(Client)
:客户端的作用是获取Flink应用程序的代码,并作一个转换之后提交给JobManager
JobManager
:Flink集群里的管事人,对作业进行中央调度管理。它获取到要执行的作业后,会进一步处理转换,然后分发任务给众多的TaskManager
TaskManager
:真正干活的,数据的处理操作就是由TaskManager节点完成的
会话模式(Session Mode)
先启动Flink集群,保持一个会话,在这个会话种通过客户端提交作业。因为集群启动时所有资源都已经确定,所以所有提交的作业会竞争集群中的资源。比如下图中提交的三个Flink Application:
有点类似大学入学前,你在的那间宿舍已准备好,开学时和你室友分床位。会话模式比较适合于单个规模小、执行时间短的大量作业。
单作业模式(Per-Job Mode)
上面的会话模式因为资源共享会导致很多问题,为了更好的隔离资源,考虑为每个提交的作业启动一个集群,即单作业Per-Job模式
单作业模式,提前不启动Flink集群,有作业提交了,再启动一个集群。现提交现启动,每个作业都用的单独的集群,作业完成后,集群关闭,所有资源释放。类似你不住宿舍了,你现在住酒店,去前台现开现住,人走退房。单作业模式Flink无法直接自己运行,需要借助一些资源管理框架来启动集群,如K8S、Hadoop的YARN。
应用模式(Application Mode)
前面提到的两种模式下,Flink应用代码都是在客户端上执行,然后由客户端提交给JobManager的。但是这种方式客户端需要占用大量网络带宽,去下载依赖和把二进制数据发送给JobManager,加上很多情况下我们提交作业用的是同一个客户端,就会加重客户端所在节点的资源消耗。
所以解决办法就是,不要客户端了,直接把应用提交到JobManger上运行。而这也就代表着,我们需要为每一个提交的应用单独启动一个JobManager,也就是创建一个集群。这个JobManager只为执行这一个应用而存在,执行结束之后JoblManager也就关闭了,这就是应用模式。
总结1:
应用模式与单作业模式,都是提交作业之后才创建集群,不同的时,单作业模式是通过客户端来提交的,客户端解析出的每一个作业对应一个集群,而应用模式下,是直接由JobManaget执行应用程序的。
总结2:
最后,对应这三种模式,采用的部署方式可以是:
本篇只整理独立部署,后两种部署方式见下篇。
JobManager是一个Flink集群中任务管理和调度的核心,是控制应用执行的主进程。也就是说,每个应用都应该被唯一的JobManager所控制执行。JobManger又包含3个不同的组件:
分发器Dispatcher
Dispatcher主要负责提供一个REST接口,用来提交应用,并且负责为每一个新提交的作业启动一个新的JobMaster 组件
。Dispatcher也会启动一个Web UI
,用来方便地展示和监控作业执行的信息。Dispatcher在架构中并不是必需的,在不同的部署模式下可能会被忽略掉。
JobMaster
JobMaster是JobManager中最核心的组件,负责处理单独的作业(Job)。所以JobMaster和具体的Job是一一对应的
,多个Job可以同时运行在一个Flink集群中, 但每个Job都有一个自己的JobMaster。需要注意在早期版本的Flink中,没有JobMaster的概念,而JobManager的概念范围较小,实际指的就是现在所说的JobMaster。
在作业提交时,JobMaster会先接收到要执行的应用。JobMaster会把JobGraph转换成一个物理层面的数据流图,这个图被叫作“执行图”(ExecutionGraph),它包含了所有可以并发执行的任务。JobMaster会向资源管理器(ResourceManager)发出请求,申请执行任务必要的资源(任务插槽等)
。一旦它获取到了足够的资源,就会将执行图分发到真正运行它们的TaskManager上。而在运行过程中,JobMaster会负责所有需要中央协调的操作,比如说检查点(checkpoints)的协调。
资源管理器ResourceManager
ResourceManager主要负责资源的分配和管理
,在Flink 集群中只有一个。所谓资源,主要是指TaskManager的任务槽(task slots)。任务槽就是Flink集群中的资源调配单元,包含了机器用来执行计算的一组CPU和内存资源。每一个任务(Task)都需要分配到一个slot上执行
。这里的ResourceManager是Flink内置的资源管理组件,和其他资源管理平台(比如YARN)的ResourceManager不是一个东西。
TaskManager是Flink中的工作进程,数据流的具体计算就是它来做的。Flink集群中必须至少有一个TaskManager;每一个TaskManager都包含了一定数量的任务槽(task slots)。Slot是资源调度的最小单位,slot的数量限制了TaskManager能够并行处理的任务数量。
启动之后,TaskManager会向资源管理器注册它的slots;收到资源管理器的指令后,TaskManager就会将一个或者多个槽位提供给JobMaster调用,JobMaster就可以分配任务来执行了。
在执行过程中,TaskManager可以缓冲数据,还可以跟其他运行同一应用的TaskManager交换数据。
解析参数,比如我们提交作业时的-p、-c等参数,然后开始逻辑流图(StreamGraph)→ 作业图(JobGraph)→ 执行图(ExecutionGraph)→ 物理图(Physical Graph)
简单来说:
逻辑流图到作业流图,做了一个算子链的优化,减少数据交换的消耗,比如上面合并算子成算子链。
作业流图到执行流图,按并行度展开,对并行子任务进行了拆分,并明确了任务间数据传输的方式。JobMaster按照执行图去申请Slot,并把一个个任务分发到TaskManager的插槽上去
JobMaster生成执行图后,会将它分发给TaskManager;各个TaskManager会根据执行图部署任务,形成物理图。物理图主要就是在执行图的基础上,进一步确定数据存放的位置和收发的具体方式。有了物理图,TaskManager就可以对传递来的数据进行处理计算了。
Application模式下去掉了客户端,Yarn模式下,Flink自己的资源管理器已经不管事了,仅仅是一个中介,JobMaster向Flink资源管理器申请slot,它转发给Yarn的ResourceManager。且之前生成逻辑流图、作业流图的任务交给了JobMaster: