##Hadoop2.0(HDFS2)以及YARN设计的亮点

Hadoop2.0(HDFS2)以及YARN设计的亮点 - 似水流年 - CSDN博客 http://blog.csdn.net/xiaoshunzi111/article/details/49283213

Paste_Image.png

HADOOP2.0（HDFS2）以及YARN设计的亮点进行总结：
1.针对Hadoop1.0中单个NameNode制约HDFS的扩展性问题，Hadoop2.0提出了HDFS Federation，它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展。对于运行中NameNode的单点故障，通过NameNode热备方案（NameNode HA）实现。
2.在Hadoop1.0中，JobTracker由资源管理和作业控制两部分组成，对JobTracker赋予的功能过多而造成负载过重，从设计角度上看，Hadoop未能够将资源管理相关功能与应用程序相关功能非开，造成Hadoop1.0难以支持多种计算框架。而YARN通过将资源管理和应用程序管理两部分分剥离开，分别由ResouceManager和ApplicationMaster负责，其中，ResouceManager专管资源管理和调度，而ApplicationMaster则负责与具体应用程序相关的任务切分、任务调度和容错等。

---

YARN总体上仍然是Master/Slave结构，在整个资源管理框架中，ResourceManager为Master，NodeManager为Slave，ResouceManager负责对各个NodeManager上的资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向ResourceManger申请资源，并要求NodeManager启动可以占用一定资源的任务。

Hadoop2.0 YARN包含以下实体，可以看图：
ResourceManager(RM)：全局的资源管理器，负责整个系统的资源管理和分配
NodeManager(NM)：每个节点上的资源和任务管理器，定时向RM汇报本节点上的资源使用情况和各个Container的运行状态，接收并处理来自AM的Container启动/停止等各种请求
ApplicationMaster(AM)：用户提交的每个应用程序均包含一个AM，主要功能与RM调度器协商以获取资源，进一步分配给内部的任务，与NM通信启动/停止任务，监控任务的运行状态
Container：是YARN中资源的抽象，封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等。当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。

结合YARN架构图描述一个资源请求的流程：
NodeManager向ResourceManager注册各机器资源
客户端向ResouceManager提交作业
ApplicationMaster向ResouceManager请求资源，并判断是否满足需要
ResouceManager以Container的形式将资源反馈给ApplicationMaster
Container作为资源单元保证作业隔离运行

关于Hadoop2.0的安装可以参考这篇博文，Hadoop 2.0安装以及不停集群加datanode，下面对HADOOP2.0（HDFS2）以及YARN设计的亮点进行总结：
1.针对Hadoop1.0中单个NameNode制约HDFS的扩展性问题，Hadoop2.0提出了HDFS Federation，它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展。对于运行中NameNode的单点故障，通过NameNode热备方案（NameNode HA）实现。
2.在Hadoop1.0中，JobTracker由资源管理和作业控制两部分组成，对JobTracker赋予的功能过多而造成负载过重，从设计角度上看，Hadoop未能够将资源管理相关功能与应用程序相关功能非开，造成Hadoop1.0难以支持多种计算框架。而YARN通过将资源管理和应用程序管理两部分分剥离开，分别由ResouceManager和ApplicationMaster负责，其中，ResouceManager专管资源管理和调度，而ApplicationMaster则负责与具体应用程序相关的任务切分、任务调度和容错等。
3.在ResouceManager中，ClientRMService和AdminService两个服务分别负责处理来自普通用户和管理员的请求，需要注意的是，之所以让这两类请求通过两个不同的通信通道发送个ResourceManager，是因为要避免普通用户请求过多导致管理员请求被阻塞而迟迟得不到处理。
4.JDK中自带一个RPC框架-RMI，之所以不直接使用该框架，主要是考虑到RPC是Hadoop最底层最核心的模块之一，保证其轻量级、高性能和可控性显得尤为重要，而RMI重量级过大且用户可控之处太少（如网络连接、超时和缓冲等均难以定制或者修改），Doug Cutting在Hadoop最初设计时就是这样描述Hadoop RPC设计动机的。
5.总体来说Hadoop2.0中的HDFS和YARN均采用了基于共享存储的HA解决方案，即Active Master不断将信息写入一个共享存储系统，而Standby Master则不断读取这些信息，以与Active Master的内存信息保持同步。当需要主备切换时，选中的Standby Master需先保证信息完全同步后，再将自己的角色切换至Active Master。目前而言，常用的共享存储系统有以下几个：Zookeeper,NFS,HDFS,Bookeeper和QJM。HA架构均分为手动模式和自动模式，其中手动模式是指由管理员通过命令进行主备切换，这通常用于服务升级；自动模式可降低运维成本，但存在潜在危险。
6.Zookeeper设计的目的并不是数据存储，但他的确可以安全可靠地存储少量数据以解决分布式环境下多个服务之间的数据共享问题。
7.解决HA问题需考虑以下几个问题：脑裂和切换对外透明。脑裂是指在主备切换时，由于切换不彻底或其他原因，导致客户端和Slave误以为出现两个Active Master，最终使得整个集群处于混乱状态。通常采用隔离机制解决脑裂问题。为了保证整个切换是对外透明的，Hadoop应保证所有客户端和Slave能自动重定向到新的Active Master上，通常是通过若干次尝试连接旧Master不成功后，再重新尝试新Master完成的，整个过程有一定的延时，可以自行设置相关参数。
8.ResourceManger并不会保存已经分配给 每个ApplicationMaster的资源信息和每个NodeManage的资源使用信息，这些均可通过相应的心跳汇报机制重构出来。正因为如此，ResouceManager HA的实现是非常轻量的。
9.Hadoop调度器支持多个队列多用户，这种调度器允许管理员按照应用需求对用户或者应用程序分组，并为不同的分组分配不同的资源量，同时通过添加各种约束防止单个用户或者应用程序独占资源，进而能够满足各种QoS需求，典型的代表是Yahoo!的Capacity Scheduler和Facebook的Fair Scheduler。
10.YARN的内存资源隔离，默认采用线程监控的方案，提供灵活的控制策略，具体可以看这篇博文，Hadoop YARN资源隔离技术。

参考：
《Hadoop技术内幕--深入解析YARN架构设计与实现原理》
《大规模分布式系统架构与设计实践》

E-mail: [email protected]://cn.linkedin.com/pub/huahui-yang/91/13a/105