开发者学堂课程【开源 Flink 极客训练营：Flink Runtime Architecture】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/760/detail/13339
Flink Runtime Architecture
内容介绍：
一、Runtime 总览
二、作业的控制中心-JobMaster
三、任务的运行容器-TaskExecutor
四、资源的管理中心-ResourceManager
一、Runtime 总览
1、Runtime 总览-分布式数据处理引擎
分布式的数据处理框架，用户的业务逻辑会以 job 的形式提交给Flink 集群。Flink Runtime 作为 Flink 引擎需要负责让作业能够调起来、跑起来，正常的完结。作业既可以是流式作业也可以是批处理作业，既可以跑在逻辑上，也 Flink stand long 方式跑，也可以跑在 yarn 上、Mesos上、K8s上，而 Flink Runtime 支持所有类型的作业，以及所有不同条件下运行的作业。
2、Runtime 总览-作业的表达
env.addSource(new StreamingWordInput())
.map(word-> new Tuple2(word,1))
.keyBy(r->rfO).sum(1)
.print();
用户首先通过 API 的方式写作业，比如左边是一个 welcome 作业的实例，还有 input 不断地输出单词，map操作负责把单词印设成二元组，后面 keyby 使二元组的相同的 word 分部到一起，然后 sum 进行计数，最后打印出来。作业对应右边逻辑拓扑，拓扑中有四个节点，分别是 source、map、sum、print 对应刚才用户业务逻辑的操作，是数据的处理逻辑算子，而边对应数据的分发方式，影响着数据以怎样的方式分发给下游，比如 map 到 sum 之间是 keyby ，意味着 map 产生的数据同一个 key 的数据必须分发到同一个下游。
Flink Runtime会进一步把它翻译成逻辑图 Jobgraph。 Jobgraph和上面逻辑图的差异在于它会把一些节点 chain 起来，Operator chain，chain 的条件需要两个 Operator ，两个算子的并发度是一样的，并且数据交换方式是一对一的，即 forward 的 partition 类型，在这种情况下形成的 Operator chain 称之为 JobVertex ，Operator chain 的意义在于能够减少一些不必要的聚焦化，chain、operator 都是在一个中进行执行，作业的实际过程中逻辑图会进一步翻译成执行图 ExEcutionGraph ，执行图是逻辑图并发层面的视图，执行图是上面逻辑图的所有算式平方度为二的表达，图中的 map 和 sum 并不能芡起来因为数据是涉及到多个下游算子的，逻辑图中的一个节点比较 relax 会对应着并发数各执行节点Execution Vertex，对应着一个一个的任务，任务最后会作为实体部署到 work 节点上执行实际的数据处理的业务逻辑。
3、Runtime总览-分布式架构
Flink 作为分布式的数据处理框架分布式架构，主要分为三块，Client 、master、worker节点。Master 是 Flink 集群的主控中心，可以有一个到多个 JobMaster，每个 JobMaster 对应一个作业， JobMaster 由 Dispatcher 的控件统一管理。Master节点中会有 ResourceManager 进行资源管理，ResourceManager 管理所有的 worker 节点，同时赋予所有的作业。Master 节点中还有 Rest server，Rest Server 用于响应各种 client 端来的 Resr 请求，client 端包括 web 端以及命令行的客户端，可以发起请求包括提交作业、查询作业的状态、停止作业等等。作业最后会通过执行图被划分成一个一个的任务，任务最后都会在 worker 节点进行执行，worker 是 TaskExecutor 是任务执行的容器。
作业执行的核心组件有三个，分别是 JobMaster 、TaskExecutor、ResourceManager。 JobMaster 用于管理作业，TaskExecutor 用于执行各个任务，ResourceManager 是管理资源并服务于 JobMaster 的资源请求。
二、JobMaster 作业的控制中心
1、主要职责
（1）作业生命周期管理
（2）任务调度
（3）出错恢复
（4）作业状态查询
（5）分布式状态快照
分布式状态快照包括 Checkpoint 和 Savepoint，Checkpoint 主要是为出错恢复服务， Savepoint 主要适用于作业的维护，包括升级和迁移等等。布式快照是由 CheckpointCoorfinator 组件进行处罚和管理。Jobmaster 中的核心组件是 scheduler 不论是作业的生命周期管理、作业的状态维护，还是任务的调度，以及出错恢复都是由 scheduler 来负责的。
2、作业的生命周期
所有生命周期的状态迁移在图里展示出来，包含了作业所有可能的状态，正常流程下作业只会走到三种状态，分别是 created、 running 、finished。作业一开始是处于 created 状态，当作业被开始调度的时候等到 master 拿到 leadership 之后会进入running 状态，并开始调度任务。等到所有的任务都成功的结束，走到 finish 的状态之后，作业也会走到 finish 的状态，并汇报最终结果然后退出。作业在执行过程中会遇到一些问题，因此有异常处理的状态，在执行过程中如果出现错误，只是作业级别错误整个作业会进到非零的状态，之后会去探索所有的任务，等到所有的任务都进入最终状态之后，包括 failed、 canceled、 finished 之后会去 check 出错异常，如果异常是不可恢复的，整个作业会走到 field 的状态并退出，如果异常是可恢复的会会受到 Restarting 的状态尝试进行重启。如果重启的次数没有超过上限就可以重启，会被重置回credit 的状态重新进行调度，否则会走到 failed 的状态然后退出。此外还有 Cancelling 和 Canceled 两种状态，只会在用户手动去探索作业的时候走到，即使用户手动的在 web UI 或者通过 Flinkmongo 探索作业的时候，会首先把状态转到 Cancel 里，然后去探索所有的任务，等到所有的任务都进入最终状态之后，整个作业会进入 Cancel 状态并退出。最后 Flink 还有一个作业，还有一个 suspended 状态，只会在配置了 have ability，并且Jobmaster 到 leadership 之后才会走到，不意味作业结束，只意味 Jobmaster 出现问题中止，等到 Jobmaster 重新拿到 leadership 之后，或是另外 standbymaster 拿到 leadership 之后，会在拿到leadership 的节点上重新启动起来。
3、任务调度
（1）任务调动的时机
调度策略(SchedulingStrategy)控制调度的时机
事件驱动
作业开始调度
任务状态变化
任务产出的数据可消费
失败任务需要重启
多种调度策略
Eager
Lazy from sources
(WIP) Pipelined region based
任务调度是叫 master 的核心职责之一，首要的问题是决定什么时候去调度任务，起始任务调度的时机，目前是由调度策略及schedulingstrategy 来控制。这个策略是事件驱动的组件，监听的事件包括作业开始调度、任务的状态发生变化、任务产出的数据变成可以消费以及有失败的任务需要重启，通过监听这些事件能够比较灵活地来决定任务启动的时机。
目前有多种不同的调度策略，分别是 Eager 和 Lazy from sources 、Cheduling strategies 主要服务于流失作业，策略会在作业开始调度的时候直接启动所有的任务。好处是可以降低调度花费的时间，因为都是一次性进行调度。 Lazy from sources 调度策略服务于批处理作业，策略是一开始只调度 Source 节点，比如 Batch作业一开始只调度 Source 节点，等到有任意节点的数据可以消费之后，才会被调起来，但图中 Source 节点数据开始产出之后，AGG节点能被调起来，AGG 节点结束之后，Sink 节点才能被调起来， Batch 作业和 Streaming 作业有不同的调策略，因为Batch 作业里存在 blocking 属于交换的模式，需要等到上游产出的所有数据完全铲除完毕之后，下游才能去消费这部分数据集。如果预先把下游调起来只会在那空转浪费资源，所以不会一开始就调起来，所以相比起 Eager 策略，批处理作业能够节省一定量的资源，避免空转带来不必要的资源浪费。目前有正在开发中的策略。Pipelined region based 的调度策略比较类似于 Lazy from sources 策略。差异在于是以 region 力度来调度任务，Pipelined region 是有Pipelined 边相连的任务都会在同一个Pipelined region 中，Flink 默认的边都是Pipelined 边，意味着上下游节点会流逝的进行数据交换，上游编写下游边消费边读。Pipelined region调度好处在于一定程度上去继承调度好处，能够节省调度花费的时间，同时也保留了Lazy from sources 避免不必要的资源浪费。通过把一部分 task 作为整体来调度，知道一部分需要同时运行的作业需要的资源量，能够进行更深度的优化。
（2）任务调动的过程
·调度过程 -任务状态
·初始 -CREATED
·被调度，开始申请资源 -SCHEDULED
·申请到资源，开始部署 -DEPLOYING
·TE 通知 JM 部署成功 -RUNNING
任务具有很多种不同的状态，最初处在一种 created 的状态，当调度策略任务可以开始背调的时候，会转到 scheduled 的状态，并开始申请 slot 资源。申请到 slot 之后可以转到 deploy 状态来生成take 的描述并部署到 worker 节点上去，之后会在 worker 节点上启动起来，当成功启动起来之后，会在 worker 节点上转到 running状态，并通知 Jobmaster 在 Jobmaster 端把任务的状态转到running，无限流的作业转到 running 是最终的状态，对于作业一旦所有的数据处理完毕之后，任务还会转到 finish 的状态标志作业执行完毕，当有异常发生的时候，任务也会转到 fail 的状态，并且会引起其他受到影响的任务，也可能会被 Cancel 掉走到 Cancel 的状态。
