hadoop的版本优化

优化与发展

hadoop已经成为了大数据公认的处理框架，在业内得到广泛应用，又因其为开源项目，所以在开源社区十分活跃，在使用过程中逐渐得到改进和完善。通过不断的优化和提升，hadoop的生态组件也越来越丰富，支持的场景应用越来越广泛，提高了集群的可用性以及带来更高的资源利用率。

新特性

组件	hadoop1.0	hadoop2.0
HDFS	名称节点单点故障	设计HDFS HA，提供节点热备份机制
HDFS	单一命名空间，无法资源隔离	设计HDFS联邦，管理多个命名空间
mapreduce	资源管理效率低	引入YARN资源管理器

HDFS2.0

2.0增加了HA（High Available）和联邦等新特性

HDFS HA

在前面介绍的HDFS原理中，介绍了名称节点存储了集群的两个核心文件Editlog和FsImage，如果没有一个机制来保证实时数据的备份，那么一旦发生故障，势必会造成一部分EditLog的操作丢失。第二名称节点起到的作用仅仅是在EditLog文件变大的时候进行与FsImage的合并，并不能直接充当热备份节点来恢复集群。

在2.0中引入了HA架构，在集群中设置两个名称节点，在集群启动时，推选出一个节点处于“活跃(Active)"状态，另外一个处于”待命(stanby)“状态。活跃状态的节点负责响应客户端的请求，待命状态节点负责同步活跃节点的数据，提供”热备份“的能力。

由架构图看出，为了实现两个名称节点同步，需要一个共享文件系统来连接两边的EditLog文件，通常有NFS、QJM、Zookeeper。活跃节点将更新数据写入到共享文件系统，待命节点接听文件系统，一旦有文件写入，就立即从共享文件系统读取这些数据并加载到自己内存中，从而保证活跃节点的同步。另外一个需要注意的是，名称节点对数据节点是被动接收数据节点心跳的方式，所以为了保证在名称节点故障切换的时候可以获得数据节点的信息，数据节点再一次心跳汇报的时候像两个名称节点汇报。而Active和Stanby的竞选则由Zookeeper来实现，保证同一时刻只有一个处于活跃状态对外提供服务。

HDFS 联邦

在1.0中不仅存在单点故障问题，还有可扩展性、性能和隔离性等问题。在可扩展性上，HDFS1.0只用一个名称节点，随着系统运行，名称节点保存的元数据信息越来越大，限制了文件、目录的数目。如果通过纵向扩展，比如增加内存、CPU，这就会导致集群元数据过大导致启动时间变得更长，影响用户体验。
在系统性能方面，在面对客户端并发时受限于名称节点的吞吐量。单个名称节点也难以提供不用程序的隔离性，一个程序可能影响其他程序的正常运行。
联邦的设计
在联邦设计中，设计多个互相独立的名称节点，这些名称节点分别进行各自的命名空间和块的管理，在水平扩展上形成联邦关系。所有名称节点共享底层的数据节点资源，每个数据节点向集群中所有的名称节点发送心跳包和块信息，报告自己的状态，同时也会响应名称节点的指令。

HDFS联邦访问
采用客户端挂载表方式把各个命名空间挂债到全局”挂载表“中，实现数据全局共享。

较HDFS1.0的优点

• HDFS集群水平可扩展性。多个名称节点分管一部分目录，使得一个集群扩展到更多节点，不会再因为内存限制制约文件存储数目
• 性能更高效。多个节点管理不同的数据，且能同时对外提供服务，为客户带来更多吞吐率。
• 良好的隔离。通过业务区分对名称节点的访问，业务与业务之间影响很小。

新一代资源管理调度框架YARN

MapReduce1.0缺陷

mapreduce1.0采用C/S架构，一个JobTracker和若干个TaskTracker，前者负责任务调度和资源管理，后者负责具体任务执行。

1. 单点故障。单个JobTracker负责集群的mapreduce作业调度，一旦出现故障系统将不可用。
2. JobTracker任务过重，消耗大量资源且容易导致任务执行失败，业内总结mapreduce1.0支持主机的上限为4000台。
3. 容易出现内存溢出，在实际工作中，资源分配并不考虑CPU,内存等实际使用情况，只根据mapreduce的任务个数来分配资源。
4. 资源划分不合理，资源被强制等分划分成多个slot，slot又进一步划分为map槽和reduce槽，彼此之间不能使用对方的槽。

YARN的诞生

为了克服上述问题，在hadoop2.0版本后，设计了YARN框架，包含ResourceManager、AppMaster和NodeManager,其中ResourceManager负责资源管理，由AppMaster负责任务调度和监控，NodeManager负责执行原TaskTracker的任务。这种设计大大降低了JobTracker的负担，提高系统运行效率和稳定性。

在1.0中mapreduce不仅仅是计算框架，还是一个任务调度框架。到了2.0mapreduce变成纯粹的计算框架，不再自己负责资源调度，而是由YARN来完成。

ResourceManager

• 处理客户端请求
• 启动/监控AppMaster
• 监控NodeManager
• 资源分配与调度
  RM是一个全局资源管理器，负责整个系统的资源管理和分配，主要有两个组件，调度器(Scheduler)和应用程序管理器(AppManager)。调度器主要负责资源管理和分配。调度器接收来自AppManager的应用程序资源请求，并根据容量、队列等限制条件，把集群中的资源以”容器“的形式分配给提出请求的应用程序。每个容器封装了一定数量的CPU、内存、磁盘资源等，从而限定每个应用程序可以使用的资源量。常见的调度器有公平调度器、先进先出调度器和容量调度器

AppMaster

• 为应用程序申请资源，并分配给内部任务
• 任务调度、监控和容错
  作业提交申请后，AppMaster向RM申请资源，RM以容器的方式返回资源给AppMaster,由AppMaster给map任务或reduce任务分配资源。AppMaster与nodemanager保持通信进行应用程序的启动、运行、监控和停止，监控资源使用情况，对任务的执行进度和状态监控，处理失败恢复，定时向RM汇报资源使用情况和应用进度信息，作业完成时向RM注销容器，执行周期完成

NodeManager

• 单个节点上的资源管理
• 处理来自ResourceManager的命令
• 处理来自NodeManage的命令
  NodeManager负责容器生命周期管理，监控每个容器的资源使用情况，跟踪节点健康情况。NodeManager只负责抽象的容器，只处理与容器相关的事情，而不具体负责每个任务自身状态管理。

部署

ResourceManager 部署在名称节点
AppMaster、NodeManager部署在每个数据节点