大数据之Hadoop3.0 新特性

 

总览

官网

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

原理参考：https://www.cnblogs.com/basenet855x/p/7889994.html

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的队列中，等待可用资源，以便执行。Opportunistic container优先级要比默认Guaranteedcontainer低，在需要的情况下，其资源会被抢占，以便Guaranteed container使用。这样就需要提高集群的使用率。
Opportunistic container默认被中央RM分配，但是，目前已经增加分布式调度器的支持，该分布式调度器做为AMRProtocol解析器来实现。
 

6. MapReduce任务级本机优化

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

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

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

7. 支持两个以上的NameNode(现在发现clouder 6.3.1 版本还是只支持2个)

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

11. 重做的守护程序和任务堆管理

主机内存大小可以自动调整，HADOOP_HEAPSIZE已弃用。

HADOOP-10950：介绍了配置守护集成heap大小的新方法。主机内存大小可以自动调整，HADOOP_HEAPSIZE 已弃用。

MAPREDUCE-5785：map和reduce task堆大小的配置方法，所需的堆大小不再需要通过任务配置和Java选项实现，已经指定的现有配置不受此更改影响。

hadoop3.0 设置方法：mapreduce.map/reduce.memory.mb 和 mapreduce.map/reduce.java.opts 只要设置其中一个就可以自动推算设置另外一个。 

参考：
守护程序堆配置
map和reduce任务堆配置

12. S3Guard：S3A文件系统客户端的一致性和元数据缓存

S3Guard

13. 基于HDFS路由器的联合

基于HDFS路由器的联合添加了一个RPC路由层，该层提供了多个HDFS名称空间的联合视图。

参考：
HDFS Router-based

14. Capacity Scheduler队列配置的基于API的配置

容量调度程序的OrgQueue扩展通过提供用户可以调用以修改队列配置的REST API，提供了一种编程方式来更改配置。

参考：
YARN-5734
Hadoop容量调度

15. YARN资源类型

YARN资源模型已被通用化，以支持用户定义的CPU和内存以外的可计数资源类型。例如，集群管理员可以定义资源，例如GPU，软件许可证或本地连接的存储。然后可以根据这些资源的可用性来调度YARN任务。

参考：
YARN-3926
YARN资源模型文档