Hadoop 3.0的新增功能– Apache Hadoop 3的增强功能

这个“ Hadoop 3.0的新功能 ”博客着重介绍了Hadoop 3预期中的更改,因为它仍处于Alpha阶段。Apache社区已合并了许多更改,并且仍在进行某些更改。因此,我们将更广泛地看待预期的变化。

我们将讨论的主要变化是:

Apache Hadoop 3将在Hadoop-2.x上合并许多增强功能。因此,让我们继续研究每个增强功能。

Hadoop 3中预期的变化| Hadoop 3 Alpha入门 埃杜雷卡

 

 

1. Hadoop 3中所需的最低Java版本从7增加到8

在Hadoop 3中,所有Hadoop JAR都是针对Java 8的运行时版本进行编译的。因此,仍在使用Java 7或更低版​​本的用户在开始使用Hadoop 3时必须升级到Java 8。

Java兼容版本-Hadoop 3-Edureka现在让我们讨论Hadoop 3的一项重要增强功能,即Erasure Encoding,它可以减少存储开销,同时提供与之前相同的容错级别。

2.支持HDFS中的纠删编码

现在让我们首先了解什么是擦除编码。

纠删编码-Hadoop 3-Edureka通常,在存储系统中,擦除编码 主要用于廉价磁盘冗余阵列(RAID)中

如上图所示,RAID通过条带化实现EC ,在条带化中,逻辑上连续的数据(例如文件)被分成较小的单元(例如位,字节或块),并将连续的单元存储在不同的磁盘上。

然后,对于原始数据单元的每个条带,计算并存储一定数量的奇偶校验单元。这个过程称为编码可以通过基于剩余数据单元和奇偶校验单元的解码计算来恢复任何条带单元上的错误

当我们有了删除编码的想法时,现在让我们首先了解一下Hadoop 2.x中较早的复制场景。  

HDFS复制开销-Hadoop 3-Edureka

HDFS中的默认复制因子是3,其中一个是原始数据块,另外两个是副本,每个副本都需要100%的存储开销。因此,这将导致  200%的存储开销,并消耗网络带宽等其他资源。

但是,在正常操作期间很少访问具有低I / O活动的冷数据集的副本,但是仍然消耗与原始数据集相同数量的资源。

与HDFS复制相比,擦除编码可存储数据并提供容错功能,并且空间开销较小。可以使用擦除编码(EC)来代替复制,这将提供  相同级别的容错能力,并减少存储开销。

纠删编码开销-Hadoop 3- Edureka将EC与HDFS集成可以保持相同的容错能力,并提高存储效率。例如,一个具有6个块的3x复制文件将消耗6 * 3 = 18个磁盘空间。但是,使用EC(6个数据,3个奇偶校验)部署时,它将仅消耗9个块(6个数据块+ 3个奇偶校验块)磁盘空间。这仅需要高达50%的存储开销。

由于擦除编码由于执行远程读取而在数据重建中需要额外的开销,因此通常用于存储访问频率较低的数据。在部署擦除代码之前,用户应考虑所有开销,例如擦除编码的存储,网络和CPU开销。

现在,为了在HDFS中有效地支持擦除编码,他们对体系结构进行了一些更改。让我们看一下架构上的变化。

HDFS擦除编码:体系结构

  • NameNode扩展 – HDFS文件被划分为块组,这些块组具有一定数量的内部块。现在,为了减少这些额外块的NameNode内存消耗,引入了新的分层块命名协议。可以从其任何内部块的ID推导出块组的ID。这允许在块组而不是块的级别进行管理。
  • 客户端扩展 –在HDFS中实现擦除编码后,NameNode在块组级别上工作,并且客户端的读写路径得到了增强,可以并行在一个块组中的多个内部块上工作。
    • 在输出/写入路径上,DFSStripedOutputStream管理一组数据流,每个数据节点一个,在当前块组中存储一个内部块。协调器负责整个块组的操作,包括结束当前块组,分配新的块组等。
    • 在输入/读取路径上,DFSStripedInputStream将请求的逻辑字节数据范围作为范围转换为存储在DataNodes上的内部块。然后,它并行发出读取请求。发生故障时,它将发出其他读取请求以进行解码。
  • 数据节点扩展 –数据节点运行额外的ErasureCodingWorker(ECWorker)任务,用于对失败的擦除编码块进行后台恢复。NameNode检测到失败的EC块,然后NameNode选择一个DataNode进行恢复工作。重建执行三个关键任务:
    1. 从源节点读取数据,并仅读取最少数量的输入块和奇偶校验块进行重构。
    2. 从输入数据中解码出新数据和奇偶校验块。所有丢失的数据和奇偶校验块一起解码。
    3. 解码完成后,恢复的块将传输到目标DataNodes。
  • ErasureCoding策略 –为了适应异构的工作负载,我们允许HDFS群集中的文件和目录具有不同的复制和EC策略。有关编码和解码文件的信息封装在ErasureCodingPolicy类中。它包含2条信息,即  ECSchema和剥离单元的大小。

Hadoop 3中第二个最重要的增强功能是YARN版本1(在Hadoop 2.x中)的YARN Timeline Service版本2。他们正在尝试在YARN版本2中进行许多积极的更改。

3. YARN时间轴服务v.2

Hadoop正在引入YARN时间轴服务iev2的主要修订版。YARN时间轴服务。它旨在解决两个主要挑战:

  1. 改善时间轴服务的可扩展性和可靠性
  2. 通过引入流程和汇总来提高可用性

开发人员可以测试YARN Timeline Service v.2,以提供反馈和建议。仅应以测试能力加以利用。 YARN时间轴服务v.2中未启用安全性。

因此,让我们首先讨论可伸缩性,然后再讨论流和聚合。 

YARN时间轴服务v.2:可扩展性

YARN版本1仅限于写入器/读取器的单个实例,并且不能很好地扩展到小型群集之外。第2版​​使用更具可扩展性的分布式编写器体系结构和可扩展的后端存储。它将数据的收集(写入)与数据的提供(读取)分开。它使用分布式收集器,每个YARN应用程序实质上是一个收集器。读取器是专用于通过REST API服务查询的单独实例。 

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

YARN时间轴服务v.2:  可用性改进

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

Flows YARN v2-Hadoop认证-Edureka现在让我们来看一下YARN版本2的体系结构级别。

YARN时间轴服务v.2:  体系结构

YARN时间轴服务v.2使用一组收集器(写入器)将数据写入后端存储。收集器与它们专用的应用程序主控器一起分布并位于同一位置,如下图所示。属于该应用程序的所有数据都被发送到应用程序级别的时间线收集器,资源管理器时间线收集器除外。

YARN v2体系结构-Hadoop 3-Edureka

对于给定的应用程序,应用程序主机可以将应用程序的数据写入位于同一位置的时间轴收集器。另外,其他正在运行应用程序容器的节点的节点管理器也将数据写入运行应用程序主机的节点上的时间线收集器。

资源管理器还维护自己的时间轴收集器。它仅发出YARN通用生命周期事件,以保持其合理的写入量。

时间线阅读器是与时间线收集器分开的单独的守护程序,它们专用于通过REST API服务查询。


4. Shell脚本重写

Hadoop Shell脚本已被重写,以修复许多错误,解决兼容性问题并在某些现有安装中进行更改。它还包含一些新功能。因此,我将列出一些重要的:

  • 现在,所有Hadoop Shell脚本子系统都执行hadoop-env.sh,它允许所有环境变量位于一个位置。
  • 守护程序已通过–daemon选项从* -daemon.sh移至bin命令。在Hadoop 3中,我们可以简单地使用–daemon start启动一个守护程序,–daemon stop停止一个守护程序,以及–daemon status设置$?到守护程序的状态。例如,“ hdfs –daemon起始namenode”。 
  • 如果已安装,触发ssh连接的操作现在可以使用pdsh。
  • $ {HADOOP_CONF_DIR}现在在任何地方都可以正确使用,而无需符号链接和其他技巧。
  • 现在,脚本可以在守护程序启动时针对日志和pid dirs的各种状态测试并报告更好的错误消息。以前,未保护的外壳错误将显示给用户。

当Hadoop 3进入Beta阶段时,您将了解更多功能。现在让我们讨论有阴影的客户端jar并了解它们的好处。 

5.阴影的客户罐

Hadoop 2.x版本中提供的  hadoop-client将Hadoop的可传递依赖项拉到Hadoop应用程序的类路径中。如果这些传递依赖项的版本与应用程序使用的版本冲突,则可能会产生问题。

因此,在Hadoop 3中,我们有了新的hadoop-client-api和hadoop-client-runtime工件,它们将Hadoop的依赖项隐藏在一个jar中。hadoop-client-api是编译范围,而hadoop-client-runtime是运行时范围,其中包含从hadoop-client重新定位的第三方依赖。因此,您可以将依赖项捆绑到一个jar中,并测试整个jar是否存在版本冲突。这样可以避免将Hadoop的依赖项泄漏到应用程序的类路径中。例如,HBase可以用来与Hadoop集群通信,而无需查看任何实现依赖项。

现在让我们继续前进,了解Hadoop 3中引入的另一项新功能,即机会容器。

6.支持机会容器和分布式计划

引入了新的ExecutionType,即机会容器,即使调度时没有可用资源,也可以在NodeManager上将其分派执行。在这种情况下,这些容器将在NM处排队,等待资源可用以启动它。机会容器的优先级比默认的“保证”容器低,因此如果需要,可以抢占机会,以便为“保证”容器腾出空间。这将提高群集利用率。

机会容器-Hadoop认证-Edureka保证的容器  对应于现有的YARN容器。它们由容量调度程序分配,一旦分配到节点,就可以确保有可用资源立即执行。而且,只要没有故障,这些容器就可以完成。

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

现在继续前进,让我们看一下如何优化MapReduce性能。

7. MapReduce任务级本机优化

在Hadoop 3中,MapReduce中已为地图输出收集器添加了本机Java实现。对于洗牌密集型工作,这可以将性能提高30%或更多。

他们添加了地图输出收集器的本地实现。对于洗牌密集型工作,这可以使速度提高30%或更多。他们正在为基于JNI的MapTask进行本机优化。基本思想是添加一个NativeMapOutputCollector来处理映射器发出的键值对,因此排序,溢出,IFile序列化都可以在本机代码中完成。他们仍在处理合并代码。


现在让我们看一下Apache社区如何尝试使Hadoop 3更具容错能力。

8.支持两个以上的NameNode

在Hadoop 2.x中,HDFS NameNode高可用性架构具有一个活动的NameNode和一个Standby NameNode。通过将编辑复制到法定数量的三个JournalNode,该体系结构能够容忍任何一个NameNode的故障。

但是,关键业务部署需要更高程度的容错能力。因此,在Hadoop 3中,用户可以运行多个备用NameNode。例如,通过配置三个NameNode(1个主动节点和2个被动节点)和5个JournalNode,群集可以容忍两个节点的故障。

2被动Namenode-Hadoop认证-Edureka接下来,我们将查看在Hadoop 3中已更改的Hadoop服务的默认端口。

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

之前,多个Hadoop服务的默认端口在Linux 临时端口范围内(32768-61000)。除非客户端程序明确请求特定的端口号,否则使用的端口号是临时端口号。因此,在启动时,由于与另一个应用程序的冲突,服务有时可能无法绑定到端口。

因此,具有短暂范围的冲突端口已移出该范围,从而影响了多个服务的端口号,即NameNode,Secondary NameNode,DataNode等。一些重要的端口是:

更改了Hadoop 3的默认端口-Hadoop 3-Edureka
期望的更多。现在继续前进,让我们知道什么是新的Hadoop 3文件系统连接器。

10.对文件系统连接器的支持

Hadoop现在支持与Microsoft Azure数据湖和Aliyun对象存储系统集成。它可用作替代的Hadoop兼容文件系统。首先添加了Microsoft Azure Data Lake,然后他们还添加了Aliyun对象存储系统。您可能会期望更多。

让我们了解如何在数据节点的多个磁盘中改进Balancer 

11.数据内节点平衡器

节点间平衡器-Hadoop认证-Edureka

单个DataNode可管理多个磁盘。在正常的写操作期间,数据被平均分配,因此磁盘被均匀填充。但是,添加或替换磁盘会导致DataNode内的歪斜。现有的HDFS平衡器无法解决这种情况。这涉及到DataNode内部偏斜。

节点内平衡器-Hadoop认证-Edureka

现在,Hadoop 3通过新的内部DataNode平衡功能处理了这种情况,该功能通过hdfs diskbalancer CLI调用。

现在让我们看一下如何进行各种内存管理。

12.重做的守护进程和任务堆管理

对Hadoop守护程序以及MapReduce任务的堆管理进行了一系列更改。

  • 用于配置守护程序堆大小的新方法。值得注意的是,现在可以根据主机的内存大小进行自动调整,并且已弃用HADOOP_HEAPSIZE变量,而已引入HADOOP_HEAPSIZE_MAX和HADOOP_HEAPSIZE_MIN分别设置Xmx和Xms。 现在,所有全局和特定于守护程序的堆大小变量都支持单位。如果变量仅是一个数字,则假定大小为MB。
  • 简化了map的配置并减小了任务堆大小,因此不再需要在任务配置和Java选项中都指定所需的堆大小。已经指定两者的现有配置不受此更改的影响。

我希望这个博客能为您提供更多信息并为您增加价值。Apache社区仍在致力于多项增强功能,这些增强功能可能要到Beta阶段才能推出。我们将为您提供最新信息,并提供有关Hadoop 3的更多博客和视频。

现在您已经知道Hadoop 3的预期变化,请查看 Edureka 的  Hadoop培训,该公司是一家受信任的在线学习公司,其网络遍布全球,共有250,000多名满意的学习者。Edureka大数据Hadoop认证培训课程使用零售,社交媒体,航空,旅游,金融领域的实时用例,帮助学习者成为HDFS,Yarn,MapReduce,Pig,Hive,HBase,Oozie,Flume和Sqoop的专家。

有问题要问我们吗?请在评论部分中提及它,我们将尽快与您联系。

发布了377 篇原创文章 · 获赞 127 · 访问量 64万+

猜你喜欢

转载自blog.csdn.net/daqiang012/article/details/104141322