数据完整性
Hadoop用户肯定都希望系统在存储和处理数据时不会丢失或损坏任何数据。尽管磁盘或网络上的每个I/O操作不太可能将错误引入自己正在读/写的数据中，但是如果系统中需要处理的数据量大到Hadoop的处理极限时，数据被损坏的概率还是很高的。
检测数据是否损坏的常见措施是，在数据第一次引入系统时计算校验和（checksum）并在数据通过一个不可靠的通道进行传输时再次计算校验和，这样就能发现数据是否损坏。如果计算所得的新校验和与原来的校验和不匹配，我们就认为数据已损坏。但该技术并不能修复数据——它只能检测出数据错误。（这正是不使用低端硬件的原因。具体说来，一定要使用ECC内存。）注意，校验和也是可能损坏的，不只是数据，但由于校验和比数据小得多，所以损坏的可能性非常小。
常用的错误校验码是CRC-32（循环冗余校验），任何大小的数据输入均计算得到一个32位的证书校验和。
HDFS的数据完整性
HDFS会对写入的所有数据计算校验和，并在读取数据时验证校验和。它针对每个由io.bytes.per.checknum指定字节的数据计算校验和。默认情况下为512个字节，由于CRC-32校验和是4个字节，所以存储校验和的额外开销低于1%
DataNode负责在收到数据后存储该数据及验证校验和。它在收到客户端的数据或复制其他DataNode的数据时执行这个操作。正在写数据的客户端将数据及其校验和发送到由一系列DataNode组成的管线，管线中最后一个DataNode负责验证校验和。如果DataNode检测到错误，客户端便会收到一个ChecksumException异常，它是IOException异常的一个子类，后者应以应用程序特定的方式来处理，比如重试这个操作。
客户端从DataNode读取数据时，也会验证校验和，将它们与DataNode中存储的校验和进行比较。每个DataNode均持久保存有一个用于验证的校验和日志(persistent log of checksum verification)，所以它知道每个数据块的最后一次验证时间。客户端成功验证一个数据块后，会告诉这个DataNode，DataNode由此更新日志。保存这些统计信息对于检测损坏的磁盘很有价值。
不只是客户端在读取数据块时会验证校验和，每个DataNode也会在一个后台线程中运行一个DataBlockScanner，从而定期验证存储在这个DataNode上的所有数据块。该项措施是解决物理存储媒体上位损坏的有力措施。
由于HDFS存储着每个数据块的复本(replica),因此它可以通过数据复本来修复损坏的数据块，今儿得到一个新的完好无损的复本。基本思路是，客户端在读取数据块时，如果检测到错误，首先向namenode报告已损坏的数据块及其正在尝试读操作的这个DataNode，再抛出ChecksumException异常。Namenode将这个数据块复本标记为已损坏，因此，它不会将处理请求直接发送到这个节点，或尝试将这个复本复制到另一个DataNode。之后，它安排这个数据块的一个复本复制到另一个DataNode，如此一来，数据块的复本因子(replication factor)又回到期望水平。伺候，已损坏的数据块复本便被删除。
在使用open()方法读取文件之前，将false值传递给FileSystem对象的setVerifyChecksum()方法，即可以禁用校验和验证。如果在命令解释器中使用带-get选项的-ignoreCrc命令或者使用等价的-copyToLocal命令，也可以达到相同的效果。如果有一个已损坏的文件需要检查并决定如何处理，这个特性是非常有用的。