Hadoop3.0的新特性

Hadoop3.0新特性介绍，比Spark快10倍的Hadoop3.0新特性

Apache hadoop 项目组最新消息，hadoop3.x以后将会调整方案架构，将Mapreduce 基于内存+io+磁盘，共同处理数据。
其实最大改变的是hdfs,hdfs 通过最近black块计算，根据最近计算原则，本地black块，加入到内存，先计算，通过IO，共享内存计算区域，最后快速形成计算结果。

1. Hadoop 3.0简介

Hadoop 2.0是基于JDK 1.7开发的，而JDK 1.7在2015年4月已停止更新，这直接迫使Hadoop社区基于JDK 1.8重新发布一个新的Hadoop版本，而这正是hadoop 3.0。

Hadoop 3.0的alpha版预计今年夏天发布，GA版本11月或12月发布。

Hadoop 3.0中引入了一些重要的功能和优化，包括HDFS 可擦除编码、多Namenode支持、MR Native Task优化、YARN基于cgroup的内存和磁盘IO隔离、YARN container resizing等。

 

2. Hadoop 3.0新特性

Hadoop 3.0在功能和性能方面，对hadoop内核进行了多项重大改进，主要包括：

2.1 Hadoop Common

（1）精简Hadoop内核，包括剔除过期的API和实现，将默认组件实现替换成最高效的实现（比如将FileOutputCommitter缺省实现换为v2版本，废除hftp转由webhdfs替代，移除Hadoop子实现序列化库org.apache.hadoop.Records

（2）Classpath isolation以防止不同版本jar包冲突，比如google Guava在混合使用Hadoop、HBase和Spark时，很容易产生冲突。（https://issues.apache.org/jira/browse/HADOOP-11656）

（3）Shell脚本重构。 Hadoop 3.0对Hadoop的管理脚本进行了重构，修复了大量bug，增加了新特性，支持动态命令等。https://issues.apache.org/jira/browse/HADOOP-9902

2.2 Hadoop HDFS

（1）HDFS支持数据的擦除编码，这使得HDFS在不降低可靠性的前提下，节省一半存储空间。（https://issues.apache.org/jira/browse/HDFS-7285）

（2）多NameNode支持，即支持一个集群中，一个active、多个standby namenode部署方式。注：多ResourceManager特性在hadoop 2.0中已经支持。（https://issues.apache.org/jira/browse/HDFS-6440）

2.3 Hadoop MapReduce

（1）Tasknative优化。为MapReduce增加了C/C++的map output collector实现（包括Spill，Sort和IFile等），通过作业级别参数调整就可切换到该实现上。对于shuffle密集型应用，其性能可提高约30%。（https://issues.apache.org/jira/browse/MAPREDUCE-2841）

（2）MapReduce内存参数自动推断。在Hadoop 2.0中，为MapReduce作业设置内存参数非常繁琐，涉及到两个参数：mapreduce.{map,reduce}.memory.mb和mapreduce.{map,reduce}.java.opts，一旦设置不合理，则会使得内存资源浪费严重，比如将前者设置为4096MB，但后者却是“-Xmx2g”，则剩余2g实际上无法让java heap使用到。（https://issues.apache.org/jira/browse/MAPREDUCE-5785）

2.4 Hadoop YARN

（1）基于cgroup的内存隔离和IO Disk隔离（https://issues.apache.org/jira/browse/YARN-2619）

（2）用curator实现RM leader选举（https://issues.apache.org/jira/browse/YARN-4438）

（3）containerresizing（https://issues.apache.org/jira/browse/YARN-1197）

（4）Timelineserver next generation （https://issues.apache.org/jira/browse/YARN-2928）

以下是hadoop-3.0的最新参数

hadoop-3.0

HADOOP
Move to JDK8+
Classpath isolation on by default HADOOP-11656

Shell script rewrite HADOOP-9902

Move default ports out of ephemeral range HDFS-9427

HDFS
Removal of hftp in favor of webhdfs HDFS-5570

Support for more than two standby NameNodes HDFS-6440

Support for Erasure Codes in HDFS HDFS-7285

YARN
MAPREDUCE
Derive heap size or mapreduce.*.memory.mb automatically MAPREDUCE-5785

在HDFS-7285中,实现了Erasure Coding这个新功能.鉴于此功能还远没有到发布的阶段,可能后面此块相关的代码还会进行进一步的改造,因此只是做一个所谓的预分析,帮助大家提前了解Hadoop社区目前是如何实现这一功能的.本人之前也没有接触过Erasure Coding技术,中间过程也确实有些偶然,相信本文可以带给大家收获.

Erasure coding纠删码技术简称EC,是一种数据保护技术.最早用于通信行业中数据传输中的数据恢复,是一种编码容错技术.他通过在原始数据中加入新的校验数据,使得各个部分的数据产生关联性.在一定范围的数据出错情况下,通过纠删码技术都可以进行恢复.下面结合图片进行简单的演示,首先有原始数据n个,然后加入m个校验数据块.如下图所示:

Parity部分就是校验数据块,我们把一行数据块组成为Stripe条带,每行条带由n个数据块和m个校验块组成.原始数据块和校验数据块都可以通过现有的数据块进行恢复,原则如下:

如果校验数据块发生错误,通过对原始数据块进行编码重新生成如果原始数据块发生错误, 通过校验数据块的解码可以重新生成。

而且m和n的值并不是固定不变的，可以进行相应调整。可能有人会好奇，这其中到底是什么原理呢? 其实道理很简单，你把上面这图看成矩阵，由于矩阵的运算具有可逆性，所以就能使数据进行恢复，给出一张标准的矩阵相乘图，大家可以将二者关联。

3. Hadoop3.0 总结

Hadoop 3.0的alpha版预计2016夏天发布，GA版本11月或12月发布。

Hadoop 3.0中引入了一些重要的功能和优化，包括HDFS 可擦除编码、多Namenode支持、MR Native Task优化、YARN基于cgroup的内存和磁盘IO隔离、YARN container resizing等。

 

 

 

 

        相对于之前主要生产发布版本Hadoop 2，Apache Hadoop 3整合许多重要的增强功能。 Hadoop 3是一个可用版本，提供了稳定性和高质量的API，可以用于实际的产品开发。下面简要介绍一下Hadoop3的主要变化。

• 最低Java版本要求从Java7变为Java8

    所有Hadoop的jar都是基于Java 8运行是版本进行编译执行的，仍在使用Java 7或更低Java版本的用户需要升级到Java 8。

• HDFS支持纠删码（erasure coding）

    纠删码是一种比副本存储更节省存储空间的数据持久化存储方法。比如Reed-Solomon(10,4)标准编码技术只需要1.4倍的空间开销，而标准的HDFS副本技术则需要3倍的空间开销。由于纠删码额外开销主要在于重建和远程读写，它通常用来存储不经常使用的数据（冷数据）。另外，在使用这个新特性时，用户还需要考虑网络和CPU开销。

• YARN时间线服务 v.2(YARN Timeline Service v.2)

    YARN Timeline Service v.2用来应对两个主要挑战：（1）提高时间线服务的可扩展性、可靠性，（2）通过引入流(flow)和聚合(aggregation)来增强可用性。为了替代Timeline Service v.1.x，YARN Timeline Service v.2 alpha 2被提出来，这样用户和开发者就可以进行测试，并提供反馈和建议，不过YARN Timeline Service v.2还只能用在测试容器中。

• 重写Shell脚本

    Hadoop的shell脚本被重写，修补了许多长期存在的bug，并增加了一些新的特性。

• 覆盖客户端的jar（Shaded client jars）

    在2.x版本中，hadoop-client Maven artifact配置将会拉取hadoop的传递依赖到hadoop应用程序的环境变量，这回带来传递依赖的版本和应用程序的版本相冲突的问题。

    HADOOP-11804 添加新 hadoop-client-api和hadoop-client-runtime artifcat，将hadoop的依赖隔离在一个单一Jar包中，也就避免hadoop依赖渗透到应用程序的类路径中。

• 支持Opportunistic Containers和Distributed Scheduling

    ExecutionType概念被引入，这样一来，应用能够通过Opportunistic的一个执行类型来请求容器。即使在调度时，没有可用的资源，这种类型的容器也会分发给NM中执行程序。在这种情况下，容器将被放入NM的队列中，等待可用资源，以便执行。Opportunistic container优先级要比默认Guaranteedcontainer低，在需要的情况下，其资源会被抢占，以便Guaranteed container使用。这样就需要提高集群的使用率。

    Opportunistic container默认被中央RM分配，但是，目前已经增加分布式调度器的支持，该分布式调度器做为AMRProtocol解析器来实现。

• MapReduce任务级本地优化

    MapReduce添加了映射输出收集器的本地化实现的支持。对于密集型的洗牌操作（shuffle-intensive）jobs，可以带来30%的性能提升。

• 支持多余2个以上的NameNodes

    针对HDFS NameNode的高可用性，最初实现方式是提供一个活跃的（active）NameNode和一个备用的（Standby）NameNode。通过对3个JournalNode的法定数量的复制编辑，使得这种架构能够对系统中任何一个节点的故障进行容错。

    该功能能够通过运行更多备用NameNode来提供更高的容错性，满足一些部署的需求。比如，通过配置3个NameNode和5个JournalNode，集群能够实现两个节点故障的容错。

• 修改了多重服务的默认端口

    在之前的Hadoop版本中，多重Hadoop服务的默认端口在Linux临时端口范围内容（32768-61000），这就意味着，在启动过程中，一些服务器由于端口冲突会启动失败。这些冲突端口已经从临时端口范围移除，NameNode、Secondary NameNode、DataNode和KMS会受到影响。我们的文档已经做了相应的修改，可以通过阅读发布说明 HDFS-9427和HADOOP-12811详细了解所有被修改的端口。

• 提供文件系统连接器（filesystem connnector）,支持Microsoft Azure Data Lake和Aliyun对象存储系统

    Hadoop支持和Microsoft Azure Data Lake和Aliyun对象存储系统集成，并将其作为Hadoop兼容的文件系统。

• 数据节点内置平衡器（Intra-datanode balancer）

    在单一DataNode管理多个磁盘情况下，在执行普通的写操作时，每个磁盘用量比较平均。但是，当添加或者更换磁盘时，将会导致一个DataNode磁盘用量的严重不均衡。由于目前HDFS均衡器关注点在于DataNode之间（inter-），而不是intra-，所以不能处理这种不均衡情况。

    在hadoop3 中，通过DataNode内部均衡功能已经可以处理上述情况，可以通过hdfs diskbalancer ClI来调用。

• 重写了守护进程和任务的堆管理机制

    针对Hadoop守护进程和MapReduce任务的堆管理机制，Hadoop3 做了一系列的修改。

    HADOOP-10950 引入配置守护进程堆大小的新方法。特别地，HADOOP_HEAPSIZE配置方式已经被弃用，可以根据主机的内存大小进行自动调整。

    MAPREDUCE-5785 简化了MAP的配置，减少了任务堆的大小，所以不需要再任务配置和Java可选项中明确指出需要的堆大小。已经明确指出堆大小的现有配置不会受到该改变的影响。

• S3Gurad:为S3A文件系统客户端提供一致性和元数据缓存

    HADOOP-13345 为亚马逊S3存储的S3A客户端提供了可选特性：能够使用DynamoDB表作为文件和目录元数据的快速、一致性存储。

• HDFS的基于路由器互联（HDFS Router-Based Federation）

    HDFS Router-Based Federation添加了一个RPC路由层，为多个HDFS命名空间提供了一个联合视图。这和现有的ViewFs、HDFS Federation功能类似，区别在于通过服务端管理表加载，而不是原来的客户端管理。从而简化了现存HDFS客户端接入federated cluster的操作。

 

• 基于API配置的Capacity Scheduler queue configuration

    OrgQueue扩展了capacity scheduler，提供了一种编程方法，该方法提供了一个REST API来修改配置，用户可以通过远程调用来修改队列配置。这样一来，队列的administer_queue ACL的管理员就可以实现自动化的队列配置管理。

• YARN资源类型

    Yarn资源模型已经被一般化，可以支持用户自定义的可计算资源类型，而不仅仅是CPU和内存。比如，集群管理员可以定义像GPU数量，软件序列号、本地连接的存储的资源。然后，Yarn任务能够在这些可用资源上进行调度。