HDFS架构指南（分布式系统Hadoop的文件系统架构）

HDFS架构指南

笔者之前为了写一篇综述，翻译了一些材料，为了符合原始的意思，我保留了一些英文，翻译的时候真的很辛苦，现在在博客里分享给大家啦!

本文翻译自《HDFS Architecture Guide》
来源于Apache开源社区的Hadoop Apache Project
文献引用为：

Borthakur D. HDFS architecture guide[J]. Hadoop Apache Project,2008,53: 1-13

作者：Dhruba Borthakur

目录

1 介绍
2 假设和目标
2.1 硬件故障
2.2 流数据访问
2.3 大数据集
2.4 简单一致性模型
2.5 “移动计算比移动数据便宜”
2.6 异构硬件和软件平台的可移植性
3 NameNode和DataNodes
4 文件系统命名空间
5 数据复制
5.1 复制品放置：第一个婴儿步骤
5.2 副本选择
5.3 安全模式
6 文件系统元数据的持久性
7 通信协议
8 稳健性
8.1 数据磁盘故障，心跳和重新复制
8.2 集群重新平衡
8.3 数据完整性
8.4 元数据磁盘故障
8.5 快照
9 数据组织
9.1 数据块
9.2 分期
9.3 复制流水线
10 可访问性
10.1 FS shell
10.2 DFSAdmin
10.3 浏览器接口
11 空间回收
11.1文件删除与取消删除
11.2减少复制因子
12 参考

1 Introduction

Hadoop分布式文件系统（HDFS）是一个旨在运行在商品硬件上的分布式文件系统。 它与现有的分布式文件系统有许多相似之处。但是，与其他分布式文件系统的差异很大。 HDFS具有高度容错能力，旨在部署在低成本硬件上。 HDFS提供高吞吐量访问应用程序数据，适用于具有大型数据集的应用程序。HDFS放宽了一些POSIX要求，以实现对文件系统数据的流式访问。HDFS最初是作为Apache Nutch网络搜索引擎项目的基础设施而构建的。HDFS现在是Apache Hadoop子项目。 项目网址是 http://hadoop.apache.org/hdfs / 。

2 Assumptions and Goals

2.1 Hardware Failure

硬件故障是常态而非例外。 HDFS实例可能包括数百或数千台服务器机器，每台服务器机器存储文件系统数据的一部分。存在大量组件并且每个组件都有一个非常重要的失败概率，意味着HDFS的某些组成部分始终无法正常运行。因此，故障检测并从中快速自动恢复是核心架构HDFS的目标。

2.2 Streaming Data Acess

在HDFS上运行的应用程序需要对其数据集进行流式访问。 他们不是一般的通常在通用文件系统上运行的目的应用程序。 HDFS的设计更多用于批处理而不是用于用户的交互式使用。 重点是高数据访问的吞吐量而不是数据访问的低延迟。 POSIX强加许多针对HDFS的应用程序不需要的硬性要求。 POSIX已经交换了几个关键领域的语义以提高数据吞吐率。

2.3 Large Data Sets

在HDFS上运行的应用程序具有大型的数据集。 HDFS中的典型文件是千兆字节太字节大小（ gigabytes to terabytes in size）。 因此，HDFS被调整为支持大文件。 它应该提供高聚合数据带宽并扩展到单个集群中的数百个节点。 它应该在单个实例中支持数千万个文件。

2.4 Simple Coherency Model 简单一致性模型

HDFS应用程序需要一个一次写入多次读取的文件访问模型。 文件一旦创建，写入，关闭不需要改变。 该假设简化了数据一致性问题并实现高吞吐量数据访问。 MapReduce应用程序或Web爬网程序应用程序完全适合此模型。 有计划在将来支持对文件的追加写入。

2.5 “Moving Computation is Cheaper than Moving Data”

如果在它运作的数据附近执行，则应用程序请求的计算效率更高。 当数据集的大小很大时尤其如此。 这个最大限度地减少网络拥塞并提高系统的整体吞吐量。 该假设通常更好地将计算迁移到更接近数据的位置找到而不是将数据移动到运行应用程序的位置。 HDFS为应用程序提供接口来移动它们自己，以便到达更靠近数据所在的位置。

2.6 Portability Across Heterogeneous Hardware and Software Platforms

HDFS的设计便于从一个平台移植到另一个平台。 这有利于广泛采用HDFS作为大量应用程序的首选平台。

3 NameNode and DataNodes

HDFS具有主/从架构。 HDFS集群由单个的NameNode，管理文件系统命名空间的主服务器（master server），用于管理对文件的访问客户端（client）；此外，还有许多DataNode，通常是集群中每个节点一个，它管理附加到它们运行的节点的存储。 HDFS公开文件系统命名空间并允许用户数据存储在文件中。 在内部，文件被拆分为一个或更多块，这些块存储在一组DataNode中。 NameNode执行文件系统命名空间操作，如打开，关闭和重命名文件和目录；它还确定了块到DataNode的映射。 DataNodes负责提供来自文件系统客户端的读写请求。 DataNode还根据NameNode的指令执行块创建，删除和复制。

NameNode和DataNode是设计用于运行在商业机器上的软件。 这些机器通常运行GNU / Linux操作系统（OS）。 HDFS是使用Java语言构建; 任何支持Java的机器都可以运行NameNode或DataNode软件。 使用高度可移植的Java语言意味着HDFS可以部署在各种机器上。 典型部署具有专用机器只运行NameNode软件。 群集中的每台其他计算机都运行一台DataNode软件的实例。 该体系结构不排除运行多个DataNodes位于同一台计算机上，但在实际部署中很少出现这种情况。集群中存在单个NameNode极大地简化了集群的体系结构系统。 NameNode是所有HDFS元数据的仲裁者和存储库。 该系统是以这样的方式设计，即用户数据永远不会流经NameNode。

4 The File System Namespace

HDFS支持传统的分层文件组织。 用户或应用程序可以创建这些目录中的目录和存储文件。 文件系统命名空间层次结构是类似于大多数其他现有文件系统; 可以创建和删除文件，从中移动文件一个目录到另一个目录，或重命名文件。 HDFS尚未实现用户配额。 HDFS不支持硬链接或软链接。 但是，HDFS架构并不排除实现这些功能。NameNode维护文件系统名称空间。 对文件系统的任何更改命名空间或其属性由NameNode记录。 应用程序可以指定应由HDFS维护的文件的副本数。 a的副本数量file被称为该文件的复制因子。 该信息由NameNode存储。

5 Data Replication

HDFS旨在跨大型集群中的计算机可靠地存储非常大的文件。 它存储每个文件作为一系列块; 除最后一个块之外的文件中的所有块都具有相同的大小。复制文件的块以实现容错。 块大小和复制因子可以按文件配置。 应用程序可以指定文件的副本数。 该复制因子可以在文件创建时指定，并可以在以后更改。 文件HDFS是一次写入的，并且在任何时候都只有一个写入器（意思是不能并行写入）。NameNode做出有关块复制的所有决定。 它会定期收到来自群集中每个DataNode的Heartbeat和Blockreport。 收到一份Heartbeat意味着DataNode正常运行。 Blockreport包含一个列表DataNode上的所有块。

5.1 Replica Placement: The First Baby Steps

复制品的放置对HDFS的可靠性和性能至关重要。 ”优化副本的放置“将HDFS与大多数其他分布式文件系统区分开来。 这个功能需要大量的调整和经验。 机架感知副本放置策略的目的旨在提高数据可靠性，可用性和网络带宽利用率。 目前副本放置策略的实现是朝着这个方向迈出的第一步。实施此政策的短期目标是在生产系统上对其进行验证，了解其行为，并为测试和研究更复杂的策略奠定基础。大型HDFS实例在通常分布在许多计算机上的计算机集群上运行机架。 不同机架中两个节点之间的通信必须通过交换机。 在大多数情况下，同一机架中的机器之间的网络带宽大于网络不同机架中机器之间的带宽。
NameNode通过概在Hadoop Rack Awareness.中的处理框架确定每个DataNode所属的机架ID。 一个简单但非最优的策略是将副本放在唯一（单独的）的机架上。 这可以防止在整个机架出现故障时丢失数据并允许使用带宽从多个机架读取数据。 此策略在集群中均匀分布副本，并可以轻松平衡组件故障时的负载。 但是，这项政策会增加成本写入因为写入需要将块传输到多个机架。
对于常见情况，当复制因子为3时，HDFS的放置策略为将一个副本放在本地机架中的一个节点上，另一个副本放在另一个节点上（远程）机架，最后一个副本在同一个远程机架中的另一个节点上。 这项政策削减了机架写入流量，通常可以提高写入性能。 机架故障的可能性是远远少于节点故障; 此策略不会影响数据的可靠性和可用性担保。 但是，它确实减少了读取时使用的聚合网络带宽数据，因为一个块只放在两个独特的机架而不是三个。 有了这个政策，文件的副本不是均匀分布在机架上。 三分之一的复制品在一个节点，三分之二的副本位于一个机架上，？另外三分之一均匀分布在剩下的货架。 此策略可提高写入性能，而不会影响数据可靠性或读取性能。此处描述的当前默认副本放置策略是正在进行的工作。

5.2 Replica Selection

为了最大限度地减少全局带宽消耗和读取延迟，HDFS通过读取来自最接近读者的副本来努力满足读取要求请求。 如果同一机架上存在副本和读取器节点，则该副本优选满足读取请求。 如果是angg / HDFS群集跨越多个数据中心，然后是驻留在本地数据中心的副本优先于任何远程副本。

5.3 Safemode

启动时，NameNode进入一个名为Safemode的特殊状态。 当NameNode处于Safemode状态时数据块的复制是不会发生的。 NameNode收到来自DataNodes的Heartbeat和Blockreport消息。 Blockreport包含DataNode正在托管的数据块的列表。 每个块都有指定的最小数量副本。 当最小数量的副本已经在NameNode检测到时，会认为是已经安全复制的。 经过可配置的安全复制的数据块的百分比在NameNode检查（再加上30秒），NameNode退出Safemode状态。 然后它接下来确定仍然少于指定数量副本的数据块列表（如果有的话）。 NameNode然后复制这些数据块到其他DataNode。

6 The Persistence of File System Metadata

HDFS名称空间由NameNode存储。 NameNode使用事务日志调用EditLog来持久记录文件系统元数据发生的每个更改。例如，在HDFS中创建新文件会导致NameNode将插入一条记录到EditLog来标记这个操作。 同样，更改文件的复制因子会导致新的要插入EditLog的记录。 NameNode在其本地主机OS文件系统中使用文件用于存储EditLog的系统。 整个文件系统命名空间，包括映射块到文件和文件系统属性，都存储在名为FsImage的文件中。 FsImage也作为文件存储在NameNode的本地文件系统中。
NameNode保留整个文件系统命名空间和文件Blockmap的镜像在memory中。 该关键元数据项被设计为紧凑的，比如NameNode带有4 GB的RAM足以支持大量的文件和目录。 当NameNode启动的时候，它从磁盘读取FsImage和EditLog，应用所有事务从EditLog到FsImage的内存中表示，并刷新的它新版本到磁盘上的新FsImage。 然后它可以截断旧的EditLog，因为它的事务已应用于持久性FsImage。 此过程称为检查点。在当前实现中，仅在NameNode启动时才会发生检查点。 支持定期检查点工作正在进行中，在不久的将来会实现。
DataNode将HDFS数据存储在其本地文件系统中的文件中
DataNode没有有关HDFS文件的知识。 它将每个HDFS数据块存储在本地文件系统的单独文件中。 DataNode不会在同一目录中创建所有文件。 相反，它使用了启发式确定每个目录的最佳文件数并适当创建子目录。 在同一目录中创建所有本地文件并不是最佳选择，因为本地文件系统可能无法有效地支持大量单个文件的文件目录。 当DataNode启动时，它会扫描其本地文件系统，生成一个列表。所有与这些本地文件对应的HDFS数据块，并将此报告发送给NameNode：这是Blockreport。

7 The Communication Protocols

所有HDFS通信协议都分层构建在TCP / IP协议之上。 一个client建立与NameNode计算机上可配置TCP端口的连接。 client通过ClientProtocol与NameNode交谈。 DataNodes使用DataNode Protocol与NameNode对话。 远程过程调用（RPC，Remote Procedure Call—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。）抽象包装client Protocol和DataNode Protocol。 按照设计，NameNode永远不会初始化启用任何RPC。相反，它只响应DataNodes或 clients发出的RPC请求。

8 Robustness

HDFS的主要目标是即使在出现故障时也能可靠地存储数据。三种常见的故障类型是NameNode故障，DataNode故障和网络分区

8.1 Data Disk Failure, Heartbeats and Re-Replication

每个DataNode定期向NameNode发送Heartbeat消息。 一个网络分区可能导致DataNode的一个子集失去与NameNode的连接。 该NameNode通过Heartbeat消息的缺失来检测此情况。 NameNode通过没有最近的Heartbeats来标记DataNodes为死亡状态，并且不向它们转发任何新的IO请求。 注册为死亡状态的DataNode的任何数据都不可用于HDFS。 DataNode的死亡可能导致某些块的复制因子低于其块的复制因子指定值。 NameNode不断跟踪需要复制的块必要时启动复制。 重新复制的必要性可能是由于原因很多：DataNode可能变得不可用，副本可能会损坏，DataNode上的硬盘可能会失败，或者文件的复制因子可能会增加。

8.2 Cluster Rebalancing

HDFS架构与数据重新平衡方案兼容。 一个方案如下，如果DataNode上的可用空间低于某个阈值，则自动将数据从一个DataNode移动到另一个DataNode。 如果对特定文件有突然的高需求，一个方案可以动态创建额外的副本并重新平衡群集中的其他数据。这些类型的数据重新平衡方案尚未实现。

8.3 Data Integrity

从DataNode获取的数据块可能已损坏。 这种损坏可能由于存储设备中的故障，网络故障或有缺陷的软件而发生。 HDFS客户端软件实现对HDFS文件内容的校验和检查。 当一个client创建一个HDFS文件，它计算文件每个块的校验和并存储这些’校验和‘于位于同一HDFS命名空间下的单独隐藏文件中。 当客户端检索文件内容，它验证从每个DataNode收到的数据校验和是否匹配存储在其相关联的校验和文件中的数据。 如果没有，则客户端可以选择另一个具有该块副本的DataNode来检索该块。

8.4 Metadata Disk Failure

FsImage和EditLog是HDFS的中心数据结构。 这些文件的损坏可能导致HDFS实例无法正常运行。 出于这个原因，NameNode可以配置为支持维护FsImage和EditLog的多个副本。 任何FsImage或EditLog的更新会导致每个FsImages和EditLogs都得到同步更新。 这种同步更新FsImage和EditLog的多个副本可能会降低NameNode命名空间每秒支持事务的速率。 但是，这种降级是可以接受的，因为虽然HDFS应用程序是它本质上是数据密集型的，但它们不是元数据密集型的。 当NameNode重新启动时，它选择使用最新的一致的FsImage和EditLog。NameNode计算机是HDFS集群的单点故障。 如果是NameNode机器出现故障，需要手动干预。 目前，NameNode软件自动重启和故障转移到另一台机器暂不支持。

8.5 Snapshots

快照支持在特定时刻存储数据副本。 一种用法快照功能可能是将损坏的HDFS实例回滚到先前已知的正常运行的时间点。 HDFS目前不支持快照，但将来会发布。

9 Data Organization

9.1 Data Blocks

HDFS旨在支持非常大的文件。 与HDFS兼容的应用程序是处理大型数据集的。 这些应用程序只写入一次他们的数据，但是读取数据一次或多次，并要求在流式速度下满足这些读取。 HDFS支持文件上的write-once-read-many语义。 HDFS使用的典型块大小为64MB。 因此，HDFS文件被切碎为64 MB块，如果可能，每个块将会驻留在不同的DataNode上。

9.2 Staging

创建文件的client请求不会立即到达NameNode。 事实上，最初HDFS client 将文件数据缓存到临时本地文件中。 应用程序的写入被透明地重定向到这个临时本地文件。 当本地文件累积数据时值得超过一个HDFS块大小，client联系NameNode。 NameNode将文件名插入到文件系统层次结构并为其分配数据块。 NameNode使用DataNode的标识和目标数据块的标识来响应客户端请求。 然后，客户端将数据块从本地临时文件刷新到指定的数据节点。 关闭文件时，临时本地文件中剩余的未刷新数据将被转移到DataNode。 然后客户端向NameNode传达文件已关闭。 在此时，NameNode将文件创建操作提交到持久性存储中。 如果NameNode在文件关闭之前死亡，则文件丢失。
在仔细考虑了目标应用之后，采用了上述方法在HDFS上运行。 这些应用程序需要流式写入文件。 如果client写入远程文件直接没有任何客户端缓冲，网络速度和拥塞网络大大影响吞吐量。 这种方法并非没有先例。 之前的分布式文件系统（例如AFS）使用客户端缓存来提高性能。 一个POSIX要求已经放宽，以实现更高的数据上传性能。

9.3 Replication Pipelining

当client将数据写入HDFS文件时，其数据首先写入本地文件在上一节中解释过。 假设HDFS文件的复制因子为3。当本地文件累积出一个完整的用户数据块时，客户端将检索NameNode中的DataNode列表。 此列表包含即将托管那个块副本的DataNodes。 然后，客户端将数据块刷新到第一个DataNode。 第一个DataNode开始以小部分（4 KB）接收数据，将每个部分写入其本地存储库并将该部分传输到列表中的第二个DataNode。 反过来，第二个DataNode开始接收数据块的每个部分，将该部分写入其存储库然后将该部分刷新到第三个DataNode。 最后，第三个DataNode将数据写入它的本地存储库。 因此，DataNode可以从流水线中接收前一个的数据，同时将数据转发到流水线中的下一个。 因此，数据是从一个DataNode流向下一个。

10 Accessibility

可以通过多种不同方式从应用程序访问HDFS。 在本地，HDFS提供了一个用于要使用的应用程序的 Java API 。 此Java API的A C语言包装器也可用。 在此外，还可以使用HTTP浏览器浏览HDFS实例的文件。 通过WebDAV协议公开HDFS的工作正在进行。

10.1 FS Shell

HDFS允许以文件和目录的形式组织用户数据。 它提供了一个命令行接口，称为FS shell，允许用户与HDFS中的数据进行交互。 该此命令集的语法类似于用户已经使用的其他shell（例如bash，csh）熟悉。 以下是一些示例操作/命令对：
行动 命令
创建一个名为 / foodir 的目录 bin / hadoop dfs -mkdir / foodir
删除名为 / foodir 的目录 bin / hadoop dfs -rmr / foodir
查看名为 / foodir / myfile.txt的文件的内容 bin / hadoop dfs -cat / foodir /myfile.txt文件
FS shell适用于需要脚本语言与存储交互的应用程序数据。

10.2 DFSAdmin

DFSAdmin命令集用于管理HDFS集群。 这些是仅由HDFS管理员使用的命令。 以下是一些示例动作/命令对：
行动 命令
将群集放在Safemode中bin / hadoop dfsadmin -safemode
输入生成DataNode列表bin / hadoop dfsadmin -report
重新发布或退役DataNode（s）bin / hadoop dfsadmin -refreshNodes

10.3 Browser Interface

典型的HDFS安装配置Web服务器以通过一个可配置的TCP端口公开HDFS命名空间。 这允许用户导航HDFS命名空间并使用Web浏览器查看其文件的内容。

11 Space Reclamation

11.1 File Deletes and Undeletes

当用户或应用程序删除文件时，不会立即从HDFS中删除该文件。相反，HDFS首先将其重命名为 / trash目录中的文件。 该文件可以恢复只要它留在 /垃圾桶里 就很快 。 文件保留在/ trash中以进行配置多少时间。 在 / trash中 生命到期后 ，NameNode将从中删除该文件HDFS名称空间。 删除文件会导致与文件关联的块释放。 请注意，文件删除之间可能存在明显的时间延迟用户以及HDFS中可用空间相应增加的时间。用户可以在删除文件后取消删除文件，只要它保留在 / trash目录中即可。如果用户想要取消删除他/她已删除的文件，他/她可以导航 /垃圾目录并检索文件。 在 / trash目录仅包含的最新副本已删除的文件。 在 / trash目录仅仅是想用一个特别的任何其他目录功能：HDFS应用指定的策略自动删除此目录中的文件。 该当前默认策略是从 / trash 删除超过6小时的文件。 在里面未来，该政策将通过定义明确的界面进行配置

11.2 Decrease Replication Factor

当文件的复制因子减少时，NameNode选择可以删除的多余副本。 下一个Heartbeat将此信息传输到DataNode。 该然后，DataNode删除相应的块，并显示相应的可用空间在群集中。 再重申一次，完成setReplication API调用与集群中可用空间出现之间可能会有一段时间延迟。

12 References

HDFS Java API: http://hadoop.apache.org/core/docs/current/api/
HDFS source code: http://hadoop.apache.org/hdfs/version_control.html