开发者学堂课程【开源 Flink 极速上手教程：Flink Runtime Architecture】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/331/detail/3709
Flink Runtime Architecture（二）
三、任务的运行器（TaskExecutor）
TaskExecutor 的资源模型
Process memory
JVM memory
Flink memory
Framework memory
Task memory
Task Slot 对应 Task 资源的子集，目前为TE的资源按照 slot 数量进行均分
Task Heap memory
Task Off-heap memory
Network memory
Managed memory
Task Slot 是任务运行的逻辑容器，需要满足任务的资源需求
TaskExecutor 是任务的运行容器，为了运行任务它具有各种各样的资源。这里主要看到的是 memory 的资源，这些所有的内存资源都是可以进行单独配置的。此外 task manage r 也对它们的配置进行了分层的管理，最外层是 process memory 其实对应了整个 taskExecutor 的 JVM 的总资源这份内存，又包含了 JVM 资源占用的内存以及 flink 占用的内存。而 flink 占用的内存又包含了框架占的内存和任务占用内存，任务占用内存包括了 task is memory 即时任务的对象占用的内存。memory一般适用于 native，而 knowledge in memory 则是受管控的 of his memory，这个会被一些组件用到，比如说 rocks DB，比如个别的 batch 的 operator，比如 thought he join等。而这些 task 的资源会被划分成一个一个的 slot，这些 slot 是任务运行的逻辑容器。在当前的话，四号大小是直接把它的资源，整个 tasks Qu 的资源是按照 slot 的数量进行均分得到的。
1.Task Slot 共享
共享一个共享组（SlotSharingGroup）
中的不同类型（JobVertex）的任务，
可以同时在一个slot中运行
-降低数据交换开销
-方便用户配置资源
-均衡负载
slot 是 task 的运行容器，但是一个 slow 里边儿可运行一个到多个任务，这个地方是有一定约束的，即同一个共享组中的不同类型的任务才可以同时在一个 Excel 中运行。一般来说，同一个排版 region 中的任务都是在一个共享组中，而流失任务的所流失作业的所有任务也都是在一个共享之中。这边不同类型指的是它们会需要属于不同的 Java tax。
借示例做一个解释，这是一个 smap sync 的一个作业，可以看到经过了部署之后，有三个 slot 中都有三个任务。分别是这三个任务是SAS maps in各一份，而有一个slot 只有两个任务，这是因为 source 只有三个拼法，没有更多拼法可以补进来。进行这种 small sharing 的好处，一个是在于可以降低数据交换的开销。像map he think 之间，它们是这种一对一的交换。可以看到实际上有物理的数据交换的这些节点都被共享在了一块儿，这样可以使得它们都属于交换在内存中进行，比如在网络中进行的开销更低。此外的话，也方便用户配置资源，通过 so sharing 的用户只需要配置N个 source，就可以保证一个虚拟作业能跑起来，这个N的话，是最大算子的拼法度。最后它也在各个算子的并发度差异不大的情况下，提高负载均衡。这是因为每个 study bur 会有更各种不同类型的算子各一份。这样，可以避免某些负债很重的sink 全体在同一个 task task scooter 中，从而避免了个别的负载特别重。
2.任务执行模型
任务（Task）在一个独占的线程中执行
Task从InputGate 中读取数据，喂给 Operator Chain，OperatorChain 会将产出数据输出到 ResultPartion 中
Source task直接通过
SourceFunction产出数据
任务的执行模型。每个任务对应的一个 OPP or train。一般来说，各个 protein 都有自己的输入和输出，输入是 input 的，输出是result partition。这些它们做一个任务总体会在一个独占的线程中执行。任务会从PK中读取数据，将它喂给operator train operator training进行业务逻辑的处理。最后会将产出的数据输出到 result partition中。这个地方有一个例外是 source task，它不从 input 中读取数据，而直接通过实施 function 来产出数据。然后向上游的result partition和下游的input之间，它们通过一个 flink 的 service 来进行数据交换。SourceTask是一个插件。目前阿夫拉莫认识现实内向 service 及下游的 input gate 会通过netty来从上游获取数据，从上游的result partition 中获取数据。此外，可以看到的是，result partition是由一个一个的Sub partition 组成的，每个Sub partition 都对应着这这种数据的不同的并发的下游消费者。ER in put 也是由一个一个 input channel 组成的，每个不同的input channel 都对应着这种输入的不同的拼法的上游。
四、资源的管理中心
ResourceManager 管理 TaskExecutor
SlotManager 管理 Slot
通过 TE-RM 心跳更新 Slot 状态，心跳信息中包含 TE 中所有的 slot 状态
Slot 申请流程
JM——RM——TE——JM，以 slot offer 的结果为准
Flink 的资源是如何进行管理的？Resource manager 是 Flink的 资源管理中心。Task is cute or 包含了各种各样的资源，ER is man 就管理着这些 task user。新启动的test is cute or 需要向 resource manager 进行注册之后，它里边的资源才能服务于作业的请求。里面有个关键组件叫做 salt manager，它管理着slot的状态。这些slot状态是通过 test his daughter 到 resource manager之间的调度来进行更新的。这条信息中包含了 sister 中的所有 solt 的状态。
有了当前所有的 slot 状态之后，Resource manager 就可以服务于作业的资源申请。当master调度一个任务的时候，会向 resource manager 发起 salt 请求，请求的resource manager 会转交给 slot manager soft manager 会去检查，它里边儿的可用的solt有没有符合请求条件的，如果有它就会相相应的taxi scooter 发起 solt 的申请。如果请求成功，XSR 会向主动向将 master offer 这个 slot 调走。之所以要这么绕一圈，是为了避免分布式带来的不一致的问题。像刚才提到 Source manager 中的source状态是用调度来进行更新的，所以存在一定的延迟。此外在整个四号申请的过程中，状态也是可能发生变化的，所以最终我们需要以 spot offer 以及它 的AK 来作为这个所有的申请的最终结果。
1. Resource manager的多种实现
StandaloneResourceManager
手动拉起 Worker
YarnResourceManager
MesosResourceManager
KubernetesResourceManager
Slot 申请过程自动拉起 Worker
Resource manager 有多种不同的实现。一般情况下，直接跑在机器上，从同一个集群的 resource manager 是 stand alone resource manager 它是需要手动的拉起，用户手动去拉起 worker 节点，这样的话就会要求用户先要了解这个作业会需要多少的总资源。但除此之外，还有一些会去自动的申请资源的 resource manager，包括resource manager message resource manager 和 carbon s resource manager。采用这些 Vs manager 之后。Resource manager 会在阿萨特的请求过程中，如果不能满足，就会自动的去拉 worker 节点拿数据。以 says manager 为例，便是master去为一个任务去请求一个 slot。将这个请求交给 Samantha Samantha 发觉没有私自申请的话，会告知杨 resource manager。says manager 就会像真正的外部的样式，Service manager 去请求 container，拿到 container 之后，它就会启动一 个task user task center 起来之后。它便会注册到这 个resource manager 中，并去告知它可用的 steam 的信息。slot manager 拿到这个信息之后就会尝试去满足当前拟定的那些 salt request，如果能够满足，就会去向 taxis tutor 发起 source 的请求，如果请求成功，sister 就会叫马赛去 offer 这个 slot。这样，用户就不需要去计算他的作业总的需要的资源量是多少了，而是只需要保证单个 Scott 的大小能够满足任务的执行就可以了。
2.总结
在 runtime 总览这一节，介绍了 flink runtime 的分布式架构以及作业的一些基本概念。在 JobMaster 这一节，介绍了 master 是如何来管理作业的状态、调度任务以及处理出错的。然后在 Task 这节，了解了 Task 的资源模型，然后 slot 的定义以及它的 So sharing 的机制，以及 Task 的任务的执行模型。最后在 resume manager 这一节，了解了 flash 是如何进行资源管理以及响应作业的资源请求的。
