HDFS架构(二)

接上一篇译文：HDFS架构(一)

---------------------------------------------------------

副本放置之第一步

由于HDFS的可靠性和高性能，副本位置的选择是严格的。经过优化的副本放置可以让HDFS区别于其他分布式文件系统，而该项特性需要不断的调优和实践。副本放置采用机架感知策略目的是为了提高数据的可靠性，可用性和网络带宽利用率。 采用这种策略的短期目标是在生产系统上进行验证，同时了解更多关于它的行为，并建立一系列测试来研究更复杂的策略。

许多HDFS实例通常是运行在由跨机架组成的计算机集群中，而不同机架上的两个节点一般要通过交换机来进行通信。通常来说，同一机架上的机器的网络带宽要比不同机架的大很多。

NameNode通过 Hadoop Rack Awareness所阐述的过程来决定DataNode所属的rack ID。一个简单的但未经优化的策略是将副本放到单独的机架上。这样可以避免由于整台机架崩溃引起的数据丢失，同时在进行读数据时利用到多个机架的带宽。这个策略甚至可以将副本分布在不同机器上以实现均衡负载。然而，这也增加了读操作的开销，因为写意味着需要将block数据传输到不同的机架上。

一般来副本数量为3时，HDFS的策略为将一份副本放在本机架的与正本相同的节点上，另一份放在同一机架的不同节点上，最后一份会放在另一机架的节点上。这种策略会减少机架间写操作的通讯开销，从而提高了写的性能。整个机架崩溃要比节点发生故障的概率小的多，因此该策略不会影响数据的可靠性和稳定性。另外它也降低了读数据时的网络开销，因为一个block数据是放置在两个独立的机架上而不是三个。使用这种策略，一个文件的副本并不均匀地分布在不同的机架:三分之一的副本在同一个节点上，三分之二在同一个机架上，剩下三分之一均匀地分布在其余的机架。不需要通过数据可靠性和读性能的折中调优，写性能也得到了提高。

上述描述的作为默认配置的副本防止策略正在紧张开发中。

副本的选择

为了最小化集群整体的网络带宽开销及读延时，HDFS尝试让发起读数据请求的客户端能从离他最近的一份副本获取数据。如果在发起读请求的client同一机架上有对应的副本，该副本首先会被HDFS用来完成数据的读取。如果副本跨越了HDFS的多个数据中心，存储于本地数据中心的副本会优先于远程副本来作为数据的访问源。

安全模式

集群启动期间，NameNode节点会进入一个成为安全模式(Safemode)的特殊状态。这种状态下不会做数据的备份，而NameNode会从DataNodes接收倒Heartbeat和Blockreport信息。一个Blockreport包含了该DataNode所存储的block列表。每个block指定了一个最少副本数量值。当数据block副本的最小序号通过NameNode核对时，我们认为该block是能安全复制的。在经过NameNode核对数据block的备份配置完成后(另外等待30秒)，NameNode退出Safemode状态。然后NameNode会判断并列出副本数仍然少于配置要求的份数的block列表，如果列表不为空，那么它就会将这些block拷贝到其他DataNode.

File System元数据持久化

HDFS的命名空间数据保存在NameNode中。NameNode使用了名为EditLog的事务日志来持续记录了文件系统元数据所发生的每一个变化。例如，在HDFS中创建新文件时，NameNode会往EditLog插入一条记录来说明此操作。同样地，修改文件的副本系数时也会在EditLog记录这样的操作。NameNode将EditLog存储在本地操作系统的文件系统的一个文件中。 整个文件系统的命名空间，包括block到file和file system property之间的映射关系, 保存在一个成为FsImage的文件中。此FsImage也是作为一个文件形式存储在NameNode本地文件系统中。

NameNode在内存中保存了一份整个文件系统命名空间和文件Blockmap的镜像。这份重要的元数据项是被压缩保存的，因此一个拥有4GB RAM的NameNode可以支持大量的文件和目录信息。NameNode启动后，它会从磁盘中读取FsImage及EditLog，应用EditLog中所有的事务到存在于内存中的FsImage文件对象，然后将版本较新的这个FsImage文件写入磁盘，之后EditLog就可以被删除了，因为所有的事务已经被持久化到FsImage中。该过程称为checkpoint。当前的实现机制为：一个checkpoint只发生在NameNode启动的时候;将来会逐渐支持周期性的checkpoint过程。

DataNode在本地文件系统中保存了HDFS数据，但它并不知道HDFS保存的具体内容，只是把HDFS数据保存在本地的独立的block中。DataNode在同一目录不会创建所有的文件，相反它会启发式的决定每个目录创建最合适的文件数和子目录数。一开始就在同一目录下初始化所有文件是不推荐的，因为本地文件系统可能不支持一个目录中创建过多数量的文件。当一个DataNode启动时，它会扫描本地文件系统，生成所有HDFS数据块的一个列表，然后向NameNode发送一个报告(这个报告称为Blockreport)。

通信协议

所有HDFS的通信协议都基于TCP/IP协议，客户端会与NameNode机器上的TCP端口建立连接，并通过ClientProtocol协议与NameNode进行会话。而DataNode节点则通过DataNode Protocol与NameNode进行通信。远程过程调用(RPC)同时封装了Client Protocol和DataNode Protocol。而NameNode从不启动任何RPC，相反它会响应来自DataNode或客户端的RPC。

稳健性

HDFS的首要目标是即使出现故障时仍然可以安全地存储数据。三种故障的类型可以概括为NameNode故障，DataNode故障和网络中断。

数据磁盘故障, 心跳及重新复制

每个DataNode会定期向NameNode发送一个心跳信息。如果一部分DataNode与NameNode断开了连接，NameNode会根据心跳信息来觉察到。NameNode会将最近没有发送心跳信息的DataNode标记为dead状态，并且不会再像它们发送任何的IO请求。一个节点被标记为dead，此时所有它那里注册过的任何信息对HDFS来说都不起作用了，这也引起了部分block的拷贝数量少于指定值。NameNode会不断跟踪需要备份的block并且启动复制。必须进行重新复制的理由是：一个DataNode可能因为故障而不可用, 拷贝过程可能失败, DataNode上的磁盘可能坏掉, 或者副本数量会被增加。

集群的重新均衡

HDFS架构会兼容数据重新均衡的策略。其设想是当节点 A的剩余空间明显低于某一阈值时，HDFS会自动选择从其他节点移动数据到节点A；当对某个特定文件有紧急高优先级的需求时, HDFS将会动态增加文件拷贝及重新均衡数据。但目前这些设想还没有实现。

数据完整性

存储在某个DataNode上的数据很可能会被损坏，可能是由于存储设备故障，网络故障或者软件漏洞所致。HDFS客户端应用实现了对文件内容的校验和。客户端创建HDFS文件时，它会计算每个文件的每个block的校验和并在相同的命名空间下的单独隐藏的文件中保存这些值。当客户端接收文件数据时，会首先验证校验和。如果校验失败，客户端会向其他拥有同样复本的DataNode重新获取数据。

元数据磁盘故障

FsImage及 EditLog文件是HDFS系统的重要数据结构，这些文件的异常会导致HDFS无法正常工作。因此NameNode可以配置拥有FsImage和EditLog的多份拷贝。对FsImage或EditLog文件的更改会引起所有复本的同步更新，这同步更新的过程会降低NameNode可以支持的命名空间每秒事务处理的频率。但这是可以接受的，因为即使HDFS应用对数据很敏感，也不会对元数据敏感。当NameNode重启时，它会选择使用最新版本的FsImage和EditLog文件。

NameNode在HDFS集群中属于单点故障。如果NameNode宕掉了，必须要经过人工来处理和修复，目前还不支持NameNode的自动重启和运行NameNode服务于备份服务器。

快照

快照(Snapshot)支持在某个时间点拷贝并保存一份数据。一种应用场景是快照用于将HDFS实例回滚到故障之前某个合适的状态(HDFS目前不支持Snapshot,但会在以后的版本中实现)。

数据组织

数据块

HDFS用于存储大文件，兼容HDFS的应用都是那些需要处理大数据集的应用。这些应用一般会只一次写入数据，但会读取多次并要求满足流式读取。HDFS支持文件的write-once-read-many原则。HDFS中典型的块大小为64 MB，因此一个文件往往会被切成64MB的大量的块(通常这些快会保存在不同的节点上)。

Staging

客户端创建文件的请求其实并没有立即发送给Namenode，事实上初始时HDFS客户端会先将文件数据缓存到本地的一个临时文件。应用程序的写操作被重定向到这个临时文件，这个操作对外是透明的。当这个临时文件的数据量超过block大小时，客户端才会通知Namenode。Namenode将文件名插入文件系统的层次结构中，并且分配一个数据块给它，然后向客户端返回Datanode的标识符和目标数据块。接着客户端将这块数据从本地临时文件flush到指定的Datanode。当文件关闭时，在临时文件中还没有上传的数据也会传输到指定的Datanode上；然后客户端通知Namenode该文件已关闭。此时Namenode才将文件创建操作持久化到日志文件里。如果Namenode在文件关闭前宕机，则该文件将丢失。

以上方法是对在HDFS上运行的目标应用进行认真考虑后才采用的。这些应用规定要以流式写入文件，如果不采用客户端缓存，网络速度和网络堵塞会对吞吐率造成较大的影响。这种方法并不是首创的，早期的文件系统如AFS，就是用客户端缓存来提高性能。为了有更高的数据上传效率，已经放松了POSIX标准。

流水线复制

当客户端向HDFS文件写入数据时，一开始是写到本地临时文件中。假设该文件的副本系数为3，当本地临时文件累积到一个数据块的大小时，客户端会从Namenode获取到一份Datanode列表用于存储副本，接着客户端开始向列表中第一个Datanode传输数据。此Datanode会分多个小块(4 KB)来接收数据，将每一部分写入本地目录的同时传输该部分到列表中第二个Datanode。第二个Datanode也像前一个节点一样接收数据和存储，并传给第三个节点。最后第三个Datanode接收数据并存储在本地。因此Datanode可以流水线地从前一个节点接收数据，然后转发给下一个节点。这样数据便以流水线的方式从前一个Datanode复制到下一个。

可访问性

HDFS向应用提供了多种访问方式。用户可以通过原生的 FileSystem Java API接口来访问，也可以通过C语言的封装API访问，甚至还可以通过浏览器的方式访问HDFS中的实例文件。目前正在开发通过WebDAV协议来访问HDFS。

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的目的是为那些需要通过脚本语言来与数据交互的应用。

DFSAdmin

DFSAdmin命令用于管理HDFS集群，只能被HDFS管理员使用。以下是一些操作/命令的示例：

操作	命令
将集群设置为安全模式	bin/hadoop dfsadmin -safemode enter
显示DataNode列表	bin/hadoop dfsadmin -report
上线或下线DataNode(s)	bin/hadoop dfsadmin -refreshNodes

浏览器接口

一个典型的HDFS安装会在一个可配置的TCP端口开启一个用于展示命名空间的web服务。这使得用户可以浏览HDFS明明空间及查看文件内容。

回收存储空间

文件的删除及恢复

当一个文件被用户或应用删除时，它并不会立即从HDFS中移除，相反它会先被重命名到目录/trash下的一个文件。因此该文件只要还在/trash下，就可以快速的还原。目录 /trash下的文件的保存时长是可以配置的，超过了这个时限后NameNode将会把它从HDFS命名空间中删除。 文件的

物理删除会引起对应block空间的释放。可以注意到，从用户删除一个文件到HDFS空闲空间的增加会有一定的延迟。

只要被删除的文件还在/trash目录中，用户就可以还原它。如果用户想还原被删除的文件，可以通过浏览/trash目录找回该文件，而/trash目录仅保存被删除文件的最后版本。/trash目录与其他的目录几乎一样，除了HDFS会应用一个特殊策略来自动删除该目录下的文件。目前默认策略是删除/trash中保留时间超过6小时的文件。以后这个策略可以通过一个被定义的接口来配置。

减少副本系数

当副本系数被降低时，NameNode会选择删除多余的副本，决定好后的下次Heartbeat检查会传递这个信息给DataNode. DataNode接收命令后即删除相应的block，这样HDFS集群对应的空闲空间便会增大。重新说明一下，从调用setReplication API到集群空间的回收会有一段时间的延迟。

参考资料

Hadoop JavaDoc API.

HDFS source code: http://hadoop.apache.org/version_control.html

源文链接：http://hadoop.apache.org/docs/r1.2.1/hdfs_design.html