- 浏览: 38020 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
XMaster:
java小小菜 写道我发现了和你这个一模一样的帖子,不知道哪一 ...
Hadoop的DistCp异常处理 -
java小小菜:
我发现了和你这个一模一样的帖子,不知道哪一个才是作者https ...
Hadoop的DistCp异常处理 -
di1984HIT:
写的很好啊~
Hadoop的DistCp异常处理
Apache Hadoop 2.0.3 发布
Apache Hadoop 2.0.3发布了,在这次版本更新中,主要增加了以下几个特性:
1. 引入一种新的HDFS HA解决方案QJM
之前NameNode HA已经有两种解决方案,分别是基于共享存储区的Backup Node方案和基于Bookeeper的方案,在该版本中引入另外一种方案:QJM(Quorum Journal Manager)。
该方案(HDFS-3077) 采用了quorum commit protocol,引入两个角色:QuorumJournalManager和JournalNode,QuourumJournalManager通过 RPC将edits日志写入N个JournalNode,只要有大多数(大于N/2个)JournalNode成功写入则任务日志写入成功。
2. YARN 多资源调度机制
在该版本中,YARN的资源调度器同时支持内存和CPU两种资源调度,采用的调度算法源自Mesos的DRF(Dominant Resource Fairness),对应论文为:“Dominant Resource Fairness: Fair Allocation of Multiple Resources Types”,具体可参考 YARN-2和 Apache Mesos调度机制。
YARN对内存资源和CPU资源采用了不同的资源隔离方案。对于内存资源,为了能够更灵活的控制内存使用量,YARN采用了进程监控的方案控制内 存使用,即每个NodeManager会启动一个额外监控线程监控每个container内存资源使用量,一旦发现它超过约定的资源量,则会将其杀死。采 用这种机制的另一个原因是Java中创建子进程采用了fork()+exec()的方案,子进程启动瞬间,它使用的内存量与父进程一致,从外面看来,一个 进程使用内存量可能瞬间翻倍,然后又降下来,采用线程监控的方法可防止这种情况下导致swap操作。对于CPU资源,则采用了Cgroups进行资源隔 离。具体可参考 YARN-3。
3. YARN ResourceManager重启机制
该版本引入了一个简单的ResourceManager重启机制,保证RM重启后,各个应用工程序可继续运行而不受影响。需要注意的是,这只是第 一阶段的实现,还很不完整,比如不能向NameNode HA那样做到自动切换,不能恢复所有正在运行的Container,Application和ApplicationMaster而只是重新启动另外一个 而已,具体可参考 YARN-230。
4. YARN稳定性和扩展性得到验证
Yahoo已使用YARN在超过3万个节点上运行了14 million个应用程序,具体可参考: Hadoop at Yahoo!: More Than Ever Before。
Hadoop 2.1.0 beta 发布,HDFS提供SnapShot模块(2013年08月28日)
Hadoop 2.1.0 Beta 版 HDFS 提供了SnapShot 模块。用于数据备份、回滚,以防止因用户的失误操作导致集群出现问题。本文先做一个简单的介绍,其他的文章在来介绍Snapshot 本身的实现机制。 HDFS Snapshot有以下几个特性:
Snapshot 创建的时间 复杂度为O(1),但是不包括INode 的寻找时间
只有当修改SnapShot时,才会有额外的内存占用,内存使用量为O(M),M 为修改的文件或者目录数
在datanode 上面的blocks 不会复制,做Snapshot 的文件是纪录了block的信息
Snapshot 并不会影响HDFS 的正常操作
产生了以下新的概念:
Snapshot table:Snapshots 会存储在snapshottable的目录下。snapshottable下存储的snapshots 最多为65535个
Snapshot 路径:举例,假设/foo 是snapshottable,/foo/bar 是文件目录,/foo 拥有一个s0的snapshot,那么路径会是 /foo/.snapshot/s0/bar,我们可以通过
hdfs dfs -ls /foo/.snapshot
hdfs dfs -ls /foo/.snapshot/s0
hdfs dfs -cp /foo/.snapshot/s0/bar /tmp
来操作与查看副本文件。
Snapshot 基本操作:
对一个路径开启Snapshot: hdfs dfsadmin -allowSnapshot <path>
关闭 Snapsshots: hdfs dfsadmin -disallowSnapshot <path>
创建Snapshosts:hdfs dfs -createSnapsshot <path> [snapshot names]
删除Snapshots:hdfs dfs -deleteSnaphost <path> <snapshotName>
修改Snapshots的名字:hdfs dfs -renameSnapshot <path> <oldname> <newname>
获取Snapshot 列表:hdfs lsSnapshottableDir
获取两个Snapshot的不同:hdfs snapsshotDiff <path> <fromSnapshot> <toSnapshot>
Apache Hadoop 2.2.0 稳定版发布(2013年10月16日)
Apache Hadoop 2.2.0 稳定版发布了,建议用户升级。该版本更加稳定,同时在 API 和协议上兼容老的版本。
与 Hadoop 1.x 比较,该版本显著的改进包括:
YARN - A general purpose resource management system for Hadoop to allow MapReduce and other other data processing frameworks and services
High Availability for HDFS
HDFS Federation
HDFS Snapshots
NFSv3 access to data in HDFS
Support for running Hadoop on Microsoft Windows
Binary Compatibility for MapReduce applications built on hadoop-1.x
Substantial amount of integration testing with rest of projects in the ecosystem
升级到 Hadoop 2.2.0 需要注意的有:
HDFS - The HDFS community decided to push the symlinks feature out to a future 2.3.0 release and is currently disabled.
YARN/MapReduce - Users need to change ShuffleHandler service name from mapreduce.shuffle to mapreduce_shuffle.
更多详细介绍请看 Hadoop 2.2.0 Release Notes
Apache Hadoop 2.3.0 发布(2014年02月25日)
Apache Hadoop 2.3.0 发布。Hadoop 是一个分布式系统基础架构,由Apache基金会开发。用户可以在不了解分布式底层细节的情况下,开发分布式程序。充分利用集群的威力高速运算和存储。
2014-02-21 这是去年2013-10-16 2.2.0之后的第一个版本。1的产品系列还是1.2.1。新特性包括支持HDFS的混合存储分级,可以集中管理HDFS内存里的缓存数据,通过HDFS中的YARN分布式缓存简化MapReduce分配及一些Bug修正。(兼容2.2.0)
完全改进及发布声明:http://hadoop.apache.org/docs/r2.3.0/hadoop-project-dist/hadoop-common/releasenotes.html
Hadoop 2.5.0 发布(2014年08月16日)
一个小更新版本,包括一些主要新特性和改进以及 Bug 修复,例如扩展文件属性和改进 HDFS 的 Web UI,提升 ATS 安全性,更丰富的 YARN REST API 等。
Hadoop 2.7.0 发布,不再支持 JDK 6(2015年04月24日)
Apache Hadoop 2.7.0 发布,包括大量显著改进,值得关注的改进如下:
重大改进
此版本不再支持 JDK 6 运行时,仅支持 JDK 7+
此版本不适用于生产环境!还有一些重要的问题需要通过测试,用于生产环境的用户请等待 2.7.1/2.7.2
Hadoop Common
支持 Windows Azure 存储 —— Blob
Hadoop HDFS
支持文件截断
支持每个存储类型配额
支持可变长度的文件块
Hadoop YARN
YARN 认证可插拔
自动分享,全局缓存 YARN 本地化资源(测试阶段)
hadoop MapReduce
限制一个作业运行的 Map/Reduce 任务
加快大量输出文件时大型作业的 FileOutputCommitter 速度
Apache Hadoop 3.0.0-alpha1,重写 Shell 脚本(2016年09月09日 )
部分更新内容:
重写了shell脚本,支持超过两个NameNode
Hadoop 3.0.0-alpha1在Java 8下编译,使用Java 7以及以下版本需更新到Java 8(2017年12月15日)
这个版本是 Apache Hadoop 3.0.0 的第一个稳定版本,有很多重大的改进,比如支持 EC、支持多于2个的NameNodes、Intra-datanode均衡器等等。下面是关于 Apache Hadoop 3.0.0 GA 的正式介绍。
Java最低版本要求从Java7 更改成Java8
所有的Hadoop JARs都是针对Java 8 编译的。仍在使用Java 7 或更低版本的用户必须升级至Java 8。
HDFS支持纠删码(Erasure Coding)
与副本相比纠删码是一种更节省空间的数据持久化存储方法。标准编码(比如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或者直接阅读本博客Hadoop 3.0纠删码(Erasure Coding):节省一半存储空间的相关介绍。
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
Shell脚本重写
Hadoop的Shell脚本被重写解决了之前很多长期存在的bug,并且引入了一些新的特性。绝大部分都保持兼容性,不过仍有些变化可能使得现有的安装不能正常运行。不兼容的改变可以参见HADOOP-9902。更多内容请参见Unix Shell Guide文档。即使你是资深用户,也建议看下这个文档,因为其描述了许多新的功能,特别是与可扩展性有关的功能。
Shaded client jars
在 Hadoop 2.x 版本,hadoop-client Maven artifact将 Hadoop 所有的依赖都加到 Hadoop 应用程序的环境变量中,这样会可能会导致应用程序依赖的类和 Hadoop 依赖的类有冲突。这个问题在 HADOOP-11804 得到了解决。
支持 Opportunistic Containers 和分布式调度
Opportunistic Container引入新 Opportunistic 类型的 Container 后,这种 Container 可以利用节点上已分配但未真正使用的资源。原有 Container 类型定义为 Guaranteed 类型。相对于 Guaranteed 类型Container, Opportunistic 类型的Container优先级更低。
MapReduce任务级本地优化
MapReduce添加了Map输出collector的本地实现。对于shuffle密集型的作业来说,这将会有30%以上的性能提升。更多内容请参见 MAPREDUCE-2841
支持多于2个的NameNodes
最初的HDFS NameNode high-availability实现仅仅提供了一个active NameNode和一个Standby NameNode;并且通过将编辑日志复制到三个JournalNodes上,这种架构能够容忍系统中的任何一个节点的失败。然而,一些部署需要更高的容错度。我们可以通过这个新特性来实现,其允许用户运行多个Standby NameNode。比如通过配置三个NameNode和五个JournalNodes,这个系统可以容忍2个节点的故障,而不是仅仅一个节点。HDFS high-availability文档已经对这些信息进行了更新,我们可以阅读这篇文档了解如何配置多于2个NameNodes。
多个服务的默认端口被改变
在此之前,多个Hadoop服务的默认端口都属于Linux的临时端口范围(32768-61000)。这就意味着我们的服务在启动的时候可能因为和其他应用程序产生端口冲突而无法启动。现在这些可能会产生冲突的端口已经不再属于临时端口的范围,这些端口的改变会影响NameNode, Secondary NameNode, DataNode以及KMS。与此同时,官方文档也进行了相应的改变,具体可以参见 HDFS-9427以及HADOOP-12811。下面表格列出了端口变化的情况
支持Microsoft Azure Data Lake filesystem连接器
Hadoop现在支持集成Microsoft Azure Data Lake,并作为替代Hadoop默认的文件系统。
Intra-datanode均衡器
一个DataNode可以管理多个磁盘,正常写入操作,各磁盘会被均匀填满。然而,当添加或替换磁盘时可能导致此DataNode内部的磁盘存储的数据严重内斜。这种情况现有的HDFS balancer是无法处理的。这种情况是由新intra-DataNode平衡功能来处理,通过hdfs diskbalancer CLI来调用。更多请参考HDFS Commands Guide
重写守护进程以及任务的堆内存管理
Hadoop守护进程和MapReduce任务的堆内存管理发生了一系列变化。
HADOOP-10950:介绍了配置守护集成heap大小的新方法。主机内存大小可以自动调整,HADOOP_HEAPSIZE 已弃用。
MAPREDUCE-5785:map和reduce task堆大小的配置方法,所需的堆大小不再需要通过任务配置和Java选项实现。已经指定的现有配置不受此更改影响。
S3Guard:S3A文件系统客户机的一致性和元数据缓存
HADOOP-13345 里面为 Amazon S3 存储系统的 S3A 客户端引入了一个新的可选特性,也就是可以使用 DynamoDB 表作为文件和目录元数据的快速一致的存储。
HDFS Router-Based Federation
HDFS Router-Based Federation 添加了一个 RPC路由层,提供了多个 HDFS 命名空间的联合视图。与现有 ViewFs 和 HDFS Federation 功能类似,不同之处在于挂载表(mount table)由服务器端(server-side)的路由层维护,而不是客户端。这简化了现有 HDFS客户端 对 federated cluster 的访问。 详细请参见:HDFS-10467
基于API来配置 Capacity Scheduler 队列的配置
OrgQueue 扩展了 capacity scheduler ,通过 REST API 提供了以编程的方式来改变队列的配置,This enables automation of queue configuration management by administrators in the queue’s administer_queue ACL.。详细请参见:YARN-5734
YARN Resource Types
YARN 资源模型(YARN resource model)已被推广为支持用户自定义的可数资源类型(support user-defined countable resource types),不仅仅支持 CPU 和内存。比如集群管理员可以定义诸如 GPUs、软件许可证(software licenses)或本地附加存储器(locally-attached storage)之类的资源。YARN 任务可以根据这些资源的可用性进行调度。详细请参见: YARN-3926。
Apache Hadoop 3.2.0 发布,3.x 系列最大版本(2019年01月30日 )
Apache Hadoop 3.2.0 发布了,这是 Hadoop 3.x 系列中最大的一个版本,带来了许多新功能和 1000 多个更改,通过 Hadoop 3.0.0 的云连接器的增强功能进一步丰富了平台,并服务于深度学习用例和长期运行的应用。
亮点包括:
ABFS 文件系统连接器:支持最新的 Azure Datalake Gen2 Storage
增强 S3A 连接器:对 AWS S3 和 DynamoDB IO 更好地弹性节流
YARN 中的节点属性支持:有助于根据节点的属性标记节点上的多个标签,并支持根据这些标签的表达式放置容器
存储策略变化:在文件/目录上设置存储策略,支持 HDFS(Hadoop 分布式文件系统)应用程序在存储类型之间移动块
Hadoop Submarine:使数据工程师能够在同一个 Hadoop YARN 集群上轻松开发、训练和部署深度学习模型(TensorFlow 中)
C++ HDFS 客户端:有助于对 HDFS 执行异步 IO,对下游项目有利,如 Apache ORC
长期运行服务升级支持:通过 YARN Native Service API 和 CLI 对长时间运行的容器进行就地无缝升级
Apache Hadoop 2.0.3发布了,在这次版本更新中,主要增加了以下几个特性:
1. 引入一种新的HDFS HA解决方案QJM
之前NameNode HA已经有两种解决方案,分别是基于共享存储区的Backup Node方案和基于Bookeeper的方案,在该版本中引入另外一种方案:QJM(Quorum Journal Manager)。
该方案(HDFS-3077) 采用了quorum commit protocol,引入两个角色:QuorumJournalManager和JournalNode,QuourumJournalManager通过 RPC将edits日志写入N个JournalNode,只要有大多数(大于N/2个)JournalNode成功写入则任务日志写入成功。
2. YARN 多资源调度机制
在该版本中,YARN的资源调度器同时支持内存和CPU两种资源调度,采用的调度算法源自Mesos的DRF(Dominant Resource Fairness),对应论文为:“Dominant Resource Fairness: Fair Allocation of Multiple Resources Types”,具体可参考 YARN-2和 Apache Mesos调度机制。
YARN对内存资源和CPU资源采用了不同的资源隔离方案。对于内存资源,为了能够更灵活的控制内存使用量,YARN采用了进程监控的方案控制内 存使用,即每个NodeManager会启动一个额外监控线程监控每个container内存资源使用量,一旦发现它超过约定的资源量,则会将其杀死。采 用这种机制的另一个原因是Java中创建子进程采用了fork()+exec()的方案,子进程启动瞬间,它使用的内存量与父进程一致,从外面看来,一个 进程使用内存量可能瞬间翻倍,然后又降下来,采用线程监控的方法可防止这种情况下导致swap操作。对于CPU资源,则采用了Cgroups进行资源隔 离。具体可参考 YARN-3。
3. YARN ResourceManager重启机制
该版本引入了一个简单的ResourceManager重启机制,保证RM重启后,各个应用工程序可继续运行而不受影响。需要注意的是,这只是第 一阶段的实现,还很不完整,比如不能向NameNode HA那样做到自动切换,不能恢复所有正在运行的Container,Application和ApplicationMaster而只是重新启动另外一个 而已,具体可参考 YARN-230。
4. YARN稳定性和扩展性得到验证
Yahoo已使用YARN在超过3万个节点上运行了14 million个应用程序,具体可参考: Hadoop at Yahoo!: More Than Ever Before。
Hadoop 2.1.0 beta 发布,HDFS提供SnapShot模块(2013年08月28日)
Hadoop 2.1.0 Beta 版 HDFS 提供了SnapShot 模块。用于数据备份、回滚,以防止因用户的失误操作导致集群出现问题。本文先做一个简单的介绍,其他的文章在来介绍Snapshot 本身的实现机制。 HDFS Snapshot有以下几个特性:
Snapshot 创建的时间 复杂度为O(1),但是不包括INode 的寻找时间
只有当修改SnapShot时,才会有额外的内存占用,内存使用量为O(M),M 为修改的文件或者目录数
在datanode 上面的blocks 不会复制,做Snapshot 的文件是纪录了block的信息
Snapshot 并不会影响HDFS 的正常操作
产生了以下新的概念:
Snapshot table:Snapshots 会存储在snapshottable的目录下。snapshottable下存储的snapshots 最多为65535个
Snapshot 路径:举例,假设/foo 是snapshottable,/foo/bar 是文件目录,/foo 拥有一个s0的snapshot,那么路径会是 /foo/.snapshot/s0/bar,我们可以通过
hdfs dfs -ls /foo/.snapshot
hdfs dfs -ls /foo/.snapshot/s0
hdfs dfs -cp /foo/.snapshot/s0/bar /tmp
来操作与查看副本文件。
Snapshot 基本操作:
对一个路径开启Snapshot: hdfs dfsadmin -allowSnapshot <path>
关闭 Snapsshots: hdfs dfsadmin -disallowSnapshot <path>
创建Snapshosts:hdfs dfs -createSnapsshot <path> [snapshot names]
删除Snapshots:hdfs dfs -deleteSnaphost <path> <snapshotName>
修改Snapshots的名字:hdfs dfs -renameSnapshot <path> <oldname> <newname>
获取Snapshot 列表:hdfs lsSnapshottableDir
获取两个Snapshot的不同:hdfs snapsshotDiff <path> <fromSnapshot> <toSnapshot>
Apache Hadoop 2.2.0 稳定版发布(2013年10月16日)
Apache Hadoop 2.2.0 稳定版发布了,建议用户升级。该版本更加稳定,同时在 API 和协议上兼容老的版本。
与 Hadoop 1.x 比较,该版本显著的改进包括:
YARN - A general purpose resource management system for Hadoop to allow MapReduce and other other data processing frameworks and services
High Availability for HDFS
HDFS Federation
HDFS Snapshots
NFSv3 access to data in HDFS
Support for running Hadoop on Microsoft Windows
Binary Compatibility for MapReduce applications built on hadoop-1.x
Substantial amount of integration testing with rest of projects in the ecosystem
升级到 Hadoop 2.2.0 需要注意的有:
HDFS - The HDFS community decided to push the symlinks feature out to a future 2.3.0 release and is currently disabled.
YARN/MapReduce - Users need to change ShuffleHandler service name from mapreduce.shuffle to mapreduce_shuffle.
更多详细介绍请看 Hadoop 2.2.0 Release Notes
Apache Hadoop 2.3.0 发布(2014年02月25日)
Apache Hadoop 2.3.0 发布。Hadoop 是一个分布式系统基础架构,由Apache基金会开发。用户可以在不了解分布式底层细节的情况下,开发分布式程序。充分利用集群的威力高速运算和存储。
2014-02-21 这是去年2013-10-16 2.2.0之后的第一个版本。1的产品系列还是1.2.1。新特性包括支持HDFS的混合存储分级,可以集中管理HDFS内存里的缓存数据,通过HDFS中的YARN分布式缓存简化MapReduce分配及一些Bug修正。(兼容2.2.0)
完全改进及发布声明:http://hadoop.apache.org/docs/r2.3.0/hadoop-project-dist/hadoop-common/releasenotes.html
Hadoop 2.5.0 发布(2014年08月16日)
一个小更新版本,包括一些主要新特性和改进以及 Bug 修复,例如扩展文件属性和改进 HDFS 的 Web UI,提升 ATS 安全性,更丰富的 YARN REST API 等。
Hadoop 2.7.0 发布,不再支持 JDK 6(2015年04月24日)
Apache Hadoop 2.7.0 发布,包括大量显著改进,值得关注的改进如下:
重大改进
此版本不再支持 JDK 6 运行时,仅支持 JDK 7+
此版本不适用于生产环境!还有一些重要的问题需要通过测试,用于生产环境的用户请等待 2.7.1/2.7.2
Hadoop Common
支持 Windows Azure 存储 —— Blob
Hadoop HDFS
支持文件截断
支持每个存储类型配额
支持可变长度的文件块
Hadoop YARN
YARN 认证可插拔
自动分享,全局缓存 YARN 本地化资源(测试阶段)
hadoop MapReduce
限制一个作业运行的 Map/Reduce 任务
加快大量输出文件时大型作业的 FileOutputCommitter 速度
Apache Hadoop 3.0.0-alpha1,重写 Shell 脚本(2016年09月09日 )
部分更新内容:
重写了shell脚本,支持超过两个NameNode
Hadoop 3.0.0-alpha1在Java 8下编译,使用Java 7以及以下版本需更新到Java 8(2017年12月15日)
这个版本是 Apache Hadoop 3.0.0 的第一个稳定版本,有很多重大的改进,比如支持 EC、支持多于2个的NameNodes、Intra-datanode均衡器等等。下面是关于 Apache Hadoop 3.0.0 GA 的正式介绍。
Java最低版本要求从Java7 更改成Java8
所有的Hadoop JARs都是针对Java 8 编译的。仍在使用Java 7 或更低版本的用户必须升级至Java 8。
HDFS支持纠删码(Erasure Coding)
与副本相比纠删码是一种更节省空间的数据持久化存储方法。标准编码(比如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或者直接阅读本博客Hadoop 3.0纠删码(Erasure Coding):节省一半存储空间的相关介绍。
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
Shell脚本重写
Hadoop的Shell脚本被重写解决了之前很多长期存在的bug,并且引入了一些新的特性。绝大部分都保持兼容性,不过仍有些变化可能使得现有的安装不能正常运行。不兼容的改变可以参见HADOOP-9902。更多内容请参见Unix Shell Guide文档。即使你是资深用户,也建议看下这个文档,因为其描述了许多新的功能,特别是与可扩展性有关的功能。
Shaded client jars
在 Hadoop 2.x 版本,hadoop-client Maven artifact将 Hadoop 所有的依赖都加到 Hadoop 应用程序的环境变量中,这样会可能会导致应用程序依赖的类和 Hadoop 依赖的类有冲突。这个问题在 HADOOP-11804 得到了解决。
支持 Opportunistic Containers 和分布式调度
Opportunistic Container引入新 Opportunistic 类型的 Container 后,这种 Container 可以利用节点上已分配但未真正使用的资源。原有 Container 类型定义为 Guaranteed 类型。相对于 Guaranteed 类型Container, Opportunistic 类型的Container优先级更低。
MapReduce任务级本地优化
MapReduce添加了Map输出collector的本地实现。对于shuffle密集型的作业来说,这将会有30%以上的性能提升。更多内容请参见 MAPREDUCE-2841
支持多于2个的NameNodes
最初的HDFS NameNode high-availability实现仅仅提供了一个active NameNode和一个Standby NameNode;并且通过将编辑日志复制到三个JournalNodes上,这种架构能够容忍系统中的任何一个节点的失败。然而,一些部署需要更高的容错度。我们可以通过这个新特性来实现,其允许用户运行多个Standby NameNode。比如通过配置三个NameNode和五个JournalNodes,这个系统可以容忍2个节点的故障,而不是仅仅一个节点。HDFS high-availability文档已经对这些信息进行了更新,我们可以阅读这篇文档了解如何配置多于2个NameNodes。
多个服务的默认端口被改变
在此之前,多个Hadoop服务的默认端口都属于Linux的临时端口范围(32768-61000)。这就意味着我们的服务在启动的时候可能因为和其他应用程序产生端口冲突而无法启动。现在这些可能会产生冲突的端口已经不再属于临时端口的范围,这些端口的改变会影响NameNode, Secondary NameNode, DataNode以及KMS。与此同时,官方文档也进行了相应的改变,具体可以参见 HDFS-9427以及HADOOP-12811。下面表格列出了端口变化的情况
支持Microsoft Azure Data Lake filesystem连接器
Hadoop现在支持集成Microsoft Azure Data Lake,并作为替代Hadoop默认的文件系统。
Intra-datanode均衡器
一个DataNode可以管理多个磁盘,正常写入操作,各磁盘会被均匀填满。然而,当添加或替换磁盘时可能导致此DataNode内部的磁盘存储的数据严重内斜。这种情况现有的HDFS balancer是无法处理的。这种情况是由新intra-DataNode平衡功能来处理,通过hdfs diskbalancer CLI来调用。更多请参考HDFS Commands Guide
重写守护进程以及任务的堆内存管理
Hadoop守护进程和MapReduce任务的堆内存管理发生了一系列变化。
HADOOP-10950:介绍了配置守护集成heap大小的新方法。主机内存大小可以自动调整,HADOOP_HEAPSIZE 已弃用。
MAPREDUCE-5785:map和reduce task堆大小的配置方法,所需的堆大小不再需要通过任务配置和Java选项实现。已经指定的现有配置不受此更改影响。
S3Guard:S3A文件系统客户机的一致性和元数据缓存
HADOOP-13345 里面为 Amazon S3 存储系统的 S3A 客户端引入了一个新的可选特性,也就是可以使用 DynamoDB 表作为文件和目录元数据的快速一致的存储。
HDFS Router-Based Federation
HDFS Router-Based Federation 添加了一个 RPC路由层,提供了多个 HDFS 命名空间的联合视图。与现有 ViewFs 和 HDFS Federation 功能类似,不同之处在于挂载表(mount table)由服务器端(server-side)的路由层维护,而不是客户端。这简化了现有 HDFS客户端 对 federated cluster 的访问。 详细请参见:HDFS-10467
基于API来配置 Capacity Scheduler 队列的配置
OrgQueue 扩展了 capacity scheduler ,通过 REST API 提供了以编程的方式来改变队列的配置,This enables automation of queue configuration management by administrators in the queue’s administer_queue ACL.。详细请参见:YARN-5734
YARN Resource Types
YARN 资源模型(YARN resource model)已被推广为支持用户自定义的可数资源类型(support user-defined countable resource types),不仅仅支持 CPU 和内存。比如集群管理员可以定义诸如 GPUs、软件许可证(software licenses)或本地附加存储器(locally-attached storage)之类的资源。YARN 任务可以根据这些资源的可用性进行调度。详细请参见: YARN-3926。
Apache Hadoop 3.2.0 发布,3.x 系列最大版本(2019年01月30日 )
Apache Hadoop 3.2.0 发布了,这是 Hadoop 3.x 系列中最大的一个版本,带来了许多新功能和 1000 多个更改,通过 Hadoop 3.0.0 的云连接器的增强功能进一步丰富了平台,并服务于深度学习用例和长期运行的应用。
亮点包括:
ABFS 文件系统连接器:支持最新的 Azure Datalake Gen2 Storage
增强 S3A 连接器:对 AWS S3 和 DynamoDB IO 更好地弹性节流
YARN 中的节点属性支持:有助于根据节点的属性标记节点上的多个标签,并支持根据这些标签的表达式放置容器
存储策略变化:在文件/目录上设置存储策略,支持 HDFS(Hadoop 分布式文件系统)应用程序在存储类型之间移动块
Hadoop Submarine:使数据工程师能够在同一个 Hadoop YARN 集群上轻松开发、训练和部署深度学习模型(TensorFlow 中)
C++ HDFS 客户端:有助于对 HDFS 执行异步 IO,对下游项目有利,如 Apache ORC
长期运行服务升级支持:通过 YARN Native Service API 和 CLI 对长时间运行的容器进行就地无缝升级
发表评论
-
hadoop:/bin/bash: /bin/java: No such file or directory
2019-08-05 16:04 1131Stack trace: ExitCodeException ... -
InvalidResourceRequestException
2019-08-05 16:00 382yarn-site.xml文件中加上 <propert ... -
No FileSystem for scheme: file 解决方法
2014-08-13 18:07 9755程序打成jar包后,放到服务器上去执行,程序能 ... -
Hadoop Archives *.har文件解析备忘
2013-09-26 11:13 1017mark:HarFileSystem source:hadoo ... -
CDH4 动态添加datanode和nodemanager
2013-08-23 22:02 3095想要在运行中的hadoop集中中动态添加或删除 ... -
Hadoop的DistCp异常处理
2013-08-21 22:49 6402CDH4中使用distcp,目前还木有成功,把异常信息记录下 ... -
Hadoop的DistCp
2013-08-21 22:14 806详细参见:http://hadoop.apache.org/d ... -
hadoop初体验之 —— 错误
2012-03-12 17:23 660将错误整理下,汇总于此: 1. Task p ...
相关推荐
6. **CHANGES.txt** 文件:记录了自上一版本以来的变更和改进。 7. **LICENSE** 和 **NOTICE** 文件:关于Hadoop的授权和版权信息。 为了部署和运行Hadoop 2.5.2,你需要按照以下步骤进行操作: 1. 解压压缩包到一...
- **使用版本控制系统**:如Git,可以更好地管理配置文件的版本,记录每次更改,并方便回滚。 - **加密备份**:为了保护敏感信息,备份文件应进行加密存储。 - **异地备份**:在不同地理位置存储备份,以抵御局部...
`fsimage`存储了文件系统的状态快照,而`EditLog`则记录了所有的元数据变更操作。 #### 五、HDFS通信流程及故障恢复 - **写入过程**:客户端发起写请求至NameNode,NameNode返回DataNode列表,客户端直接与DataNode...
2. JournalNode(JN):记录NameNode的元数据变更,用于同步活动和备用NameNode。 3. ZooKeeper:协调HA状态的改变,例如选举新的活动NameNode。 三、配置步骤 1. 安装与配置: - 在两台机器上分别安装Hadoop,并...
FsImage 存储文件系统的静态状态,Editlog 记录所有变更操作。当 Namenode 启动时,会合并 FsImage 和 Editlog 并生成新的 FsImage,这个过程称为检查点。为了提高效率,未来版本的Hadoop将支持周期性的检查点。 总...
6. `README.txt`和`CHANGES.txt`:提供版本信息和变更记录。 通过解压并编译这个Hadoop 2.7.1版本,开发者可以深入了解Hadoop的工作原理,或者根据自己的需求进行定制和扩展。同时,对于大数据分析和处理的初学者,...
这对于跟踪Hadoop不同版本间的API变更非常有用。 6. **json-simple-1.1.1.jar**:这是一个轻量级的Java库,用于处理JSON(JavaScript Object Notation)数据格式。在Hadoop中,JSON常用于数据交换和配置文件,因为...
#### 八、API和环境变更 为了实现上述安全特性,需要对现有的API和运行环境进行一定的修改和扩展,包括但不限于: 1. **添加新的安全API**:提供用于身份验证、令牌管理等操作的新API。 2. **增强现有API的安全性*...
特别是变更表,它是Greenplum中一种特殊类型的表,用于高效地记录数据的历史变化,支持审计跟踪、数据版本控制和时间旅行功能。 变更表通过捕获插入、更新和删除操作,为数据提供了完整的生命周期管理。在Greenplum...
FsImage包含了整个文件系统元数据的快照,而EditLog则记录了自上次保存快照以来发生的变更。每当客户端进行写操作时,这些操作会被记录在EditLog中,随后在适当的时机与FsImage合并,以更新文件系统元数据。因此,...
- **资源管理**:随着Hadoop版本的演进,YARN(Yet Another Resource Negotiator)成为资源管理的核心组件,提供了更加灵活的任务调度机制。 #### 五、应用场景与案例 Hadoop因其出色的性能和灵活性,在众多领域...
- **Hadoop版本**:提供了Hadoop不同版本的信息与变更记录。 - **本书涵盖的内容**:概述了本书的主要章节结构与覆盖的知识点。 - **兼容性问题**:讨论了不同版本间可能存在的兼容性问题及解决策略。 4. **第2...
针对这些应用,HBase能够提供毫秒级响应的随机读取和数据导出,支持多字段分词查询,以及灵活的数据模型以应对宽表字段的快速变更。 2. 海量数据处理:随着数据量的急剧增加,支付宝需要处理的数据量达到数十TB级别...
- 记录所有的配置变更。 - **6.4.2 导入导出** - 导入或导出配置文件。 **6.5 组件升级** - 升级Intel® Manager for Hadoop或其他组件到最新版本。 #### 七、附加配置 **7.1 FTP over HDFS** - **7.1.1 安装...
EditLog则记录所有的元数据变更,用于在NameNode崩溃后的恢复。为了防止EditLog过大影响系统重启速度,Secondary NameNode扮演了一个辅助角色,定期将FsImage和EditLog合并成一个新的FsImage checkpoint,同时生成新...
2. **JournalNode**:用于存储 NameNode 之间的元数据变更记录,实现故障恢复。 3. **ZKFC (Zookeeper Failover Controller)**:利用 ZooKeeper 协调两个 NameNode 的状态转换,确保任何时候只有一个 Active ...
JournalNode是HDFS HA的重要组成部分,用于存储Edit Logs(NameNode的数据变更记录)。在多台机器上启动JournalNode,确保数据的安全性和一致性。例如,在`master`、`slave1`和`slave2`节点上执行`hadoop-daemons....