资源管理层的进化随着大数据相关技术的发展，相关模块的抽象和功能也更加具有专注性。尤其是 Hadoop 一代到二代 Yarn 的进化，以及 Mesos 的出现，我们可以看出资源管理层在大数据框架中的重要性。随着多租户的需求，资源管理层面也面临很多技术挑战，归根结底也就是如何最大化的利用集群资源以及数据和资源的隔离。
接触过 Hadoop 一代的读者，应该了解在一代 Hadoop 中，资源管理层并没有被单独的抽象出来，而是和任务管理层一起处理。相信这种架构的的缺点，很多读者已经有所了解，因而也导致了 Yarn 的产生。对于进化后的 Hadoop 而言，Yarn 将资源管理层和任务管理层分离开来，首先易于管理和理解，降低了层级之间的耦合性。这样的架构很易于向前发展，例如对多种计算框架的支持。接着，我们再来理解下计算框架的进化。首先，在大数据的概念之前，我们听到的更多的是高性能计算或并行计算。那时候的计算框架，基本都是计算密集型任务。也就是说一般情况下，我们只用关心 CPU 的利用率。而随着大数据框架的发展，数据密集型的任务也越来越多，尤其是以 Spark 为代表的内存计算框架的出现。而之前的资源管理层默认都是以 CPU 为主的一维调度，这样就显得不合理，如今耳熟能详的多维资源调度就是在这样的背景下产生的。目前最常见也就是 CPU 加内存的调度策略。多维度调度的策略和算法并不是本文要探讨的，这里也就不再多说。另外关于本文将要描述的想法和方案，目前并没有落地到某一个产品或开源框架，可以认为本文只是一种可行性方案的讨论，我也并没有实现的代码验证该方案的效率。希望读者可以通过以此开始了解其他类似的方案。
相关概念介绍为了更好的阐述本文将要描述的方法和观点，我们需要熟悉一些抽象化的概念，有的可以跟开源的某些模块联系起来理解，有些则可能需要读者自己琢磨了。
Application：一般指进行一种职能的应用框架，我们也简称为应用。
Resource：这里指的就是用于运行应用所需的计算资源，例如 CPU、内存、磁盘等。
Resource Group：将多个 Resource 资源组成的一个群组，方便管理和应用。
Multi-dimension Resource Scheduler：一种同时管理多种类型的计算资源（如 CPU 和内存）的调度策略。
Resource Fragment：多维度资源分配过程中，在某一节点产生或遗留的资源块，且无法被任何应用使用。例如当低优先级的 Application“a1”在一个节点申请了 4G 内存和 4 CPU 核数，而高优先级的 Application“a2”又在该节点强占 a1 所申请的资源，但是只强占了 3G 内存和 3 CPU 核数，那么在该节点上就会产生 1G 内存和 1 个 CPU 核数的资源碎片。又例如当该节点只有 5G 内存和 5 CPU core 时，a1 的资源申请也会造成 1G 内存和 1 个 CPU 核数的碎片，而当 a2 强占时，累积的碎片就会达到 2 G 内存和 2 个 CPU 核数。
Resource Manager（简称为 RM）：用于管理和调度集群资源的模块，也就是 Multi-dimension Resource Scheduler 的承载者。例如 Yarn 中的 Resource Manager。
Application Workload Manager：用于管理或调度某一类型任务的模块。这里我们可以认为 Yarn 的 Application Master 就是一个类似的实现。
Application Resource Proxy：为 Application Workload Manager 申请计算资源的模块。也就是说，当运行一种 Workload 的时候，Workload Manager 会通过 Resource Proxy 向资源层的 RM 申请计算资源。可以将 Proxy 本身模块化到 Workload Manager 中，也可以提出来单独作为一个 Adaptor（适配层）。
Resource Share Pool：Resource Proxy 中设定的一个资源共享池，可以将其中的资源借出给其他类型的 Workload 使用。
我们可以将以上相关的抽象概念组合在如下的图中，如下：
图 1. 相关模块的关系图 资源碎片的产生和影响其实我们已经在上小节中举例说明了资源碎片的产生。一般来说，资源碎片的产生主要和资源的维度有关。例如，当资源只有一个维度时，一般不涉及资源碎片的产生和管理。多维度的需求以及实现，也只是这几年才开始落地到类似的产品中。目前很多开源和非开源的产品，都还没有一个通用的框架体系来管理和处理资源碎片。像目前的 Yarn 中，多维资源维度一般也就是 CPU 加内存。不过随着计算框架的发展，IO 磁盘和带宽也将成为一个维度，那么资源碎片将会更容易产生，其中的原因是比较容易理解的。在实际生产环境中，资源层往往统一管理整个集群的资源，而之上的任务管理层，则可能同时运行多种不同类型的 Workload。例如，当我们在 Yarn 之上同时运行 MapReduce 和 Spark 两种计算任务时，此时 MapReduce 和 Spark 对资源的需求一般是不同的。例如 MapReduce 的 Map 阶段可能只对 CPU 要求很多，Reduce 阶段又过多的需求 IO 和网络带宽，而 Spark 可能又着重与 Mem 和 CPU。因此在默认情况下，我们需要对不同的计算任务分配不同的资源配比，如果配比差异越大，遍更容易产生资源碎片。如果集群中，机器的配置也是参差不齐，那么也会加重碎片的产生。
对于任务管理层的设计来说，它只是资源的消费者，理论上，并不需要参与资源的分配。只需要定额定时的申请和归还资源即可。资源管理层，负责统一管理和分配资源给任务层。但如果碎片过多的产生，尤其是配比差异大的碎片，会明显的导致资源的某一维度空余而又无法使用的状况。这就会严重的降低集群资源的利用率。我们可以举一个稍微极端的例子，例如当集群所有的机器都拥有 10G 内存和 10 CPU 核数的资源，而提交的 A 类型任务的资源配比需求（一个 Task）是 5G 内存和 6 CPU 核数，那么势必所有机器都会空余 5G 内存和 4 CPU 核数不能被使用。如果用户此时又提交一个优先级更高的 B 任务，Task 的资源配比需求是 5G 内存和 5 CPU 核数，此时 B 会强占 A 拥有的（一个 Task）5G 内存和 6 CPU 核数的资源。强占完成后，A 仍然握有 1 个 CPU 核的资源。那么此时某些机器上便会有两个碎片，一个是没被任何任务占用的 5G 内存和 4 CPU 核数，另一个便是 A 拥有的一个 CPU 核。如果简单粗暴的放任碎片不管，会大大增加任务的响应时间，降低了集群的资源利用率。但是如果资源管理层能将 A 的拥有的碎片资源要回来，并和机器上未分配的碎片拼接，那么就可以满足 B 任务的需求，从而提高资源的利用率。 |
