【大数据系列】hadoop2.0中的jobtracker和tasktracker哪里去了
低版本的hadoop下MapReduce处理流程
1、首先用户程序(JobClient)提交了一个job,job的信息会发送到Job Tracker,Job Tracker是Map-reduce框架的中心，他需要与集群中的机器定时通信heartbeat,需要管理哪些程序应该跑在哪些机器上，需要管理所有job失败、重启等操作。
2、TaskTracker是Map-Reduce集群中每台机器都有的一个部分，他做的事情主要是监视自己所在机器的资源情况。
3、TaskTracker同时监视当前机器的tasks运行状况。TaskTracker需要把这些信息通过heartbeat发送给JobTracker,JobTracker会搜集这些信息以给新提交的job分配运行在哪些机器上。
但是随着集群规模个工作负荷的增长，原框架的问题便暴露出来了。
1、JobTracker是Map-reduce的集中处理点，存在单点故障
2、JobTracker完成了太多的任务，造成了过多的资源消耗，当map-reduce job非常多的时候，会造成很大的内存开销，潜在来说，也增加了JobTracker fail的风险，这也是业界普遍总结出老hadoop 的Map-Reduce只能支持4000节点主机的上限。
3、在TaskTracker端，以map/reduce task的数目作为资源的表示过于简单，没有考虑到cpu/内存的占用情况，如果两个大内存消耗的task被调度到了一块，很容易出现OOM
4、在TaskTracker端，把资源强制划分为map task slot和reduce task slot如果当系统中只有map task或者只有reduce task的时候，会造成资源的浪费，也就是前面提到过的集群资源利用的问题。
5、源代码非常难读，因为一个类做了太多的事情，而代码量过多，造成class的任务不清晰，增加bug的修复和版本维护的难读。
新hadoop yarn框架原理及运行机制
为了从根本上解决旧的MapReduce框架的性能瓶颈，促进Hadoop框架的更长远发展，从0.23.0版本开始，Hadoop的MapReduce框架完全重构，叫做MapReduceV2或者Yarn.
基本思想就是将JobTracker两个主要的功能分分离成单独的组件，这两个功能是资源管理和任务调度/监控。新的资源管理器全局管理所有应用程序计算资源的分配。每一个应用的ApplicationMaster负责相应的调度和协调。一个应用程序无非是一个单独的传统的MapReduce任务或者是一个DAG(有向无环图)任务。ResourceManager和每一台机器的阶段管理服务器能够管理用户在哪台机器上的进程并能对计算进行组织。
事实上，每一个应用的ApplicationMaster是一个详细的框架库，它结合从ResourceManager获得的资源和NedoManager协同工作运行和监控任务。
ResourceManager支持分层级的应用队列，这些队列享有集群一定比例的资源。从某种意义上讲他就是一个纯粹的调度器，它在执行过程中不对应用进行监控和状态跟踪。同样，它也不能重启因应用失败或者硬件错误而运行失败的任务。
ResourceManager是基于应用程序对资源的需求进行调度的；每一个应用程序需要不同类型的资源因此就需要不同的容器。资源包括：内存、CPU、磁盘、网络等。可以看出，这同现在MapReduce固定类型的资源使用模式有显著区别，它给集群的使用带来负面的影响，资源管理器提供一个调度策略的插件，它负责将集群资源分配给多个队列和应用程序，调度插件可以基于现有的能力调度和公平调度模型。
图中NodeManager是每一台机器框架的代理，是执行应用程序的容器，监控应用程序的资源使用情况（CPU 内存 磁盘 网络）并且向调度器汇报。
每一个应用的ApplicationMaster的职责有：向调度器索要适当的资源容器，运行任务，跟踪应用程序的状态和监控他们的进程，处理任务的失败原因。
新旧Hadoop MapReduce框架对比
1、客户端不变，其调用API及接口大部分保持兼容，这也是为了开发使用者透明化，对原码不必做大的改变，但是原框架的JobTracker和TaskTracker不见了，取而代之的是ResourceManager AppliactionMaster NodeManager三个部分。
2、ResourceManager是一个中心的服务，它做的事情是调度、启动每一个Job所属的ApplicationMaster、另外监控ApplicationMaster的存在情况。Job里面所在的task的监控，重启等内容不见了，这就是ApplicationMaster存在的原因。ResourceManager负责作业与资源的调度，接收JobSubmitter提交的作业，按照作业的上下文(context)信息，以及从NodeManager收集来的状态信息，启动调度过程，分配一个Container作为Application Master
3、NodeManager功能比较专一，就是负责Container状态的维护，并向RM保持心跳。
4、ApplicationMaster负责一个Job生命周期内的所有工作，类似老的框架中JobTracker,但注意每一个Job(不是每一种)都有一个ApplicationMaster,他可以运行在ResourceManager以外的机器上.
Hadoop yarn优势
1、大大减小了JobTracker（也就是现在的ResourceManager）的资源消耗，并且让检测每一个Job子任务（tasks）状态的程序分布式化了。更安全、更优美
2、在新的Yarn中，ApplicationMaster是一个可变更的部分，用户可以对不同的编程模型写自己的ApplicationMaster，让更多类型的编程模型能够跑在Hadoop集群中。
3、对于资源的表示以内存为单位，比之前以剩余slot数目更合理
4、老的框架中，JobTracker一个很大的负担就是监控kob下的tasks的运行状况，现在，这个部分就扔给ApplicationMaster了，而ResourceManager中有一个模块叫做ApplicationsMaster,它是检测ApplicationMaster的运行状况，如果出问题，会将其在其他机器上重启
5、Container是Yarn为了将来做资源隔离而提出的一个框架，这一点应该借鉴了Mesos的工作，目前是一个框架，仅仅提供Java虚拟机内存的隔离，hadoop团队的设计思路应该后续能支持更多的资源调度和控制，既然资源表示成内存量，那就没有了之前的map slot/reduce slot分开造成集群资源闲置的尴尬情况。
配置hadoop yarn
<property> <name>yarn.resourcemanager.hostname</name> <value>www.node1.com</value> </property> <property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value> </property> </configuration>
