hadoop2.0 yarn 之 资源调度器 基于hadoop2.2.0

java高级交流群：37341439 欢迎所有学习hadoop2.2.0的朋友加入讨论交流，分享实战经验！我们群无下限哦~~  

资源调度器是 hadoop yarn中最核心的组件之一，是resourcemanage中一个插拔式的服务组件，负责整个集群资源（container）的管理和分配。

      背景：

          hadoop最初设计目的是支持大数据批处理作业，如日志挖掘，web索引等作业，为此，hadoop仅提供了一个非常简单的调度机制：FIFO，即先来先服务，在该调度机制下，所有作业被统一提交到一个队列中，hadoop按照提交顺序依次运行这些作业。但是随着hadoop的普及，单个hadoop集群的用户量越来越大，不同用户提交的应用程序往往具有不同的服务质量要求（QoS），典型的应用有以下几种：

•      批处理作业：这种作业往往耗时很长，对时间完成一半没有严格要求，如数据挖掘，机器学习等方面的应用程序。
•      交互式作业：这种作业期望能及时放回结果（sql查询，hive）等
•      生产性作业：这种作业要求有一定量得资源保证，如统计值计算，垃圾数据分析等。

因为以上应用对硬件资源需求量也是不同的，如过滤，统计类作业一般为cpu密集型，数据挖掘，机器学习作业一般为io密集型。因此简单的fifo调度策略不仅不能满足多样化需求，也不能充分利用硬件资源。

解决方式有2种：

•      在一个物理集群上虚拟多个hadoop集群，这些集群各自拥有全套独立的hadoop服务，典型代表是HOD调度器。
•      扩展hadoop调度器，使之支持多个队列多用户，这种调度器允许管理员按照应用需求对用户或者应用程序分组，并为不同的分组分配不同的资源量。同事通过添加各种约束防止单个用户或者应用程序独占资源，进而满足各种qos需求，典型代表是yahoo！的capacity scheduler 和facebook 的fair Scheduler。

资源表示模型（container）

当前yarn支持 内存和 cpu两种资源类型的管理和分配，yarn采用了动态资源分配机制。nodemanager启动时会向resourceManager注册，注册信息中包含该节点可分配的cpu和内存总量。

• yarn.nodemanager.resource.memory-mb:可分配的物理内存总量，默认是8mb*1024，即8G
• yarn.nodemanager.vmem-pmem-ratio:任务使用单位物理内存量对应最多可使用的虚拟内存量，默认值是2.1，表示每1mb的物理内存，最多可以使用2.1mb虚拟内存总量
• yarn.nodemanager.resource.cpu-vcores:可分配的虚拟cpu个数，默认是8.为了更细粒度的划分cpu资源和考虑到cpu性能异构性，yarn允许管理员根据实际需要和cpu性能将每个物理cpu划分成若干个虚拟cpu，二管理员可以为每个节点单独配置可用的虚拟cpu个数，且用户提交应用程序时，也可指定每个人物需要的虚拟cpu个数。比如node1节点上面有8个cpu，node2上有16个cpu，且node1的cpu是node2的2倍，那么可为这2个节点配置相同数目的虚拟cpu个数，比如均为32.由于用户设置虚拟cpu个数必须是整数，每个任务最少使用node2的半个cpu。

ps：出了cpu和内存两种资源，服务器还有很多其他资源，比如磁盘容量，网络和磁盘io等，yarn可能在将来支持这些资源的调度。

y arn支持的 capacity scheduler和fair scheduler调度器对比：

	capacity scheduler	fair scheduler
目标	通用一种多用户共享hadoop集群的方法，以提高资源利用率和减小集群管理成本	通用一种多用户共享hadoop集群的方法，以提高资源利用率和减小集群管理成本
设计思想	资源按比例分配给各个队列，并添加各种严格的限制防止个别用户或者队列独占资源。	给予最大最小公平算法将资源分配给哥哥资源池或者用户
是否支持动态加载配置文件	是	是
是否支持负载均衡	否	是
是否支持资源抢占	是	是
是否支持批量调度	是	是
container请求资源力度	最小资源量的整数倍，比如container请求量是1.5gb，最小资源量是1gb，则container请求自动被规划了2gb	有专门的内存规整化参数控制，粒度更小，container请求量是1.5g，规整化值为128m，则container请求不变。
本地行任务调度优化	基于跳过次数的延迟调度	基于跳过次数的延迟调度
队列间资源分配方式	资源使用率低者优先	fair，fifo或者drf
队列内部资源分配方式	fifo或者drf	fair，fifo或者drf

名词解释：

是否支持动态加载配置文件：2种调度器的配置文件修改后是否能够动态生效。

 

是否支持负载均衡：fair schedler提供了一个基于任务数目的负载均衡机制，改机制尽可能将系统中的任务均匀分配到各个节点上，此外用户也可以根据自己的需要设计负载均衡策略。

 

是否支持资源抢占：每个队列可以设置一个最小资源量和最大资源量。为了提高资源利用率，资源调度器会将负载较轻的队列的资源暂时分配给负载较重的队列，仅当负载较轻的队列突然收到需要资源请求时，调度器才进一步将本属于该队列的资源分配给他，因为这个时候资源可能正在被别的队列使用，所以调度器要等那个队列释放资源释放资源才能将资源归还，这通常需要一段不确定的等待时间，为了防止应用程序等待时间太长，调度器等待一段时间后，发现资源并为得到释放，则进行资源抢占。

 

fifo：按照优先级高低调度，如果优先级相同，则按照提交时间先后顺序调度，如果提交时间也相同，则按照（队列或者应用程序）名称大小（字符串比较）调度。

 

fair：按照内存资源使用量比率调度，即按照used_memory/minshare大小调度（核心思想是按照该调度算法决定调度顺序。）如果一个队列中有2个应用程序同时运行，则每个得到1/2的资源，如果是3个则是1/3.

 

drf：按照主资源公平调度算法进行调度，drf被证明非常适合应用于多资源和复杂需求的环境中，因此被越来越多的系统采用，包括apache mesos。在drf算法中，将所需份额（资源比例）最大的资源成为主资源，而drf的基本设计思想则是将最大最小公平算法应用于主资源上。即drf总是最大化所有主资源中最小的。

假设系统中共有9个cpu和18gb ram，有2个用户分别运行了2种任务，分别需要的资源量为a:<1cpu,4gb>，b:<3cpu,1gb>对于用户a，每个任务要消耗总cpu的1/9和总内存的2.9，a的主资源为内存；b的主资源为cpu。

所以最终a的资源分配为：<3cpu,12gb>可以运行3个任务，b的资源分配为<6cpu，2gb>可运行2个任务。

 

原帖地址： http://blog.csdn.net/jiushuai/article/details/17733683