【论文】精读笔记5-前沿-字节跳动统一调度架构Gödel-C-研究方案梳理

📖《Gödel: Unified Large-Scale Resource Management and Scheduling at ByteDance》

2023 年 Virginia大学、字节跳动团队 发表于 CCF-B 类云计算顶级会议 SoCC。

系列博客：

1. Gödel-初步略读笔记
2. Gödel-相关工作发展脉络梳理
3. Gödel-研究方案梳理
4. Gödel-实验梳理

🎯需求

字节跳动对生产调度系统的主要要求是在异构机器上调度各种工作负载（如表 1 所列），提高资源利用率，跟上每个计算集群不断增长的机器规模，并实现高吞吐量。

在异构机器上需要调度各种工作负载（如下表）。

表1：字节跳动的工作负载分解

🛩创新

• 为了应对这些挑战，我们提出了一个名为 Gödel 的资源管理和调度系统。
  • 它为所有业务部门提供了一个统一的计算基础设施，以便在统一的资源池下运行各种工作负载。它将各种工作负载集中在每台机器上，以实现更好的资源利用率和弹性。
  • Gödel 基于 Kubernetes（事实上的开源容器编排系统）构建，但其核心调度器使用全局共享状态调度器进行了重新发明。相应地，我们还大幅增强了其周边组件。通过替换或增强重要组件，实现适应大规模的各种工作负载。
• 本文的贡献如下：
  • （1）我们引入了一种统一异构资源的新模式，以共同定位在线和离线工作负载，从而在超大规模上提供更好的拓扑亲和性、更高的资源弹性和更低的运营开销。
  • （2）我们在 Kubernetes 的基础上设计并实现了名为 Gödel 的新型资源管理和调度系统。我们对 Kubernetes 进行了多项优化和增强，以提高调度性能。
  • （3）我们在 ByteDance 的多个数据中心部署了 Gödel，这些数据中心拥有数万台机器，除了在模拟环境中进行密集测试外，我们还在实际工作负载下进行了评估。对 Gödel 的详细评估证明了它的实用性以及如何实现我们的目标。我们的结果表明，Gödel 在各种调度方案中都实现了卓越的性能和效率。
• 本文报告了我们使用 Gödel 的设计和实施情况。此外，本文还讨论了我们在 ByteDance 大规模生产中开发和运行 Gödel 的经验教训和最佳实践。

🏠架构设计

Gödel-相关工作发展脉络梳理的“动机”一节中的研究表明，粗粒度主机托管技术和单实例调度器方法无法实现我们的目标。因此，我们提出了一种名为 Gödel 的统一调度系统，用于更高效地调度超大规模集群（即 >= 20,000 个节点）中的异构工作负载（即微服务、批处理作业和机器学习作业）。

本节将介绍如何设计 Gödel 来实现我们的目标。

图 2 是 Gödel 的架构概览。

图2：Gödel 的架构概览

作为一个类似于 Kubernetes 的系统，Gödel 继承了 vanilla Kubernetes 的一些经典设计，不仅简化了开发工作，还为将来的开源铺平了道路。例如，

• 它使用 API server 为 REST 操作提供服务，并为集群的共享状态提供前端，所有其他组件都通过该前端进行交互。
• ETCD [1] 或其他键值存储为集群状态和元数据提供后端存储。
  • 由于我们发现 ETCD 可能成为调度吞吐量的瓶颈，与 Kubernetes 不同，Gödel 默认使用 KubeBrain [5] 作为高性能后端存储（KubeBrain 是一个基于高性能键值存储的元数据服务，由字节跳动开发并开源）。

Kubernetes 默认的调度器只有一个实例，所有请求都必须单独处理。因此，其调度效率远低于我们的要求。

• 为了提高调度吞吐量，Gödel调度器被设计和实施为分布式调度系统，多个调度器实例可以并行处理所有 pod 请求。
• 这种设计提供了比 vanilla Kubernetes 高得多的调度吞吐量。

Gödel 调度器主要由以下三个增强或新增组件提供支持：分发器（Dispatcher）、调度器（Scheduler）和绑定器（Binder）。为了处理不同的拓扑约束，Gödel 还依赖于自定义节点资源（CustomNodeResource，CNR）。

• 请注意，即使配置了多个调度器，分发器和绑定器也是单例（单个实例），因为它们在调度阶段不进行直接计算。

关键组件

分发器 Dispatcher

整体逻辑：分发器 Dispatcher 是调度逻辑的入口点。

• 它验证所有接收到的Job请求，并根据其资源请求和QoS优先级将它们存储在优先级队列中。
• 分发器最终将每个有效的请求转发到所需的调度器实例。图3表明了调度器的请求处理工作流程。
  • 当监控到提交的pod请求时，事件处理器被调用。
  • 事件处理器将pod请求发送到策略管理器，策略管理器使用不同的策略对pod进行排序，并从由逻辑队列表示的相应配额中扣除它们的资源请求。
  • 所有排序后的pod请求都被追加到优先级队列中。
  • 分发器从优先级队列中挑选一个pod请求，并将其转发到所需的调度器实例。
    

    

    图3：Gödel Dispatcher

逻辑队列：在分发器 Dispatcher 中，我们使用逻辑队列来表示分配给不同业务组的资源配额。

• 流程：
  • 例如，要求（asking） 100 个 CPU 内核和 256GB 内存的业务组会在 Gödel 中获得所需的配额，并为其创建一个具有已配置排序策略的逻辑队列。
    • 逻辑队列支持多种排序策略，如主导资源公平（DRF）[17]、基于优先级的排序策略、最小-最大公平（FairShare）和先进先出（FIFO）。
  • 每次该业务组部署 pod 时，请求都会转发到其预先分配的队列，消耗的资源会从其配额中扣除。
• 作用：
  • 在生产中，这些使用不同排序策略的逻辑队列通常会协同工作，在考虑公平性、优先级和响应速度的情况下处理我们的异构工作负载。
    • 例如，哥德尔还能像其他调度器（如 Kubernetes）一样实现基于优先级的调度。
      • 为了确保具有较高优先级的延迟敏感型工作负载的 SLA，这些工作负载可能会在队列中得到提升，从而以响应更快的方式进行调度。
      • 如果集群中的某些资源不足，对延迟敏感的工作负载还可能抢占（preempt）低优先级工作负载的插槽。

资源分区：分发器 Dispatcher 的另一个关键功能是使用分区（partition）/分片（sharding）在调度程序之间进行负载平衡。

• 分区数量：
  • 默认情况下，分发器 Dispatcher 从代表整个计算集群的一个分区开始，所有调度器实例都在同一分区上运行。
  • 不过，在某些情况下，如果集群分配超过 90%，或吞吐量超过 2000 个 pod/秒，且多个调度器之间的调度冲突超过 1%（所有阈值均可配置），那么 Dispatcher 会动态分区（dynamically partitions）集群，并相应地为每个调度器实例分配一组分区。
• 分区映射：
  • 启用多个调度程序实例时，群集中的节点总是根据调度程序之间的负载平衡进行分区。
  • 只有在新添加或移除调度器实例时，控制器才会动态调整节点映射。
  • 当一个或多个调度器被移除时，与之相关的节点将根据其当前负载重新分配给其他活动调度器。
  • 重新分配的开销与重新分配的节点数量成正比，但与调度吞吐量无关。

调度器 Scheduler

整体逻辑：

• 流程：调度器 Scheduler 接收来自调度器的请求，然后就节点选择和 pod 抢占做出调度决定。
• 对象：Gödel Scheduler 不对每个 pod 进行单独调度，而是对称为调度单元（Scheduling Unit）的 pod 组进行调度。
• 策略：与 Kubernetes 类似，调度决策也是通过一系列可配置插件做出的。
• 架构：如前所述，哥德尔调度器是一个分布式调度系统，可按需配置多个调度器实例。
  • 每个调度器实例可在本地分区或整个集群上独立做出调度决策。
  • 多个调度器实例通过共享状态（通过调用 API Server 到后备存储）和乐观并发进行合作。

调度范围权衡：在本地分区和整个集群上工作之间存在权衡。

• 使用本地分区优点：
  • a. 在本地分区工作可使调度器实例避免冲突，
  • b. 并减少节点过滤的时间消耗，因为扫描的节点会减少。
• 使用本地分区缺点：
  • a. 第一个代价是调度质量。
    • 例如，最适合运行 pod 的节点可能在另一个分区，即使我们可以在本地找到一个可接受的节点。
  • b. 在本地分区工作的另一个缺点是资源碎片化。
    • 以 Gang 调度为例，如果我们只在本地分区搜索可行的节点，而多个分区都有足够的资源，我们可能会错误地调度失败。
• 我们的解决方案是：配置基于需求的调度策略，以适应更多场景。
  • 当集群中存在大量资源，且调度器实例之间的冲突可以忽略不计时，每个调度器实例会在乐观并发控制下跨分区选择最佳节点。
  • 否则，我们会切换到分片模式（Sharding mode），在这种模式下，每个调度器实例只能从自己拥有的分区中寻找可行的节点，以降低冲突率。
  • 一种特殊情况是抢占，即调度器实例在本地或全局范围内都找不到合适的节点。在这种情况下，调度程序会尝试抢占优先级较低的受害 pod（victim Pod，这形容太好笑了 很生动形象），以腾出资源。

调度器数量：Gödel 允许水平扩展，可添加/删除活动调度程序实例，按需处理不同情况。

• （1）新添加的 schedulers 调度器会自动向 Dispatcher 和 API Server 注册。
• （2）然后，Dispatcher 开始将 pod 请求分派给新的 scheduler 调度器，而不会主动将 pod 迁移到现有的调度器。
• （3）当特定调度程序变为非活动状态（inactive）时，分配给它们的 pod 将被重新调度（reschedule）到活动的调度程序实例上。
• 至于调度器实例的首选数量，则取决于集群规模和系统负载。
  • 在 5.1 （EVALUATION - Scalability）中，我们将证明 “调度实例越多越好 “并不总是正确的。

绑定器 Binder

整体逻辑：

• 架构：绑定器 Binder 有一个领导者实例和两个跟随者实例作为备份（主从单活）。
• 功能：绑定器 Binder 使用乐观并发控制来解决调度冲突，支持抢占、共同调度，并最终将 pod 绑定到调度器选择的特定节点上。
  • 它的工作原理与 Kubernetes 默认调度器的绑定周期（binding cycle）类似，但必须比 vanilla Kubernetes 处理更多冲突，因为 Gödel Schedulers 调度器会在多个调度器实例中并行做出调度决策。
  • 与 Kubernetes 相比，
    • （1）调度器 - 静态选择->动态选择：在 vanilla Kubernetes 中，可以配置多个不同的调度器，但必须预先配置其中一个用来调度 pod；而 Gödel 会在运行时选择合适的调度器实例。
    • （2）冲突处理位置 - 节点->绑定器：其次，vanilla Kubernetes 在 Kubelet 上解决调度器之间的冲突，这会严重影响吞吐量，而 Gödel 在 Binder 上解决冲突，这使得重试更快、更高效。
• 流程：绑定器 Binder 使用优先队列来处理多个调度程序发送的调度决定，并按顺序处理 Pod 的绑定。被拒绝的 pod 将返回到调度器，重新进行调度。绑定决定流程如下所示：
  • 绑定器 Binder 使用细粒度方法实现乐观并发控制。绑定器 Binder 会检查单个 pod 所选节点上的所有硬约束是否都已通过，还会检查节点上是否有相同数量的可用资源。
  • 对于抢占，绑定器 Binder 会检查是否有多个调度器实例试图抢占一个节点上的同一个受害者 Pod。如果是，绑定器 Binder 会接受第一个抢占，并拒绝同一受害者上的所有其他抢占。
  • 对于 gang帮派 或 co-scheduling共同调度 作业，绑定器 Binder 会尝试解决所有 pod 的冲突。如果通过，则分别绑定所有 pod。否则，属于同一作业的所有 pod 都会被拒绝。

自定义节点资源 Custom Node Resource（CNR）

整体逻辑：

• 功能：CNR 是哥德尔引入的一种特殊的 Kubernetes 客户资源定义（Customer Resource Definition，CRD），用于实现拓扑感知调度。我们用它来定义每个节点上具有拓扑结构的可用资源。
  • （1）集群中的每个活动服务器都会在数据存储中创建一个 CNR 对象。CNR 对象的生命周期与其关联的服务器完全相同。每个 CNR 对象代表一个特定节点的拓扑结构和资源使用情况，以及该节点上每个 pod 的拓扑结构。
    • 例如，它告诉我们一个节点有多少个 NUMA 或子 NUMA，以及每个 NUMA 的 CPU/内存实时分配情况。
  • （2）有了这些信息，Gödel 就能在节点上启动 pod 之前，根据拓扑限制选择合适的节点来承载作业，从而避免节点代理（即 kubelet）遇到不必要的调度失败。
    • 例如，通过扫描 CNR，哥德尔就能知道哪个节点有空闲的 NUMA 节点用于内存敏感型作业，哪个节点有空闲带宽充足的网卡用于网络密集型作业，然后做出正确的调度决策。
  • （3）在创建或删除 pod 时，每个节点上的 Katalyst[3]代理会及时更新 CNR 对象。
    • Katalyst 是一个资源管理工具，提供 QoS。它由字节跳动开发，并已开源。

调度单元 Scheduling Unit

我们为 Gödel 引入的最重要的概念之一是调度单元（Scheduling Unit）。

• 目标：让我们回顾一下，我们希望实现的一个重要目标是统一资源池，在这个资源池中，在线或离线的异构工作负载都可以被调度到同一个集群中，以充分共享底层资源，而不会产生巨大的运行开销。
• 功能：调度单元 Scheduling Unit 是实现这一目标的关键机制。
  • 每个调度单元由一个或多个运行单元（Running Units）组成，代表最小的可部署计算单元，就像 Kubernetes 的 pod 一样。
    • 与 Kubernetes 单独调度每个 pod 不同，在 Gödel 中，调度单元是基本的可调度单元。
  • 当作业部署到集群时，部署模板（deployment template，K8s 中定义和管理Pod的一种资源对象）会映射到两级调度结构（调度和执行）。
    • （1）调度：部署 Deployment 所代表的作业 Job 被映射到一个调度单元 Scheduling Unit，其中的所有 pod/子任务 subtasks 都被转化（translate）为运行单元 Running Units。在这种情况下，所有运行单元 Running Units 都作为一个整体由 Gödel 调度器处理。
    • （2）执行：只有当 Gödel 调度器在集群中找到足够的计算资源，至少可以容纳运行单元 Running Units 的最小成员数量（Min Member）时，它们所属的调度单元才会被认定为可调度。否则，不会为该作业启动 pod。

最小成员数量 Min Member：上述功能-（2）执行部分中，最小成员数量 Min Member 是一个重要的可配置参数。通过为调度单元设置不同的 Min Member 值，我们可以处理许多复杂的场景。

• 例如，为了支持某些批处理作业可能需要的 Gang 调度，我们可以将它的 Min Member 设置为其 Running Units 数量。这意味着除非我们找到足够的计算资源来一起运行所有作业，否则由调度单元表示的作业不能在集群中进行调度和执行。
• 另一方面，如果我们使用 Gödel 运行一个微服务作业，应该将 Min Member 设置为 1，这意味着只要集群中可以启动任何作业，该作业就是可运行的。此时，这类似于使用 Kubernetes Deployment 部署微服务的情况。

目前，我们通常在 ByteDance 生产集群中部署三种或三种以上类型的应用：微服务（在线）、批处理作业（离线）和机器学习（离线）。调度单元 Scheduling Unit 帮助我们填补了在线和离线作业在调度器层面上的语义空白。

原有工具适配：不过，我们还需要一个 YARN container 适配器，以便将离线作业从原来运行的 YARN 无缝迁移到 Gödel。（YARN具体调度策略见[2]）

• 在 YARN 侧，我们保留了 YARN 框架库，允许用户在不更改配置文件和模板的情况下部署现有作业。
• 在 Gödel 侧，
  • 将 YARN 资源管理器（RM）分配周期决策（allocation cycle decisions）卸载给 Gödel 调度器，并将资源公平分配算法移至 Gödel 调度器。
  • 如图 4 所示，从操作的角度来看，我们创建了多个自定义资源定义（CRD）来模仿 YARN 的应用程序（application）、应用程序尝试（app attempts，YARN中会多次尝试运行Application，每次成为一次“运行尝试”，也可称为“运行实例”）和更多对象。
    • （1）当 YARN 收到传入请求时，其资源管理器 Resource Manager 会将请求转换为 CRD 和 pod 对应字段，并将请求提交给 Gödel API Server（图里用 Godel Ecosystem 生态来粗略表示）。
    • （2）资源管理器 Resource Manager 还会订阅 API Server 的更新，以关注更新并做出相应反应。
    • 在这种方法中，我们替换了资源管理器 Resource Manager 的调度组件 scheduling component，同时保持了与接纳管理器 admissions manager、应用管理器 application manager 和配额管理器 quota manager 的相同资源管理器操作（Resource Manager’s operations）。
    • 从最终用户的角度来看，迁移是透明的。吞吐量、资源和作业公平性保持不变或更高，已成功将数十万个节点从传统的Kubernetes和YARN集群迁移到每天运行数百万作业的Gödel集群。

图4：Yodel（YARN + Gödel）架构概述。增加了Gödel调度适配器Scheduler Adaptor以在Gödel和YARN之间转换对象（transform objects）。其次，资源管理器的调度功能（scheduling feature）卸载到Gödel，其余操作保持不变。

性能优化

Gödel 采用与 Kubernetes 类似的顺序来做出计划决策：1)筛选Filter；2)排序Prioritize；3)选择节点Select node。

• 筛选Filter：调度器注册一系列谓词（predicates，在调度过程中起着“过滤器”的作用，通过过滤掉不符合条件的节点，从而为调度器提供候选节点），寻找符合指定条件的可行节点。
  • 这种机制用于提高大规模集群的调度性能。
    • 例如，如果节点总数为 1,000 个，需进行评分 scoring 的节点百分比为 10%，则调度器在筛选Filter过程中只需找到 100 个匹配节点。这样就不必筛选所有节点，减少了需要排序的节点。
  • 不过，这样做也有缺陷，因为作业可能不会被安排到最合适的节点上。
• 排序Prioritize：这是一种对满足指定条件的节点进行评分 scoring，然后按评分对节点进行排序的方法，有助于为 pod 找到最合适的节点。
• 选择节点Select node：选择一个节点作为运行作业的保留节点。该节点在可行节点列表中评分最高。

筛选Filter和排序Prioritize是每个调度周期中最费时（expensive）的两个步骤。然而，Kubernetes 会为每个 pod 重复这两个步骤，导致调度性能不理想。
为了让 Gödel 调度器在调度吞吐量方面比 Kubernetes 默认调度器更有效，我们对这些步骤进行了一系列优化。其中最有效的两种机制是缓存可行节点（Cache Feasible Nodes）和减少评分百分比（Reduce Scoring Percentage）。

缓存可行节点（Cache Feasible Nodes）

问题：筛选Filter和排序Prioritize很耗时（time-consuming）。理想情况下，如果能缩短甚至跳过这两个步骤，我们就能及时调度更多的 pod。

发现：ByteDance 的不同部门都在内部使用我们的基础架构。但是，我们观察到，来自同一用户的一项作业的 deployment pods 中，约 90%（根据日志分析）通常具有相同的资源请求。

• 例如，社交媒体团队可能要求运行 20,000 个 HTTP Web 服务器，每个服务器配备 4 个 CPU 和 8GB 内存。
• 同样，一个数据分析团队希望运行一个包含 10,000 个子任务的大数据作业，每个任务需要 1 个 CPU 和 4GB 内存。
• 当他们提交作业部署到集群中时，每个部署中的所有 pod 都会请求相同的计算资源。

思想：因此，如果通过 “筛选Filter” 和 “排序Prioritize” 流程从一堆节点中选出的可行节点适合一个 pod/任务，那么它也应该适合同一部署中的其他节点。这一观察结果促使我们缓存可行节点，并在更多 pod 中重复使用。

算法1

解决：算法 1 演示了这一想法背后的伪代码。

• 流程：
  • （第20-31行）要运行第一个 pod，我们必须不可避免地检索可行节点列表 a list of feasible nodes，并通过 “筛选Filter” 和 “排序Prioritize” 流程对它们进行评分。
    • 一般来说，可行列表 the feasible list 中的第一个节点（即得分最高的节点）将被选中运行当前任务。
    • （第27行）列表中的其他节点将被缓存
  • （第9-19行）如果下一个 pod 有相同的资源请求，且节点状态未发生变化，则尝试与之匹配。
• 效果：这种优化方法在许多情况下将每个运行单元的节点扫描步骤的时间复杂度从 O(n) 降至 O(1)，并显著缩短了整个调度周期。因此，与 vanilla Kubernetes 相比，我们每秒能调度的 pod 数量要多得多。我们将在第 5 节 Evaluation 展示我们的成果。

减少评分百分比（Reduce Scoring Percentage）

问题：

• 如上段所述，扫描集群 scanning the cluster 以查找可行节点是调度周期中最耗时的步骤。
  • 尽管我们已通过缓存计算出的可行节点以便重复使用来优化这一步骤，但在作业/部署的每个调度周期中，仍必须对集群进行至少一次或两次扫描。
    • 例如，在每次调度第一个 pod 时，或者在集群状态发生任何变化（如节点添加/删除）时，都需要扫描集群。
• 为了找到能够托管指定 pod 的最合适节点，大多数现有的调度器都会预先选择比所需数量更多的可行节点作为候选节点。所有这些节点都有足够的资源来运行 pod，目标节点最终将从中选出。
  • 以 Kubernetes 为例，其默认调度程序会持续扫描集群，直到在过滤步骤中获得 Min（50，集群规模的配置百分比 configured_percentage of cluster size）可行节点为止。configured_percentage 的值通常大于 5%。
• 从理论上讲，可行节点列表越长，找到最佳结果的几率就越大。但考虑到节点扫描的成本不可忽略，我们并不建议最大化这个列表。

思想：为了进一步缩短完成时间，Gödel 通过减少可行节点列表的长度来调整这一步骤。我们必须在列表长度和调度质量之间做出权衡。

• 对于 Gödel，可行节点列表的最小长度应该是运行单元 Running Units 的数量。
  • 它每次都必须为一个调度单元 Scheduling Unit 的所有运行单元 Running Units 找到可行的节点。

解决：

• 为了确保我们有足够的候选节点来挑选高质量节点，我们在筛选步骤中选择了（运行单元 Running Units 数量+50）个可行节点。

效果：

• 当集群规模较小时，没有明显的区别。
• 相反，在大规模集群中，尤其是当运行单元数量很少时，这种优化会大大减少节点扫描。
• 即使一个调度单元中有很多运行单元，导致使用哥德尔技术的第一个 pod 的扫描时间很长，但由于可行节点缓存机制的存在，调度单元的整体调度时间仍然比 vanilla Kubernetes 短得多。

评分功能扩展 extend the scoring

除了性能优化，我们还扩展了丰富调度策略的评分功能。

• 在 Kubernetes 中，评分步骤对候选节点进行排名，以选择最合适的 Pod 放置位置。
  • Kubernetes 只支持针对所有工作负载的集群级评分策略。
• Gödel 继承了 Kubernetes 的评分机制。
  • 与 Kubernetes 不同的是，Gödel 调度器允许通过实施不同的评分插件来定义针对特定工作负载的评分策略。它们在计算分数时会考虑不同的因素，以适应表 1 中的异构工作负载。
    • 例如，为提高整体资源利用率，Gödel 可从两个维度进行主机托管。
      • （1）它可以将 CPU/Mem 密集型工作负载和网络密集型工作负载放在同一个节点上，以消耗各种资源。
      • （2）它还可以将对延迟敏感的工作负载（如微服务）和批处理作业混合在一起运行。延迟敏感型工作负载的服务水平协议（SLA）将如 4.1 （关键组件 Key Components） 所述得到保证。

🧠疑问

1. 分区（partition）/分片（sharding）/节点随机散装（Node shuffle，图3）之间的区别是什么？
2. 看起来 Gödel 还是在调度之后才使用 binder 进行冲突处理，那么它对 fuxi2.0 的攻击（对冲突的处理过晚）如何成立？
3. 抢占决策是如何做的？是以所有已部署 Pod 为候选、从中选择一个被抢占？感觉会很费时。
4. 目前的翻译中，没有特意区分作业job和任务task，后续会根据原文表述进一步调整。通常作业job和deployment对应，任务task和pod对应。
5. 减少评分百分比（Reduce Scoring Percentage）部分，原文可能有笔误。原文中最终选择的数量是“Scheduling Unit + 50”，但按逻辑应该是一个调度单元 Scheduling Unit 中的运行单元 Running Units 数量的和，即根据 Pod 总数 而非根据 Deployment 总数 来选择筛选数量。
6. 评分功能扩展（extend the scoring）部分，多种类型请求共置操作具体怎么实现没有明确说，感觉具体策略会对调度结果产生很大影响，不过确实不是本文的关注点所在。
7. Dispatcher部分，多个优先级队列如何汇总到一个优先级队列还是很奇怪

---

---

• 希望这篇博客对你有帮助！如果你有任何问题或需要进一步的帮助，请随时提问。
• 如果你喜欢这篇文章，欢迎动动小手给我一个follow或star。

🗺参考文献

[1] Gödel: Unified Large-Scale Resource Management and Scheduling at ByteDance

[2] YARN调度器