介绍
Hadoop分布式文件系统(HDFS)是一种运行在通用硬件上的分布式文件系统。它与传统的分布式文件系统有很多相似之处,但是也有显著的不同。HDFS是高容错的,可以部署在低成本硬件上。HDFS提供了对应用数据的高吞吐量访问,适用于具有大数据集的应用。HDFS为了流数据访问放松了一些POSIX的限制。
设定和目标
- 硬件故障:硬件故障是常态。一个HDFS实例可能由成百上千个服务器组成,每台服务器存储部分数据。如此大量的组件,每个组件都有发生故障的概率,这意味着总有组件是不工作的。因此,故障探测,快速,自动回复一直是HDFS的核心架构目标。
- 流数据访问:某些运行在HDFS上的应用程序需要以流的方式访问数据集。为此,HDFS在批处理上做了更多设计。重点在于数据访问的高吞吐量而不是数据访问的低延迟。
- 大数据集:典型的HDFS文件通常以GB乃至TB计。
- 简单的一致性模型:HDFS文件使用的是一次写入,多次读取的访问模型。文件一旦创建完毕,除了append和truncate,文件不需要写入和关闭。文件可以追加但是无法更新。这个设定简化了数据一致性问题从而带来了高吞吐量的数据访问。
- 移动计算比移动数据更廉价:数据与计算过程在同一节点上无疑可以让计算效率更高,尤其是在面对海量数据的时候。这么做可以极大的减少网络堵塞并提高系统吞吐量。HDFS假定将计算过程移动到数据处比将数据移动到计算过程处更好。
- 跨异构硬件和软件平台的可移植性:HDFS可以很容易的从一个平台移植到另一个平台。
NameNode和DataNode
HDFS是主从结构。一个HDFS集群由一个NameNode和一组DataNode组成。NameNode是主服务器,负责管理文件系统命名空间以及客户端对文件的访问。DataNode通常每个节点一个,负责管理存储。HDFS对外暴露了一个文件系统命名空间并允许用户数据作为文件存储。在内部实现上,一个文件会被分割成一个或多个block,这些block存储在一组DataNode上。NameNode负责执行文件系统命名空间操作,例如打开,关闭,重命名文件和目录等。此外NameNode还维护着block和DataNode之间的映射关系。DataNode负责处理来自客户端的读写请求,并根据NameNode的指令创建,删除,备份block。
NameNode和DataNode都是运行在通用机器上的软件。这些机器通常使用Linux系统。HDFS使用Java构建,任何支持Java的机器都可以运行NameNode和DataNode。一种典型的集群部署方式是使用一台机器运行NameNode,其它机器每台运行一个DataNode实例。
文件系统命名空间
HDFS使用传统的分层文件结构。用户可以创建目录并在目录下存储文件。文件系统命名空间结构与传统文件系统类似,用户可以创建,删除文件,将文件从一个目录移动到另一个目录,重命名文件。HDFS支持用户限额和访问权限。
NameNode维护整个文件系统命名空间,它会记录任何对命名空间的修改。应用程序可以指定HDFS中文件的备份数量。文件的拷贝数称为该文件的备份因子。这个信息也存储在NameNode中。
数据备份
HDFS可以跨机器存储海量文件。每个文件分成一个block的序列存储。为了容错,文件的block会被备份。每个文件的block大小和备份因子都是可配置的。
文件中所有block的大小是相等的(除了最后一个),而对append和hsync提供可变长block支持后,用户可以直接创建一个新block,不必继续填充最后一个block。
应用程序可以指定文件的备份数。备份因子可在文件创建时指定,也可以稍后修改。HDFS的文件都是一次写入的(除了append和truncate),并且任何时候都只有一个写入器。
NameNode决定如何备份block。它周期性的接收来自DataNode的心跳检测和block报表。收到心跳检测说明DataNode工作正常,block报表包含该DataNode上的所有block。
副本安置:第一步
备份文件的位置对HDFS的可用性和性能至关重要。对备份的优化让HDFS从众多分布式系统中脱颖而出。这个工作需要大量的优化和经验。机架感知备份放置策略的目的是提高数据的可靠性,可用性和网络带宽利用率。目前的备份放置策略实现是这个方向上的第一步。短期目标是在生产环境上对其进行验证,更多的了解它的行为,为测试和研究更复杂的策略奠定基础。
大型HDFS集群的机器通常隶属于多个机架。两个不同机架上的节点进行通信必须通过交换机。一般来说,同一机架机器之间的网络带宽要优于不同机架机器间的网络带宽。
NameNode通过Hadoop Rack Awareness进程确定每个DataNode所属的机架ID。一个简单但是并非最优的策略是将备份放置在独立的机架上。这种策略可以避免机架故障时丢失数据,读数据时也可以利用多个机架的网络带宽。这种策略在集群中平均分配备份文件,这样组件发生故障时可以平衡负载。但是这种策略会增加写入成本,因为数据需要跨机架传输。
最常见的情况,备份因子是3。HDFS的放置策略是:如果写入器位于DataNode上,则将副本放置在本地计算机,否则随机选择一个DataNode,另一个副本放置在另一个远程机架的节点上,最后一个副本放在同一个远程机架的另一个节点上。这种策略减少了机架间的写入流量,从而提高写性能。机架发生故障的几率远小于节点故障几率。这种策略并不影响数据可靠性和可用性,但是它确实减少了读操作时的聚合网络带宽,因为一个block被放置到两个机架上而不是三个。这种策略的文件副本并不是均匀的分布在所有机架上,副本的三分之一位于一个节点,剩下的三分之二位于另一个机架上。这种策略可以提高写性能,而不会影响数据可靠性和读性能。
如果备份因子大于3,那么第四个和之后的副本随机放置,同时要保证副本数量不能超过机架的上限(公式:(replicas - 1) / racks + 2
)。
由于DataNode不能放置同一个block的多个副本,所以最大备份因子就是最大DataNode数。
在提供了存储类型和存储策略的支持之后,除了机架感知,NameNode放置副本时也会考虑放置策略。NameNode首先根据机架感知选择节点,然后根据备份文件的放置策略检查该节点的存储类型,如果该候选节点没有要求的存储类型,NameNode会查找下一个节点。如果第一轮没有找到足够的节点放置备份,NameNode会使用后备存储类型开始第二轮查找。
目前,副本放置策略依然在开发中。
副本选择
为了减少带宽消耗和读延迟,HDFS会尝试找寻一个离读请求最近的副本。如果读请求节点所在机架有这样一个副本,HDFS就优先使用这个副本。如果HDFS集群跨越多个数据中心,则本地数据中心的副本优先于远程副本。
安全模式
启动HDFS时,NameNode会进入一种称为安全模式的特殊状态。安全模式下数据block无法备份。NameNode会从DataNode接收心跳检测和block报表。block报表包含该DataNode下所有数据block的列表信息。每个block都有一个指定的最小备份数。只有block的最小备份数登记到NameNode中后,block才可以备份。备份登记结束后,NameNode退出安全模式。这是如果还有block不满足最小备份数的条件,NameNode才开始备份这些block。
文件系统元数据持久化
HDFS命名空间由NameNode保存,NameNode使用一个称为EditLog的事务日志记录对文件系统元数据的所有更改。例如,创建一个新文件会在EditLog中插入一条对应记录,同样的,修改文件备份因子也会插入一条记录。NameNode使用本地文件存储EditLog。整个文件系统命名空间,包括文件与block之间的映射关系,文件系统数据等,都保存在FsImage文件中。
NameNode在内存中维护文件系统命名空间和文件block映射关系的镜像。当NameNode启动,或者某个阈值触发了检查点时,NameNode从磁盘上读取FsImage和EditLog的内容,将所有EditLog中的事务操作应用到FsImage的内存镜像中,然后在磁盘上生成一个全新的FsImage。之后可以截断EditLog,因为所有事务都已持久化到FsImage。这个过程称为检查点。检查点的目的是通过获取文件系统元数据的快照并保存到FsImage来保证HDFS文件系统元数据的一致性。读取FsImage可能很快,但是持续编辑FsImage就不同了。因此我们将操作记录到EditLog中,而不是直接修改FsImage。在检查点期间,所有EditLog操作应用到FsImage。检查点可以按周期触发(dfs.namenode.checkpoint.period
),也可以按事务数触发(dfs.namenode.checkpoint.txns
)。如果两个属性都设置了,第一个满足的阈值会触发检查点。
DataNode在本地文件系统中存储HDFS数据。DataNode对HDFS文件一无所知,它以block为单位存储HDFS数据。DataNode不会在同一个目录下保存所有文件。相反,它使用启发式方法来确定每个目录的最佳文件数,并适时创建子目录。在同一个目录下创建所有文件并不是最佳选择,因为本地文件系统可能无法支持一个目录下的大量文件。DataNode启动时,它会扫描整个本地文件系统,生成一个本地文件与数据block之间的关系列表,将其发送给NameNode,这个列表称为block报告。
通信协议
所有HDFS通信协议都构建在TCP/IP协议之上。客户端通过TCP端口与NameNode建立连接,它使用ClientProtocol与NameNode交互。DataNode使用DataProtocol与NameNode交互。一个RPC抽象封装了客户端协议和DataNode协议。NameNode从不初始化任何RPC,它只是响应来自的客户端和DataNode的请求。
健壮性
HDFS的主要目标是即使出现故障也可以可靠的存储数据。三种常见的故障分别是:NameNode故障,DataNode故障和网络分区。
数据磁盘故障,心跳检测和重备份
DataNode周期性的发送心跳检测给NameNode。网络分区可能导致某些DataNode无法连接NameNode。NameNode无法收到DataNode的心跳检测后,它会把这样的DataNode标记为dead,并不在发送新的I/O请求。注册到死亡DataNode上的数据对HDFS来说不再可用,也会导致某些block的备份数少于文件指定的最小备份数。NameNode持续追踪block的备份情况并在必要时初始化备份操作。重备份的原因是多种多样的:DataNode不可用,某个备份文件损坏,DataNode磁盘故障,或者文件的备份因子增大。
为了避免DataNode状态抖动引起的备份风暴,标记DataNode死亡的超时时间设置的很长(默认超过10分钟)。用户可以设置一个更短的时间将DataNode标记为陈旧(stale),这样可以避免对性能敏感的工作负载的陈旧DataNode的读写操作。
集群重平衡
HDFS架构与数据重平衡scheme兼容。scheme可以在DataNode的磁盘空间低于某个阈值时将数据移动到另一个DataNode上。如果对某个文件的需求特别高,scheme还可以动态创建额外的副本并平衡到整个集群中。这些数据平衡scheme还未实现。
数据完整性
从DataNode中读取的block可能是损坏的。损坏的原因有多种:磁盘故障,网络故障,或者软件问题。HDFS客户端会对文件内容进行校验和检查。当客户端创建一个HDFS文件时,它会计算出文件所有block的校验和并保存在同一个命名空间的一个独立的隐藏文件中。当客户单检索文件时还要检查对应校验和文件中的值。如果校验和不匹配,客户端会尝试该block其它节点上的副本。
元数据磁盘故障
FsImage和EditLog是HDFS的核心数据结构。如果它们发生损坏,HDFS就无法使用了。因此,可以通过配置让NameNode维护多个FsImage和EditLog的拷贝。对两个文件的修改会同步到所有拷贝中。这种同步操作会降低NameNode的TPS,但是这种牺牲是可接受的,因为HDFS是数据密集,不是元数据密集。NameNode重启时,它会选择最一致的FsImage和EditLog使用。
另一种减低故障的办法是使用HA。
快照
(略)
数据组织
数据block
HDFS的目的是支持大型文件。HDFS支持一次写入多次读取。一个典型的block大小是128MB。因此,HDFS文件按照128MB的大小分割,每个block可能分布在不同的节点上。
备份管道
客户端向HDFS文件写入数据时,如果备份因子是三,NameNode使用备份目标选择算法检索出一组DataNode。这个列表是可以存储副本的DataNode。客户端先向第一个DataNode写入数据,DataNode接收数据并将数据传输到列表中的第二个DataNode。第二个DataNode开始接收数据并继续传输数据到第三个DataNode。这样,数据通过管道从一个DataNode传输到下一个。
可访问性
(略)
空间回收
文件删除和恢复
如果开启了trash配置,从FS shell中删除的文件并不会立刻从HDFS中删除,HDFS将它移动到一个trash目录(每个用户都有自己的trash目录,/user/<username>/.Trash
)。只要文件还在trash目录中就可以快速恢复。
最近删除的文件移动到/user/<username>/.Trash/Current
目录中,每隔一段时间,HDFS会为这些文件创建检查点文件(/user/<username>/.Trash/<date>
)并删除旧检查点文件。
如果trash中的文件过期了,NameNode将这些文件从命名空间中删除。与文件关联的block被释放。删除文件和空间释放之间可能会有延迟。
下面是一个例子,首先创建两个文件:
$ hadoop fs -mkdir -p delete/test1
$ hadoop fs -mkdir -p delete/test2
$ hadoop fs -ls delete/
Found 2 items
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:39 delete/test1
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:40 delete/test2
然后删除test1,该文件会被移到Trash目录:
$ hadoop fs -rm -r delete/test1
Moved: hdfs://localhost:8020/user/hadoop/delete/test1 to trash at: hdfs://localhost:8020/user/hadoop/.Trash/Current
接着跳过Trash删除test2:
$ hadoop fs -rm -r -skipTrash delete/test2
Deleted delete/test2
现在可以查看Trash目录:
$ hadoop fs -ls .Trash/Current/user/hadoop/delete/
Found 1 items\
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:39 .Trash/Current/user/hadoop/delete/test1
降低备份因子
文件的备份因子降低后,NameNode选择可以删除的副本,在下次心跳检测时把信息发送给DataNode,之后DataNode删除block并释放空间。