简介

Hadoop Distributed File System(HDFS)是一个运行在商用硬件平台上的分布式文件系统。它和很多现存的分布式文件系统有很多相似之处。当然，和其他的分布式文件系统的区别也是很明显的。HDFS在廉价硬件平台上提供高可靠的文件服务，提供数据访问的高吞吐量，适合那些运行在大数据集上的应用。HDFS并不完全符合POSIX文件系统方面的标准，这是因为HDFS运行环境和POSIX filesystem适用的环境是不同。HDFS支持对文件系统数据的流式访问。HDFS最初是为Apache Nutch搜索引擎项目设计的。现在HDFS是Apache Hadoop的一个子项目，项目地址为http://hadoop.apache.org/hdfs/

假定和目标

Hardware Failure

硬件失效是很普通的情况而不是什么异常。HDFS运行环境可能包含数百台服务器，每台机器存储着文件系统的部分数据。事实上这些服务器的数据已经很大了，而且每一台机器都有不小的可能性会失败，这就导致HDFS部件并不总是正常工作的。因此，检测失败并且能够迅速的恢复是HDFS的核心设计目标。

Stream Data Access

运行在HDFS上的应用需要流式的访问他们的数据集。HDFS应用不像 那些在通用的文件系统上操作的应用。HDFS是面向批处理操作而不是那些user交互操作。HDFS侧重于高吞吐量而不是低延迟。POSIX标准的一些需求并不适合面向HDFS的应用，因此为了达到高吞吐量而在某些方面违反了Posix 标准。

Large Data Sets

运行在HDFS上的应用操纵的都是大数据集。一个典型的HDFS文件的尺寸是GB~TB大小。因此，HDFS针对大文件进行了优化。通过把一个文件分散到集群内的数千个节点，来提供更高的数据带宽。HDFS应该能够支持千万级的文件数目。

Append-writes and File Syncs

大部分HDFS应用的文件操作模式是写一次读多次。HDFS提供了两个高级功能：hflush和append。hflush提供read一致性和数据持久性。使得文件的最后一块对文件的读用户都可见。Append提供了一种机制能够重新打开关闭的文件添加额外的数据。

关于 hflush和append的更多细节，参考Append/Hflush/Read Design document

Move Computation is Cheaper than Moving Data

当计算在数据保存的节点附近时，效率会更高，尤其当操作的数据非常大的时候。就近计算使得网络消耗和系统吞吐量都最小。根据这个原则，移动计算到数据的保存位置而不是把数据移动到计算节点。HDFS向应用提供了接口：移动计算到数据存放位置。

Protability Across Heterogeneous Hardware and Software Platforms

HDFS很容易的在不同平台移植。这个特性使得HDFS被很多应用采纳为平台。

NameNode and DataNodes

HDFS采用master/slave体系结构。HDFS集群包含一个NameNode，用来管理文件系统的名空间以及管理Clients访问文件的权限。此外，HDFS还包括一定数目的DataNodes，用来管理所在机器的存储空间（通常每台机器只有一个DataNodes）。HDFS通过Namenode向用户提供一个 文件系统名空间，允许用户存储数据为HDFS files。在HDFS内部，一个文件则被分割成很多块，这些块被存储在多个DataNodes中。Namenode执行文件系统名空间操做如open, close, rename文件和目录，同时负责到DataNodes节点的块映射。DataNodes负责Client读写数据请求，DataNodes还会执行block的创建，删除以及在block的复制。

NameNode和DataNode是运行在普通机器上的软件，这些机器一般为GNU/Linux操作系统。HDFS是用Java语言实现的，因此任何支持Java的机器都可以运行NameNode和DataNode软件。使用移植性很强的Java语言意味着HDFS的可部署范围非常之广。典型的部署是NameNode使用一个特定的机器，集群中的其他机器节点，每一个上面运行一个DataNode。虽然HDFS架构本身并不排斥一台机器运行多个DataNode，但是实际部署中很少这样用。

集群中仅有一个NameNode极大的简化了系统架构。NameNode是系统的仲裁者，负责HDFS所有的元数据。NameData不会经手任何user data

The File System Namespace

HDFS支持传统的文件分级组织。一个user或者application可以在这些目录下创建目录和存储文件。文件系统名空间的层次结构类似于现在的大部分文件系统：可以创建和删除文件，移动文件到另外一个目录，或者重命名一个文件。HDFS实现了一个目录下的名称数目和数据块的User配额。此外HDFS支持符号链接。

NameNode维护文件系统的名空间。任何对文件系统名空间和名空间属性的改变都会记录到NameNode中。一个应用可以指定一个文件的复制因子，这个信息保存在NameNode中。

Data Replication

HDFS能可靠的存储非常大的文件到集群中的多个机器上。每个文件被分割为连续的block，除了最后一块，文件中的每个块尺寸相同。文件的block被复制多份提供容错能力。可以为每一个文件指定块尺寸和复制因子，复制因子可以在文件创建的时候指定也可以在稍候修改。HDFS中的文件在任何时候只能有一个writer

NameNode决定何时做block复制。它周期性的从集群的每个DataNode接收Heartbeat和Blockreport。从DataNode接收到Heartbeat意味着DataNode工作正常。Blockreport包含一个DataNode的所有blocks列表。

Replica Placement: The First Baby Steps

复制的位置对于系统可靠性和性能是至关重要的。复制位置优化使得HDFS有别于其他的分布式文件系统。这个Features依赖于调整和经验。Rack-aware复制位置策略用来改善数据的稳定性，可用性以及网络带宽的优化，当前的复制位置策略仅仅是这个方向上的第一步。短期目标是在真正的部署中验证它，通过它来测试和研究更复杂的策略。

大型HDFS实现通常会分布在多个racks上。不同机架的两个节点通讯不得不通过机架间的交换机。通常情况下，同一机架内机器间网络带宽大于不同机架间机器的网络带宽。

NameNode通过Hadoop Rack Awareness进程来决定每个DataNode所属的Rack ID。一个简单未优化的策略是放置备份在不同的机架。防止整个机架失效后的数据丢失同时还能从多个机架读取数据。这个策略可以在某个节点失效后，剩余的备份能有效的实现负载均衡。然而，这个策略增加了写的代价，因为写会跨越多个机架执行block的传输。

在复制因子为3的常用情况下，HDFS的防止策略是一个备份在本地机架，另外一个备份在一个不同的(remote)机架，最后一个放置到remote机架的不同DataNode上。这个策略减少了机架间的写流量因此改善了写性能。机架失效的几率远小于节点失效的几率，因此这个策略没有影响到可靠性和可用性。然而它的确减少了读数据时的网络带宽使用，因为一个块被放在两个rack而不是三个rack。这个策略改善了写性能同时并没有破坏数据的稳定性和读性能。

除了上面描述的缺省放置策略，HDFS还提供了block放置的可替换接口，参考BlcokPlacementPolicy

Replica Selection

为了优化网络带宽消耗以及读延迟，HDFS试图从reader就近的节点满足读请求。如果一个文件备份和reader在同一个机架上，那么选择这个备份满足读请求。如果一个HDFS集群散布在多个数据中心，那么本地数据中心的备份要优于远程的备份。

Safemode

在启动时，NameNode先进入一个特定的状态叫Safemode。当NameNode在Safemode不允许有数据块的复制。NameNode从DataNodes接收Heartbeat和Blockreport。Blockreport包含DataNode所含data blocks的列表。每一个块有一个给定数目的最小备份，当NameNode检查发现给定数据块达到了这个最小备份数，那么认为这个数据block是安全的。当安全复制块数达到了给定的百分比后（外加额外的30秒时间），NameNode退出Safemode状态。然后把那些小于最小备份数的data blocks保存到一个列表里，开始复制这些blocks的备份到其他的DataNodes

The Persistence of File System Metadata

HDFS文件系统的名空间保存在NameNode中。NameNode使用事务日志EditLog来记录发生在文件系统metadata上的所有变华。比如，在HDFS中创建一个新文件时，会促使NameNode插入一条记录到EditLog中。类似的，修改文件的复制因子也会在EditLog中生成一条新的记录。NameNode在它的本地OS文件系统保存这个EditLog文件。整个文件系统的名空间，包括文件的块映射和文件系统属性，都被存储在一个FsImage文件中。FsImage也被存储在NameNode的本地文件系统中。

NameNode保存整个文件系统的名空间镜像和文件块图在memory中。这个关键的metadata项很紧凑，这样在拥有4G内存空间的NameNode上，可以支持很大数目的目录和文件。当NameNode开始启动，它首先从本地磁盘读取FSImage和EditLog，应用所有EditLog事务到FsImage在内存中的表示。然后把这个新版本的内存FsImage刷新到磁盘上。现在NameNode可以truncate掉老的EditLog文件，因为我们已经把这些事务永久的保存到on-disk FsImage上。这个过程被称作checkpoint。CheckPoint Node 是独立于NameNode的一个守护进程，可以周期性的从FsImage和EditLog创建checkpoint，并且上传给NameNode。Backup Node 类似于Checkpoing Node可以创建checkpoint，同时还能维护一个升级后的copy在内存中。

DataNode存在HDFS数据到本地文件系统的文件中。DataNode自身不知道HDFS文件的metadata。HDFS数据的每一block都对应到到DataNode的一个文件中。DataNode并使把所有的文件都创建在同一个目录下，相反，它自启的决定每个目录下的最优文件数目并且会相应的创建新的子目录。在一个目录下创建所有的文件不是最优的，因为本地文件系统可能无法在单一目录下，有效的支持这么大数目的文件。当一个DataNode启动后，它首先扫描它的本地文件系统，然后生成HDFS数据block对应的本地文件列表，并且以报告的形式发送给NameNode：这就是Blockreport。

The Communication Protocols

所有的HDFS通讯协议位于TCP/IP协议层之上。Client通过一个可配置的TCP端口连接到NameNode机器，它和NameNode之间采用ClientProtocol。DataNodes和NameNode之间采用DataNode Protocol。一个Remote Procedure Call(RPC)抽象层封装了Client Protocol和DataNode Protocol。按照设计，Namenode不会主动发起RPCs，它只是响应来自DataNodes和clients的RPCs

Robustness

HDFS设计的一个主要目标是可靠的存储数据，即便存在失效的可能。在HDFS系统中存在三种可能的失效：NameNode失效，DataNode失效，以及网络部分失效。

Data Disk Failure, Heartbeats and Re-Replication

每一个DataNode周期性的发送一个Hearbrat message给NameNode。网络可能会导致一部分DataNodes无法和NameNode联系。在这种情况下DataNode察觉到Heartbeat的缺失。NameNode把最近没有发送Heartbeats的DataNode标记为dead，并且不会再向这个DataNode发送任何I/O请求。的宕机促使一些blocks的复制因此小于设定值。NameNode会持续的检测那些块需要复制，一旦必要就启动复制。Re-Replication可能因为以下原因：一个DataNode变得不可用，一个复制变得失效，DataNode的一个磁盘失效，或者文件的复制因子增加。

Cluster Rebalancing

HDFS架构本身是和数据均衡计划兼容的。当一个DataNode的空闲空间低于给定的阀值，应该自动移动一个DataNode的数据到另外一个DataNode。在一个文件引发较高需求的情况下，一个计划可以动态的增加额外备份并且平衡集群内的其他数据。当前这种类型的Reblanacing scheme还没实现。

Data Integrity

从DataNode获取的block data可能是损坏的。这个损坏可能是因为存储设备的错误，网络错误或者软件bug。HDFS client软件对HDFS内容进行checksum。当一个client创建一个HDFS文件时，它为这个文件的每一个block生成checksum，并且存储这些checksums到HDFS名空间的一个隐藏文件中。当一个client从DataNode获取这个文件内容时，它会验证获取的数据块是否匹配存储在checksum文件中的checksum。如果不匹配，那么client会从其他的DataNode获取这个block的备份。

Metadata Disk Failure

FsImage和EditLog是HDFS的核心数据结构。这两个文件的损坏会导致HDFS无法正常工作。基于这个原因，可以配置NameNode以便支持FsImage和EditLog的多个copies。对FsImage和EditLog的任何升级都会促使所有的copies同步的更新。多个FsImage和EditLog copies同步更新会导致NameNode可支持的名空间事务速度降低。然而，这个降低是可以接受的，因为即便HDFS应用是数据密集型的，也不会是metadata密集型的。当一个NameNode重新启动，它选择使用最近的一致性的FsImage和EditLog。

NameNode机器是HDFS集群的单点故障。如果Namenode机器失效，手动介入是必需的。当前软件不支持自动重启和失效后转到其他机器

Snapshots

Snapshots是指在一瞬间实现数据的一个备份，Snapshot是一种分量备份。Snapshot feather可以使我们回滚损坏的HDFS到前面一个已知的好状态。HDFS当前不支持snapshots但是将来会支持这个功能。

Data Organization

Data Blocks

HDFS是为支持大文件设计的。兼容HDFS的应用是那些处理大数据集的应用。这些应用仅仅写一次数据当时会读很多次，同时需要读的速度很快。HDFS支持Write-once-read-many到这种文件。一个典型的HDFS block size是64MB。因此，HDFS文件被分割成64MB的块，如果可能，每一个chunk被存放在不同的DataNode上。

Replication Pipelining

当一个client写数据到复制因此为3的HDFS集群中时，NameNode通货复制目标选择算法获取一个DataNode list。这个list包含那些要保存数据备份的DataNode。client然后向第一个DataNode写入数据。第一个DataNode以很小的单位（4K）接收数据，写每个单位到本地存储同时传送这个部分给list的第二个DataNode。第二个DataNode相应的开始接收数据快的每个小部分，写入本地存储的同时把数据传送给第三个DataNode。最终三个DataNode把数据都写到了本地存储。因此一个DataNode从前面的DataNode接收数据同时传送给下一个DataNode。就如同在管道中流动一样。

Accessibility

可以通过多种方式访问HDFS。HDFS提供了Java API供应用使用。还有C语言接口是对这个Java API的包装。此外，可以使用HTTP browser可以用来浏览HDFS文件。通过WevDAV协议访问HDFS正在开发当中。

FS Shell

HDFS允许用户按照文件和目录的形式组织数据。它提供了叫做FS shell的命令行接口，FS shell允许晕乎通过命令操作HDFS数据。这种命令的语法类似于其他的Shells命令。下表是一些动作和对应命令的例子

FS shell是面向那些需要使用脚本处理数据的应用

DFSAdmin

The DFSAdmin 命令集用来管理HDFS集群。这些命令仅仅被HDFS管理员使用，下表是一些动作和对应命令的例子

Browser Interface

一个典型的HDFS部署，会配置一个web server来暴露HDFS的名空间。这样用户可以通过Web browser来浏览HDFS名空间以及查看文件内容。

Space reclamation

File Deletes and Undeletes

当一个文件被用户或者application删掉后，这个文件并不会立刻从HDFS删除，HDFS首先把这个文件重命名为/trash下的一个文件。这个文件可以被立即恢复如果它还在/trash下。文件停留在/trash内的时间是可配值的。过了这个时间以后，HDFS从名空间删除这个文件。删除这个文件会释放这个文件相关的数据块被释放。注意在文件被删除后到HDFS相应的空闲空间增加之间存在一定时间延迟。

用户可以Undelete 一个还在/trash目录下的文件。如果用户想要undelete一个已经删除的文件，首先浏览/trash目录然后恢复这个文件。/trash目录仅仅包含删除文件最晚的版本。/Trash和其他目录非常类似，只是包含了一个特殊功能：HDFS会根据某种策略自动删除这个目录下的文件。当前缺省的策略是删除移到目录/trash超过6个小时的文件。未来，这个策略可以通过一个良好定义的接口配置。

Decrease Replication Factor

当复制因子被减少时，NameNode选择超出的备份予以删除。NameNode把这个信息通过Heartbeat传送给DataNode，DataNode删除replicas后相应的空闲空间释放给集群。注意，在SetReplication API调用到相应的空闲空间出现之间存在一定的延迟。

将正在运行的hadoop作业kill掉

hadoop job –kill  [job-id]