Hadoop IO 特性详解（1）【数据完整性】

本文结合hadoop : the definitive guide精心而作，包含作者的心血，希望可以帮助大家理解一点hdfs的皮毛，足矣。（charles@xingbod.cn）

hadoop本身自带原始的数据IO操作，包括数据处理的完整，压缩等等。但是面对大数据集，还是需要特殊考虑，还包含hadoop tools中的一些组件，例如序列化框架，硬盘数据存储结构等。

因为数据要在HDFS中分散多处，那么，数据其实不应该有丢失或者损坏。但是，每个磁盘或者网络IO都有可能对读写操作引入错误，但数据变得更大。叠加起来的概率就会更加高。磁盘读写错误率与磁盘本身的状态有关，网络延迟或者故障等也会导致网络IO错误。

如果很难感受IO错误概率的影响，我们可以做一个简单的计算：

假设我们每一次的IO流量是1MB，每一次出现的概率是很低很低的，假设为1/10^7 对于普通磁盘和网络IO大概可以达到这个概率，平常用户单一操作并不会产生什么影响。当时大数据集处理500GB的时候，出现错误的概率：

R=1-(1-10^7)^500*1024=5%

由此可见，在我们传输500GB的时候，有5%的概率产生IO错误。

因此大数据处理的时候就应该仔细考虑这个问题。我们面临的不只是500GB，可能是500TB或者更多海量的数据。IO操作中对数据的校验操作是解决这个问题的一个不可或缺的方法。

常用的做法是在第一次进入系统的时候计算数据校验和。校验和（Checksum）是冗余校验的一种形式。 它是通过错误检测方法，对经过空间（如通信）或者时间（如计算机存储）传送的数据的完整性进行检查的一种简单方法。计算机领域常见的校验和的方法有循环冗余校验（CRC）、MD5、SHA家族等。当传输结束时，接收者可以根据这个数值判断是否接到了所有的数据。如果数值匹配，那么说明传送已经完成。

例如上图，节点1和节点2之间进行文件传输，node1写文件到Node2,Node2收到数据的时候就会进行校验，如果Node1中的checksum和Node2中的不一样，就说明文件传输中被损坏，就会马上抛出checksum exception.这个checksum excepion属于IOException的一个子类。

每一校验的文件的大小默认是512字节，这是由系统默认设置的，也可以人工设置为其他的值（io.bytes.per.checksum）.

以上的例子是节点之间或者客服端可节点之间的网络传输的校验。另外一个校验的地点发生在数据节点上面，也就是节点本地系统。数据节点data node维护一个连续的校验和验证日志，他知道每个数据块最后的验证时间，出了与client进行验证，每个节点还会在后台运行datablockscanner，这个程序用来检验存在节点上的所有的数据块，防止bit rot的产生。

bit rot在这里指的是，存储在磁盘中的 数据的 性能和完整性的缓慢变化。

由于HDFS存在至少三个副本，在client进行数据操作，发现数据块校验失败之后，抛出checksu exception，就会报告这个数据块以及他的这个数据节点，名称节点会标记这个 节点上的这个数据块为损坏，组织进行修复。

在本地文件系统里面的校验和是怎么体现出来的呢？校验和保存在哪里？校验和对应的数据块大小改变了怎么办？

其实在hdfs中，在同一个文件夹下面包含每一个文件的校验和，譬如：

文件的名字是filename,

那么

校验文件就是.filename.crc

校验文件包含校验值以及校验文件的大小等信息。因此即使系统中的文件块大小改变，还是可以通过校验文件，读取到校验码对应的文件块大小以及文件块。

当然，除了校验文件保证文件没有出现错误之外，我们还要考虑另外一个问题，大量的数据导致大量的存储需求，因此我们面临着压缩和解压缩，编码和解码的需求压力。hadoop要怎么解决这个问题，下一篇文章我会用代码来说明这个问题。

文件校验以后有机会也会贴出源代码讨论，看机缘吧。

Charles 于2015-12-21 Phnom Penh

---

版权说明：

本文由Charles Dong原创，本人支持开源以及免费有益的传播，反对商业化谋利。

CSDN博客：http://blog.csdn.net/mrcharles

个人站：http://blog.xingbod.cn

EMAIL：charles@xingbod.cn