1. 概述
目前从 Hadoop 官网的 Wiki 来看, 稳定版本已经发行到 Hadoop2.9.0, 最新版本为 Hadoop3.1.0, 查阅 JIRA, 社区已经着手迭代 Hadoop3.2.0. 那么, 今天笔者就带着大家来剖析一下 Hadoop3, 看看它给我们带来了哪些新特性.
2. 内容
从功能上来说, 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
MapReduce 任务级本地优化
支持多个 NameNode
部分默认服务端口被改变
支持文件系统连接器
DataNode 内部添加了负载均衡
重构后台程序和任务对管理
下面, 笔者就为大家来一一剖析这些新特性的具体内容, 其内容包含 JDK 版本, EC 技术, YARN 的时间轴服务这三类特性, 其他特性笔者在后面的博客再为大家慢慢剖析.
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 查询操作.
3. 总结
本篇博客先给大家剖析前面几个特性, 其内容由 JDK 的版本升级, EC 技术的作用及优势, YARN 的时间轴 V2 版本的主要作用. Hadoop3 后面的几个特性, 在下一篇博客为大家再剖析.
4. 结束语
这篇博客就和大家分享到这里, 如果大家在研究学习的过程当中有什么问题, 可以加群进行讨论或发送邮件给我, 我会尽我所能为您解答, 与君共勉!
来源: https://www.cnblogs.com/smartloli/p/8827623.html