一、Hadoop2x的新特性
1.集群间的数据拷贝
（1）scp实现两个远程主机之间的文件复制
scp -r hello.txt root@hadoop100:/user/zheng/hello.txt // 推 push
scp -r root@hadoop100:/user/zheng/hello.txt hello.txt // 拉 pull
scp -r root@hadoop100:/user/zheng/hello.txt root@hadoop101:/user/zheng //是通过本地主机中转实现两个远程主机的文件复制；如果在两个远程主机之间ssh没有配置的情况下可以使用该方式。
（2）采用distcp命令实现两个Hadoop集群之间的递归数据复制
[zheng@hadoop102 hadoop-3.1.3]$ bin/hadoop distcp hdfs://hadoop101:9820/user/atguigu/hello.txt hdfs://hadoop104:9820/user/zheng/hello.txt
2.小文件存档
（1）HDFS存储小文件弊端
因为大量小文件会耗尽NameNode中的大部分内存。但注意，存储小文件所需要的磁盘容量和数据块的大小无关
（2）解决存储小文件具体办法
具体来说，HDFS存档文件对内还是一个一个独立文件，对NameNode而言却是一个整体，减少了NameNode的内存
（3）案例实操（需要一台配有hadoop的虚拟机）
步骤一：需要启动YARN进程
[atguigu@hadoop102 hadoop-3.1.3]$ start-yarn.sh
步骤二：归档文件
把/user/atguigu/input目录里面的所有文件归档成一个叫input.har的归档文件，并把归档后文件存储 到/user/atguigu/output路径下。
[atguigu@hadoop102 hadoop-3.1.3]$ hadoop archive -archiveName input.har -p /user/atguigu/input /user/atguigu/output
步骤三：查看归档
[atguigu@hadoop102 hadoop-3.1.3]$ hadoop fs -ls /user/atguigu/output/input.har
[atguigu@hadoop102 hadoop-3.1.3]$ hadoop fs -ls har:///user/atguigu/output/input.har
步骤四：解归档文件
[atguigu@hadoop102 hadoop-3.1.3]$ hadoop fs -cp har:/// user/atguigu/output/input.har/* /user/atguigu
3.回收站
（1）开启回收站功能参数说明
1、默认值fs.trash.interval=0，0表示禁用回收站：其他值表示设置文件的存活时间。
2、默认值fs.trash.checkpoint.interval=0，检查回收站的间隔时间。如果该值为0，则该值设置和fs.trash.interval的参数值相等。
3、要求fs.trash.checkpoint.interval<=fs.trash.interval。
（2）回收站工作机制
（3）案例实操
步骤一：启用回收站
修改core-site.xml，配置垃圾回收时间为1分钟。
fs.trash.interval
1
步骤二：查看回收站
回收站目录在hdfs集群中的路径：/user/atguigu/.Trash/….
步骤三：通过程序删除的文件不会经过回收站，需要调用moveToTrash()才进入回收站
Trash trash = New Trash(conf);
trash.moveToTrash(path);
步骤四：通过网页上直接删除的文件也不会走回收站。
步骤五：只有在命令行利用hadoop fs -rm命令删除的文件才会走回收站。
[atguigu@hadoop102 hadoop-3.1.3]$ hadoop fs -rm -r /user/atguigu/input
2020-07-14 16:13:42,643 INFO fs.TrashPolicyDefault: Moved: ‘hdfs://hadoop102:9820/user/atguigu/input’ to trash at: hdfs://hadoop102:9820/user/atguigu/.Trash/Current/user/atguigu/input
步骤六：恢复回收站数据
[atguigu@hadoop102 hadoop-3.1.3]$ hadoop fs -mv
/user/atguigu/.Trash/Current/user/atguigu/input /user/atguigu/input
二、Hadoop3x的新特性
1.多NN的HA架构
HDFS NameNode高可用性的初始实现为单个活动NameNode和单个备用NameNode，将edits复制到三个JournalNode。该体系结构能够容忍系统中一个NN或一个JN的故障。
但是，某些部署需要更高程度的容错能力。Hadoop3.x允许用户运行多个备用NameNode。例如，通过配置三个NameNode和五个JournalNode，群集能够容忍两个节点而不是一个节点的故障。
2.纠删码
HDFS中的默认3副本方案在存储空间和其他资源（例如，网络带宽）中具有200％的开销。但是，对于I / O活动相对较低暖和冷数据集，在正常操作期间很少访问其他块副本，但仍会消耗与第一个副本相同的资源量。
纠删码（Erasure Coding）能够在不到50% 的数据冗余情况下提供和3副本相同的容错能力，因此，使用纠删码作为副本机制的改进是自然而然的。
查看集群支持的纠删码策略：hdfs ec -listPolicies
3.所需的最小Java版本从Java 7增加到Java 8
所有的Hadoop jar现在都针对Java 8的运行时版本进行了编译。仍然使用Java 7或更低版本的用户必须升级到Java 8。
4.在HDFS中支持擦除编码
擦除编码是一种持久存储数据的方法，与复制相比可以节省大量空间。像Reed-Solomon(10,4)这样的标准编码有1.4倍的空间开销，而标准HDFS复制有3倍的开销。
由于擦除编码在重建过程中增加了额外的开销，并且主要执行远程读取，因此传统上它被用于存储较冷的、访问频率较低的数据。在部署此功能时，用户应该考虑擦除编码的网络和CPU开销。
5.Yarn时间线服务v.2
我们正在介绍一个纱线时间线服务的主要修订的早期预览(alpha 2): v.2。v.2解决了两个主要的挑战:提高时间轴服务的可伸缩性和可靠性，以及通过引入流和聚合来增强可用性。
提供YARN Timeline Service v.2 alpha 2是为了让用户和开发人员可以测试它，并提供反馈和建议，使其成为Timeline Service v.1.x的替代品。它应该只在测试容量中使用。
6.Shell脚本重写
Hadoop shell脚本已经被重写，以修复许多长期存在的错误，并包括一些新特性。在关注兼容性的同时，一些变化可能会破坏现有的安装。
7.支持机会容器和分布式调度
引入了ExecutionType的概念，应用程序现在可以请求具有机会执行类型的容器。即使在调度时没有可用的资源，这种类型的容器也可以在NM上被调度执行。在这种情况下，这些容器将在NM处排队，等待启动可用的资源。机会容器的优先级低于默认的保证容器，因此在需要时被抢占，为保证容器腾出空间。这将提高集群的利用率。
机会容器在默认情况下是由中央RM分配的，但是也增加了支持，允许由作为AMRMProtocol拦截器实现的分布式调度器分配机会容器。
8.MapReduce任务级原生优化
MapReduce增加了对映射输出收集器本地实现的支持。对于移动密集的任务，这可以导致30%或更多的性能改进。
9.多个服务的默认端口已更改
以前，多个Hadoop服务的默认端口都在Linux临时端口范围内(32768-61000)。这意味着在启动时，服务有时会由于与另一个应用程序的冲突而无法绑定到该端口。
这些冲突的端口已经被移出短暂的范围，影响NameNode、Secondary NameNode、DataNode和KMS。
10.支持Microsoft Azure数据湖和阿里云对象存储系统文件系统连接器
11.Intra-datanode均衡器
一个DataNode管理多个磁盘。在正常的写操作期间，磁盘将被均匀地填满。但是，添加或替换磁盘可能会导致DataNode中的严重倾斜。现有的HDFS均衡器不能处理这种情况，它只关注DN之间而不是内部的倾斜。
这种情况由新的datanode内平衡功能处理，该功能是通过hdfs diskbalancer CLI调用的。
12.重新工作的守护进程和任务堆管理
对Hadoop守护进程和MapReduce任务的堆管理进行了一系列更改。
HADOOP-10950引入了配置守护进程堆大小的新方法。值得注意的是，现在可以根据主机的内存大小进行自动调优，而且HADOOP_HEAPSIZE变量已经不赞成使用。
MAPREDUCE-5785简化了map的配置并减少了任务堆大小，因此所需的堆大小不再需要在任务配置中指定，也不再作为Java选项指定。已经指定了两者的现有配置不会受到此更改的影响。
13.HDFS Router-Based联合会
14.基于api的容量调度器队列配置
15.Yarn源类型
Yarn资源模型已经被一般化，以支持除CPU和内存之外的用户定义的可计数资源类型。例如，集群管理员可以定义gpu、软件许可证或本地附加存储等资源。然后可以根据这些资源的可用性来安排Yarn任务。