Hadoop 3.x 新特性剖析系列2

1.概述

接着上一篇博客的内容，继续介绍Hadoop3的其余新特性。其内容包含：优化Hadoop Shell脚本、重构Hadoop Client Jar包、支持等待Container、MapReduce任务级别本地优化、支持多个NameNode、部分默认服务端口被改变、支持文件系统链接器、DataNode内部添加负载均衡、重构后台程序和任务堆管理。

2.内容

2.2.1 优化Hadoop Shell脚本

Hadoop Shell脚本已经被重写，用来修复已知的BUG，解决兼容性问题和一些现有安装的更改。它还包含了一些新的特性，内容以下所示：

• 全部Hadoop Shell脚本子系统如今都会执行hadoop-env.sh这个脚本，它容许全部环节变量位于一个位置；
• 守护进程已经过*-daemon.sh选项从*-daemon.sh移动到了bin命令中，在Hadoop3中，咱们能够简单的使用守护进程来启动、中止对应的Hadoop系统进程；
• 触发SSH链接操做如今能够在安装时使用PDSH；
• ${HADOOP_CONF_DIR}如今能够任意配置到任何地方；
• 脚本如今测试并报告守护进程启动时日志和进程ID的各类状态；

2.2.2 重构Hadoop Client Jar包

Hadoop2 中可用的Hadoop客户端将Hadoop的传递依赖性拉到Hadoop应用程序的类路径上。若是这些传递依赖项的版本与应用程序使用的版本发送冲突，这可能会产生问题。

所以，在Hadoop3中有新的Hadoop客户端API和Hadoop客户端运行时工件，它们将Hadoop的依赖性遮蔽到单个JAR中，Hadoop客户端API是编译范围，Hadoop客户端运行时是运行时范围，它包含从Hadoop客户端从新定位的第三方依赖关系。所以，你能够将依赖项绑定到JAR中，并测试整个JAR以解决版本冲突。这样避免了将Hadoop的依赖性泄露到应用程序的类路径上。例如，HBase能够用来与Hadoop集群进行数据交互，而不须要看到任何实现依赖。

2.2.3  支持等待容器和分布式调度

在Hadoop3 中引入了一种新型执行类型，即等待容器，即便在调度时集群没有可用的资源，它也能够在NodeManager中被调度执行。在这种状况下，这些容器将在NM中排队等待资源启动，等待荣容器比默认容器优先级低，所以，若是须要，能够抢占默认容器的空间，这样能够提供机器的利用率。以下图所示：

默认容器对于现有的YARN容器，它们由容量调度分配，一旦被调度到节点，就保证有可用的资源使它们执行当即开始。此外，只要没有故障发生，这些容器就能够容许完毕。

等待容器默认由中心RM分配，但还增长了支持以容许等待容器被分布式调度，该调度群被实现于AM和RM协议的拦截器。

 2.2.4 MapReduce任务级别本地化优化

在Hadoop3中，本地的Java实现已加入MapReduce地图输出器，对于Shuffle密集的做业，这样能够提升30%或者更高的性能。

它们添加了映射输出收集器的本机实现，让MapTask基于JNI来本机优化。基本思想是添加一个NativeMapOutputCollector收集器来处理映射器发出的键值对，所以Sort、Spill、文件序列化均可以在本机代码中完成。

2.2.5 支持多个NameNode节点

在Hadoop2中，HDFS NameNode高可用体系结构有一个Active和Standby NameNode，经过JournalNodes，该体系结构可以容忍任何一个NameNode失败。

然而，业务关键部署须要更高程度的容错性。所以，在Hadoop3中容许用户运行多个备用的NameNode。例如，经过配置三个NameNode（1个Active NameNode和2个Standby NameNode）和5个JournalNodes节点，集群能够容忍2个NameNode节点故障。以下图所示：

2.2.6 默认的服务端口被修改

早些时候，多个Hadoop服务的默认端口位于Linux端口范围之内。除非客户端程序明确的请求特定的端口号，不然使用的端口号是临时的，所以，在启动时，服务有时会由于与其余另外一个应用程序冲突而没法绑定到端口。

所以，具备临时范围冲突端口已经被移除该范围，影响多个服务的端口号，即NameNode、Secondary NameNode、DataNode等以下所示：

Daemon	App	Hadoop2 Port	Hadoop3 Port
NameNode Port	Hadoop HDFS NameNode	8020	9820
	Hadoop HDFS NameNode HTTP UI	50070	9870
	Hadoop HDFS NameNode HTTPS UI	50470	9871
Secondary NameNode Port	Secondary NameNode HTTP	50091	9869
	Secondary NameNode HTTP UI	50090	9868
DataNode Port	Hadoop HDFS DataNode IPC	50020	9867
	Hadoop HDFS DataNode	50010	9866
	Hadoop HDFS DataNode HTTP UI	50075	9864
	Hadoop HDFS DataNode HTTPS UI	50475	9865

2.2.6 支持文件系统链接器

Hadoop如今支持与微软 Azure数据和阿里云对象存储系统的集成。它能够做为一种替代Hadoop兼容的文件系统，首先添加微软Azure数据，而后添加阿里云对象存储系统。

2.2.7 DataNode内部负载均衡

单个数据节点配置多个数据磁盘，在正常写入操做期间，数据被均匀的划分，所以，磁盘被均匀填充。可是，在维护磁盘时，添加或者替换磁盘会致使DataNode节点存储出现偏移，这种状况在早期的HDFS文件系统中，是没有被处理的。如图下图所示，维护前和维护后不均衡的状况：

 

如今Hadoop3经过新的内部DataNode平衡功能来处理这种状况，这是经过hdfs diskbalancer CLI来进行调用的。执行以后，DataNode会进行均衡处理，以下图所示：

 

2.2.8 重构后台程序和任务堆管理

Hadoop守护进程和MapReduce任务的堆管理已经发生了一系列的变化。

• 配置守护进程堆大小的新方法：值得注意的是，如今能够根据主机的内存大小进行自动调整，而且已经禁止HADOOP_HEAPSIZE变量。在HADOOP\_HEAPSIZE\_MAX 和 HADOOP\_HEAPSIZE\_MIN位置上，分别设置XMX和XMS。全部全局和守护进程特定堆大小变量如今都支持单元。若是变量仅为一个数，它的大小为MB。
• Map和Reduce的堆大小的配置被简化了，因此再也不须要任务配置做为一个Java选项指定。已经指定的两个现有配置不受此更改的影响。

3.总结

Hadoop3的这些新特性仍是很吸引人的，目前官方推出的稳定版本是2.9.0，发行版是3.1.0，感兴趣的同窗能够下载Hadoop3去体验调研学习一下这些新特性。

4.结束语

这篇博客就和你们分享到这里，若是你们在研究学习的过程中有什么问题，能够加群进行讨论或发送邮件给我，我会尽我所能为您解答，与君共勉！