Hadoop——分布式资源管理框架YARN总结

分布式资源管理框架YARN

1. YARN概述

  YARN是“Yet Another Resource Negotiator”的简称。
  在进一步了解 YARN 框架之前我们需要知道，相比较而言，MapReduce 则是 YARN 的一个特例。 YARN 则是 MapReduce 的一个更加通用和高级的框架形式，并在其上增加了更多的功能。例如通过加载分布式执行脚本可以在集群节点上执行独立的脚本任务，并且更多功能正在被追加中。
  所以我们可以看到，YARN 可以直接运行在 MapReduce 运行的框架上而不会造成更多的干扰，并且会为集群的运算带来更多的好处。更一步的开发显示了 YARN 会允许开发者根据自己的需求运行不同版的MapReduce 在集群中，这将为开发者提供更为便捷的服务。
  普遍认为，云计算包括以下几个层次的服务: IaaS、PaaS和SaaS。这里所谓的层次，是分层体系架构意义上的“层次”。laas. Paas、 Saas分别实现在基础设施层、软件开放运行平台层、应用软件层。

• IaaS(Infrastructure-as-a-Service):基础设施即服务。消费者通过Internet可以从完善的计算机基础设施获得服务。laas 通过网络向用户提供计算机(物理机和虚拟机)、存储空间、网络连接、负载均衡和防火墙等基本计算资源;用户在此基础上部署和运行各种软件，包括操作系统和应用程序等。
• PaaS(Platform-as-a-Service):平台即服务。PaaS 是将软件研发的平台作为一种服务，以SaaS的模式提交给用户。平台通常包括操作系统、编程语言的运行环境、数据库和Web服务器等，用户可以在平台上部署和运行自己的应用。通常而言，用户不能管理和控制底层的基础设施，只能控制自已部署的应用。
• SaaS(Software-as-a-Service):软件即服务。它是一种通过Internet提供软件的模式，用户无需购买软件，而是向提供商租用基于Web的软件，来管理企业经营活动。云提供商在云端安装和运行应用软件，云用户通过云客户端(比如Web浏览器)使用软件。

  从云计算分层概念上讲，YARN可看做PAAS层，它能够为不同类型的应用程序提供统一的管理和调度。

2. YARN 设计目标

  通用的统一资源管理系统
  同时运行长应用程序和短应用程序

• 长应用程序
  通常情况下，永不停止运行
  Service（Spark、Storm）、HTTP Server等
• 短应用程序
  短时间（秒级、分钟级、小时级）内会运行结束的程序
  MR job、Spark Job等

3.Hadoop1 MapReduce (架构理解图)

4. YARN架构

关于上图架构 ,主要包括以下几种角色
ResourceManager(RM)：
  主要接收客户端任务请求，接收和监控NodeManager(NM)的资源情况汇报，负责资源的分配与调度，启动和监控ApplicationMaster(AM)。
NodeManager：
  主要是节点上的资源管理，启动Container运行task计算，上报资源、container情况给RM和任务处理情况给AM。
ApplicationMaster：
  主要是单个Application(Job)的task管理和调度，向RM进行资源的申请，向NM发launch Container指令，接收NM的task处理状态信息。

ResourceManager是Yarn的核心, 负责调度Application master, 来给每个NodeManager分配资源, 资源储存在Container中, 此处的资源包括JVM,内存等, 然后将程序copy到container中运行, container还需要回报状态给App master, 再有app master汇报给Resource manager, nodeManager也要按时汇报ResourceManager当前节点的资源使用情况.
下面简单介绍以下提交一个job的处理过程
1、client submit一个job到RM，进入RM中的Scheduler队列供调度(Scheduler负责申请资源)
2、RM根据NM汇报的资源情况(NM会定时汇报资源和container使用情况)，请求一个合适的NM launch container，以启动运行AM
3、AM启动后，注册到RM上，以使client可以查到AM的信息，便于client直接和AM通信
4、AM启动后，根据Job 相关的split的task情况，会和RM协商申请container资源
5、RM分配给AM container资源后，根据container的信息，向对应的NM 请求launch container
6、NM启动container运行task，运行过程中向AM汇报进度状态信息，类似于MRv1中 task的汇报；同时NM也会定时的向RM汇报container的使用情况。
7、在application(job)执行过程中，client可以和AM通信，获取application相关的进度和状态信息。
8、在application(job)完成后，AM通知RM clear自己的相关信息，并关闭，释放自己占用的container。

5.YARN调度管理

yarn分为一级调度管理和二级调度管理

• 一级调度管理 (更近底层,更接近于操作资源, 更偏向于应用层和底层结合)
  计算资源管理(cpu,内存等,计算复杂消耗的cpu多)
  App生命周期管理
• 二级调度管理 (自己代码的算法等, 更偏向于应用层)
  App内部的计算模型管理
  多样化的计算模型

6. YARN 服务组件

• 组件： Client、 runjar 、 MRAppMaster、ResourceManager、Application Master NodeManager、Container yarnchild
• container 容器 （1.启动 appmaster 2.container 列表 yarnchild）
• 其他组件

YARN 总体上仍然是Master/Slave(主/从) 结构，在整个资源管理框架中，ResourceManager 为主Master ，NodeManager 为从Slave。
ResourceManager：
  负责对各个NodeManager 上的资源进行统一管理和调度（自身的资源使用情况 自身的运行情况 以及所给的命令）
RM: 从不主动 通过心跳来完成 （1NM 报活 2RM 下达命令）
  当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的AM ApplicationMaster，它负责向ResourceManager 申请资源，并要求NodeManger启动container。
appMaster–RM–NM–container
application-specific协议（AM–yarnChild ）
am在通知nodemanager启动container的时候container-launch-specification
由于不同的ApplicationMaster 被分布到不同的节点上，因此它们之间不会相互影响
ResourceManager全局的资源管理器，整个集群只有一个，负责集群资源的统一管理和调度分配。
功能 :处理客户端请求runjar client获取AM

• 启动/监控ApplicationMaster
• RM 启动第一个container（先启动appmaster ）AM 再次与RM 申请资源
• 监控NodeManager （注意只能监听容器和整台机器的资源使用情况 不能查看具体的任务）

资源分配与调度
第一个容器在启动（AM） container-launch-specification
容器运行 AM–yarnchild application-specific
Application Master
管理一个在YARN 内运行的应用程序的每个实例，这个应用在每个container中的进程都交给AM管理
mr在运行的时候 – 申请am — 申请子资源 — 返回容器的列表 – 机器的资源使用情况 — 节点数据
功能

• 数据切分 （找寻数据在哪个节点上，并且在这个节点上启动container）
• 为应用程序申请资源，并进一步分配给内部任务
• 任务监控与容错（yarnchild 宕机 appmaster能够监听1到 再去申请启动）
• 负责协调来自ResourceManager的资源，幵通过NodeManager监视容器的执行和资源使用（CPU、内存等的资源分配）。

NodeManager
整个集群有多个，负责单节点资源管理和使用
功能

• 单个节点上的资源管理和任务管理（监控生命周期）
• 处理来自ResourceManager的命令（分配资源的命令）
• 处理来自ApplicationMaster的命令（启动容器的命令）
  ApplicationManager container —> NodeManager

NodeManager管理抽象容器，这些容器代表着可供一个特定应用程序使用的针对每个节点的资源。yarnchild
定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态。(心跳机制汇报)
Container
YARN中的资源抽象，封装某个节点上多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM向AM返回的资源便是用Container表示的。
YARN 会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。
功能

• 对任务运行环境的抽象
• 描述一系列信息
• 任务运行资源（节点、内存、CPU）
• 任务启动命令
• 任务运行环境

JobHistoryServer
  JobHistoryServer(将各个容器中的日志合并在一起展示 mr运行结果之后 进行合并结果日志的一个进程)、只是适用于mr框架，作业历史服务,记录历史情况 , 通过mr-jobhistory-daemon.sh start historyserver 来启动, 启动成功会出现JobHistoryServer进程 , 并且可以从19888端口进行查看日志详细信息
TimelineServer
  通用的日志服务器
  用来写日志服务数据 , 一般来写与第三方结合的日志服务数据(比如spark等) 所有计算框架的日志合并

7.YARN 优势

更快地MapReduce计算
  YARN利用异步模型对MapReduce框架的一些关键逻辑结构（如JobInprogress、TaskInProgress等）进行了重写，相比于MRv1，具有更快地计算速度。
对多框架支持
   YARN不再是一个单纯的计算框架，而是一个框架管理器，用户可以将各种各样的计算框架移植到YARN之上。
框架升级更容易
  在YARN中，各种计算框架不再是作为一个服务部署到集群的各个节点上（比如MapReduce框架，不再需要部署JobTracler、TaskTracker等服务），而是被封装成一个用户程序库（lib）存放在客户端，当需要对计算框架进行升级时，只需升级用户程序库即可。

8.YARN 工作流程

  当用户向YARN中提交一个应用程序后，YARN将分两个阶段运行该应用程序

• 第一个阶段是启动ApplicationMaster；
• 第二个阶段是由ApplicationMaster创建应用程序，为它申请资源，并监控它的整个运行过程，直到运行完成
• 在整个工作流程当中，ResourceManager和NodeManager都是通过心跳保持联系的，NodeManager会通过心跳信息向ResourceManager汇报自己所在节点的资源使用情况。
  
  

9.YARN通信协议

  RPC协议是连接各个组件的“大动脉”，了解不同组件之间的RPC协议有助于我们更深人地学习YARN框架。在YARN中，任何两个需相互通信的组件之间仅有一个RPC协议，面对于任何一个RPC协议，通信双方有一端是Client, 另一端为Server, 且Client总是主动连接 Server的，因此，YARN实际上采用的是拉式(ull-based) 通信模型。如下图所示，箭头指向的组件是RPC Server, 而箭头尾部的组件是RPC Client,
YARN主要由以下几个RPC协议组成:
  (1)JobClient(作业提交客户端)与RM之间的协议—ApplicationClientProtocol
JobClient通过该RPC协议提交应用程序、查询应用程序状态等。
  (2)Admin(管理员)与RM之间的通信协议——ResourceManagerAdministrationProtocol:
Admin通过该RPC协议更新系统配置文件，比如节点黑白名单、用户队列权限等。
  (3)AM与RM之间的协议一ApplicationMasterProtocol: AM通过该RPC协议向RM注册和撒销自己，并为各个任务申请资源。
  (4)AM与NM之间的协议一-ContainerManagementProtocol: AM通过该RPC要求NM启动或者停止Container,获取各个Container的使用状态等信息。
  (5)NM与RM之间的协议一-ResuceTracker: NM通过该RPC协议向RM注册，并定时发送心跳信息汇报当前节点的资源使用情况和Container运行情况。

10.YARN资源管理

   资源调度和资源隔离是YARN作为一个资源管理系统，最重要和最基础的两个功能。资源调度由ResourceManager完成，而资源隔离由各个NM实现。
  ResourceManager将某个NodeManager上资源分配给任务（这就是所谓的“资源调度”）后，NodeManager需按照要求为任务提供相应的资源，甚至保证这些资源应具有独占性，为任务运行提供基础的保证，这就是所谓的资源隔离。
  当谈及到资源时，我们通常指内存，CPU和IO三种资源。Hadoop YARN同时支持内存和CPU两种资源的调度。
  内存资源的多少会会决定任务的生死，如果内存不够，任务可能会运行失败；相比之下，CPU资源则不同，它只会决定任务运行的快慢，不会对生死产生影响。
  YARN允许用户配置每个节点上可用的物理内存资源，注意，这里是“可用的”，因为一个节点上的内存会被若干个服务共享，比如一部分给YARN，一部分给HDFS，一部分给HBase等，
YARN配置的只是自己可以使用的，配置参数如下：
   (1) yarn.nodemanager.resource.memory-mb
表示该节点上YARN可使用的物理内存总重，默认是8192(MB)，注意，如果你的节点内存资源不够8CB,则懦要调减这个值，而YARN不会智能的探测节点的物理内存总里。
   (2) yarn.nodemanager.vmem-pmem-ratio
任务每使用1MB物理内存，最多可使用虚拟内存里，默认是2.1.
   (3) yarn.nodemanager.pmem-check-enabled
是否启动一个线程检查每个任务正使用的物理内存里，如果任务超出分配值，则直接将其杀掉，默认是true
   (4) yarn.nodemanager.vmem-check-enabled
是否启动一个线程检查每个任务正使用的虚拟内存里，如果任务超出分配值，则直接将其杀掉，默认是true
   (5) yarn.scheduler.minimum-allocation-mb
单个任务可申请的最少物理内存里，默认是1024(MB)，如果一个任务申请的物理内存重少于该值，则该对应的值改这个数。
   (6) yarn.scheduler.maximum-allocation-mb
单个任务可申请的最多物理内存里，默认是8192(MB)。
   默认情况下，YARN采用了线程监控的方法判断任务是否超量使用内存，一旦发现超量，则直接将其杀死。由于Cgroups对内存的控制缺乏灵活性（即任务任何时刻不能超过内存上限，如果超过，则直接将其杀死或者报OOM），而Java进程在创建瞬间内存将翻倍，之后骤降到正常值，这种情况下，采用线程监控的方式更加灵活（当发现进程树内存瞬间翻倍超过设定值时，可认为是正常现象，不会将任务杀死），因此YARN未提供Cgroups内存隔离机制。
   目前的CPU被划分成虚拟CPU（CPU virtual Core），这里的虚拟CPU是YARN自己引入的概念，初衷是，考虑到不同节点的CPU性能可能不同，每个CPU具有的计算能力也是不一样的，比如某个物理CPU的计算能力可能是另外一个物理CPU的2倍，这时候，你可以通过为第一个物理CPU多配置几个虚拟CPU弥补这种差异。用户提交作业时，可以指定每个任务需要的虚拟CPU个数。在YARN中，CPU相关配置参数如下：
   (1) yarn.nodemanager.resource.cpu-vcores
表示该节点上YARN可使用的虚拟CPU个数, 默认是8.注意.目前推荐将该值设为与物理CPU核数数目相同,如果你的节点CPU核数不8个,则懦要调小这个值,而YARN不会智能的探测点物理CPU总数.
   (2) yarn.scheduler.minimum-allocation-vcores
单个任务可申请的最小虚拟cpu个数默认是1, 如果一个任务申请的CPU个数少于该数.则该对应的值改为这个数.
   (3) yarn.scheduler.maximum-allocation-vcores
单个任务可申请的最多虚拟CPU个数,默认是32。

12、AM与RM的详细交互

   用户向YARN ResourceManager提交应用程序，RM收到提交申请后，先向资源调度器申请用以启动AM 的资源，待申请到资源后，再由ApplicationMasterLauncher与对应的NodeManager通信，从而启动应用程序的ApplicationMaster。
   ApplicationMaster启动完成后，ApplicationMasterLaucher会通过事件的形式，将刚刚启动的Application Master注册到AMLiveMonitor，以启动心跳监控。
   ApplicationMaster启动后，先向ApplicatinMaterService注册，并将自己所在host、端口号等信息汇报给它。
   AM运行过程中，周期性地向ApplicationMaserService回报心跳信息（信息中包含想要申请的资源描述）。
   ApplicationMasterService每次收到ApplicationMaster心跳信息好后，将通知AMLivelinessMonitor更新应用程序的最新回报心跳的时间。
   应用程序运行完成后，AM向AMService发送请求，注销自己。
   AMService收到注销请求后，标注应用程序运行状态完成，同时通知 AMLivelinessMonitor移除对它的心跳监控。

13.YARN 核心组件

14.Hadoop 发行版本

• Apache Hadoop
• Cloudera — CDH
• Hortonworks — HDP
• MapR
• EMC、IBM
• Intel、华为
• 其他

Cloudera Hadoop
   2008 年成立的 Cloudera 是最早将 Hadoop 商用的公司，为合作伙伴提供 Hadoop 的商用解决方案，主要是包括支持，咨询服务，培训。
2009年Hadoop的创始人 Doug Cutting也加盟 Cloudera公司。Cloudera 产品主要为CDH，Cloudera Manager，Cloudera Support
CDH是Cloudera的Hadoop发行版，完全开源，比Apache Hadoop在兼容性，安全性，稳定性上有所增强。
   Cloudera Manager是集群的软件分发及管理监控平台，可以在几个小时内部署好一个Hadoop集群，并对集群的节点及服务进行实时监控。Cloudera Support即是对Hadoop的技术支持。
   Cloudera 的标价为每年每个节点4000美元。Cloudera开发并贡献了可实时处理大数据的Impala项目。

16.Hortonworks Hadoop

   2011年成立的Hortonworks是雅虎与硅谷风投公司Benchmark Capital合资组建的公司
   公司成立之初就吸纳了大约25名至30名专门研究Hadoop的雅虎工程师，上述工程师均在2005年开始协助雅虎开发Hadoop，这些工程师贡献了Hadoop 80%的代码。
雅虎工程副总裁、雅虎Hadoop开发团队负责人Eric Baldeschwieler出任Hortonworks的首席执行官。
   Hortonworks 的主打产品是Hortonworks Data Platform (HDP)，也同样是100%开源的产品，HDP除了常见的项目外还包含了Ambari，一款开源的安装和管理系统。
   HCatalog，一个元数据管理系统，HCatalog现已集成到Facebook 开源的Hive中。Hortonworks的Stinger开创性地极大地优化了Hive项目。Hortonworks为入门提供了一个非常好的，易于使用的沙盒。
   Hortonworks开发了很多增强特性并提交至核心主干，这使得Apache Hadoop能够在包括Windows Server和Windows Azure在内的Microsoft Windows平台上本地运行。定价以集群为基础，每10个节点每年为12500美元。

17.MapR Hadoop

   2009年成立的MapR公司在Hadoop领域显得有点特立独行，它提供了一款独特的发行版 。
   Hadoop在性能(在Hadoop1.X及其之前的设计中，所有的meta data操作都要通过集中式的NameNode来进行，NameNode有可能是性能的瓶颈;M/R 应用程序需要通过NameNode来访问HDFS, 这就涉及到额外的进程切换和网络传输开销)，可用性与扩展性(NameNode，JobTracker单点问题)，企业级应用上的弱点(比如完全可读写的文件系统，snapshot，mirror等等)各大厂商均知，MapR则认为，Hadoop的这些缺陷来自于其架构设计本身，小修小补不能解决问题。
   他们选择了一条艰难得多的路： 用新架构重写HDFS，同时在API级别，和目前的Hadoop 发行版保持兼容。这家2009年成立的创业公司，在蛰伏了两年之后，终于一鸣惊人，大放异彩。
   成功实现了“构建一个HDFS的私有替代品，这个替代品比当前的开源版本快三倍，自带快照功能，而且支持无NameNode单点故障(SPOF)，并且在API上和开源版兼容，所以可以考虑将其作为替代方案”。
   MapR版本不再需要单独的NameNode机器，元数据分散在集群中，也类似数据默认存储三份，正如OpenStack对象存储系统Swift的设计。
   也不再需要用网络附加存储(NAS)来协助NameNode做元数据备份，提高了机器使用率。还有个重要的特点是可以使用nfs直接访问hdfs，提供了与旧有应用的兼容性
镜像功能也很适合做数据备份，而且支持跨数据中心的镜像，快照功能对于数据的恢复作用明显。MapR还领导着Apache Drill项目，该项目是Google Dremel的开源实现，目的是在Hadoop上执行类似SQL的交互实时查询。
   MapR有免费和商业两个版本，免费版本在功能上有所缩减。据报道MapR标价也为每年每个节点4000美元。

Intel和华为等发行 Hadoop
   Intel的商业版本，主要是强调其能提供全面的软硬件解决方案设计，针对硬件具有更好的性能优化，以及提供集群管理工具和安装工具简化了 Hadoop 的安装和配置，能够提供项目规划到实施各阶段专业的咨询服务，实际中采购Intel版本貌似动力不足。
华为在硬件上具有天然的优势，在网络，虚拟化，PC机等都有很强的硬件实力。华为的    FusionInsight Hadoop版本基于Apache Hadoop，构建NameNode、 JobTracker、HiveServer的HA功能，进程故障后系统自动Failover，无需人工干预，这个也是对Hadoop的小修补，远不如MapR解决的彻底。华为在Hadoop社区中的Contributor和Committer也是国内最多的，算是国内技术实力较强的公司。
   Microsoft和Hortonworks相互合作，特别是合作将Apache Hadoop引入到Windows Server操作系统和Windows Azure云服务中。
   Oracle通过将自己的软硬件与Cloudera的Apache Hadoop发行版本结合到一起，提供一个大数据应用产品。
   像SAP、Talend这样的软件提供商则同时支持几个不同的发行版本。