随着公司近两年业务的快速扩张，业务数据量和数据处理需求也呈几何增长，对基础设施建设提出了较高的要求，如基础存储和计算。本文重点关注集群资源的使用和资源调度，将带您了解集群资源调度的整体过程、问题，以及我们在底层所做的一系列开发和优化工作。
从整个大数据生态系统来看，hadoop在离线计算的核心位置。为实现大数据的存储和计算，hadoop1.0提供了hdfs分布式存储和mapreduce虽然整个计算框架具有大数据处理的原型，但它不支持多种类型的计算框架，如后来spark、flink，此时没有资源调度的概念。
到了hadoop2.0减轻单个服务节点的调度压力，与各种类型的调度框架兼容，hadoop分布式资源调度框架框架---YARN（Yet Another Resource Negotiator）。Yarn如图1所示：
图1：Hadoop生态体系
Yarn通过优化的双层调度框架，将hadoop1.0中原本需要执行资源调度和任务调度的单点JobTracker分为Resourcemanager和ApplicationMaster两个角色分别负责集群的整体资源调度和单一任务的管理调度Nodemanager角色负责每个计算节点的管理。Yarn任务提交流程如图2：
图2：Yarn任务提交过程
客户端提交的任务实际上是由客户端提交的Resourcemanager直接处理，Resourcemanager启动每一项任务ApplicationMaster，任务资源申请由ApplicationMaster直接负责，这样每个框架都可以通过实现自己ApplicationMaster管理任务，申请container作为一种资源，你可以成功yarn集群将任务运行起来，资源的获取对任务完全透明，任务框架和yarn完全解耦。
Yarn开源版本实现了三种策略，即先进先出（FIFO Scheduler）、容量调度（Capacity Scheduler）和公平调度（Fair Scheduler），经过社区版本的演变，公平调度已经按队列级别实现，我们集群采用了公平调度策略。
在理解几种调度策略之前，我们首先理解一个概念：队列。Yarn队列实际上是指资源池，如果将整个集群的资源视为大资源池，Yarn这个资源池将根据用户配置进一步分为小资源池；父队列可以进一步向下划分。子队列将继承父队列的资源，不超过父队列的最大资源。整个资源队列的组织形式就像一棵多叉树。
先进先出的容量调度策略根据任务提交顺序和任务组织任务，这两种方法不太适合生产环境，因为我们的目的是让尽可能多的任务运行，并充分利用集群资源，这两种策略会导致任务堵塞和资源浪费。
生产环境中的公平调度遵循以下规则：确保任务资源分配的公平性。当小任务没有资源时，调度器将大任务释放的资源留给小任务，以确保大任务不会总是占用资源。三种调度策略的组织形式如图3所示：
图3：Yarn三种调度策略
除上述保证任务间资源公平外，公平调度还将动态调整队列大小，确保队列间资源公平。调整的基础是集群的实时负载。当集群闲置时，队列基本上可以获得配置的最大资源值；当集群繁忙时，调度器优先满足队列的最小值，并根据最小值等参数平均分配。
当单个集群达到数千个节点的规模时，单个集群Resourcemanager事实上，它已经接近了调度的性能瓶颈。进一步扩大集群社区的计划是通过联邦调度横向扩大。该方案的核心是Router，对外，Router在内部，Router管理多个集群，实际任务由Router负责转发，转发到哪个集群由Router来决定。Router实际工作流程如图4所示：
图4：Yarn的联邦调度
可见，通过Router在联邦调度模式的管理中，集群的概念实际上对用户是透明的，当群出现问题时，Router通过配置及时转移故障，将任务路由到健康集群，从而保证整个集群对外服务的稳定性。
经过两年多的集群建设，我们的集群已经达到了相当大的规模。在这样的集群规模下，保持稳定实际上是首要任务。我们在集群的稳定性方面做了很多工作，如权限控制、重要指标监控等。
除了部分稳定性建设外，另一个重点是集群资源的利用率。目前，大多数集群资源的使用都有明显的周期性规律。从图5中的集群监控可以看出，集群在清晨往往很忙，白天相对空闲。
图5:单个集群资源利用率变化图
集群高峰期的资源紧张问题仅依靠集群内部自身协调其实能取得的效果有限，我们针对这种情况是考虑在凌晨高峰期与k8s联合调度，将空闲在线资源协调部分到离线集群，后面将详细描述该方案。
除了高峰期资源短缺外，我们发现白天还会有大量的队列任务pending具体情况，我们对pending分析任务，总结出以下三项导致任务pending的问题：
1)队列配置不合理:
根据公平的调度机制，队列的实时可用资源很大程度上取决于配置的最小值。一些队列配置的最小值太小或0会直接导致队列无法获得足够的资源。
此外，如果队列配置CPU以及内存比和实际执行的任务CPU内存比过大也会导致资源不足，任务无法运行。
2)用户突然向队列提交了大量任务，资源使用超过了队列上限:
这种情况实际上与用户自身的使用有关。当任务量增加时，更适合向我们申请扩大队列。
3)不释放大任务占用资源，导致后续提交的任务无法申请启动资源:
Spark或者Flink任务与传统的Mapreduce任务运行机制不同。这两类任务将长期占用资源，导致新提交的任务无法及时获取资源。针对这一问题，我们还设计了相应的资源抢占机制，以后详细描述。
总的来说，队列配置对运行影响很大，合理优化配置往往能事半功倍。
从上面可以看出，监控中的集群大部分时间都很忙，但通过统计单个服务器的资源使用，我们发现仍有大量的资源空闲，如图6所示：
图6:单台服务器CPU和内存利用率
其实这个问题的原因是用户申请的资源往往比实际需要的资源要多得多。据我们统计，95%的资源被发现Container实际利用率低于76%， 99%的Container实际利用率低于90%。表明作业申请的资源规模存在"虚胖"问题。如果能利用这部分浪费的资源，实际上可以大大提高集群资源的利用率。我们将在后续讨论这部分浪费资源的优化利用。
社区联邦调度计划对我们来说太简单了，只是实现了简单的加权随机路由。在后续计划中，我们将获得更多的路由集群资源，Router服务会提供统一个队列和任务管理，用户只需要把任务统一提交到Router而不是关系到哪个集群。Router对所有集群的状态和负载进行统计，并为任务找到合适的资源调度。
图7：Yarn router动态路由
资源转配和资源超卖的目的是提高每个节点的实际资源利用效率。
资源转配：在调度资源时，根据历史统计值调整分配container更接近资源container资源的实际需求。通过我们的实践，资源转配可以提高10-20%的资源利用效率。
超卖资源:每一个container运行时，会产生一定的碎片，nodemanager你可以收集你的管理资源碎片，插入一些额外的container上去。我们计划通过额外的碎片调度器来完成这个过程，当有更多的碎片时，启动一些额外的container，如果碎片减少，这些额外的碎片container它将被回收。
图8:资源限售
图9：资源超卖
为了解决资源峰谷的问题，我们正在与云平台合作，通过错峰资源调度，实现在线离线资源的混合框架，提高资源的整体利用率。调度过程主要通过Yarn Router和OKE协调完成两项服务，实时资源闲而离线资源紧张时，Yarn会向OKE申请资源，实时资源紧张时，OKE会向YARN申请回收这部分资源。同时，我们引入了自研的Remote Shuffle Service来提升动态Nodemanager的稳定性。
图10：Yarn动态扩缩容
在实践过程中，我们发现用户任务会有明显的优先级区别，因此我们计划实现一个基于优先级的公平调度器，来保障高优先级任务的运行延时和效率。一个队列下的资源会优先保障高优先级任务，统一优先级的任务之间公平分配资源。同时，我们也实现了任务抢占功能，即使低级任务已经拿到了资源，高级别任务也可以用抢占调度来强行获取资源。
图11：基于优先级的公平调度
Oppo yarn权限采用神盾统一鉴权，每个用户组在神盾申请队列权限。用户通过hive，livy，或者flink等客户端直接提交的任务，都会在神盾系统上进行用户的认证和队列的鉴权，无权限的用户会被拒绝访问。
图12：Yarn队列权限管理
本文主要介绍了Yarn的基本工作原理及Yarn在OPPO的落地实践，总体来说可以归纳为以下几点：
1）Yarn作为典型的双层调度架构，突破了单层调度架构的资源和框架限制，使作业的运行和资源分配更加灵活。
2）如何优化作业pending与如何使资源利用最大化是所有调度系统都会面临的问题，对此，我们可以从自己系统本身特点来分析，寻找适合自己的解决方案。我们认为分析可以基于现有的数据统计。
3）离线和在线业务的错峰特性决定了单项业务无法充分利用所有服务器资源，通过合适的调度策略组织这些资源将会极大降低服务器成本。
主要负责YARN离线资源调度平台的开发和建设工作，对大数据基础平台的建设有较丰富的经验。
主要负责OPPO YARN集群的开发和优化工作，在大数据计算任务调度方面有丰富的经验。