Hadoop新特性、改进、优化和Bug分析系列3：YARN-392

作者: Dong | 新浪微博： 西成懂 | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明 网址:http://dongxicheng.org/mapreduce-nextgen/hadoop-jira-yarn-392/ 本博客的文章集合:http://dongxicheng.org/recommend/ 重大消息：我的Hadoop新

作者:Dong | 新浪微博：西成懂 | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明
网址:http://dongxicheng.org/mapreduce-nextgen/hadoop-jira-yarn-392/
本博客的文章集合:http://dongxicheng.org/recommend/

Hadoop jira链接：https://issues.apache.org/jira/browse/YARN-392
所属范围（新特性、改进、优化或Bug）：新特性
修复版本：2.1.0-beta及以上版本
所属分支（Common、HDFS、YARN或MapReduce）：YARN
涉及模块：resourcemanager
英文标题：“Make it possible to specify hard locality constraints in resource requests”

背景介绍

在YARN中，用户提交应用程序后，对应的ApplicationMaster负责将应用程序的资源需求转化成符合特定格式的资源请求，并发送给ResourceManager。一旦某个节点出现空闲资源，ResourceManager中的调度器将决定把这些空闲资源分配给哪个应用程序，并封装成Container返回给对应的ApplicationMaster。ApplicationMaster发送的资源请求（ResourceRequest）形式如下（具体可阅读我的这篇文章：YARN/MRv2 ResourceManager深入解析&＃8211;ContainerAllocator解析）：

其中，Priority为资源的优先级、HostName是期望资源所在的节点，可以为节点host名、节点所在rack名或者*（任何节点均可以），Resource为资源量，#Container为满足上述三个属性的资源个数。

在2.1.0-beta版本之前，通过以上描述无法申请到这样的资源，比如“只给我节点Node1上的资源，其他节点上的不要”或者“只给我机架rack1上的资源，其他机架上的不要”，这是因为ResourceScheduler（参考我的这篇文章：YARN/MRv2 ResourceManager深入解析&＃8211;ResourceScheduler解析）自带的delay Scheduling机制导致的，这个机制来自于MapReduce架构，这个机制进一步表现了YARN是直接从MapReduce演化而来的，它对MapReduce天生的支持，而对其他框架不友好。Delay scheduling机制是为了提高数据本地性提出的，它的基本思想是，当一个节点出现空闲资源时，调度器按照调度策略应将该资源分配给job1，但是job1没有满足locality的任务，考虑到性能问题，调度器暂时跳过该作业，而将空闲资源分配给其他有locality任务的作业，今后集群出现空闲资源时，job1将一直被跳过，知道它有一个满足locality的任务，或者达到了管理员事先配置的最长跳过时间，这时候不得不将资源分配给job1（不能让人家再等了啊，亲）。从上面描述可知道，ApplicationMaster申请的node1上的资源，最终可能得到的是node2上的资源，这在某些应用场景下，是不允许如此操作的。

解决方案

在这个Jira链接中，经过讨论后，产生了两种可行方案，分别是：

【方案1】：为每个ResourceRequest添加一个bool类型变量relaxLocality以表明是否为该资源请求启动delay scheduling机制，默认是true，表示启用。举例说明：当应用程序申请rack1上node1节点上的资源时，需将rack1和ANY资源的relaxLocality值置为false，同样，当申请rack1上的资源时，需将ANY资源的relaxLocality值置为false。换句话说，某个应用程序的rack1资源请求的relaxLocality设为false的含义是YARN不会为该应用程序的分配rack1上的任何资源，直到它接下来请求rack1上的某个节点或者某些节点上的资源。

【方案2】：该方案提出将delay scheduling的延迟时间（指上面的最长跳过时间）配置下放给各个Application，而不是由管理员配置一个全局的值。这样，当需要某个节点或者机架上的资源时，只需将对应的延迟时间设置为无限大即可，同样可以巧妙的完成所需功能。

对比两种方案，感觉实现上难度和复杂度差不多，但实际上，第2种方案更加复杂：ResourceManager需要为每个ResourcRequest中的node和rack增加一个超时监控器（之前每个application有一个就行），且每次发送新的ResourceRequest后，ResourceManager需要进行较为复杂的逻辑进行资源合并和存放。相比之下，方案1则简单得多，不需要修改太多代码，不会引入过多的复杂逻辑，考虑到2.1.0-beta版本发布在即，采用方案1是明智之选。但需要注意的是，该jira并没有解决所有的资源请求语义表达方面的需求，很多语义仍不能表达出来，比如，“应用程序需要同时申请一组资源，这些资源必须同时满足应用程序才能运行”；“应用程序需要一个集合中的任何一个资源，只要获得了任何一个资源，则其他资源就不需要了”等等。

这个jira可看做实现了一个应用程序为自己添加资源白名单的需求，也就是说，只有满足某些条件的资源才分配给自己；而YARN-750则是应用程序申请将某些节点加入自己的黑名单中，此后不要为自己分配这几个节点上的资源，该功能有很多应用场景，比如在MapReduce中，当一个作业在某个节点失败的任务数据过多时，作业会将该节点加入到自己的黑名单中，此后不会再在这个节点上运行任务。

我们学到了什么？

（1） 实现一个庞大无边的功能时，在未搞清全局问题前，最好先易后难的解决问题。该jira只是YARN-397中的一个子问题，YARN-397的主题是为ResourceManager Scheduler增加新的API，以支持各种语义的资源调度，比如gang-scheduling（同时申请一组资源,参考：YARN-624）、deadline-scheduling（在规定时间内分配资源）等，这方面的需求伴随着各种应用而生，需要从各种应用程序需求中抽取出更全面的调度模型和语义表达模型。

（2）YARN调度器是一个resource-centric调度器，调度时间复杂度是O（number of nodes），而JobTracker调度器是一个task-centric调度器，调度时间复杂度是O（number of tasks），在设计YARN调度策略时，一定要牢记这一点，这是保证YARN高扩展性的前提，切莫混淆了这两种调度。

（3）YARN的调度语义在不断的演化，没有尽头。应用程序可能有各种各样的资源需求，比如需要同时获得一组资源（少一个都不行）、需要获取来自同一个rack上的资源等，这些通常是从无数类型的应用程序需求中抽象出来的，需要在不断归纳和抽象中提取，是一个漫长的路。

原创文章，转载请注明： 转载自董的博客

本文链接地址: http://dongxicheng.org/mapreduce-nextgen/hadoop-jira-yarn-392/

作者：Dong，作者介绍：http://dongxicheng.org/about/

本博客的文章集合:http://dongxicheng.org/recommend/