Hadoop 3.0 中的新功能


这篇“ Hadoop 3.0 的新特性”博客重点关注 Hadoop 3 中的预期变化，因为它仍处于 alpha 阶段。Apache 社区已经合并了许多更改，并且仍在处理其中的一些更改。因此，我们将更广泛地审视预期的变化。
Apache Hadoop 3 将结合 Hadoop-2.x 的许多增强功能。因此，让我们继续前进，看看每项增强功能。
 
1. Hadoop 3 中最低要求的 Java 版本从 7 增加到 8
在 Hadoop 3 中，所有 Hadoop JAR 都是针对 Java 8 的运行时版本编译的。因此，仍在使用 Java 7 或更低版本的用户在开始使用 Hadoop 3 时必须升级到 Java 8。
 
2. 支持 HDFS 中的擦除编码
那么现在让我们先了解一下什么是擦除编码。
通常，在存储系统中，纠删码 主要用于廉价磁盘冗余阵列（RAID）。
RAID通过条带化striping实现EC ，其中逻辑上连续的数据（如文件）被分成更小的单元（如位、字节或块），并将连续的单元存储在不同的磁盘上。
然后对于原始数据单元的每个条带，计算并存储一定数量的奇偶校验单元。这个过程称为编码。任何条带单元上的错误都可以通过基于幸存数据单元和奇偶校验单元的解码计算来恢复。
在我们了解了擦除编码的概念后，现在让我们首先回顾一下早期的 Hadoop 2.x 中的复制场景。
HDFS 中的默认复制因子是 3，其中一个是原始数据块，另外 2 个是副本，每个副本都需要 100% 的存储开销。因此，这会产生 200% 的存储开销，并且会消耗其他资源，例如网络带宽。
然而，在正常操作期间很少访问具有低 I/O 活动的冷数据集的副本，但仍然消耗与原始数据集相同数量的资源。
与 HDFS 复制相比，纠删码可存储数据并提供容错，同时具有更少的空间开销。可以使用纠删码 (EC) 代替复制，这将提供 相同级别的容错能力，同时存储开销更少。
将 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管理一组数据流处理器，每个 DataNode 一个，在当前块组中存储一个内部块。协调器负责对整个区块组的操作，包括结束当前区块组、分配新的区块组等。
    • 在输入/读取路径上，DFSStripedInputStream将请求的数据逻辑字节范围作为范围转换为存储在 DataNode 上的内部块。然后它并行发出读取请求。出现故障时，它会发出额外的读取请求以进行解码。

  • 数据节点扩展 -数据管理部运行失败的擦除编码块的背景回收额外ErasureCodingWorker（ECWorker）任务。NameNode 会检测到失败的 EC 块，然后它会选择一个 DataNode 来执行恢复工作。重建执行三项关键任务：
    1. 从源节点读取数据，只读取最少数量的输入块和奇偶校验块进行重构。
    2. 从输入数据中解码新数据和奇偶校验块。所有丢失的数据和奇偶校验块一起解码。
    3. 解码完成后，将恢复的块传输到目标 DataNode。

  • ErasureCoding 策略——为了适应异构工作负载，我们允许 HDFS 集群中的文件和目录具有不同的复制和 EC 策略。有关编码和解码文件的信息封装在 ErasureCodingPolicy 类中。它包含 2 条信息，即 ECSchema 和剥离单元的大小。

Hadoop 3 中第二个最重要的增强是来自 YARN 版本 1（在 Hadoop 2.x 中）的 YARN 时间线服务版本 2。他们正试图在 YARN 版本 2 中做出许多积极的改变。
 
3. YARN 时间线服务 v.2
Hadoop 正在引入 YARN 时间线服务 iev2 的重大修订。YARN 时间线服务。它的开发是为了解决两个主要挑战：
  1. 提高时间线服务的可扩展性和可靠性
  2. 通过引入流和聚合来增强可用性

YARN Timeline Service v.2 可以由开发人员测试以提供反馈和建议。它应该仅在测试能力中被利用。 YARN Timeline Service 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 应用程序以完成逻辑应用程序更为常见。Timeline Service v.2 明确支持流的概念。此外，它支持在流级别聚合指标，如下图所示。
  • YARN 时间线服务 v.2： 架构

YARN Timeline Service v.2 使用一组收集器（写入器）将数据写入后端存储。收集器与它们所专用于的应用程序主服务器分布并位于同一位置。属于该应用程序的所有数据都被发送到应用程序级别的时间线收集器，但资源管理器时间线收集器除外。
对于给定的应用程序，应用程序主机可以将应用程序的数据写入位于同一地点的时间线收集器。此外，运行应用程序容器的其他节点的节点管理器也将数据写入运行应用程序主节点的时间线收集器。
资源管理器还维护自己的时间线收集器。它仅发出 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 start namenode'。 
  • 如果已安装，触发 ssh 连接的操作现在可以使用 pdsh。
  • ${HADOOP_CONF_DIR} 现在无处不在，无需符号链接和其他此类技巧。
  • 脚本现在可以在守护程序启动时针对日志和 pid 目录的各种状态测试和报告更好的错误消息。以前，未受保护的外壳错误会显示给用户。

当 Hadoop 3 处于测试阶段时，您将了解更多功能。现在让我们讨论阴影客户端 jar 并了解它们的好处。 
 
5. 切分客户Jar
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 集群对话，而无需查看任何实现依赖项。
 
6. 支持机会容器和分布式调度
引入了一个新的 ExecutionType，即Opportunistic 容器，即使在调度时没有可用资源，它也可以在 NodeManager 上分派执行。在这种情况下，这些容器将在 NM 排队，等待资源可用以启动。机会容器的优先级低于默认的保证（Guaranteed ）容器，因此在需要时会被抢占，为保证（Guaranteed ）容器腾出空间。这应该会提高集群利用率。
保证（Guaranteed ）容器 对应于现有的 YARN 容器。它们由容量调度器分配，一旦被调度到一个节点，就保证有可用的资源可以立即开始执行。此外，只要没有故障，这些容器就会运行完成。
机会容器默认由中央 RM 分配，但也添加了支持以允许由分布式调度程序分配机会容器，该调度程序实现为 AMRMProtocol 拦截器。
现在继续前进，让我们看看 MapReduce 性能是如何优化的。
 
7. MapReduce 任务级原生优化
在 Hadoop 3 中，MapReduce 中为地图输出收集器添加了本机 Java 实现。对于 shuffle 密集型作业，这将性能提高 30% 或更多。
他们添加了地图输出收集器的本地实现。对于 shuffle 密集型作业，这可能会提供 30% 或更多的加速。他们正在研究基于 JNI 的 MapTask 原生优化。基本思想是添加一个 NativeMapOutputCollector 来处理映射器发出的键值对，因此排序、溢出、IFile 序列化都可以在本机代码中完成。他们仍在处理合并代码。
现在让我们看看 Apache 社区是如何尝试使 Hadoop 3 更具容错性的。
 
8. 支持 2 个以上 NameNode
在 Hadoop 2.x 中，HDFS NameNode 高可用性架构具有单个活动 NameNode 和单个备用 NameNode。通过将编辑复制到法定数量的三个 JournalNode，该架构能够容忍任何一个 NameNode 的故障。
但是，关键业务部署需要更高程度的容错能力。因此，在 Hadoop 3 中允许用户运行多个备用 NameNode。例如，通过配置三个 NameNode（1 个主动和 2 个被动）和五个 JournalNode，集群可以容忍两个节点的故障。
 
9. 多个服务的默认端口已更改
早些时候，多个 Hadoop 服务的默认端口在 Linux临时端口范围内(32768-61000)。除非客户端程序明确请求特定端口号，否则使用的端口号是临时端口号。所以在启动时，服务有时会因为与另一个应用程序冲突而无法绑定到端口。
因此，具有临时范围的冲突端口已移出该范围，从而影响多个服务的端口号，即 NameNode、Secondary NameNode、DataNode 等。其中一些重要的是：

 
10. 支持文件系统连接器
Hadoop 现在支持与 Microsoft Azure Data Lake 和 Aliyun Object Storage System 的集成。它可以用作替代的 Hadoop 兼容文件系统。首先添加了 Microsoft Azure Data Lake，然后他们也添加了阿里云对象存储系统。你可能会期待更多。
 
11. 数据节点内平衡器
单个 DataNode 管理多个磁盘。在正常的写操作期间，数据被平均划分，因此磁盘被均匀地填满。但是添加或更换磁盘会导致 DataNode 内出现偏差。现有的 HDFS 平衡器早期无法处理这种情况。这涉及到 DataNode 内的偏斜。
现在 Hadoop 3 通过新的内部 DataNode 平衡功能处理这种情况，该功能通过 hdfs diskbalancer CLI 调用。 
 
12. 重新设计守护进程和任务堆管理
对 Hadoop 守护进程和 MapReduce 任务的堆管理进行了一系列更改。
  • 配置守护进程堆大小的新方法。值得注意的是，现在可以根据主机的内存大小进行自动调整，并且不推荐使用 HADOOP_HEAPSIZE 变量。取而代之的是，引入了 HADOOP_HEAPSIZE_MAX 和 HADOOP_HEAPSIZE_MIN 来分别设置 Xmx 和 Xms。 所有全局和特定于守护进程的堆大小变量现在都支持单位。如果变量只是一个数字，则假定大小以兆字节为单位。

  • 简化 map 的配置并减少任务堆大小，因此不再需要在任务配置和 Java 选项中指定所需的堆大小。已指定两者的现有配置不受此更改的影响。