技术干货：YARN发展趋势

                                     在2013年的Hadoop峰会上，YARN是一个热点话题，YARN本质上是Hadoop的新操作系统，突破了MapReduce框架的性能瓶颈。Murthy认为Hadoop和YARN的组合是企业大数据平台致胜的关键。

以下内容摘自《Hadoop技术内幕：深入解析YARN架构设计与实现原理》董西成著,机械工业出版社

13.3本章尝试从YARN自身完善、YARN生态系统和YARN周边工具的完善等几个方面分析YARN可能的发展趋势，供大家参考和讨论。

13.3.1YARN自身的完善

本小节我们先从YARN自身来分析一下其发展趋势。

（1）调度框架

当前YARN支持内存和CPU两种资源类型的管理和分配。除了CPU和内存两种资源，服务器还有很多其他资源，比如磁盘容量、网络和磁盘IO等，YARN可能在将来支持这些资源的调度和隔离。

为了更友好地为应用程序分配资源，YARN内部包含了一些调度语义，这决定了YARN作为一个资源管理系统可给用户带来的服务承诺。当前YARN的调度器能够表达的语义是有限的，这也决定了它对某些应用是友好的，但对于其他应用来说会带来性能问题。当前YARN支持的语义和不支持的语义可总结如下。

支持的调度语义：

请求某个特定节点上的特定资源量。比如，请求节点nodeX上5个这样的Container：虚拟CPU个数为2，内存量为2GB。

请求某个特定机架上的特定资源量。比如，请求机架rackX上3个这样的Container：虚拟CPU个数为4，内存量为3GB。

将某些节点加入（或移除）黑名单，不再为自己分配这些节点上的资源。比如，ApplicationMaster发现节点nodeX和nodeY失败的任务数目过多，可请求将这两个节点加入黑名单，从而不再收到这两个节点上的资源，过一段时间后，可请求将nodeX移除黑名单，从而可再次使用该节点上的资源。

请求归还某些资源。比如，ApplicationMaster已获取的来自节点nodeX上的2个Container暂时不用了，可将之归还给集群，这样这些资源可再次分配给其他应用程序。

不支持的调度分配语义：

请求任意节点上的特定资源量。比如，请求任意节点上5个这样的Container：虚拟CPU个数为3，内存量为1GB。

请求任意机架上的特定资源量。比如，请求同一个机架上（具体并不关心是哪个机架，但是必须来自同一个机架）3个这样的Container：虚拟CPU个数为1，内存量为6GB。

请求一组或几组符合某种特质的资源。比如，请求来自两个机架上的4个Container，其中一个机架上2个这样的Container：虚拟CPU个数为2，内存量为2GB，另一个机架上2个这样的资源：虚拟CPU个数为2，内存量为3GB。如果目前集群没有这样的资源，需要从其他应用程序那里抢占资源。

超细粒度资源。比如CPU性能要求、绑定CPU等。

动态调整Container资源，应允许根据需要动态调整Container资源量（对于长作业尤其有用）。

（2）在线升级

YARN作为一个通用资源管理平台，不仅可以运行短作业（通常运行几分钟或者几个小时，比如MapReduce作业），还可以运行长作业（通常永不停止运行，比如HBase Server或者Web Server）等。对于长作业而言，由于它们需对外不间断提供服务，因此，当YARN自身升级时，不应该干扰这类长作业，比如NodeManager重启时，正运行在它上面的任务（尤其是长服务）不应受到干扰，这一点，同类系统Mesos已经可以做到（具体参考第12章）。

（3）容错机制

将短作业和长作业同时运行在YARN上后，不同类型的应用程序对容错性需求通常不一样，对于长作业而言，由于它们通常拥有自己的客户端，需为它们不间断提供服务。因此，当这些作业出现故障时，应尝试本地重启它们（防止客户端无法找到服务位置），如果重启失败，再尝试将其调度到其他节点上，而不应向MapReduce作业那样，一旦运行失败则换另外一个节点重新运行。

13.3.2　以YARN为核心的生态系统

YARN是未来的一个趋势，YARN本身已经变成了一个云操作系统，很多计算框架或者应用程序不再基于传统的操作系统开发（比如Linux），而是基于YARN这个云操作系统。这意味着，很多新的计算框架或者应用程序脱离了YARN将不再能够单独运行，典型的代表是DAG计算框架Tez和Spark（Spark也可以运行在Mesos上）。

当前很多计算框架都在往YARN上迁移，即使不迁移也要支持在YARN上运行。本小节将对这部分内容进行简单的梳理。

MapReduce：MapReduce是一个非常经典的离线计算框架，在MRv1中，MapReduce应用程序需运行在由JobTracker和TaskTracker组成的运行时环境中，而在YARN中，不再有JobTracker和TaskTracker这样的服务组件，取而代之的是一个ApplicationMaster组件，它只负责应用程序相关的管理，比如任务切分和调度、任务监控和容错等，而资源相关的调度和管理交给YARN完成，具体在第8章已经进行了介绍。

Tez：Hortonworks开源的DAG计算框架，是在MapReduce基础上扩展而来的，重用了MapReduce大量代码，仅支持运行在YARN上，不可单独运行，具体在第9章已经进行了介绍。

Storm：实时计算框架，运行时环境由Nimbus和supervisor等组件组成，为了能够让Storm运行在YARN上，Yahoo！开源了一个简单的版本StormOn YARN，具体在第10章已经进行了介绍。

Spark：Spark是一个基于内存实现的MapReduce计算框架，某些应用场景下更加高效，它目前已经支持运行在YARN上，具体在第10章已经进行了介绍。

HBase：构建在HDFS之上的实时存取系统，运行时环境由HMaster和RegionServer等组件构成。Hortonworks公司开源的Hoya项目正常时将HBase自动化部署到YARN上。

Giraph：开源图算法库，最开始的版本是基于MRv1实现的，随着Hadoop2.0的成熟，正尝试将所有图算法运行在YARN之上（不再基于MapReduce）。

OpenMPI：非常经典的高性能并行编程接口，目前正尝试将其运行在YARN上。

最终，YARN之上可以运行各种应用类型的框架，包括离线计算框架MapReduce、实时计算框架Storm、DAG计算框架Tez等，真正实现一个集群的多用途，这样的集群或者系统我们通常称为轻量级弹性计算平台。说它轻量级，是因为YARN采用了Cgroups轻量级隔离方案；说它弹性，是因为YARN能根据各种计算框架、应用的负载或者需求调整它们各自占用的资源，实现集群资源共享、资源弹性收缩。在不久的将来，普遍采用的部署方案应该如图13-2所示。

图13-2　以YARN为核心的生态系统

当然，随着YARN朝着资源管理系统方向更好地发展，最终Web Server、MySQL Server等服务，均可以部署到YARN之上，这样YARN将变为一个服务统一部署和管理的平台，最终形成一个以YARN为核心的生态系统。如图13-3所示，未来整个集群或者数据中心只需部署三个基础系统，分别是HDFS2（Hadoop2.0中的HDFS实现，增加了NameNode HA和Name Node Federation两个重要功能）、YARN和Zookeeper，其他系统，比如HBase、Storm、MySQL等，均可根据需要自动部署运行到YARN上。

图13-3　未来可能的Hadoop生态系统基础软件形态

然而，从实际应用看来，由于不同应用或者服务对调度策略的要求不同，这将使得YARN资源调度器变得非常复杂，难以兼顾所有需求。为了解决该问题，YARN将来可能出现多种定制化版本应对不同类型的调度问题，比如现有YARN用来运行短作业，而定制化的YARN用来运行各类服务等。

13.3.3YARN周边工具的完善

随着YARN的不断发展和完善，各种类型的应用程序，包括类似MapReduce的短作业、类似Web Service的长作业等，均可直接部署和运行到YARN上。当前YARN对外提供的接口均是底层接口，这给用户编写和调试应用程序带来了很大的麻烦，比如无法聚集分散在各个节点上的应用程序日志、应用程序生命周期难以管理、缺乏第三方工具将一个现有的系统运行在YARN上等。为了解决以上关于YARN上应用程序的创建、管理、调试等方面的问题，一些开源软件诞生了，典型代表是Continuuity公司的Weave和Cloudera公司的Kitten。

接下来以Weave为例，说明YARN尚需进一步完善的周边工具。Weave针对YARN之上应用程序编写、调试和管理等方面的不完善，进行了以下改进：

一套经简化的，用于定义、运行和管理应用程序的编程接口。

一个通用的ApplicationMaster实现，以便直接部署简单的服务。

应用程序的日志和Metric信息自动聚集呈现。

Discovery服务。该组件对长作业尤其有用，比如将一个服务部署到YARN上，服务运行起来后，可向Zookeeper注册，这样当服务失败被重新调度运行到另外节点上后，Weave可将新的位置通知给各个客户端。

相比于Weave，Kitten提供了一套Shell配置工具提交应用程序，这对于部署一些简单的服务或者应用程序非常有用。

数据分析, 数据挖掘

风险提示及免责条款

市场有风险，投资需谨慎。本文不构成个人投资建议，也未考虑到个别用户特殊的投资目标、财务状况或需要。用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！