案例研究：Hadoop 分布式文件系统 (HDFS)

案例研究：Hadoop 分布式文件系统 (HDFS)

Hadoop分布式文件系统（HDFS）是Apache Hadoop项目的核心组件之一，专为存储和处理大规模数据集而设计。本文将详细介绍HDFS的体系结构、工作原理、设计目标、群集拓扑、文件读写操作、一致性模型、容错机制以及其优缺点。

HDFS 体系结构

HDFS是一种分布式文件系统（DFS），设计为在节点群集上运行，其体系结构设计具有以下目标：

• 单一的群集范围公共命名空间
• 能够存储大文件（例如 TB 级或 PB 级）
• 支持 MapReduce 编程模型
• 流数据访问，用于写入一次、多次读取数据访问模式
• 使用商用硬件实现高可用性

图 1：HDFS 体系结构

HDFS遵循主从设计。主节点称为NameNode，负责处理元数据管理，并为HDFS上存储的所有文件维护单个命名空间。从节点称为DataNode，将实际数据块存储在每个节点中的本地文件系统上。

HDFS中的文件被拆分为各个块（也称为区块），默认大小为每个128MB。较大的块大小设计是为了高效处理MapReduce作业。默认情况下，MapReduce中的单个映射任务配置为独立地处理单个HDFS块，因此多个映射任务可以并行处理多个HDFS块。

此外，由于HDFS设计为可容忍单个节点的故障，因此数据块会在节点间进行复制，以提供数据冗余。

HDFS 中的群集拓扑

Hadoop群集通常部署在数据中心内，其中包含多个机架的使用胖树拓扑连接的服务器。为此，HDFS设计为可感知群集拓扑，这有助于进行块放置决策以影响性能和容错。

图 2：HDFS 群集拓扑

当在群集上部署HDFS时，系统管理员可以使用将每个节点映射到群集中特定机架的拓扑描述进行配置。网络距离按跃点进行度量，其中一个跃点对应于拓扑中的一个链接。Hadoop采用树样式拓扑，两个节点之间的距离是它们与最接近的公共上级的距离之和。

文件读写操作

文件读取

图 3：HDFS 中的文件读取

在文件打开进行读取时，HDFS客户端首先联系NameNode。NameNode随后向客户端提供文件块位置的列表。Hadoop还假设块在节点间进行复制，因此在提供特定块的位置时，NameNode实际上会查找与客户端最近的块。位置按以下顺序确定（“递减位置”）：客户端所在的同一个节点中的块、客户端所在的同一个机架中的块以及客户端所在的机架外部的块。

确定块位置后，客户端将启动与每个DataNode的直接连接，将数据从DataNode流式传输给客户端进程，此过程是在HDFS客户端调用对数据块的读取操作时完成的。因此，不必传输整个块，客户端便可开始计算，从而使计算和通信错开。客户端读取完第一个块后，它会对其余块重复此过程，直到客户端读取完所有块，然后关闭文件。

文件写入

在HDFS中，文件写入与文件读取不同。需要将数据写入HDFS的客户端会首先联系NameNode，随后向它通知创建文件。NameNode会检查文件是否已存在，并验证客户端是否拥有创建文件的权限。如果检查通过，则NameNode会创建新文件的记录。

客户端随后继续将文件写入内部数据队列，并向NameNode请求获取集群中DataNode上的块位置。内部队列中的块随后会以管道方式传输到各个DataNode。块在第一个DataNode上写入，后者随后通过管道将块传输到其他DataNode，以便写入块的副本。因而在文件写入期间进行复制。必须注意的是，HDFS不会向客户端确认写入（图4.28中的步骤5），直到该文件的所有副本都已由DataNode写入。

Hadoop还在副本放置期间使用机架位置的概念。默认情况下，数据块在HDFS中进行三次复制。HDFS尝试将第一个副本放置在正在写入块的客户端所在的同一个节点上。如果客户端进程未在HDFS群集中运行，则会随机选择节点。第二个副本会写入到所处机架与第一个节点不同（机架外）的节点。块的第三个副本随后会写入到所处机架与第二个节点相同的另一个随机节点。更多副本会写入到群集中的随机节点，但系统会尝试避免将过多副本放置在同一个机架上。

同步：语义

HDFS的语义发生了一点变化。早期版本的HDFS遵循严格的不可变语义。在早期版本的HDFS中写入文件后，便无法再重新打开以进行写入。仍可以删除文件。不过当前版本的HDFS支持以有限的方式进行追加。这仍然十分有限，因为现有二进制数据一旦写入到HDFS，便无法进行修改。

选择在HDFS中进行这种设计是因为某些最常见的MapReduce工作负载遵循一次写入、多次读取数据访问模式。MapReduce是具有预定义阶段的受限计算模型，MapReduce中的化简器的输出会将独立文件作为输出写入到HDFS。HDFS侧重于一次有多个客户端同时进行快速读取访问。

一致性模型

HDFS是一个具有强一致性的文件系统。每个数据块都会复制到多个节点，但只有在所有副本都已成功写入之后，才会声明写入成功。因此，所有客户端都应在文件写入后立即看到文件，并且文件在所有客户端上的视图都相同。HDFS的不可变语义使得这一点相对容易实现，因为在文件的生存期内文件只能打开进行写入一次。

HDFS 中的容错

HDFS中的主要容错机制是复制。如前所述，默认情况下，写入HDFS的每个块都会复制三次，但用户可以根据需要按文件更改这一点。

NameNode通过检测信号机制跟踪DataNode。每个DataNode将定期检测信号消息（每隔几秒）发送到NameNode。如果DataNode处于不活动状态，则发送到NameNode的检测信号会停止。如果错过的检测信号消息数达到某个阈值，则NameNode会检测到DataNode死亡。NameNode随后将DataNode标记为不活动，不再将任何I/O请求转发到该DataNode。存储在该DataNode上的块应在其他DataNode上具有其他副本。此外，NameNode对文件系统执行状态检查以发现复制不足的块，并执行群集重新平衡过程，以便为副本数量少于所需数量的块启动复制。

NameNode是HDFS中的单一故障点（SPOF），因为NameNode的故障会使整个文件系统关闭。NameNode在内部维护两个用于存储文件系统状态的磁盘上数据结构：映像文件和编辑日志。映像文件是文件系统元数据在某个时间点的检查点，而编辑日志是自上次创建映像文件以来，文件系统元数据的所有事务的日志。对文件系统元数据的所有传入更改都会写入到编辑日志。编辑日志和映像文件会定期进行合并以创建新映像文件快照，并且编辑日志会被清除。但在NameNode发生故障时，元数据将不可用，NameNode上的磁盘故障会是灾难性的，因为文件元数据会丢失。

为了备份NameNode中的元数据，HDFS允许创建辅助NameNode，后者会定期从NameNode复制映像文件。这些副本有助于在NameNode上发生数据丢失时恢复文件系统，但NameNode编辑日志中的最后几个更改会丢失。最新版本Hadoop中正在进行的工作旨在创建真正丰富的辅助NameNode，它会在NameNode发生故障时自动接管。

HDFS 实践

虽然HDFS主要设计用于通过为映射和化简运算提供DFS来支持Hadoop MapReduce作业，但是HDFS发现了大量与大数据工具一起使用的情况。

HDFS用于在Hadoop框架之上构建的多个Apache项目，其中包括Pig、Hive、HBase和Giraph。其他项目（如GraphLab）中也包含HDFS支持。

HDFS的主要优点包括以下这些：

• MapReduce工作负载的高带宽：众所周知，大型Hadoop群集（数千台机器）可使用HDFS以高达每秒1TB的速率连续写入数据。
• 高可靠性：容错是HDFS中的主要设计目标。HDFS复制可提供较高的可靠性和可用性，尤其是在大型群集中（磁盘和服务器的故障概率明显更高）。
• 每个字节的低成本：与专用共享磁盘解决方案（如SAN）相比，每GB的HDFS成本更低，因为存储与计算服务器并置。使用SAN时，必须为托管基础结构（如磁盘阵列机箱和更高级别的企业磁盘）支付额外费用以管理硬件故障。HDFS设计为通过商用硬件运行，并且冗余采用软件进行管理以容忍故障。
• 可伸缩性：HDFS允许将DataNodes添加到正在运行的群集，并提供工具以在添加群集节点时手动重新平衡数据块（可以在不关闭文件系统的情况下进行）。

HDFS的主要缺点包括以下这些：

• 小文件低效：HDFS设计为用于较大的块大小（64MB及以上）。这是为了接收大文件（数百MB、GB或TB）并将它们分为各个块，随后可以将块送入MapReduce作业以并行处理。当实际文件大小较小（在KB范围内）时，HDFS十分低效。具有大量小文件会对NameNode施加额外压力，后者必须维护文件系统中所有文件的元数据。通常，HDFS用户使用诸如序列文件之类的技术将许多小文件合并为较大的文件。
• 不与POSIX兼容：HDFS并未设计成为POSIX兼容的可装载文件系统；应用程序必须从头开始编写或进行修改才能使用HDFS客户端。存在一些变通方法，使HDFS可以使用FUSE驱动程序进行装载，但是一旦文件关闭，文件系统语义便不允许对其进行写入。
• 一次写入模型：对于需要对相同文件进行并发写入访问的应用程序，一次写入模型是一种潜在的缺点。但是，最新版本的HDFS现在支持文件追加。

简而言之，对于遵循MapReduce模型或专门编写为使用HDFS的分布式应用程序，HDFS是一个很好的存储后端选择。HDFS可以高效地用于少量大文件，而不是大量小文件。

参考

1. Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung (2003).The Google File Systems19th ACM Symposium on Operating Systems Principles
2. White, Tom (2012).Hadoop: The Definitive GuideO'Reilly Media, Yahoo Press