Hadoop的资源管理——Yarn初探

本文介绍了Hadoop中YARN的引入背景及其资源管理机制。YARN将JobTracker的职责拆分成ResourceManager、ApplicationMaster和NodeManager,提升了系统架构的优雅性和资源管理效率。ApplicationMaster负责任务调度和监控,ResourceManager则提供资源分配服务,通过这种方式增强了多类型Job的资源管理灵活性。
摘要由CSDN通过智能技术生成

首次接触Hadoop是在2011年,当时主流版本是0.20.2,很多介绍hadoop的经典书籍也是基于那个经典的版本。0.20.2虽然经典,但也有很多不够完善的地方,比如namenode的性能瓶颈,jobtracker和tasktracker资源管理机制不够高效等等。在这些制约下,当年的雅虎也有单集群5000节点,秒级terasort的成绩,可见Hadoop是一个非常成功的分布式系统。

Hadoop运行mapreduce计算任务的流程可以简化为如下步骤:

  1. 1. JobClient提交一个job到 JobTracker 中。JobTracker与集群中的机器维持heartbeat, 管理哪些程序应该跑在哪些机器上,管理所有 job 的失败、重启等生命周期各个阶段。
  2. 2. TaskTracker 负责自己所在机器的资源收集、上报、分配,资源单位简化为slot,同一时间一个slot中可以运行一个Task,TaskTracker维护slot数量,具体点就是TaskTracker知道自己所在的服务器能够支持多少个mapTask或者ReduceTask并行运行。
    3. JobTracker用job生成许多task(MapTask, ReduceTask)。根据
    搜集的TaskTracker上报的信息将Task分配到各个TaskTracker。
  3. 很多人从这个流程中总结出了一些缺陷,比如:
  4. 1. JobTracker 负担很重,当 map-reduce job 非常多的时候,会造成很大的内存开销,也增加了 JobTracker fail 的风险,这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点上限的原因。
  5. 2. 在 TaskTracker 端,以 map/reduce task 的数目作为资源的表示过于简单,没有考虑到 cpu和内存的实际使用情况,如果两个大内存消耗的 task 被调度到了一块,很容易出现 OOM。
  6. 3. 在 TaskTracker 端,把资源强制划分为 map task slot 和 reduce task slot, 如果当系统中只有 map task 或者只有 reduce task 的时候,会造成资源的浪费,也就是前面提过的集群资源利用的问题。
  7. 我们需要正确理解这些缺陷,只有当很多不同的Job需要并行运行的时候才会暴露缺陷,如果只需要运行一个Job,是有办法将资源利用率最大化的,因为我们可以手动调整map slot和reduce slot的比例,也可以设置input split size来控制单个MapTask处理的数据量,让系统的CPU利用率在Job运行过程中始终保持在80%以上(对IO密集型的计算来说已经很高了)。但当很多不同特性的Job一起运行时,即使Hadoop已经内置了几个任务调度的策略(还可以自己扩展),即使可以根据试验得出一套比较合理的配置,但资源管理的效果总会随着实际业务的变化而变差。我觉得这是因为基于人工配置项的资源管理机制在通用性方面较差。对比我熟悉的另一个分布式PaaS系统CloudFoundry(被动发现计算节点、计算节点自主上报自身资源、异步的健康检查机制),有很大差距(这也是正常的,CloudFoundry应用场景是云计算,就是玩资源管理的......)。
近些年互联网业务数据量爆炸式增长,hadoop集群的规模也越来越大,资源管理越来越受重视,毕竟机器越多,优秀资源管理框架产生的价值越大。hadoop 2.0新加入了Yarn,资源管理这项工作被分的更细致了。

  1. ResourceManager 支持分层级的应用队列,这些队列享有集群一定比例的资源。从某种意义上讲它就是一个纯粹的调度器,它在执行过程中不对应用进行监控和状态跟踪,也就不用处理应用的failover。ResourceManager 是基于应用程序对资源的需求进行调度的,资源包括:内存,CPU,磁盘,网络等等。资源管理器提供一个调度策略的插件,它负责将集群资源分配给多个队列和应用程序。
    NodeManager 是每一台机器框架的代理,是执行应用程序的容器,监控应用程序的资源使用情况 (CPU,内存,硬盘,网络 ) 并且向调度器汇报。
    ApplicationMaster 是一个详细的框架库,它结合从 ResourceManager 获得的资源和 NodeManager 协同工作来运行和监控任务,它会处理任务的failover。

    综上所述,JobTracker的职责被分散给了多个组件,其中ApplicationMaster仅需为自己的Job负责,ResourceManager成为了一个创建ApplicationMaster然后只需要问ApplicationMaster提供资源申请服务的单纯的资源管理组建。这不仅让整个系统 的架构更优美,潜在瓶颈更分散,最关键的是,每类Job甚至每个Job都会有自己的ApplicationMaster,Job的Context、Failover都是由ApplicationMaster维护的,这就意味着我们自己可以根据每类Job的特点,配置或者实现各种更优的ApplicationMaster,这彻底解决了经典MapReduce资源管理框架多类Job通用性的问题。

  2. Yarn的资源集合叫做Container,不过目前并没有实现docker、lxc这种完整的容器,仅使用cgroup对内存和CPU做了隔离,这是一个未来可期待的优化点。
  3. 客户端将job提交给RM(由调度器和app管理模块组成),RM首先会创建一个ApplicationMaster,Job相关的数据、任务切割、资源申请、task监控和failover处理都由这个AM负责。
  4. 模块间通信实现是RPC,任意两个模块之间只有一个Protocol,且总是由Client主动去连接Server。序列化使用了PB。


  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值