劉涌　韓偉　趙靜雅

摘要：Hadoop在存儲(chǔ)數(shù)據(jù)的過程中，首先要保證的就是數(shù)據(jù)的完整性，通常，Hadoop是根據(jù)由數(shù)據(jù)計(jì)算出的校驗(yàn)和進(jìn)行數(shù)據(jù)驗(yàn)證的，從而保證數(shù)據(jù)的完整性，為了達(dá)到持續(xù)保持完整性的目的，Hadoop會(huì)分別在I/O過程中和利用定時(shí)掃描程序驗(yàn)證數(shù)據(jù)并具備一套完善的糾正機(jī)制；在此前提下，通過文件的壓縮，Hadoop可以有效地減少文件占用的空間并提高文件傳輸速度，相關(guān)的壓縮算法有bzip2和LZO等。

關(guān)鍵詞：Hadoop；HDFS ；I/O ；壓縮

中圖分類號(hào)：TP311 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2018）15-0239-01

1 引言

Hadoop用戶都希望自己的數(shù)據(jù)在存儲(chǔ)和調(diào)用的過程中，不會(huì)丟失或損壞，盡管磁盤和網(wǎng)絡(luò)中的每個(gè)I/O操作在讀寫過程中發(fā)生錯(cuò)誤的情況非常少，但當(dāng)系統(tǒng)中需要處理的數(shù)據(jù)量達(dá)到Hadoop的處理極限時(shí)，數(shù)據(jù)的誤碼率會(huì)明顯升高。

檢測(cè)數(shù)據(jù)是否損壞的主要手段是通過校驗(yàn)和的方式去驗(yàn)證數(shù)據(jù)：在數(shù)據(jù)產(chǎn)生時(shí)可根據(jù)相應(yīng)協(xié)議對(duì)數(shù)據(jù)進(jìn)行疊加相加的操作計(jì)算出初始校驗(yàn)和，當(dāng)數(shù)據(jù)通過一個(gè)不可靠通道到達(dá)目的地址后使用相同的方法計(jì)算校驗(yàn)和，將兩次校驗(yàn)和結(jié)果匹配比較，如果結(jié)果為不匹配則證明數(shù)據(jù)已經(jīng)損壞，反之則說明數(shù)據(jù)極有可能是正常傳輸?shù)臄?shù)據(jù)。

2 HDFS的數(shù)據(jù)完整性

HDFS會(huì)對(duì)所有寫入的數(shù)據(jù)進(jìn)行校驗(yàn)和計(jì)算，并在讀取時(shí)進(jìn)行校驗(yàn)和驗(yàn)證。它針對(duì)每個(gè)由io.bytes.per.checksum指定字節(jié)的數(shù)據(jù)計(jì)算校驗(yàn)和。默認(rèn)情況下是512Bytes，由于CRC-32循環(huán)冗余校驗(yàn)的校驗(yàn)和是32位，即4Bytes，所以存儲(chǔ)校驗(yàn)和的額外開銷低于1%。

Hadoop通過校驗(yàn)和驗(yàn)證數(shù)據(jù)的過程與其他系統(tǒng)中校驗(yàn)和的應(yīng)用并沒有本質(zhì)的不同：數(shù)據(jù)節(jié)點(diǎn)DataNode在收到數(shù)據(jù)后存儲(chǔ)數(shù)據(jù)并驗(yàn)證校驗(yàn)和，正在寫數(shù)據(jù)的客戶端將數(shù)據(jù)機(jī)器校驗(yàn)和發(fā)送到由一系列DataNode組成的管線，管線中最后一個(gè)DataNode負(fù)責(zé)驗(yàn)證校驗(yàn)和，如果檢測(cè)到校驗(yàn)和不匹配，客戶端會(huì)收到一個(gè)ChecksumException異常，它是IOException異常的一個(gè)子類，后者會(huì)以應(yīng)用程序特定的方式進(jìn)行響應(yīng)處理，如重新發(fā)送等。

反之，在客戶端從DataNode中讀取數(shù)據(jù)時(shí)，也會(huì)驗(yàn)證校驗(yàn)和，將他們與DataNode中存儲(chǔ)的校驗(yàn)和進(jìn)行比較，每個(gè)DataNode都持續(xù)保存一個(gè)用于驗(yàn)證的校驗(yàn)和日志persistent log of checksum verification，當(dāng)客戶端成功驗(yàn)證校驗(yàn)和后，DataNode也會(huì)更新該日志， 確保數(shù)據(jù)和校驗(yàn)和均保持最新的確認(rèn)正確狀態(tài)。

要徹底持久的保持?jǐn)?shù)據(jù)的完整性，除了在I/O過程中均進(jìn)行驗(yàn)證外，還要防止小概率事件的發(fā)生，即每個(gè)DataNode都會(huì)在后臺(tái)運(yùn)行一個(gè)DataBlockScanner，定期掃描驗(yàn)證存儲(chǔ)在DataNode上的所有數(shù)據(jù)塊，從而保證已經(jīng)存儲(chǔ)的數(shù)據(jù)不會(huì)因?yàn)槲锢泶鎯?chǔ)媒介的原因造成數(shù)據(jù)的損失。

HDFS存儲(chǔ)著每個(gè)數(shù)據(jù)塊的復(fù)本，DataNode通過上述過程及時(shí)的發(fā)現(xiàn)數(shù)據(jù)的損壞，利用ChecksumException報(bào)警，將該數(shù)據(jù)塊復(fù)本標(biāo)記為已損壞，暫時(shí)屏蔽這個(gè)復(fù)本的I/O操作，之后，安排該數(shù)據(jù)塊的一個(gè)其他復(fù)本復(fù)制到另一個(gè)DataNode，最終將已損壞的數(shù)據(jù)塊復(fù)本刪除，從而保持所有數(shù)據(jù)的完整性。

3 壓縮與切分

對(duì)文件進(jìn)行壓縮，不僅可以減少存儲(chǔ)文件所需占用的磁盤空間，還可以提高文件在網(wǎng)絡(luò)和磁盤中傳輸?shù)乃俣?，因此，在Hadoop中數(shù)據(jù)文件的壓縮尤為重要，常見的壓縮格式有：deflate、gzip、bzip2、LZO、LZ4、Snappy等。

所有的壓縮算法都需要在速度與壓縮率之間權(quán)衡，提高壓縮、解壓縮速度，通常就意味著無法進(jìn)行復(fù)雜的壓縮，即能壓縮減少的空間很少，因此，所有壓縮工具都提供9級(jí)不同程度的壓縮參數(shù)供使用者自由選擇，選項(xiàng)-1為優(yōu)化壓縮速度，選項(xiàng)-9為優(yōu)化壓縮空間。不同的壓縮工具的壓縮性能不同：bzip2的壓縮能力比gzip強(qiáng)，但壓縮速度稍慢于后者，盡管bzip2本身的解壓速度比壓縮速度快，但仍比其他壓縮格式要慢一些；LZO、LZ4和Snappy的壓縮速度都比gzip高一個(gè)數(shù)量級(jí)，但壓縮效率稍遜一籌；而LZ4和Snappy的解壓速度比LZO高很多。

上述壓縮算法中僅有bzip2可切分，如果LZO文件已經(jīng)在預(yù)處理過程中被索引，則LZO文件是可切分的。是否支持切分，決定了是否可以搜索數(shù)據(jù)流的任意位置并進(jìn)一步往下讀取數(shù)據(jù)，這種特性尤其適合MapReduce。在Hadoop中，使用這兩種支持切分的壓縮格式要比在應(yīng)用中將文件切分成塊，再為每個(gè)數(shù)據(jù)塊進(jìn)行壓縮至大小近似于HDFS塊的大小的效率更高； 如果想要進(jìn)一步提高效率，可以使用順序文件、RCFile或Avro等同時(shí)支持壓縮和切分的文件格式，最好再與一個(gè)快速壓縮工具聯(lián)合使用，如LZO、LZ4或Snappy等。當(dāng)然，以上三種手段都比不壓縮文件直接存儲(chǔ)的效率更高。

4 結(jié)束語(yǔ)

Hadoop中處理的數(shù)據(jù)往往動(dòng)輒好幾個(gè)TB，在這種情況下，既要保證數(shù)據(jù)的正確性和完整性，又要考慮數(shù)據(jù)占用的空間盡可能小，存儲(chǔ)和運(yùn)行數(shù)據(jù)塊的速度盡可能快，因此，對(duì)Hadoop中的I/O操作進(jìn)行分析優(yōu)化就顯得十分有必要，本文僅就上述幾方面進(jìn)行了簡(jiǎn)述，關(guān)于I/O相關(guān)工作，還有很大的發(fā)展空間，具有廣闊的開發(fā)前景。

參考文獻(xiàn)：

[1] 張子凡. OpenStack部署實(shí)踐[M].北京：人民郵電出版社，2014：1-364.

[2] 鮑亮，李倩. 實(shí)戰(zhàn)大數(shù)據(jù)[M].北京：清華大學(xué)出版社，2014：1-327.

[3] 吳萍，朱晴婷. 算法與程序設(shè)計(jì)基礎(chǔ)（Python版）[M].北京：清華大學(xué)出版社，2015：30-270.