Hadoop 2.x与Hadoop 3.x之间的功能比较

布满荆棘的人生 2022-04-12 14:17 439阅读 0赞

### Hadoop 2.x与Hadoop 3.x之间的功能比较 ###

*  1.JDK要求
 *  2.HDFS支持纠删码
 *  3.YARN Timeline Service版本更新到v.2
 *  4.重写相关shell脚本，比如所有脚本都以hadoop-env.sh为基础脚本等等
 *  5.合并客户端jar，比如使用maven的shaded插件将 hadoop-client-api和hadoop-client-runtime合并为一个jar
 *  6.支持投机性的容器和分布式调度，比如在没有资源可分配时仍可执行一个Applications
 *  7.MapReduce本地优化
 *  8.支持2个以上namenode
 *  9.默认的端口和服务有改变
 *  10.支持微软Azure存储系统和阿里云存储系统
 *  11.新增内部节点的平衡器
 *  12.重做了后台程序和任务的堆内存管理
 *  13.针对S3文件系统支持DynamoDB存储
 *  14.HDFS支持基于路由器的联盟
 *  15.提供REST API来修改容量调度
 *  16.YARN的资源除了传统的CPU和内存外，还可以支持用户自定义的资源类型，比如GPU

# 1.JDK要求 #

JDK>=1.7

# 2.HDFS支持纠删码 #

与副本相比纠删码是一种更节省空间的数据持久化存储方法。标准编码(比如Reed-Solomon(10,4))会有1.4 倍的空间开销；然而HDFS副本则会有3倍的空间开销。因为纠删码额外开销主要是在重建和执行远程读，它传统用于存储冷数据，即不经常访问的数据。当部署这个新特性时用户应该考虑纠删码的网络和CPU 开销。更多关于HDFS的纠删码可以参见http://hadoop.apache.org/docs/r3.0.0-beta1/hadoop-project-dist/hadoop-hdfs/HDFSErasureCoding.html.

# 3.YARN Timeline Service版本更新到v.2 #

本版本引入了Yarn时间抽服务v.2，主要用于解决2大挑战：改善时间轴服务的可伸缩性和可靠性，通过引入流和聚合增强可用性。  
YARN Timeline Service v.2 alpha 1可以让用户和开发者测试以及反馈，以便使得它可以替换现在的Timeline Service v.1.x。请在测试环境中使用。更多关于YARN Timeline Service v.2的知识请参见http://hadoop.apache.org/docs/r3.0.0-beta1/hadoop-yarn/hadoop-yarn-site/TimelineServiceV2.html

# 4.重写相关shell脚本，比如所有脚本都以hadoop-env.sh为基础脚本等等 #

Hadoop的Shell脚本被重写解决了之前很多长期存在的bug，并且引入了一些新的特性。绝大部分都保持兼容性，不过仍有些变化可能使得现有的安装不能正常运行。不兼容的改变可以参见HADOOP-9902。更多内容请参见Unix Shell Guide文档。即使你是资深用户，也建议看下这个文档，因为其描述了许多新的功能，特别是与可扩展性有关的功能。

# 5.合并客户端jar，比如使用maven的shaded插件将 hadoop-client-api和hadoop-client-runtime合并为一个jar #

在 Hadoop 2.x 版本，hadoop-client Maven artifact将 Hadoop 所有的依赖都加到 Hadoop 应用程序的环境变量中，这样会可能会导致应用程序依赖的类和 Hadoop 依赖的类有冲突。这个问题在 HADOOP-11804 得到了解决。

# 6.支持投机性的容器和分布式调度，比如在没有资源可分配时仍可执行一个Applications #

Opportunistic Container引入新 Opportunistic 类型的 Container 后，这种 Container 可以利用节点上已分配但未真正使用的资源。原有 Container 类型定义为 Guaranteed 类型。相对于 Guaranteed 类型Container， Opportunistic 类型的Container优先级更低。

# 7.MapReduce本地优化 #

# 8.支持2个以上namenode #

初的HDFS NameNode high-availability实现仅仅提供了一个active NameNode和一个Standby NameNode；并且通过将编辑日志复制到三个JournalNodes上，这种架构能够容忍系统中的任何一个节点的失败。然而，一些部署需要更高的容错度。我们可以通过这个新特性来实现，其允许用户运行多个Standby NameNode。比如通过配置三个NameNode和五个JournalNodes，这个系统可以容忍2个节点的故障，而不是仅仅一个节点。HDFS high-availability文档已经对这些信息进行了更新，我们可以阅读这篇文档了解如何配置多于2个NameNodes。

# 9.默认的端口和服务有改变 #

在此之前，多个Hadoop服务的默认端口都属于Linux的临时端口范围（32768-61000）。这就意味着我们的服务在启动的时候可能因为和其他应用程序产生端口冲突而无法启动。现在这些可能会产生冲突的端口已经不再属于临时端口的范围，这些端口的改变会影响NameNode, Secondary NameNode, DataNode以及KMS。与此同时，官方文档也进行了相应的改变，具体可以参见 HDFS-9427以及HADOOP-12811。

# 10.支持微软Azure存储系统和阿里云存储系统 #

# 11.新增内部节点的平衡器 #

== 一个DataNode可以管理多个磁盘，正常写入操作，各磁盘会被均匀填满==。然而，当添加或替换磁盘时可能导致此DataNode内部的磁盘存储的数据严重内斜。这种情况现有的HDFS balancer是无法处理的。这种情况是由新intra-DataNode平衡功能来处理，通过hdfs diskbalancer CLI来调用。更多请参考HDFS Commands Guide

# 12.重做了后台程序和任务的堆内存管理 #

Hadoop守护进程和MapReduce任务的堆内存管理发生了一系列变化。  
HADOOP-10950：介绍了配置守护集成heap大小的新方法。主机内存大小可以自动调整，HADOOP\_HEAPSIZE 已弃用。  
MAPREDUCE-5785：map和reduce task堆大小的配置方法，所需的堆大小不再需要通过任务配置和Java选项实现。已经指定的现有配置不受此更改影响。

# 13.针对S3文件系统支持DynamoDB存储 #

HADOOP-13345 里面为 Amazon S3 存储系统的 S3A 客户端引入了一个新的可选特性，也就是可以使用 DynamoDB 表作为文件和目录元数据的快速一致的存储

# 14.HDFS支持基于路由器的联盟 #

HDFS Router-Based Federation 添加了一个 RPC路由层，提供了多个 HDFS 命名空间的联合视图。与现有 ViewFs 和 HDFS Federation 功能类似，不同之处在于挂载表（mount table）由服务器端（server-side）的路由层维护，而不是客户端。这简化了现有 HDFS客户端 对 federated cluster 的访问。 详细请参见：HDFS-10467

# 15.提供REST API来修改容量调度 #

OrgQueue 扩展了 capacity scheduler ，通过 REST API 提供了以编程的方式来改变队列的配置，This enables automation of queue configuration management by administrators in the queue’s administer\_queue ACL.。详细请参见：YARN-5734

# 16.YARN的资源除了传统的CPU和内存外，还可以支持用户自定义的资源类型，比如GPU #

YARN 资源模型（YARN resource model）已被推广为支持用户自定义的可数资源类型（support user-defined countable resource types），不仅仅支持 CPU 和内存。比如集群管理员可以定义诸如 GPUs、软件许可证（software licenses）或本地附加存储器（locally-attached storage）之类的资源。YARN 任务可以根据这些资源的可用性进行调度。详细请参见： YARN-3926。

版权声明：本博客为记录本人自学感悟，转载需注明出处！  
[https://me.csdn.net/qq\_39657909][https_me.csdn.net_qq_39657909]

[https_me.csdn.net_qq_39657909]: https://me.csdn.net/qq_39657909