【Hadoop】Hadoop 3.x 新特性总览

阿里云国内75折回扣微信号：monov8

阿里云国际，腾讯云国际，低至75折。AWS 93折免费开户实名账号代冲值优惠多多微信号：monov8 飞机：@monov6

Hadoop 3.x 新特性剖析系列1

1. 概述

从功能上来说Hadoop3比Hadoop2有些功能得到了增强具体增加了哪些后面再讲。首先我们来看看Hadoop3主要带来了哪些变化

JDK在Hadoop2时可以使用JDK7但是在Hadoop3中最低版本要求是JDK8所以低于JDK8的版本需要对JDK进行升级方可安装使用Hadoop3
EC技术Erasure Encoding 简称EC是Hadoop3给HDFS拓展的一种新特性用来解决存储空间文件。EC技术既可以防止数据丢失又能解决HDFS存储空间翻倍的问题
YARN提供YARN的时间轴服务V.2以便用户和开发人员可以对其进行测试并提供反馈意见使其成为YARN Timeline Service v.1的替代品。
优化Hadoop Shell脚本
重构Hadoop Client Jar包
支持随机Container
支持多个NameNode
部分默认服务端口被改变
支持文件系统连接器
DataNode内部添加了负载均衡

2. 内容

2.1 JDK

在Hadoop 3中所有的Hadoop JAR包编译的环境都是基于Java8来完成的所有如果仍然使用的是Java 7或者更低的版本你可能需要升级到Java 8才能正常的运行Hadoop3。如下图所示
在这里插入图片描述

2.2 EC技术

首先我们先来了解一下什么是Erasure Encoding。如下图所示

在这里插入图片描述

一般来说在存储系统中EC技术主要用于廉价磁盘冗余阵列即RAID。如上图RAID通过Stripping实现EC技术其中逻辑顺序数据比如文件被划分成更小的单元比如位、字节或者是块并将连续单元存储在不同的磁盘上。

然后对原始数据单元的每个Stripe计算并存储一定数量的奇偶校验单位。这个过程称之为编码通过基于有效数据单元和奇偶校验单元的解码计算可以恢复任意Stripe单元的错误。当我们想到了擦除编码的时候我们可以先来了解一下在Hadoop2中复制的早期场景。如下图所示
在这里插入图片描述

HDFS默认情况下它的备份系数是3一个原始数据块和其他2个副本。其中2个副本所需要的存储开销各站100%这样使得200%的存储开销会消耗其他资源比如网络带宽。然而在正常操作中很少访问具有低IO活动的冷数据集的副本但是仍然消耗与原始数据集相同的资源量。

对于EC技术即擦除编码存储数据和提供容错空间较小的开销相比HDFS复制EC技术可以代替复制这将提供相同的容错机制同时还减少了存储开销。如下图所示

在这里插入图片描述
　　EC和HDFS的整合可以保持与提供存储效率相同的容错。例如一个副本系数为3要复制文件的6个块需要消耗6*3=18个块的磁盘空间。但是使用EC技术6个数据块3个奇偶校验块来部署它只需要消耗磁盘空间的9个块6个数据块+3个奇偶校验块。这些与原先的存储空间相比较节省了50%的存储开销。

由于擦除编码需要在执行远程读取时对数据重建带来额外的开销因此他通常用于存储不太频繁访问的数据。在部署EC之前用户应该考虑EC的所有开销比如存储、网络、CPU等。

2.3 YARN的时间线V.2服务

Hadoop引入YARN Timeline Service v.2是为了解决两个主要问题

提高时间线服务的可伸缩性和可靠性
通过引入流和聚合来增强可用性

下面首先我们来剖析一下它伸缩性。

2.3.1 伸缩性

YARN V1仅限于读写单个实例不能很好的扩展到小集群之外。YARN V2使用了更具有伸缩性的分布式体系架构和可扩展的后端存储它将数据的写入与数据的读取进行了分离。并使用分布式收集器本质上是每个YARN应用的收集器。读则是独立的实例专门通过REST API服务来查询

2.3.2 可用性

对于可用性的改进在很多情况下用户对流或者YARN应用的逻辑组的信息比较感兴趣。启动一组或者一系列的YARN应用程序来完成逻辑应用是很常见的。如下图所示
在这里插入图片描述

2.3.3 架构体系

YARN时间线服务V2采用了一组收集器写数据到后端进行存储。收集器被分配并与它们专用的应用程序主机进行协作如下图所示属于该应用程序的所有数据都被发送到应用程序时间轴的收集器中但是资源管理器时间轴收集器除外。
在这里插入图片描述
对于给定的应用程序应用程序可以将数据写入同一时间轴收集器中。此外为应用程序运行容器的其他节点的节点管理器还会向运行应用程序主节点的时间轴收集器写入数据。资源管理器还维护自己的时间手机线收集器它只发布YARN的通用生命周期事件以保持其写入量合理。时间的读取器是单独的守护进程从收集器中分离出来的它旨在服务于REST API查询操作。

2.4 优化Hadoop Shell脚本

Hadoop Shell脚本已经被重写用来修复已知的BUG解决兼容性问题和一些现有安装的更改。它还包含了一些新的特性内容如下所示

所有Hadoop Shell脚本子系统现在都会执行hadoop-env.sh这个脚本它允许所有环节变量位于一个位置
守护进程已通过*-daemon.sh选项从*-daemon.sh移动到了bin命令中在Hadoop3中我们可以简单的使用守护进程来启动、停止对应的Hadoop系统进程
触发SSH连接操作现在可以在安装时使用PDSH
${HADOOP_CONF_DIR}现在可以任意配置到任何地方
脚本现在测试并报告守护进程启动时日志和进程ID的各种状态

2.5 重构Hadoop Client Jar包

Hadoop2 中可用的Hadoop客户端将Hadoop的传递依赖性拉到Hadoop应用程序的类路径上。如果这些传递依赖项的版本与应用程序使用的版本发送冲突这可能会产生问题。

因此在Hadoop3中有新的Hadoop客户端API和Hadoop客户端运行时工件它们将Hadoop的依赖性遮蔽到单个JAR中Hadoop客户端API是编译范围Hadoop客户端运行时是运行时范围它包含从Hadoop客户端重新定位的第三方依赖关系。因此你可以将依赖项绑定到JAR中并测试整个JAR以解决版本冲突。这样避免了将Hadoop的依赖性泄露到应用程序的类路径上。例如HBase可以用来与Hadoop集群进行数据交互而不需要看到任何实现依赖。

2.6 支持等待容器和分布式调度

在Hadoop3 中引入了一种新型执行类型即等待容器即使在调度时集群没有可用的资源它也可以在NodeManager中被调度执行。在这种情况下这些容器将在NM中排队等待资源启动等待荣容器比默认容器优先级低因此如果需要可以抢占默认容器的空间这样可以提供机器的利用率。如下图所示

在这里插入图片描述

默认容器对于现有的YARN容器它们由容量调度分配一旦被调度到节点就保证有可用的资源使它们执行立即开始。此外只要没有故障发生这些容器就可以允许完毕。

等待容器默认由中心RM分配但还增加了支持以允许等待容器被分布式调度该调度群被实现于AM和RM协议的拦截器。

2.7 支持多个NameNode节点

在Hadoop2中HDFS NameNode高可用体系结构有一个Active和Standby NameNode通过JournalNodes该体系结构能够容忍任何一个NameNode失败。

然而业务关键部署需要更高程度的容错性。因此在Hadoop3中允许用户运行多个备用的NameNode。例如通过配置三个NameNode1个Active NameNode和2个Standby NameNode和5个JournalNodes节点集群可以容忍2个NameNode节点故障。如下图所示
在这里插入图片描述