开发者学堂课程【开源 Flink 极速上手教程：Flink Runtime Architecture】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/331/detail/3709
Flink Runtime Architecture（一）
内容介绍：
一、总览
二、作业控制中心
三、任务的运行器
四、资源的管理中心
一、总览
1.分布式数据处理引擎
Flink 是分布式的数据处理框架。用户的业务逻辑是以教育的形式提交给 flink 集群。Flink Runtime 作为 Flink 引擎则是需要负责让这些作业能够吊起来，跑起来，然后正常的完结。而这些作业，既可以是流式作业，也可以是批式作业。而作业既可以跑在逻辑上，也就是 Flick a stand alone 集群的方式跑。也可以跑在样上，Methods上，等。Flink Runtime 必须要支持这些所有的类型的作业，以及这些所有不同条件下运行的作业。
2.作业的表达
要执行作业，首先就要理解作业，作业是如何在 flash 中进行表达的。用户首先可能通过 API 的方式来写作业，比如左边是作业的事例，还有一个虚拟的 input，就不断地输出一个一个的单词，map 操作，负责把这个单词映射成一个二元组。后面是一个keyby，使得这些二元组的相同的 word 都被分布到一起，然后将他们进行技术，最后打印出来。
而这个作业对着右边的逻辑图，这个逻辑图中有四个节点，分别是 source map sum print。他们就对应着刚才写的那些用户的业务逻辑的操作，他们是数据的处理逻辑，被称之为算子。而这些 chain 则对应的数据的分发方式，影响着一个数据是以什么样的方式分发给下游。比如 map 到 song 之间是 keyby，它意味着 map 产出的数据，同一个 key 的数据都必须分发到同一个下游。
有了逻辑图之后，Flink Runtime 会进一步的把它翻译成一个逻辑图及 job graph。叫 class，和上面逻辑图的差异在于它会把一些节点欠了进去，protein。欠的条件是需要两个 operator，及两个算子，他们的并发度是一样的，并且它们的数据交换方式是一对一的及 forward 的 partition 类型。这种情况下形成的数据，被称之为 Java hacks。map 这圈的意义在于它能够减少一些不必要的聚焦化。这样子就是欠的，他们都是在一个网站中执行。而在作业的实际执行过程中，逻辑图会进一步被翻译成执行图 graph。执行图，它是逻辑图的一个并发层面的视图，比如下面这个执行图，它就是上面逻辑图的所有算式平方度为二的一个表达。也能看出来上面的图中的 map、source 并不能圈起来。因为他们的数据是涉及到多个下游算子的。ER 逻辑图中的一个节点比较 relax，它就会对应着并发数各执行节点 existence vertex，这些节点就是对应着一个一个的任务，这些任务最后会作为实体部署到 worker 节点上去执行实际的数据处理的业务逻辑。
3.分布式架构
Flink 做为一个分布式的数据处理框架，它有一套分布式的架构，架构主要分为这么三块：Client、master、worker节点。Master是Frank集群的触控中心。Flink 可以有一个到多个 master，每个 maste r对着一个作业。而这些 maste r有一个的叫 Dispatcher 统一进行管理。此外，Master 节点中还会有一个 resource manager 进行资源管理。Resource manager 管理者所有的 worker 节点，然后是同时服务于所有的作业的。此外 master 节点中还有个 server，reserve 会用于响应各种 client 端来的请求，客户端，包括 web 端以及命令的客户端，reserve 可以发起请求，包括提交作业，查询作业的状态、停止作业等等。而像刚才提到的作业，最后会通过执行图被划分成一个一个的任务，这些任务最后都会在 worker 节点中进行执行，这些 worker 就是 task user，他们是任务执行的容器。
从上面的介绍可以看出，作业执行的核心组件有三个，分别是 ta master task excuse he resource manager。the master 用于管理作业而 tasks tasks 用于执行。master用于管理作业，而 tasks tasks tutor 用于执行，各个任务尔 resource manager 则是管理资源，并服务于叫 master 的资源请求。
二、作业控制中心（JobMaster）
1.概述
JobMaster 是作业的控制中心，它的主要职责包括所有的生命周期管理、任务的调度、出错的恢复、所有的状态查询以及分布式的状态快照。分布式状态快照包括checkpoint 和 savepoint，其中 checkpoint 主要是为出错恢复服务。savepoint 主要适用于作业的维护，包括升级和迁移等等。JobMaster 中的核心组件是 schedule。不论是作业的生命周期管理、作业的状态维护，还是任务的调度以及出错恢复，都是由 schedule 来负责的。
2.作业的生命周期
首先看一下作业的生命周期管理。作业的生命周期的一个状态迁移都如图展示出来，也包含了作业所有可能的状态。正常流程下，作业只会走到三种状态，分别是created running finished。
一个作业一开始是处于 created 状态。当这个作业被开始调度的时候，一般是等到叫maste r拿到 leadership 之后，它会进入 running 状态并开始调度任务。等到所有的任务都成功的结束了，即使走到 finish 的状态之后，这个作业也会走到 finish 的状态，并汇报最终结果，然后退出。
一个作业在执行过程中也会遇到一些问题，因此也会有异常处理的状态。在作业执行过程中如果出现错误，如果只是作业级别错误的话，整个作业会进到非零的状态。之后作业会去探索所有的任务。等到所有的任务都进入最终状态之后，包括 field canceled finished 之后，作业会去到 check。出错的异常，如果异常是不可恢复的，那么整个作业会进入 Failed 的状态并退出。如果这个异常是可恢复的，那么会走到restarting 的状态来尝试进行充气。在这儿也要判断，如果重启的次数没有超过上限。那么就做一个就可以重启，作业会被重置回 credit 的状态来重新进行调度，否则作业会走到 feel 的状态然后退出。
此外，还要看数量和 cancelling 的状态，这两种状态，只会在用户手动去探索作业的时候走到，即使当用户手动的在 web UI 或者说通过 fling com and 来探索作业的时候，Pink 会首先把状态转到。然后去探索所有的任务，等到所有的任务都进入最终状态之后，整个作业就会进入看守状态并退出。最后还有一个作业，还有一个suspended 状态，这个状态只会在配置了 high visibility，并且当叫 master 丢到leadership 之后才会走到。这个状态不意味着作业结束了，但是并只意味着这个叫master。出现问题，终止了。一般来说，等到作业叫 master 重新拿到 leadership 之后，或是另外有一个 standby master 拿到 leadership 之后，所以会在拿到 leadership 的节点上重新启动起来。
3.调度任务
任务调度是 jobmaster 的核心步骤之一。要调度任务，第一个问题就是决定什么时候去调度任务及任务调度的时机。
调度策略（SchedulingStrategy）控制调度的时机
事件驱动：
作业开始调度
任务状态变化
任务产出的数据可消费
失败任务需要重启
多种调度策略：
Eager
Lazy from sources
（WIP）Pipelined region based
目前是由调度策略及 scheduling strategy 来控制的。这个策略它是一个事件驱动的一个组件。今天的事件包括让作业开始调度任务的状态发生变化，任务产出的数据变成可以消费，以及有失败的任务需要重启。通过监听这些事件，他能够比较灵活地来决定，作业就任务系统的时机。目前有多种不同的调度策略，分别是 eagle from source eagle scheduling strategies，主要是服务于流失作业。它的策略是，会在作业开始调度的时候，直接启动所有的任务。这样做的优点就是可以降低调度的花费时间。因为都是一次性进行调度。
ER lady from sources 调度策略只是服务于批处理作业。它的策略是，一开始只调度source 节点，就比如下面这个 batch 作业，它一开始调度 source 节点，而等到有任意节点的数据可以消费之后，它才会被吊起来。也就是当 source 节点，图中 sink 节 点，它的数据开始产出之后，被吊起来，agg节点结束之后，Sink 节点才能被吊起来。其实也是为什么实际作业会和虚拟作业有不同的调度策略，这是因为作业里边儿存在一种 blocking下风，属于交换的模式。在这种模式下，需要等到上游产出的所有数据完全产出完毕之后，下游才能去消费这部分数据。因此，如果预先把下游吊起来，它只会在那儿空着，浪费资源。所以不会一开始就把它吊起来。所以相比起第一个策略而言，对于批处理作业，它能够节省一定量的资源，避免空转这种带来不必要的资源浪费。
而目前还有一个正在开发中的策略叫 plan region，为此调度策略的政策的比较类似于 lazy from sources。但是它的差异在于它是以 region 为力度来调度任务的。Region region 其实是 plan 的 region，就是说有 plan 相连的那些任务都会在同一个软件中，立刻默认的边都是 pipeline 边。然后，叛变意味着上下游节点，会流逝的进行数据交换及上游编写，然后下游就边消费边读。这个 plan reading 调度的好处在于它也一定程度上继承了调度好处，能够节省这个调度花费的时间，同时它也保留了laser from success 避免不必要的资源浪费的优势。此外通过这种把一部分他所做一个整体来调度，能够知道这一部分需要同时运行的作业，它们需要的资源量是多少，能够以此进行企业更深度的优化。
接下来讲任务调度的过程。任务也是具有很多种不同的状态的，它最初是处在一种create 的状态。当调度策略允许任务可以开始被调的时候，它会转到 schedule 的状态，并开始申请资源，就 slot 资源。ER 申请到了 slot 之后，就可以转到状态来生成坦克的描述，并部署到 worker 节点上去。再之后，就会在 worke r节点上启动起来，当成功的启动起来之后，它会在 worker 节点上转到 running 状态，并同时给master，从而 master，可以再 master 端把这个任务的状态转到 deployed，转到running。对一个无限流的作业而言，找到一半就是它的最终状态，但是对于有限流的作业，一旦所有的数据处理完毕之后，任务还会转到 finish 的状态。从而标志这个作业执行完毕。除此之外，当有异常发生的时候，任务也会转到 feel 的状态，并且其他受到影响的任务也可能会被 cancel 掉，走到 cancel 的状态。
4.出错恢复
重启出错失败的任务以及可能受其影响的任务
-停止相关任务-FAILED/CANCELED
-重置任务状态-CREATED
-通知调度策略重新调度
由出错恢复策略（FailoverStrategy）决定需要重启的任务
-RestartPipelinedRegionFailoverStrategy
-RestartAllFailoverStrategy
-单点重启？？
master 对于出错恢复的处理，当有任务出现错误的时候，将 master 策略或者基本思路是通过重启出错失败的任务以及可能受到其影响的任务来处理错误任务。
这个过程包含三个步骤，第一步是停止相关的任务，包括上面提到的出错、失败、任何可能受影响任务。失败任务已经是feel的，然后其他任务会被 cancel，最终进到cancel 的状态。接下来会把这些任务重置回credit状态，最后会通知给调度策略来重新调度这些任务。上面提到的需要重启可能受影响的任务。那么什么样的任务可能受影响？或者什么样的任务需要重启？这个其实是由恢复策略 favor strategies 来决定的。
目前 FLINK 默认的 favor strategies 是 restart the plant a region favor strategy。采用了这个策略以后，如果是 task feel 的话，会被重启。所在的 region 为什么会这样？这跟刚才聊到的 pipeline 的属于交换有关系，就是有 plan 数据交换的节点之间，如果任意一个节点失败了，那么相关连的其它节点也会跟着失败，这是白皮赞的行为，主要是为了防止出现数据的不一致，因此为了避免耽搁是非而导致多次 fever，一般会在说到第一个的时候就把其他的特色一并给 cancel 掉，来一并的进行重启。当然，这还没有结束，因为 restart pipeline region 策略除了重启失败任务所在的 region 之外，它还会重启下一个 region。这个的原因是在于任务的产出很多时候是非确定性的，就比如说一条 record，这次被分发到了下游的第一个拼法，那重跑一次，可能会分发到下游的第二个拼法，一旦两个下游在不同软件中的话，就可能会导致 record 不重要，不丢失，丢失比如产生数据的不一致。为了避免这种情况，当一个 region 发生的时候，也会重启它的所有的下游，就是说采用 region favor strategies 的话，会重启失败任务所在 region，以及它所有的下一个 region。
此外，还有一个 reset all favor strategy，这个策略，会在任意 tank，field 之后重启这个作业中的所有的任务。这个策略一般并不需要，但是在一些特殊情况下，就比如说用户希望当有任意任务失败的时候，不希望作业在局部的运行，而是宁可它整个任务都是结束，并且等到全部都能启动起来之后再一块儿运行。最后一个问题是有没有办法去只重启失败的任务本身及单点重启？其实答案肯定是有的，不过目前的话，还有一些技术难点没有突破，需要慢慢的去解决。路要一步一步走，但是在短期内可能会在接下来一到三个版本内推出一个叫 best effort 的单点重启的策略。为什么叫SF？因为在这种策略下，不保证数据的一致性，但是它的优势就在于它可以支撑起这个失败的任务本身，从而对作业的吞吐的影响最小。
