Flink Run time解析

整体架构

Flink Run time解析_第1张图片

以上是flink的整体架构,今天我们一起来学习一下Flink的Runtime这一层。

Runtime架构

Flink Run time解析_第2张图片

这个是runtime的架构,基本上一目了然。

图中可以看到,

1.client向cluster Management(standalone、yarn、messos、K8S)提交app请求。同时,client也会完成作业的编译以及优化的过程,譬如哪些task可以连在一块,输出输入类型是否匹配等,它将用户编写的table、stream、patch等转换成可以提交的jobGraph。

2.cluster启动一个AM(application master),在这个AM中又有三个组件,分别是dispatcher,ResourceManager,JobManager。AM也会将一些元数据信息存储的外部系统中

    dispatcher:用来接受用户提交的作业,然后负责将JobManager拉起来。

    ResourceManager:负责资源管理的,不是yarn里面的RM,,这个是单独的一个,在AM里面。

    JobManager:负责作业执行,将jobGraph转换为ExecutionGraph。在作业的生命周期里面,可能会有多个任务(yarn session模式),所以可能会有多个jobmanager。

3.JobManger接受到jobGraph后,向AM里的RM,去申请资源。如果这个时候,是yarn session的模式,那么RM会直接去找TM(Task Manager)去申请slot。如果不是,那么就会去找cluster Management去申请资源,然后cluster Management就会去启动Task Manager,然后,RM就可以去向TM去拿slot了,因为RM是知道TM的slot的使用情况,所以它是去通知TM,这个slot,JM要用了,而不是去和TM申请slot。

4.当TM接受到slot申请的时候,它就会把待分配的slot告诉JM,然后JM收到后,就会像对应的TM去提交task。TM接收到task后,就在slot中启动这些task。当所有task都启动后,这些task之间就会互相通信。会通过flink的shuffle模块来交互数据。

这里就提到了flink的两种运行模式:per-Job、session

Per-Job:

  • 独享Dispather与Resource Manager  
  • 按需要申请资源(即TaskManager)
  • 适合执行时间较大的作业

Session:

  • 共享Dispatcher和Resource Manager
  • 功效资源(即TaskManager)
  • 适合规模小,执行时间短的作业

资源管理与作业调度

slot管理

Flink Run time解析_第3张图片

 slot管理主要分为三块:

ResourceManager: 主要是Slot Manager模块

  • slot Manager:负责维护TM上的slot和slot的状态,并且有资源申请的时候,负责管理和分配slot的资源

TaskManager:实际持有slot资源,当slot的task任务结束后(不管是正常结束或者是异常结束),TM都会将信息发送给RM,告诉RM这个slot已经被释放掉了。同时,TM也会定期向RM、JM发送心跳,在心跳中会带上slot的信息,防止信息丢失。

JobManager:slot资源的申请者,他会管理整个task的进度。当JM接受到TM发过来的offerslot的时候,它会把slot的信息缓存在slotpool中。slotpool,会将受到的slot会前面的request进行匹配,匹配上后,就会将task分配到对应的slot中去。

slot sharing

Flink Run time解析_第4张图片

单个slot中部署多个task,同一个Vertex的多个task能共享,意思是,A1,A2不能共享一个task

作业DAG图结构

 Flink Run time解析_第5张图片

Job-Graph:

  客户端提交的作业DAG图结构,是逻辑结构,不考虑并发

ExecutionGraph

JobManager实际维护的数据结构,是物理结构,考虑并发。

Flink作业调度策略

Flink Run time解析_第6张图片

Eager调度:适用于流作业。一次性调度所有的Task。

Lazy_From_Source:适用于批作业,上游作业执行完成后,调度下游的作业,所以相对来说,slot会占用的少一点,如图中,只要两份,因为但一个task(图中的绿点)运行完成后,slot就空出来了,可以给下面的task用。

错误恢复

Flink的错误又可以分为:Task Failover和Master Failover

Task Failover:1.单个task执行失败或TM出错退出等 2.可以有多种不同的恢复策略

Master Failver:AM执行失败

Task Failover

Restart-all

重启所有Task,从上次的Checkpoint开始重新执行

Flink Run time解析_第7张图片

Restart-individual

只能重启出错的Task,这个只能用于Task间无连接的情况,应用极为有限

Flink Run time解析_第8张图片

Restart-Region

这里涉及到两个概念:Pipeline边和blocking边

Pipeline指的是上游一个分区的数据都被下游的一个分区应用,如下图的A1-》B1或者C1-》D1这种的。如果是流式作业,那么A和B会同时起来,那么这个时候数据直接走网络就可以了

Blocking指的是上游的一个分区的数据被下游的多个分区所应用,如下图的B1-》C1和B1-》C2。像这种就是一般在批计算中,B1先起来,然后将数据写入磁盘或者一块内存中,供后续的task使用。

 这个时候,它的策略是重启Pipeline Region :  Blocking数据落盘,可以直接读取,逻辑上仅需重启通过pipeline边关联的Task。

它一般包括两种错误类型:1.作业自身执行失败  2.作业读取上游数据失败。

下图是两者错误类型所重启的region:

第一种:D1失败:

Flink Run time解析_第9张图片

第二种:C1失败

Flink Run time解析_第10张图片

 

Master Failover

多个Master通过ZK进行选主,目前Master Failover要求全图重启。

你可能感兴趣的:(flink)