深入解析 Flink 细粒度资源管理
- 细粒度资源办理与适用场景
- Flink 资源调度结构
- 依据 SlotSharinGroup 的资源装备接口
- 动态资源切开机制
- 资源恳求战略
- 总结与未来展望
一、细粒度资源办理与适用场景
在 Flink1.14 之前，运用的是一种粗粒度的资源办理方式，每个算子 slot request 所需求的资源都是未知的，在 Flink 内部用一个 UNKNOWN 的特殊值来表明，这个值能够和恣意资源标准的物理 slot 来匹配。从 TaskManager (以下简称 TM) 的视点来说，它具有的 slot 个数和每个 slot 的资源维度都是依据 Flink 装备静态决议的。
关于多数简略作业，现有的粗粒度资源办理现已能够根本满意对资源功率的要求。比方上图作业，由 Kafka 读入数据后经过一些简略的处理，终究将数据写入到 Redis 中。关于这种作业，咱们很容易将上下流并发保持一致，并将作业的整个 pipeline 放到一个 SlotSharingGroup (以下简称 SSG) 中。这种状况下，slot 的资源需求是根本相同的，用户直接调整默许的slot装备即可到达很高的资源运用功率，一同由于不同的 task 热点峰值纷歧定相同，经过削峰填谷效应，将不同的 task 放到一个大的 slot 里，还能够进一步下降全体的资源开支。
可是关于一些生产中或许遇到的杂乱作业，粗粒度资源办理并不能很好地满意他们的需求。
比方图上作业，有两个 128 并发的 Kafka source 和一个 32 并发的 Redis 维表，上下两路数据处理途径。一条是两个 Kafka source，经过 join 今后再经过一些聚合操作，终究将数据 sink 到第三个 16 并发的 Kafka 中；另一条途径则是 Kafka 和 Redis 维表进行 join，结果流入一个依据 TensorFlow 的在线推断模块，终究储存到 Reids 中。
在这个作业中粗粒度资源办理就或许导致资源运用功率下降。
首要作业上下流并发纷歧致，假如想把整个作业放到一个 slot 中，只能和最高的 128 并发对齐，对齐的过程关于轻量级的算子没有太大问题，可是关于比较重的资源消耗的算子，会导致很大的资源糟蹋。比方图上的 Redis 维表，它将一切数据都缓存到内存中来提高性能，而聚合算子则需求比较大的 managed memory 来存储 state。关于这两个算子，原本只需求别离恳求 32 和 16 份资源，对齐并发今后则别离需求恳求 128 份。
一同，整个作业的 pipeline 或许由于资源过大而无法放到一个 slot 或是 TM 中，比方上述算子的内存，再比方 Tensorflow 模块需求 GPU 来确保核算功率。由于 GPU 是一种十分昂贵的资源，集群上纷歧定有满意的数量，从而导致作业由于对齐并发而无法恳求到满意的资源，终究无法履行。
咱们能够将整个作业拆分红多个 SSG。如图所示，咱们将算子依照并发区分红 4 个 SSG，确保每个 SSG 内部的并发是对齐的。可是由于每个 slot 只需一种默许标准，仍然需求将该 slot 的一切资源维度都对齐到各个 SSG 的最大值，比方内存需求和 Redis 维表的需求对齐，managed memory 需求和聚合算子对齐，乃至扩展资源中都需求加入一块 GPU，这仍然不能处理资源糟蹋的问题。
为了处理这个问题，咱们提出了细粒度资源办理，其根本思想是，每个 slot 的资源标准都能够单独定制，用户按需恳求，最大化资源的运用功率。
综上，细粒度资源办理便是经过使作业各个模块按需恳求和运用资源来提高资源的全体运用功率。它的适用场景包括以下几种：作业中上下流 task 并发有显著差异、pipeline 的资源过大或者其中包括比较昂贵的扩展资源。这几种状况都需求将作业拆分红多个 SSG，而不同的 SSG 资源需求存在差异，这时经过细粒度资源办理就能削减资源糟蹋。此外，关于批使命，作业或许包括一个或多个 stage，不同 stage 之间资源消耗存在显著差异，相同需求细粒度资源办理来削减资源开支。
二、Flink 资源调度结构
Flink 的资源调度结构中首要有三个角色，别离是 JobMaster (以下简称 JM)，ResourceManager (以下简称 RM) 和 TaskManager。用户写好的使命首要会被编译成 JobGraph，注入资源后提交到 JM，JM 的效果便是办理 JobGraph 的资源恳求以及履行布置。
JM 中的调度相关的组件是 Scheduler，它会依据 JobGraph 生成一系列 SlotRequest，然后将这些 SlotRequest 进行聚合，生成一个 ResourceRequirement 发送给 RM，RM 接到资源声明今后，首要会检查集群中现有的资源能否满意其需求，能够的话就会向 TM 发出恳求，让他给对应的 JM 去 offer slot (这儿 slot 的分配由 SlotManager 组件来完成)。假如现有资源不行，它会经过内部的 driver 向外部的 K8s 或者 Yarn 恳求新的资源，终究 JM 接纳满意多的 slot 之后就会开端布置算子，作业才干运转起来。
顺着这个结构，接下来对细粒度资源办理中的技术实现细节和 design choice 进行分析论述。
三、依据 SlotSharingGroup 的资源装备接口
在入口处 Flink 需求将资源装备注入 JobGraph 中。这部分是 FLIP-156 中提出的依据 SlotSharingGroup 的资源装备接口，关于资源装备接口的规划挑选，首要问题是资源装备的粒度：
首要是最小的算子粒度 operator。假如用户在 operator 上装备资源的话，Filnk 需求依据 chaining 和 slot sharing 进一步将资源聚合成 slot 等级再进行资源调度。
运用这个粒度的优点是，咱们能够将资源装备与 chaining 和 slot sharing 的逻辑解耦，用户只需求考虑当前算子的需求，而无须考虑它是否和其他算子嵌在一同或者是否调度到一个 slot 中。其次，它使 Flink 能够更准确地核算每个slot的资源。假如某一个 SSG 中上下流算子具有不同的并发，那么或许 SSG 对应的物理 slot 需求的资源也是有差异的；而假如 Flink 掌握了每个算子的资源，它就有机会进一步优化资源功率。
当然它也存在一些缺点，首要是用户装备本钱过高，生产中的杂乱作业包括了大量算子，用户很难逐个装备。其次，这种状况下，很难支撑粗细粒度混合资源装备。一个 SSG 中假如既存在粗粒度，又存在细粒度的算子，会导致 Flink 无法判别其所需求的资源究竟是多少。最后，由于用户对资源的装备或估量会存在必定程度的偏差，这种偏差会不断累积，算子的削峰填谷效应也无法被有用运用。
第二种挑选是将算子 chaining 后形成的 task 作为资源装备的粒度。这种状况下，咱们有必要向用户露出 Flink 内部的 chaining 逻辑，一同 Flink 的 runtime 仍然需求依据 task 的 slot sharing 的装备进一步将资源聚合成 slot 等级再进行资源调度。
它的优缺点和算子粒度大致相同，只不过相比算子，它在用户的装备本钱上有了必定程度的下降，但这仍然是一个痛点。一同它的价值是无法将资源装备和 chaining 解耦，将 chaining 和 Flink 内部的逻辑露出给用户，导致内部潜在的优化受到约束。由于一旦用户装备了某个 task 的资源，chaining 逻辑的改动或许让 task 分裂成两个或者三个，形成用户装备不兼容。
第三种挑选是直接将 SlotSharingGroup 作为资源装备的粒度，这样对 Flink 来说资源装备所见既所得，省略了前面的资源聚合逻辑。
一同这种挑选还有以下几个优点：
- 榜首，运用户的装备更灵活。咱们将装备粒度的挑选权交给用户，既能够装备算子的资源，也能够装备 task 资源，乃至装备子图的资源，只需求将子图放到一个 SSG 里然后装备它的资源即可。
- 第二，能够较为简略地支撑粗细粒度混合装备。一切装备的粒度都是 slot，不必忧虑同一个 slot 中既包括粗粒度又包括细粒度的 task。关于粗粒度的 slot，能够简略地依照 TM 默许的标准核算它的资源巨细，这个特性也使得细粒度资源办理的分配逻辑能够兼容粗粒度调度的，咱们能够把粗粒度看作是细粒度的一种特例。
- 第三，它使得用户能够运用不同算子之间的削峰填谷效应，有用削减偏差发生的影响。
当然，也会引进一些约束，它将资源装备的 chaining 以及 Slot Sharing 耦合在了一同。此外假如一个 SSG 里算子存在并发差异，那么为了最大化资源运用功率，或许需求用户手动拆组。
归纳考虑，咱们在 FLIP-156 中，终究挑选了依据 SlotSharingGroup 的资源装备接口。除了上述说到的优点，最重要的是从资源调度结构中能够发现，slot 实践上便是资源调度中最根本的单位，从 Scheduler 到 RM\TM 都是以 slot 为单位进行资源调度恳求的，直接运用这个粒度，防止了添加系统的杂乱度。
回到示例作业，在支撑了细粒度资源办理装备接口后，咱们就能够为 4 个 SSG 装备不同的资源，如上图所示。只需调度结构严厉依照这个原则进行匹配，咱们就能够最大化资源运用功率。
四、动态资源切开机制
处理了资源装备今后，下一步便是为这些资源恳求 slot，这一步需求用到 FLIP-56 提出的动态资源切开机制。
简略回顾一下这幅图，现在最左边的 JobGraph 现已有资源了，往右走就进入了 JM、RM 和 TM 的资源调度。在粗粒度资源办理下，TM 的 slot 都是固定巨细、依据发动装备来决议的，RM 在这种状况没法满意不同标准的 slot 恳求的，因而咱们需求对 slot 的创建方式进行必定的改造。
先来看现有的静态 slot 恳求机制。实践上 TM 发动的时候 slot 就现已区分好了，而且标记了编号。它会将这些 slot 上报给 Slot Manager，slot request 来暂时 Slot Manager 会决议恳求 slot1、slot3，最后 slot1 上的 task 运转完今后会开释 slot。这种状况下，只需 slot3 处于占用的状况。咱们能够发现，这时尽管 TM 有 0.75 core，3G 的闲暇资源，但假如 job 去恳求对应资源巨细的 slot，TM 也无法满意它，由于 slot 现已提前区分好了。
因而咱们提出了动态资源切开机制。slot 不再是 TM 发动后就生成而且不变的，而是依据实践 slot 的恳求动态地从 TM 上切开下来。TM 发动时，咱们把能分配给 slot 的资源看作是一整个资源池，比方上图有 1core，4G 内存的资源，现在有一个细粒度的作业，Slot Manager 决议从 TM 上要一个 0.25core，1G 的 slot，TM 会检查自己的资源池是否能够切下这个 slot，然后动态生成 slot 并分配对应的资源给 JM，接下来这个作业又恳求一个 0.5core，2G 的 slot，Slot Manager 还是能够从同一个 TM 上恳求 slot，只需不超过闲暇资源就能够。当某个 slot 不再需求时，咱们能够将它销毁，对应的资源会回到闲暇资源池。
经过这种机制，咱们处理了细粒度资源恳求怎么满意的问题。
回到示例作业，咱们只需求起 8 个相同标准的 TM 就能调度作业，每个 TM 上带一块 GPU 来满意 SSG4，之后将 CPU 密集型的 SSG1 和内存密集型的 SSG2 和 SSG3 进行混布，对齐 TM 上全体的 CPU 内存比即可。
五、资源恳求战略
何谓资源恳求战略？它包括 RM 与 Resource Provider 还有 TM 交互时的两个决策，一个是从 Resource Provider 处恳求什么资源标准的 TM 以及各个标准 TM 各需求几个，另一个是怎么将 slot 摆放到各个 TM 中。实践上这两个决策都是在 Slot Manager 组件内部进行的。
粗粒度的资源恳求战略比较简略，由于只存在一种标准的 TM，而且 slot 标准都是相同的。在分配战略上只需求考虑是否将 slot 尽量平铺到各个 TM。但在细粒度资源办理下的战略就需求考虑到不同的需求。
首要咱们引进了动态资源切开机制。slot 的调度就能够看作一个多维装箱问题，既需求考虑怎么削减资源碎片，也需求保证资源调度功率。此外还有 slot 是否需求评价，以及集群或许对 TM 的资源标准有一些要求，比方不能过小，在 K8s 上假如 TM 资源过小，会导致发动过慢，最后注册超时，但也不能太大，会影响 K8s 的调度功率。
面临上述杂乱性，咱们将这个资源恳求战略抽象出来，定义了一个 ResourceAllocationStrategy，Slot Manager 会将当前的资源恳求和集群中现有的可用资源告知 strategy，strategy 负责决策并告知 Slot Manager 现有资源怎么分配、还需求恳求多少个新的 TM 以及它们别离的标准，还有是否存在无法满意的作业。
现在细粒度资源办理还处于 beta 版本，社区内置了一个简略的默许资源办理战略。在这个战略下 TM 的标准是固定的、依据粗粒度的装备决议的，假如某个 slot 的恳求大于资源装备，或许导致无法分配，这是它的局限性。在资源分配方面，它会顺序扫描当前闲暇的 TM，只需满意 slot 的恳求就会直接切开，这种战略保证了资源调度即便在大规模的使命上也不会成为瓶颈，但价值是无法防止资源碎片的发生。
六、总结与未来展望
细粒度资源办理现在在 Flink 中还只是 beta 版本。上图能够看到，关于 runtime 来说，经过 FLIP-56 与 FLIP-156，细粒度资源办理的工作现已根本完成了。而从用户接口的视点，FLIP-169 现已开放了 Datastream API 上的细粒度装备，详细怎么装备，能够参阅社区的用户文档。
未来，咱们的发展方向首要是以下几个方面：
- 榜首，定制更多的资源办理战略来满意不同场景，比方 session 和 OLAP 等；
- 第二，现在咱们是把扩展资源看作一个 TM 等级的资源，TM 上的每个 slot 都能够看到它的信息，之后咱们会对它的 scope 进行进一步约束；
- 第三，现在细粒度资源办理能够支撑粗细粒度混合装备，可是存在一些资源功率上的问题，比方粗粒度的 slot 恳求能够被恣意巨细的 slot 满意，未来咱们会进一步优化匹配逻辑，更好地支撑混合装备；
- 第四，咱们会考虑适配社区新提出的 Reactive Mode；
- 最后，对 WebUI 进行优化，能够展示 slot 的切分信息等。