大数据之Hadoop3.0 新特性

总览

最低要求的Java版本从Java 7增加到Java 8
支持HDFS中的擦除编码
YARN时间轴服务v.2
Shell脚本重写
支持随机container和分布式计划
MapReduce任务级本机优化
支持两个以上的NameNode
多个服务的默认端口已更改
支持Microsoft Azure Data Lake和Aliyun对象存储系统文件系统连接器
数据内节点平衡器
重做的守护程序和任务堆管理
S3Guard：S3A文件系统客户端的一致性和元数据缓存
基于HDFS路由器的联合
Capacity Scheduler队列配置的基于API的配置
YARN资源类型

介绍

1. 最低要求的Java版本从Java 7增加到Java 8

所有Hadoop JAR现在都是针对Java 8的运行时版本编译的。

2.支持HDFS中的擦除编码（HDFS Erasure Coding）

Erasure coding纠删码技术简称EC,是一种数据保护技术.最早用于通信行业中数据传输中的数据恢复,是一种编码容错技术.他通过在原始数据中加入新的校验数据,使得各个部分的数据产生关联性.在一定范围的数据出错情况下,通过纠删码技术都可以进行恢复.EC技术可以防止数据丢失，又可以解决HDFS存储空间翻倍的问题。

创建文件时，将从最近的祖先目录继承EC策略，以确定其块如何存储。与3路复制相比，默认的EC策略可以节省50％的存储空间，同时还可以承受更多的存储故障。

建议EC存储用于冷数据，由于冷数据确实数量大，可以减少副本从而降低存储空间，另外冷数据稳定，一旦需要恢复数据，对业务不会有太大影响。

使用擦除编码的目的
复制非常昂贵– HDFS中的默认3x复制方案在存储空间和其他资源（例如，网络带宽）上有200％的开销。但是，对于具有相对较低I / O活动的冷热数据集，在正常操作期间很少访问其他块副本，但是仍然消耗与第一个副本相同的资源量。

因此，自然的改进是使用擦除编码（EC）代替复制，它提供了相同级别的容错能力，而存储空间却少得多。在典型的擦除编码（EC）设置中，存储开销不超过50％。EC文件的复制因子没有意义。它始终为1，无法通过-setrep命令进行更改。

3. YARN时间轴服务v.2（The YARN Timeline Service v.2）

可拓展性
V.1仅限于写入器/读取器和存储的单个实例，并且无法很好地扩展到小型群集之外。V.2使用更具扩展性的分布式写入器体系结构和可扩展的后端存储。

YARN时间轴服务v.2将数据的收集（写入）与数据的提供（读取）分开。它使用分布式收集器，每个YARN应用程序实质上是一个收集器。读取器是专用于通过REST API服务查询的单独实例。

YARN Timeline Service v.2选择Apache HBase作为主要的后备存储，因为Apache HBase可以很好地扩展到较大的大小，同时保持良好的读写响应时间。

可用性改进
在许多情况下，用户对YARN应用程序的“流”级别或逻辑组级别的信息感兴趣。启动一组或一系列YARN应用程序以完成逻辑应用程序更为常见。时间轴服务v.2明确支持流的概念。另外，它支持在流级别汇总指标。

4. Shell脚本重写（Unix Shell Guide）

Hadoop Shell脚本已被重写，以修复许多长期存在的错误并包括一些新功能。尽管一直在寻求兼容性，但是某些更改可能会破坏现有的安装。

增加了参数冲突检测，避免重复定义和冗余参数
CLASSPATH, JAVA_LIBRARY_PATH, and LD_LIBRARY_PATH等参数的去重，缩短环境变量
提供一份Hadoop环境变量列表 Shell脚本现在支持一个--debug选项，它将报告有关各种环境变量，java选项，classpath等构造的基本信息，以帮助进行配置调试
增加了distch和jnipath子命令到hadoop命令
触发ssh连接的操作现在可以使用pdsh（如果已安装）。$ {HADOOP _SSH _OPTS}仍然被应用
一个名为--buildpaths的新选项将尝试将开发人员构建目录添加到类路径以允许在源代码树测试中
守护进程已经通过--daemon选项从* -daemon.sh移动到了bin命令。只需使用--daemon启动一个守护进程

5. 支持随机container（Opportunistic Containers）和分布式计划

引入了ExecutionType的概念，应用程序现在可以请求执行类型为Opportunistic的容器。即使调度时没有可用资源，也可以在NM上调度这种类型的容器以执行。在这种情况下，这些容器将在NM处排队，等待资源可用以启动它。机会容器的优先级比默认的“ 保证”容器低，因此如果需要，可以抢占机会以为“保证”容器腾出空间。这将提高群集利用率。

默认情况下，机会容器由中央RM分配，但是还添加了支持，以允许由实现为AMRMProtocol拦截器的分布式调度程序分配机会容器。

6. MapReduce任务级本机优化

MapReduce增加了对map输出收集器本地实现的支持。
本机库将使用-Pnative自动构建。
用户可以通过设置：

    mapreduce.job.map.output.collector.class=org.apache.hadoop.mapred. nativetask.NativeMapOutputCollectorDelegator

对于 shuffle-intensive jobs可能会提高30%甚至更多的工作效率。

7. 支持两个以上的NameNode

HDFS NameNode高可用性的初始实现是为单个活动NameNode和单个Standby NameNode提供的。通过将编辑复制到法定数量的三个JournalNode，该体系结构能够容忍系统中任何一个节点的故障。但是，某些部署需要更高的容错度。这项新功能启用了此功能，该功能允许用户运行多个备用NameNode。

例如，通过配置三个NameNode和五个JournalNode，群集可以承受两个节点的故障，而不仅仅是一个节点。

参考：HDFS 高可用说明文档

8. 多个服务的默认端口已更改

参考：HDFS should not default to ephemeral ports
The patch updates the HDFS default HTTP/RPC ports to non-ephemeral ports. The changes are listed below:
Namenode ports: 50470 --> 9871, 50070 --> 9870, 8020 --> 9820
Secondary NN ports: 50091 --> 9869, 50090 --> 9868
Datanode ports: 50020 --> 9867, 50010 --> 9866, 50475 --> 9865, 50075 --> 9864

How about changing into something like below? Just replace 50 with 9

应用	Hadoop2.x port	Hadoop3.x port
Namenode	8020	9820
Namenode Http UI	50070	9870
Namenode Https UI	50470	9871
SNN HTTP	50091	9869
SNN HTTP UI	50090	9868
DN IPC	50020	9867
DN	50010	9866
DN HTTP UI	50075	9864
DN HTTPS UI	50475	9865

9. 支持Microsoft Azure Data Lake和Aliyun对象存储系统文件系统连接器

10. 数据内节点平衡器

单个DataNode可管理多个磁盘。在正常的写操作过程中，磁盘将被均匀填充。但是，添加或替换磁盘可能会导致DataNode内部出现严重偏差。现有的HDFS平衡器无法处理这种情况，该平衡器自身涉及DN之间的偏移，而不涉及内部DN偏移。
这种情况由新的内部DataNode平衡功能处理，该功能通过hdfs diskbalancer CLI调用。

使用参考：HDFS Commands Guide