HDFS体系结构

1.HDFS体系结构

1.1介绍

1.2假设和目标

1.3 NameNode 和 DataNode

1.4 文件系统命名空间

1.5 数据复制

1.5.1 Replica Placement: The First Baby Seteps

1.5.2 副本选择

1.5.3 安全模式

1.6 文件系统元数据保存

1.7 The Communication协议

1.8 Robustness

1.8.1 Data Disk Failure, Heartbeats and Re-Replication

1.8.2 Cluster Rebalancing

1.8.3 数据完整性

1.8.4 元数据磁盘错误

1.8.5 快照

1.9 数据组织

1.9.1 数据块

1.9.2 复制流水

1.10 可访问性

1.10.1 FSShell

1.10.2 DFSAdmin

1.10.3 浏览器接口

1.11 空间回收

1.11.1文件删除和不删除

1.11.2 减少复制数量

1.12 Reference

1.HDFS体系结构

1.1介绍

HDFS是分布式文件系统，运行在商用的硬件环境上。和其他的分布式文件系统相似。但是也有不同，HDFS是高度容错的并且设计用来部署在低成本的硬件上。HDFS提供高吞吐量，比较适合大数据的应用。HDFS释放POSIX来启动流方式的访问文件系统数据。HDFS原来是Apache Nutch网页搜索引擎的底层服务。HDFS是Apache Hadoop Core项目的一部分。

1.2假设和目标

略

1.3 NameNode和 DataNode

HDFS有Master Slave体系结构。HDFS集群包含一个NameNode，master服务管理文件系统命名空间和控制client访问。另外有一些Datanodes，通常Cluster中一个node有一个datanode。用来管理node的空间。HDFS暴露文件系统命名空间允许用户数据保存在文件中。在内部，文件会被分为多个块并且这些块被保存在一些datanode上。Namenode执行文件系统命名空间操作，比如打开，关闭，重命名文件和目录。也决定了datanode 的块映射。Datanode为client读写请求服务。Datanode也执行block的创建，删除，根据namenode的指令复制。

Namenode和datanode是软件的一部分。HDFS使用java开发，任何支持java的设备都可以运行namenode和datanode。部署通常有一个专用的机器用来执行namenode。其他的设备运行datanode。当然也可以在一个设备上运行多个datanode，但是一般很少出现。

1.4 文件系统命名空间

HDFS支持传统的分层的文件组织，一个用户或者应用程序创建目录，文件存在这些目录中。文件系统命名空间分层和其他现有的文件系统类似。可以创建，删除文件，移动文件，重命名文件。HDFS支持用户配额和访问权限。HDFS不支持硬链接或者软连接。但是HDFS不排除这些功能的实现。

Namenode维护文件系统的命名空间。任何修改文件系统命名空间或者属性都被记录在Namenode里面。一个引用程序可以指定一个文件多个副本维护在HDFS里面。这些信息也放在namenode里面。

1.5 数据复制

HDFS设计用来保存大文件到一个大集群上。每个文件都以顺序的块存储。块被复制用来容错。块的大小和复制参数可以为每个文件配置。文件中的所有的块大小都是一样的,while users can start a new block without filling out the last block to the configured block size after the support for variable length block was added to append and hsync.

应用可以指定文件的副本个数。复制参数可以在文件创建的时候创建，之后可以修改。HDFS的文件是write-once(除了append和truncate)，并且在任何时间都是严格的1个writer。

Namenode决定所有的关于复制的块。定期会接收一个心跳和一个block report。接受一个心跳表示datanode还活着，block report表示datanode的所有block。

1.5.1 Replica Placement: The First Baby Seteps

副本的安置对HDFS的可靠性和性能来说是很重要的。优化副本的安置是HDFS和其他分布式文件系统的区别。这个特性需要有很多的经验和调整。目的是机架级别的安置策略，用来提高数据可靠性，可用性和网络带宽利用。

对于很大的HDFS集群来说，通常会传播到很多机架。不通机架间的node交互需要路过交换机。在很多情况下同一个机架下的网络带宽比不通机架下的设备带宽搞。

Namenode为每个datanode决定rackid，通过Hadoop Rack Awareness来识别。一个最简单的策略是把副本放到不通的机架下面。这样如果整个机架错误了允许使用其他的机架下的数据。这个策略均匀的把副本分布到集群，可以很简单的让它在出现错误的时候来均衡。但是这个策略增加了写入的开销，因为要写入到多个机架下。

对于最通常的例子，复制参数是3，HDFS放置策略是如果writer在本地，那么放在本地也就是写入的那个datanode，否则随机随机选择一个datanode，第二个放在一个不通的机架下的datanode上。第三个放在相同的机架的不通datanode下。这个策略减小了机架间的传输，提高了写入性能。机架出现故障的概率远小于一个node出现错误的概率，这个策略不影响可靠性和可用性的保证。但是减少了网络带宽的使用，因为一个block只在2个机架中，而不是3个机架。但是这个策略不能让数据均匀的分布。1/3的副本在一个node中，2/3的副本在一个机架下，其他剩下的均匀的分布在剩下的机架下。这个策略提高了写入性能并没有和可靠性和读性能冲突。

如果副本参数大于3，那么第4个副本或者之后的副本是随机存放的，但是每个机架存放副本的个数有个上限，(replicas - 1) / racks + 2。

因为namenode不允许datanode拥有同一个block的多个副本，副本的最大个数，就是datanode 的个数。

Storage Types and Storage Policies支持了之后，namenode除了Rack awareness之外，还考虑了这个策略。Namenode选择node先基于rack awareness，然后检查候选node的存储需求。如果候选node没有storage type，namenode会查看其它node。如果在第一个path的node不够，那么namenode在第二个path查找storage path。

1.5.2 副本选择

为了最小化带宽和读延迟，HDFS会尝试从最近的一个副本上读取。如果在同一个机架上面有一个可读副本，这个副本是被读取的首选。如果HDFS集群跨了多个数据中心，那么本地的数据中心会被首选。

1.5.3 安全模式

在startup的时候，namenode会进入特别的状态叫做safemode。在safemode下，数据块的复制是不会发生的。Namenode从datanode上接受到心跳和blockreport。Blockreport包含了datanode拥有的所有block。每个block有个副本的最小值。一个block如果在namenode中被检查完后，那么就认为是安全的。如果安全率到达某个值，那么namenode就退出安全模式。如果发现有一些数据块的副本不够，那么就会创建这些数据库的副本。

1.6 文件系统元数据保存

HDFS的命名空间保存在namenode上。Namenode使用事务日志叫editlog来保存记录的修改。比如创建一个新的文件，namenode就会插入一条记录到editlog。同样的修改复制参数也会在editlog上创建一条机滤。Namenode在系统的文件系统上保存editlog。整个文件系统的命名空间，包括block和文件的映射，文件系统的属性。都被保存在fsimage中。Fsimage也被保存在本地文件系统上。

Namenode在内存中，保存了整个文件系统命名空间和文件block map的快照。当namenode启动，或者出发checkpoint，就会从磁盘中把fsimage和editlog读出来，应用所有editlog上的事务，到内存中的fsimage，然后重新刷新到磁盘中的fsimage。然后可以截断，因为已经被应用到磁盘fsimage。这个过程叫checkpoint。目的是保证HDFS有一致性的文件系统元数据。尽管读取fsimage速度很快，但是增量的直接修改fsimage并不快。我们不直接修改fsimage，而是保存在editlog中。在checkpoint的时候然后应用的fsimage上。Checkpoint的周期可以通过参数dfs.namenode.checkpoint.period 指定时间间隔来触发，也可以使用dfs.namenode.checkpoint.txns指定多少个事务之后触发。如果都设置了，那么第一个触发就会checkpoint。

HDFS数据在datanode中以文件的方式被保存在本地文件系统上。Datanode不会在意HDFS文件。HDFS数据每个block一个文件保存在本地文件系统上。Datanode不会把所有的文件都放在一个目录下面。而是使用一个启发式结构来确定，每个目录的最优文件个数，并且适当的创建子目录。当datanode启动，会扫描本地文件系统，生成一个HDFS的列表，并且发送给namenode。这个report叫blockreport。

1.7 The Communication协议

所有HDFS交互协议都是基于tcp/ip的client创建一个连接到namenode机器。使用clientprotocol和namenode交互，datanode使用datanode protocol和namenode交互。Namenode并不开启任何RPC。只是对datanode 和client的反应。

1.8 Robustness

尽管存在错误，HDFS保存数据还是可靠的。一下是一些namenode错误，datanode错误和网络分区。

1.8.1 Data Disk Failure, Heartbeats and Re-Replication

每个datanode会发送心跳信息到namenode。网络分区会导致子网的datanode和namenode 的连接中断。Namenode通过心跳信息来发现。Namenode把没有收到心跳信息的node标记为死亡，并且发送新的IO请求到这个node。任何数据在死亡的datanode不在对HDFS可用。Datanode 的死亡会导致一些block的复制参数少于指定的值。Namenode会不间断的跟踪这些需要复制的block，并且在有需要的时候启动复制。需要重新复制的理由可能很多：datanode变的不可用，副本损坏，datanode所在的硬件损坏，或者复制参数增加。

1.8.2 Cluster Rebalancing

HDFS结构兼容数据再平衡框架。如果一个datanode的空闲超过了阀值，一个框架可能把数据从一个datanode移动到另外一个。如果一个特定的文件请求特别高，框架会动态的创建副本并且再平衡数据。数据再平衡目前没有实现。

1.8.3 数据完整性

一个block的数据出现损坏是很有可能的。出现损坏，可能是磁盘问题，网络问题或者有bug。HDFS客户端软件实现了checksum检查HDFS文件的内容。当一个客户端创建了HDFS文件。会为每个block计算checksum并且保存在在同一个命名空间下，独立的隐藏文件下。当client获取文件内容，需要验证每个datanode的checksum和checksum文件中的一致。如果不一致，从副本上获取。

1.8.4 元数据磁盘错误

Fsiamge和editlog是HDFS结构的核心。如果出现损坏，会导致HDFS实例无法运行。因为这个可以配置fsimage和editlog多个副本。任何更新fsimage和editlog会同步的更新副本。同步的更新fsiamge和editlog可能会导致性能问题。然而还是可以接受的，因为HDFS是数据敏感而不是元数据敏感的。当namenode重启会选择最新的fsimage和editlog使用。

另外一个选项是使用多namenode启动HA，或者使用NFS共享存储，分布式的editlog。

1.8.5 快照

快照是被支持的。快照的一个用处是修复HDFS。

1.9 数据组织

1.9.1 数据块

HDFS被设计用来支持非常大的文件。应用使用HDFS来处理这些文件。这些应用只写一次但是要读很多次。HDFS支持write-once-read-many。通常HDFS block大小是128MB。因此HDFS会被切成128MB的块。

1.9.2 复制流水

当client写数据到HDFS，并且复制参数是3，namenode会获取datanode的一个列表使用复制选择算法。这些列表包含了datanode 的副本block。Client然后写入第一个datanode。第一个datanode一部分一部分的接受数据，把每个部分写到本地的存储库中并且把这部分传输到list中的第二个datanode。第二个datanode，一样接受数据，然后存储到本地存储库，然后传输到第三个datanode。第三个datanode，接受数据保存到本地存储库。因此数据是以pipeline的方式从一个到另外一个。

1.10 可访问性

HDFS可以以不同的方式被访问。最原始的使用java 的API。也可以使用http浏览器。HDFS可以被mount到client本地文件系统。

1.10.1 FSShell

HDFS允许用户数据以目录和文件的方式组织。提供了命令行借口FSShell可以让用户和HDFS交互。语法和bash类似。

1.10.2 DFSAdmin

DFSAdmin命令主要用来管理HDFS集群。

1.10.3 浏览器接口

HDFS安装配置了web服务来暴露HDFS的命名空间。允许通过浏览器查看和定位文件。

1.11 空间回收

1.11.1文件删除和不删除

如果trash配置启用了，FSShell删除的文件并不会马上从HDFS上面删除。HDFS会把这些移动到trash目录中(/user/<username>/.Trash)。这样文件可以快速的恢复。

最近被删除的文件会被移动到当前的trash目录(/user/<username>/.Trash/Current),根据checkpoint的配置，HDFS为当前的删除创建checkpoint(/user/<username>/.Trash/<date>)，到期后会删除老的checkpoint。查看 expunge command of FS shell

到期之后，namenode会删除文件的元数据。删除后会导致相关的block被回收。例子如下：

创建2个文件

删除一个文件根据提示被移动到了trash目录

删除test2，但是跳过trash

最后只会看到trash中的一个文件

1.11.2 减少复制数量

当复制数量减少，namenode会选择多余的副本进行删除。在下一次心跳传输给datanode，datanode然后删除响应的块，释放空间。通过setReplication API设置到真正释放空间有延迟。

1.12 Reference

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

    本文转自 Fanr_Zh 博客园博客，原文链接：http://www.cnblogs.com/Amaranthus/p/8549950.html，如需转载请自行联系原作者