Hadoop的资源管理——Yarn初探

首次接触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。