Hadoop 提供了一組原始的數據IO，這些都是比Hadoop更爲通用的技術，比如數據一致性、壓縮等。但是值得考慮的是處理TB級的數據。
數據一致性（Data Integrity）
在數據存儲和處理期間，用戶不希望發生數據的丟失或中斷的情況，然而在磁盤或網絡上讀寫數據難免發生錯誤，並且發生的機率較高。
檢測數據是否損壞的常用方式是當數據第一次進入系統時計算數據的校驗和（checksum），在傳輸完成後再次計算校驗和，如果兩次計算的校驗和不相等，則認爲數據是損壞的。但是這項技術並不能修復數據，僅只能用來數據錯誤檢測。此外也有可能是校驗和本身損壞了，而不是數據，但這是很不可能的，因爲校驗和的大小比數據的大小要小很多。
常用的錯誤檢測碼是CRC-32（32位循環冗餘檢測），它對任意大小的數據計算，結果爲一個32位整數的校驗和。它被用於Hadoop文件系統的校驗，HDFS做了些高效的改進稱之爲CRC-32C。
HDFS的數據一致性
HDFS默認對所有數據的寫入和讀取做校驗和。datanode節點負責在數據存入前對接收到的數據進行校驗，並保存校驗和。一個客戶端寫數據發送到datanode節點的管道，管道中的最後一個節點負責做計算數據的校驗和，如果檢測到錯誤，客戶端將接收到一個IOException，通常客戶端將採取特定的方式做處理（比如，重新發送數據）。
當客戶端從datanode節點中讀取數據，同樣需要驗證校驗和，和存儲在datanode節點中的校驗和做對比。每個datanode節點都保存着檢驗和的驗證日誌，所以知道每個數據塊的最後驗證時間。當客戶端校驗成功，它會告訴datanode更新日誌。在檢測壞的數據塊方面統計這些日誌是值得的。
除了在客戶端讀取時驗證塊之外，每個datanode還運行了一個DataBlockScanner後臺進程來定期檢測存儲的所有數據塊，這主要是防止在物理存儲介質中的“循環”。
因爲HDFS保存着塊的副本，它可以通過複製沒有損壞的副本，產生一個新的完整的數據塊來恢復損壞的塊。這種方式的工作機制是如果客戶端在讀取一個數據塊時檢測到錯誤，它將報告給datanode 節點，然後datanode節點在拋出CheckSumException異常之前會告訴namenode節點，namenode節點將改塊標記爲已損壞，不再允許其它任何客戶端或者試圖要複製此塊的datanode節點訪問它，然後它將複製塊的副本到其它節點，這樣複製因子就回到了的原來的水平。一旦操作完成，損壞的數據塊將被刪除。
在FileSystem上調用open方法讀取文件之前可以通過傳遞false給setVerifyChecksum()方法來禁用校驗和的驗證，另外還可以通過使用-ignoreCrc選項或使用-copyToLocal命令來禁用。
Compression
文件壓縮有兩個好處：一是它降低了文件的存儲空間，而是它加快了文件在網絡或磁盤上傳輸。當處理海量數據時，這些節省將會很有意義。所以，需要仔細考慮在Hadoop中怎樣使用壓縮。
Hadoop中有多種不同的壓縮格式、工具和算法，每一個都有其特徵。如下圖一些常用的壓縮方式：
所有的壓縮算法都要權衡空間和時間：更快的壓縮或解壓縮通常佔用的空間較大。上圖中不同的壓縮方式有很大不同的特性。gzip是一個比較常用的壓縮方式，它在空間和時間權衡中出於中間位置。bzip2比gzip更有效的壓縮，但是壓縮速度較慢，bzip2解壓縮比其壓縮速度要快，但是它仍慢於其它的壓縮方式。LZO、LZ4和Snappy三者的壓縮速度要比gzip快一個數量級，但是它們的壓縮低效。Snappy和LZ4在解壓縮方面要比LZO塊很多。
上圖表格中的“Splittable”列表示壓縮格式是否支持分割（也就是說，你可以在流中查找任何點來開始讀取）。可分割的壓縮格式非常適合MapReduce。