http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html

Introduction

HDFS是一个被设计用于（日用硬件）的分布式文件系统。与已有的分布式文件系统有很多相似之处，但是也存在着明显的不同。HDFS具有高容错性，并可以运行在廉价的硬件上，提供了对应用数据的高吞吐率，因而非常适合需要处理大数据集合的应用。HDFS没有严格遵循POSIX（可移植操作系统接口）要求，允许以流形式访问文件系统中的数据。HDFS最初作为Apache Nutch web搜索引擎项目的基础架构，目前已经是Apache Hadoop的核心项目。

Assumptions and Goals

Hardware Failure

硬件故障是常态，而非例外。一个HDFS实例可以由成百上千台server机器组成，每台机器都存放文件系统的部分数据。由于巨大的硬件数据，而每个硬件都有一个简单概率会失败，这意味着HDFS中总是有一部分组件是失效的。因此快速检查失败并恢复是HDFS架构设计的一个核心目标。

Streaming Data Access

运行在HDFS上的应用需要以流形式访问数据。这些应用并不是运行在通用文件系统上的通用应用，HDFS更多的是为进行数据的批处理，而不是与用户的交互。因此，设计的重点在于提高数据访问的吞吐率，而不是数据访问的低延迟。POSIX中一些严格的要求并不是HDFS目标应用所需要的，因此HDFS处理了其中一些关键领域以提高数据吞吐率。

Large Data Sets

运行在HDFS上的应用需要处理大量的数据集合。在HDFS上的一个典型文件规模是GB甚至TB级别的。因此HDFS必须支持大文件。同时，需要提供高带宽，并可以在单个集群中达到成百上千个节点的规模。单个HDFS实例中可能包含数百万文件。

Simple Coherency Model

HDFS应用一般是“一次写入，多次读取”的。这意味着一个文件一旦创建、写入、关闭，就无需再修改。这种假设简化了数据一致性问题，提高了数据访问的吞吐率。一个Map/Reduce应用或者一个Web爬虫应用都完美地符合上述模型。在未来，HDFS已经有计划支持对文件appending-writes。

"Moving Computation is Cheaper than Moving Data"

一个计算越接近所需处理的数据运行效率越高，特别是当数据规模非常大的时候。数据距离越近，网络对数据处理的影响越小，从而提高整个系统的吞吐率。整个假设意味着，当计算和数据距离较远时，应该将计算移动到数据附近，而不是将数据移动到计算附近。HDFS为应用提供了接口，以方便应用将自己移动到离数据更近的地方。

Portability Across Heterogeneous Hardware and Software Platforms

（在异构硬件和软件平台中的可移植性）

HDFS可以轻松地从一个平台移植到另一个平台，这种便利提高了HDFS作为一个大规模应用平台的适用性。

NameNode and DataNodes

HDFS架构可简单概括为master/slave。一个HDFS集群一个NameNode用于管理文件系统的命名空间，一个master server用于管理客户端对文件的访问。同时，还包含一组DataNodes，一般而言集群中的一个节点上面有一个DataNode，用于管理所在节点的存储。HDFS公开文件系统命名空间，允许用户数据存放。在内部，一个文件被分为一个或多个块，这些块存储在一系列的DataNodes中。NameNode提供了对命名空间的操作，如打开、关闭和重命名文件或目录，并决定了块和DataNodes之间的映射关系。DataNodes负责客户端的读写请求。同时在NameNode的指示下完成块的创建、删除和复制。

NameNode和DataNode可运行于普通机器上。这些机器一般运行在Linux操作系统上。HDFS是使用Java语言编写的，任何支持Java的机器都可以运行NameNode或者DataNodes。使用高可移植性的Java语言意味着HDFS可以部署在大多数机器上。一个典型的部署中，有一台专用机器运行NameNode，其他机器分别运行一个DataNode。HDFS允许一台机器中运行多个DataNode，但在实际中很少出现。

单个NameNode的设计极大地简化了架构，相比于多个NameNode，单个NameNode完成对元数据的存储和管理而无需考虑数据一致性问题，同时客户端所需要的数据直接通过DataNodes访问，数据无需经过NameNode。

（也带来了问题，1、内存占用过大，如果存在上百万文件，那么会占用大量内存，以为NameNode将元数据存储在内存中以提高速度；2、文件查找耗时，存储过多文件，使得文件查找时间增加，有时查找文件的时间长过了文件读取的时间。

针对上述问题，出现了HDFS Federation）

The File System Namespace

HDFS所使用的文件系统与传统文件系统相似。用户或者应用可以创建目录或者文件在相应的目录中。HDFS的命名空间也和现存的大部分文件系统相似，可以创建和删除文件，移动文件，重命名文件。HDFS未实现访问权限控制，同样也不支持硬连接和软连接，但HDFS架构支持对上述特性的实现。

NameNode维护了文件系统的命名空间，任何对命名空间的修改都会被NameNode记录。HDFS还管理文件的副本数量，一个应用可以指定文件的副本数量。

Data Replication

HDFS实现在大规模集群中对大文件的可靠存储，每个文件被划分为一系列块，除了最后一个，其他块大小相同。为了防止硬件故障导致数据损坏，每个块包含特定数量的副本。每个文件块的大小和副本的数量都可以配置，副本数量在创建时指定并可修改。HDFS中文件只写一次，并且在任意时刻只能有一个写者。

NameNode管理与副本相关的全部内容。通过定期接收DataNodes的heartbeat和blockreport，NameNode将了解DataNode是否运行正常（接收到就意味着运行正常），以及DataNode中包含了哪些块。

Replica Placement: The First Baby Steps

副本位置对于HDFS的可靠性和性能至关重要。良好的副本定位使得HDFS区别于其他大多数分布式文件系统。副本定位需要不断调整和经验总结。机架敏感的定位策略有助于改善数据的可靠性、可用性和网络带宽使用率。当前的实现是在此道路上的第一次尝试，短期的目标是在一个产品级系统中验证，以便获得更多关于其行为的信息，以发现更加复杂的策略。

大的HDFS集群中机器通常分布在多个机架上，不同机架的节点之间需要通过交换机进行通信。在大多数情况下，同一个机架上的网络带宽要远高于不同机架之间的带宽。

NameNode如何决定每个DataNode的rack id，详见http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/ClusterSetup.html#HadoopRackAwareness。一个简单但并一定最佳的策略是将副本放到一个不同的机架上。这样做可以避免由于机架故障导致数据不可用，同时在读取数据时可以使用多个机架的带宽。这种策略实际上在集群上分布复制，这样有助于平衡由于组件失败导致的负载。尽管如此，这个策略增加了写的代价，因为需要将块复制到不同的机架上。

在一般情况下，复制因子是3，根据HDFS的定位策略，将一个副本放在本地机架的本节点，第二个副本放在本地机架的另一个节点，第三个副本放在另一个机架的节点。这种策略兼顾机架故障和性能。机架故障的概率远低于节点故障。这个策略并不影响数据的可靠性和可用性，确实降低了读取数据的带宽，当读取数据时一个块只可能存在于两个不同的机架上而不是三个。由于副本并不是完全分布在不同的机架上，一个在本节点，一个在同一机架的另一个节点，还有一个在另一个机架，实际上降低了写操作的代价。

Replica Selection

为了最小化全局带宽消耗和读延迟，HDFS处理读请求时尽量选择离读者最近的副本。如果有一个副本和读者节点在同一个机架，那么这个副本将被选择来满足读请求。如果angg/HDFS集群跨越多个数据中心，那么本地数据中心的副本被选择的优先级高于远程副本。

Safemode

启动时，NameNode会进入一个特殊的状态：safemode。在safemode时，数据块的复制不会进行。NameNode接收来自DataNodes的心跳和块报告，其中块报告中包含DataNode的块列表，每个块有一个指定的最小副本数量。一个块如果满足最小副本数量，则认为是安全的。在检查了配置比例的块是否安全后（加上一个额外的30秒），NameNode离开safemode，然后根据所找到的不安全块列表，对表中的块根据最小副本数量进行复制。

The Persistence of File System Metadata

HDFS命名空间保存在NameNode中，NameNode使用一个事务日志（EditLog）保存对系统元数据的所有改动。例如，创建一个新文件时，NameNode向EditLog中插入一条记录表示新文件创建。类似的，对文件副本因子的改变也会导致一条新的记录插入EditLog。NameNode在本地OS文件系统中创建一个文件用于存放EditLog。整个文件系统的命名空间，包括文件和块之间的映射、文件系统属性等都保存在一个叫FsImage文件中。整个文件也保存在本地文件系统中。

NameNode在内存中保存整个文件系统命名空间和文件块映射的一个快照。这个关键的元数据项被设计的非常紧凑，使得NameNode可以使用4GB内存空间存放巨大数量的文件和目录。当NameNode节点启动之后，会读取FsImage和EditLog，并对内存中FsImage的快照执行EditLog中的全部事务，然后将新版本保存为一个新FsImage。然后，将EditLog中现有的记录删除，因为其中的事务应经被保存到持久化的FsImage中。这个过程被称为checkpoint，在目前的实现中，一个checkpoint只在NameNode启动时发生。在不久的将来会支持周期性的checkpoint。

DataNode在本地文件系统中保存HDFS数据。DataNode并不知道HDFS文件。每个DataNode在本地文件系统中将HDFS数据的块保存为一个独立的文件。DataNode并不在同一个目录中创建所有的文件。相反，它使用一种启发式策略决定每个目录的最佳文件数量，并相应地创建子目录。在同一个目录中创建所有的文件并不是最佳选择，因为本地文件系统可能无法高效支持在一个单独的目录中包含大量文件。当一个DataNode启动时，扫描本地文件系统，生成一个块和本地文件对应的列表，并将这些信息发送到NameNode，这些信息就是BlockReport。

The Communication Protocols

所有的HDFS通信协议都是以TCP/IP协议为基础的。客户端通过ClientProtocol，建立一个连接到NameNode一个可配置的端口，而DataNode通过DataNode协议与NameNode通信。一个RPC（Remote Procedure Call）抽象封装了客户端和DataNode协议。NameNode不会发出任何RPC，只是对DataNodes或者Clients的RPC做出响应。

Robustness

HDFS需要在发生故障时保证数据的可靠性。常见的三种故障是：NameNode故障、DataNode故障和网络分区（network partition，网络中断导致通信无法连接）。

Data Disk Failure, Heartbeats and Re-Replication

每个DataNode周期性向NameNode发送心跳。网络分区导致DataNode无法连接NameNode。NameNode没有接收到心跳，从而检测到上述情况，然后将这些DataNode标记为dead，不再发送新的IO请求给这些DataNode。一个dead节点上的数据对于HDFS而言是不可用的，并会导致一些块的副本数量低于其副本因子。NameNode持续追踪哪些块需要复制，并在任何需要的时候开始复制。导致重新复制的原因主要有：一个DataNode不可用，一个副本被损坏，一个DataNode硬盘故障或者一个文件的副本因子被增加了。

Cluster Rebalancing

HDFS架构兼容数据调整方案。方案在一个DataNode节点的剩余空间低于一定限制时，自动移动节点中的数据到另一个节点。如果对一个特定文件有突发的高需求，方案动态创建更多副本，并调整集群中的其他数据。这些数据调整方案还没有实现。

Data Integrity

DataNode中的块可能会损坏，损坏可能是由于存储设备造成的，也可能是网络错误或者软件BUG。HDFS客户端实现了对HDFS文件内容的校验和检查。当客户端创建了一个HDFS文件时，计算该文件每个块的校验和并将其保存为HDFS命名空间的一个独立的隐藏文件。当客户端检索文件时，会将从DataNode中获得数据进行校验和检查。如果检查出错，客户端可以选择从保存该块副本的另一个DataNode中获取数据。

Metadata Disk Failure

FsImage和EditLog是HDFS的核心数据结构。这些文件的损坏将导致HDFS失效。因此，NameNode可以配置为保存FsImage和EditLog多个副本。任何对FsImage和EditLog的更新都会导致每个副本同步更新。这种同步更新机制降低了NameNode每秒支持的命名空间事务数。尽管如此，这种降低是可接受的，因为HDFS是数据密集型而不是元数据密集型。当NameNode重启后，会选择一个最新的一致的FsImage和EditLog使用。

目前，对于HDFS集群，NameNode存在单点故障，如果NameNode所在机器故障，那么人工干预是不可避免的。自动重启和故障转移现在还未支持。

Snapshots

快照在一个特定时间保存数据的一个副本。快照的一个作用是回滚一个损坏的HDFS到之前一个特定时间。在未来HDFS将支持快照功能。

Data Organization

Data Blocks

HDFS被设计来支持非常大的文件，因而适合那些需要处理大数据集合的应用。这些应用写数据一次，但是多次读取并要求读数据速度非常快，达到流处理速度。HDFS支持一次写入多次读出的模式，一个典型的块大小是64M，每个HDFS文件按照64M大小分块，如果可能，每块存储在不同的DataNode上以支持更高的并发读效率。

Staging

当客户端请求创建一个新文件时，请求并不是立刻到达NameNode。实际上，首先HDFS客户端会将文件数据保存到一个本地临时文件。应用程序的写入被透明地重定向到临时文件。当临时文件大小超过HDFS块大小时，客户端通知NameNode。NameNode在文件系统结构中插入文件名，并分配一个数据块。NameNode将分配的DataNode标识和数据块的地址发送给客户端，客户端将临时文件中的数据flush到分配的DataNode中。当一个文件关闭时，在临时文件中还未被flush的数据将被传递给DataNode。客户端通知NameNode文件已经关闭，此时，NameNode提交文件创建操作到一个永久存储（EditLog？）。如果NameNode在file关闭前已经死亡，那么文件将会丢失。（因为没有记录创建文件的事务，那么在NameNode重启后将不会存在该文件。）

上述方法充分考虑到运行在HDFS上应用的目标。这些应用需要流方式写入文件，如果客户端写入时没有缓存，那么网络速度和网络拥塞会显著影响到数据的吞吐率。这种方法并非没有先例，早期的分布式文件系统，如AFS，通过客户端缓存提高性能。在这里，为了提高数据上传的性能而放松了POSIX要求。

Replication Pipelining

当客户端向HDFS写数据时，首先如上一节所述下乳一个本地文件。假定HDFS文件副本因子为3，那么本地文件累积满足块大小的数据时，客户端从NameNode接收到一个DataNode列表，列表中包含了存储该块数据副本的所有DataNode。然后客户端flush数据到第一个DataNode，第一个DataNode以小块（portion，4KB）方式接收数据，将其写入本地存储并将小块传递到列表中的第二个DataNode，第二个DataNode接收第一个DataNode传递的portition，将其写入本地存储并将小块传递到列表中的第三个DataNode，第三个DataNode接收小块并保存到本地。流水线中的DataNode，从之前的接收数据并传递给下一个。因此数据像流水线一样，在不同的DataNode之间传递。

Accessibility

HDFS提供了多种方式用于应用的访问。HDFS本身提供了Java API，同时还有一个C语言包装器。另外，HTTP浏览器也可以用于浏览HDFS文件。这种方式主要是通过WebDAV协议（ WebDAV（Web-based Distributed Authoring and Versioning）是基于 HTTP 1.1 的一个通信协议。它为 HTTP 1.1 添加了一些扩展（就是在 GET、POST、HEAD 等几个 HTTP 标准方法以外添加了一些新的方法），使得应用程序可以直接将文件写到 Web Server 上，并且在写文件时候可以对文件加锁，写完后对文件解锁，还可以支持对文件所做的版本控制。这个协议的出现极大地增加了 Web 作为一种创作媒体对于我们的价值。基于 WebDAV 可以实现一个功能强大的内容管理系统或者配置管理系统。 ）实现的。

FS Shell

HDFS允许用户数据以文件和目录形式组织，并提供了FS Shell命令行接口用于用户交互。这种命令集的语法和其他shell相似，下面是一些例子：

Action	Command
Create a directory named /foodir	bin/hadoop dfs -mkdir /foodir
Remove a directory named /foodir	bin/hadoop dfs -rmr /foodir
View the contents of a file named /foodir/myfile.txt	bin/hadoop dfs -cat /foodir/myfile.txt

FS Shell是为了那些需要脚本语言的应用而设计的。

DFSAdmin

DFSAdmin命令集用于管理HDFS集群。这些命令只有HDFS管理员才能使用。下面是一些样例：

Action	Command
Put the cluster in Safemode	bin/hadoop dfsadmin -safemode enter
Generate a list of DataNodes	bin/hadoop dfsadmin -report
Recommission or decommission DataNode(s)	bin/hadoop dfsadmin -refreshNodes

Browser Interface

一个典型的HDFS可以通过配置一个Web服务器，使得用户通过浏览器访问HDFS命名空间和浏览文件内容。

Space Reclamation（空间再利用）

File Deletes and Undeletes

当文件被用户或应用删除时，并没有立刻从HDFS中移除。实际上，HDFS首先将其重命名并转移到/trash目录。这样文件可以快速重载，因为它仍然存在于/trash中。文件在/trash中存在的时间可以配置，在超过配置的保存时间后，NameNode从命名空间中删除文件，文件的删除导致其关联的块被释放。注意，文件删除和HDFS剩余空间增加之间存在延迟。

只要文件仍在/trash中，用户可以undelete该文件。如果用户想要undelete文件，那么可以访问/trash目录并恢复文件。/trash目录中保存被删除文件的最新副本。/trash目录有一个特性：HDFS根据特定的策略，自动删除该目录中的文件。目前默认的策略是自动删除/trash中存在时间超过6小时的文件。未来，可以通过接口配置该策略。

Decrease Replication Factor

当副本因子降低时，NameNode选择超额的副本并删除。在下一次心跳时，将该信息发送给DataNode，DataNode删除关联的块并释放空间。在setReplication API调用和集群中剩余空间增加之间存在着延迟。