hadoop2.0中的jobtracker和tasktracker哪里去了??
一、低版本的hadoop下MapReduce处理流程
1.jobtracker和tasktracker简介
首先用户程序(JobClient)提交了一个job,job的信息会发送到JobTracker。
*JobTracker
*Map-reduce框架的中心
*与集群中的机器定时通信heartbeat
*管理哪些程序应该跑在哪些机器上
*管理所有job失败、重启等操作
*TaskTracker
*集群中每台机器都有的一个部分
*监视自己所在机器的资源情况/tasks运行状况
*通过heartbeat把资源情况/tasks运行状况的信息发送给JobTracker,JobTracker会搜集这些信息以给新提交的job分配运行在哪些机器上
2.问题
*JobTracker
*JobTracker是Map-reduce的集中处理点,存在单点故障
*JobTracker完成了太多的任务,造成了过多的资源消耗,当map-reduce job非常多的时候,会造成很大的内存开销,潜在来说,也增加了JobTracker fail的风险,这也是业界普遍总结出老hadoop 的Map-Reduce只能支持4000节点主机的上限
*TaskTracker
*在TaskTracker端,以map/reduce task的数目作为资源的表示过于简单,没有考虑到cpu/内存的占用情况,如果两个大内存消耗的task被调度到了一块,很容易出现OOM(内存溢出)
*在TaskTracker端,把资源强制划分为map task slot和reduce task slot,如果当系统中只有map task或者只有reduce task的时候,会造成资源的浪费,也就是前面提到过的集群资源利用的问题。
*源代码非常难读,因为一个类做了太多的事情,而代码量过多,造成class的任务不清晰,增加bug的修复和版本维护的难读。
二、Hadoop2.x的Yarn运行原理机制
为了从根本上解决旧的MapReduce框架的性能瓶颈,促进Hadoop框架的更长远发展,从0.23.0版本开始,Hadoop的MapReduce框架完全重构,叫做MapReduceV2或者Yarn.
基本思想就是将JobTracker两个主要的功能分离成单独的组件,这两个功能是:资源管理、任务调度/监控。
*ResourceManager:
ResourceManager有两个主要组件:Scheduler和ApplicationsManager。
Scheduler:(分配资源给应用程序)
*负责根据熟悉的容量,队列等约束将资源分配给各种正在运行的应用程序。它不执行应用程序状态的监视或跟踪。
*根据应用程序的资源需求执行其调度功能;它是基于资源Container的抽象概念,它包含内存,cpu,磁盘,网络等元素。
*调度程序具有可插入策略,该策略负责在各种队列,应用程序等之间对集群资源进行分区。
ApplicationsManager:(接受作业提交并执行ApplicationMaster)
*负责接受作业提交,协商第一个容器以执行特定于应用程序的ApplicationMaster
*提供在失败时重新启动ApplicationMaster容器的服务
*NodeManager:
*每一台机器框架的代理,是执行应用程序的容器,监控应用程序的资源使用情况(CPU 内存 磁盘 网络)并且向调度器汇报
*ApplicationMaster:负责从Scheduler协商适当的资源容器,并与NodeManager跟踪其状态并监视进度。
三、新旧Hadoop MapReduce框架对比
*客户端不变,其调用API及接口大部分保持兼容,这也是为了开发使用者透明化,对原码不必做大的改变,但是原框架的JobTracker和TaskTracker不见了,取而代之的是ResourceManager AppliactionMaster NodeManager三个部分。
*ResourceManager是一个中心的服务,它做的事情是:
*ResourceManager负责作业与资源的调度,接收JobSubmitter提交的作业,按照作业的上下文(context)信息,以及从NodeManager收集来的状态信息,启动调度过程,分配一个Container作为Application Master
*启动每一个Job所属的ApplicationMaster、另外监控ApplicationMaster的存在情况
*NodeManager功能比较专一,就是负责Container状态的维护,并向RM保持心跳。
*ApplicationMaster负责一个Job生命周期内的所有工作,类似老的框架中JobTracker,但注意每一个Job都有一个ApplicationMaster,他可以运行在ResourceManager以外的机器上.
四、Hadoop Yran的优势
*大大减小了JobTracker(也就是现在的ResourceManager)的资源消耗,并且让检测每一个Job子任务(tasks)状态的程序分布式化了。更安全、更优美
*在新的Yarn中,ApplicationMaster是一个可变更的部分,用户可以对不同的编程模型写自己的ApplicationMaster,让更多类型的编程模型能够跑在Hadoop集群中。
*对于资源的表示以内存为单位,比之前以剩余slot数目更合理
*老的框架中,JobTracker一个很大的负担就是监控job的运行状况,现在,这个部分就扔给ApplicationMaster了,而ResourceManager中有一个模块叫做ApplicationsManager,它是检测ApplicationMaster的运行状况,
如果出问题,会将其在其他机器上重启
*Container是Yarn为了将来做资源隔离而提出的一个框架,这一点应该借鉴了Mesos的工作,目前是一个框架,仅仅提供Java虚拟机内存的隔离,hadoop团队的设计思路应该后续能支持更多的资源调度和控制,既然资源表示成内存量,
那就没有了之前的map slot/reduce slot分开造成集群资源闲置的尴尬情况。
转载:https://blog.csdn.net/weixin_38655836/article/details/80333404