hdfs 数据一致性

转载地址：http://www.wubiaoblog.com/archives/984

HDFS以流式数据访问模式来存储文件，运行于大量硬件集群上。个人觉得，HDFS被设计成为支持AP，并具有最终一致性（简单一致性模型）。为什么呢？因为在集群系统中P是必须的，而HDFS对文件采用一次写入多次读入的逻辑设计，不支持文件并发写入、不支持文件修改。所以高可用性对HDFS来说至关重要的！

 

为实现高可用性，HDFS采用诸多策略，包括：

• 冗余副本策略
• 机架策略
• 心跳机制
• 安全模式
• 校验和
• 回收站
• 元数据保护
• 快照机制

 

本文有部分参考：《Hadoop权威指南》及http://jenmhdn.iteye.com/。

 

冗余副本策略

HDFS存储数据的节点是使用大量的廉价设备，这就意味着这些设备会时不时的出点问题，也就是说我们面临着数据节点的失效问题，并且这种失效会经常发生，比如一台机器3年坏一次，如果有上千台机器的话，每天都会有机器坏掉。

HDFS处理节点失效的一个方法就是数据冗余，即对数据做多个备份，在HDFS中可以通过配置文件设置备份的数量，如果不进行设置，这个数量默认为3。

 

注意参数dfs.replication.min和dfs.replication的区别：在一个块被写入期间，只要至少写入了dfs.replication.min个副本数（默认是1），写操作就会成功，直到达到其目标副本数dfs.replication（默认是3）。

 

心跳机制

检测节点失效使用“心跳机制”。每个 Datanode 节点周期性地向 Namenode 发送心跳信号。网络分区可能导致一部分 Datanode 跟 Namenode 失去联系。 Namenode 通过心跳信号的缺失来检测这一情况，并将这些近期不再发送心跳信号 Datanode 标记为宕机，不会再将新的 IO 请求发给它们。

 

任何存储在宕机 Datanode 上的数据将不再有效。Datanode 的宕机可能会引起一些数据块的副本系数低于指定值， Namenode 不断地检测这些需要复制的数据块，一旦发现就启动复制操作。在下列情况下，可能需要重新复制：某个 Datanode 节点失效，某个副本遭到损坏，Datanode 上的硬盘错误，或者文件的冗余因子增大。

 

机架策略

通常，大型 Hadoop 集群是以机架的形式来组织的，同一个机架上不同节点间的网络状况比不同机架之间的更为理想。Namenode 设法将数据块副本保存在不同的机架上以提高容错性。

 

HDFS又是如何得知哪个Datanode在哪个机架上呢？HDFS使用了一种称为“机架感知”的策略。HDFS不能够自动判断集群中各个 Datanode 的网络拓扑情况，必须通过配置 dfs.network.script 参数来确定节点所处的机架。文件提供了 IP->rackid 的翻译，NameNode 通过这个得到集群中各个 Datanode 节点的 rackid。

 

有了机架感知， Namenode 就可以知道图所示的Datanode 网络拓扑图。D1,R1 都是交换机，最底层是 datanode 。则 H1 的 rackid=/D1/R1/H1，H1的parent 是R1，R1 的是D1。

 

安全模式

Namenode 启动后会进入一个称为安全模式的特殊状态。处于安全模式的Namenode对于客户端来说是只读的。Namenode 从所有的Datanode 接收心跳信号和块状态报告（blockreport）。

 

每个数据块都有一个指定的最小副本数（dfs.replication.min），当 Namenode 检测确认某个数据块的副本数目达到这个最小值，那么该数据块就会被认为是副本安全 (safely replicated)的。

 

在一定百分比（这个参数配置于dfs.safemode.threshold.pct，默认值是99.9%）的数据块被 Namenode 检测确认是安全之后，再过若干时间后（这个参数配置于dfs.safemode.extension，默认值是30秒）， Namenode 将退出安全模式状态。接下来Namenode会确定还有哪些数据块的副本没有达到指定数目，并将这些数据块复制到其他 Datanode上。

 

校验和

HDFS会对写入的所有数据计算校验和（checksum），并在读取数据时验证。Datanode在收到客户端的数据或者复制其他Datanode的数据时，在验证数据后会存储校验和。正在写数据的客户端将数据及其校验和发送到由一系列Datanode组成的管线，管线中的最后一个Datanode负责验证校验和。如果Datanode检测到错误，客户端便会收到一个ChecksumException。

 

客户端从Datanode读取数据时，也会验证校验和，将它们与Datanode中存储的校验和进行比较。每个Datanode均持久保存一个用于验证的校验和日志，所以它知道每个数据块的最后一次验证时间。客户端成功验证一个数据块后，会通知这个Datanode更新次日志。

 

此外，每个Datanode也会在一个后台运行一个称为DataBlockScanner的进程定期验证存储在这个Datanode上的所有数据块。检测到错误后，Namenode将这个已损坏的数据块标记为已损坏，之后从其他Datanode复制此数据的副本，最后使得数据的副本达到指定数目。

 

回收站

当用户或应用程序删除某个文件时，这个文件并没有立刻从 HDFS 中删除。实际上， HDFS 会将这个文件重命名转移到 /trash 目录。只要文件还在/trash 目录中，该文件就可以被迅速地恢复。

 

文件在 /trash 中保存的时间是可配置的（配置参数fs.trash.interval），当超过这个时间时， Namenode 就会将该文件从命名空间中删除。 删除文件会使得该文件相关的数据块被释放。注意，从用户删除文件到 HDFS 空闲空间的增加之间会有一定时间的延迟。

 

元数据保护

FsImage 和 Editlog 是 HDFS 的核心数据。如果这些文件损坏了，整个HDFS都将失效。因而， Namenode 可以配置成支持维护多个 FsImage 和Editlog 的副本。任何对 FsImage 或者 Editlog 的修改，都将同步到它们的副本上。这种多副本的同步操作可能会降低 Namenode 每秒处理的名字空间事务数量。然而这个代价是可以接受的，因为即使 HDFS 的应用是数据密集的，它们也非元数据密集的。当 Namenode 重启的时候，它会选取最近的完整的FsImage 和Editlog 来使用。不过，Namenode是依然HDFS集群中单节点。如果 Namenode 节点发生故障，需要手工切换。

 

快照机制

快照支持某一特定时刻的数据的复制备份。利用快照，可以让 HDFS 在数据损坏时恢复到过去一个已知正确的时间点。 HDFS 目前还不支持快照功能，但计划会在将来的版本支持。