Flink Run time解析

整体架构

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

Runtime架构

这个是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管理

 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

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

作业DAG图结构

 

Job-Graph：

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

ExecutionGraph

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

Flink作业调度策略

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开始重新执行

Restart-individual

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

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失败：

第二种：C1失败

 

Master Failover

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