技術(shù)干貨 | 如何做Hadoop集群存儲規(guī)劃—HDFS篇

眾所周知，Hadoop的存儲組件有已經(jīng)存活了十二年之久的HDFS，問世三年而用戶寥寥的KUDU，以及來勢兇猛的新晉網(wǎng)紅Ozone。

KUDU雖然有和HDFS一樣的水平擴(kuò)展能力以及近似HBase的高效隨機(jī)讀寫能力，但受限于其功能局限性以及和其他軟件之間的兼容能力不強(qiáng)，因此目前主要作為存放"實(shí)時(shí)更新的，用來做快速分析的結(jié)構(gòu)化數(shù)據(jù)"的載體，這部分?jǐn)?shù)據(jù)量不會太大，比起HDFS中的數(shù)據(jù)應(yīng)該會小的多。

Ozone到目前剛剛推出了alpha 0.4.1版本，離正式release還有一段路要走，所以短期內(nèi)也只有小范圍的試用需求。

說到底，目前的存儲規(guī)劃還是要以HDFS為主。而對于HDFS，這里有幾個(gè)問題考量：

HDFS設(shè)計(jì)初衷是以多副本機(jī)制解決硬件的不可靠性，從而在節(jié)約硬件成本的情況下盡量提升數(shù)據(jù)的可用性與讀寫效率。HDFS通常默認(rèn)配置為3副本，結(jié)合HDFS的機(jī)架感知特性，3個(gè)副本通常按照如下分布：

在幾年前大數(shù)據(jù)產(chǎn)業(yè)發(fā)展伊始，企業(yè)中的數(shù)據(jù)量都還是”數(shù)據(jù)庫量級”的時(shí)候，數(shù)據(jù)庫軟件和專用存儲都非常昂貴，這樣做的確是最佳實(shí)踐，既降低了軟硬件的成本，還提高了數(shù)據(jù)的可用性。然而技術(shù)發(fā)展日新月異，在企業(yè)的大數(shù)據(jù)發(fā)展終于進(jìn)入”大數(shù)據(jù)量級”的時(shí)候，即便是普通廉價(jià)的工業(yè)磁盤也因?yàn)榧哼^大，數(shù)量太多產(chǎn)生了經(jīng)濟(jì)方面的壓力。

多副本機(jī)制是否有必要，是不是造成了存儲資源的浪費(fèi)？

Hadoop 3.X實(shí)現(xiàn)了EC碼(糾刪碼)機(jī)制，來減少數(shù)據(jù)存儲副本，提升數(shù)據(jù)的可用性。最簡單的EC碼是XOR編碼(異或操作碼)，它的原理如下：

異或操作(XOR-2-1- 1024k策略)

異或操作是將兩個(gè)數(shù)據(jù)塊做異或操作，生產(chǎn)一個(gè)校驗(yàn)碼，當(dāng)有一個(gè)數(shù)據(jù)庫丟失時(shí)，通過另一個(gè)數(shù)據(jù)塊或者校驗(yàn)碼計(jì)算出丟失的數(shù)據(jù)庫信息。這樣的話，兩個(gè)數(shù)據(jù)塊只需要一個(gè)校驗(yàn)碼塊就可以保障高可用性了，存儲的開銷從300%下降為150%。

這種情況是在只丟了一個(gè)數(shù)據(jù)塊的時(shí)候好用，那如果丟了兩個(gè)以上的數(shù)據(jù)塊呢？顯然異或操作就失效了。EC碼中的Reed-Solomon Codes編碼 (里德所羅門編碼，簡稱RS碼)是專門應(yīng)對這種情況的，RS碼通過線性代數(shù)里的矩陣運(yùn)算法則將多個(gè)數(shù)據(jù)塊(K個(gè)數(shù)據(jù)塊，即K階向量)與一個(gè)生成矩陣(Gt)相乘，得出一個(gè)包含包含K個(gè)數(shù)據(jù)塊和m個(gè)校驗(yàn)塊的新向量，在不超過m個(gè)塊(數(shù)據(jù)塊和校驗(yàn)塊)丟失的情況下，可以通過矩陣再次算出丟失的數(shù)據(jù)。RS碼在CDH中常用的有4種，分別是包括RS-3-2-1024k，RS-6-3-1024k，RS-10-4-1024k，RS-LEGACY-6-3-1024k，它們各自的存儲效率為：

RS碼策略存儲開銷

可以看出，使用了EC碼(無論是XOR碼還是RS碼)以后，存儲的開銷都從之前的300%下降到了150%左右，但是不是說EC糾刪碼代替原來的多副本機(jī)制就是更好的解決方案？或者說考慮使用磁盤陣列(RAID)的方式來提高數(shù)據(jù)可用性操作性更強(qiáng)？畢竟RAID方式也是使用了EC糾刪碼的原理(RAID5實(shí)現(xiàn)了XOR的機(jī)制允許壞掉一個(gè)副本，RAID6則實(shí)現(xiàn)了RS的機(jī)制允許壞掉2個(gè)副本)。

事情沒有這么簡單，多副本機(jī)制與EC糾刪碼碼機(jī)制相比，有以下特點(diǎn)：

多副本與EC碼

可以看出，EC糾刪碼雖然大大提升了磁盤利用率，但是其在數(shù)據(jù)恢復(fù)方面的表現(xiàn)是不太理想的，因?yàn)镋C糾刪碼的加密解密過程大大依賴于CPU的能力，而數(shù)據(jù)恢復(fù)過程中，又需要網(wǎng)絡(luò)傳輸大量的數(shù)據(jù)。

在同一個(gè)集群中，同一份數(shù)據(jù)要么配置EC糾刪碼機(jī)制，要么配置多副本機(jī)制，兩者是互斥的?；谶@么一個(gè)前提，有benchmark測試表明，在未發(fā)生數(shù)據(jù)故障時(shí)，配置了EC糾刪碼和多副本機(jī)制的HDFS讀寫效率基本一致，但在發(fā)生了數(shù)據(jù)恢復(fù)時(shí)，多副本機(jī)制的HDFS讀寫效率要比EC碼機(jī)制的讀寫效率快3-4倍。在數(shù)據(jù)量超大，CPU配置不高以及網(wǎng)絡(luò)帶寬有限的集群環(huán)境里，這也是相對致命的問題。

要不要使用磁盤陣列(RAID)的方式？

其實(shí)配置磁盤陣列與配置HDFS糾刪碼實(shí)現(xiàn)原理是一樣的，但是磁盤陣列只在單個(gè)節(jié)點(diǎn)生效，HDFS糾刪碼則針對整個(gè)集群生效。換句話說，即便配置了磁盤陣列，但是單個(gè)節(jié)點(diǎn)的服務(wù)器如果由于磁盤以外的其他原因故障了，那數(shù)據(jù)就丟失了，這個(gè)風(fēng)險(xiǎn)很大，因此使用HDFS糾刪碼要比單純使用磁盤陣列安全的多。

怎么選擇使用多副本機(jī)制還是EC糾刪碼？

通常建議熱數(shù)據(jù)較多，業(yè)務(wù)密集型的集群還是按照3副本機(jī)制進(jìn)行配置容量，而冷數(shù)據(jù)較多，以存放備份歸檔數(shù)據(jù)為主的集群可考慮以EC糾刪碼的方式來進(jìn)行配置容量，但是磁盤總?cè)萘坎粦?yīng)小于實(shí)際數(shù)據(jù)的大小的2倍。另外需要注意的是，使用EC糾刪碼只能在Hadoop 3.X以上的版本進(jìn)行。

HDFS上的數(shù)據(jù)可以啟用壓縮，通常這也是做存儲規(guī)劃時(shí)值得考慮的因素。對于一個(gè)在Hadoop發(fā)生的計(jì)算過程，以典型的MapReduce框架考慮，壓縮可以在三個(gè)階段處理：map任務(wù)階段，reduce任務(wù)階段，以及最終寫HDFS的階段。由于map任務(wù)階段和reduce任務(wù)階段主要是寫本地磁盤為主，因此主要考慮最后寫HDFS的階段的壓縮(spark等內(nèi)存計(jì)算引擎也只需要考慮最后寫HDFS的壓縮)。

HDFS支持的壓縮方式有Deflate,gzip,bzip2,LZO,LZOP,LZ4,Snappy幾種。他們的區(qū)別如下：

各種壓縮方式對比

以100M的常規(guī)文件(XML文件，來自http://mattmahoney.net/dc/textdata.html的enwik8.zip，非純文本)作為原始文件，各種壓縮方式的壓縮時(shí)間，解壓時(shí)間以及壓縮率比較如下：

各種壓縮方式性能表現(xiàn)

由上表可以看出，壓縮比最好的是bzip方式，但是其效率實(shí)在是不高，在大數(shù)據(jù)量的時(shí)候，壓縮和解壓的時(shí)間耗費(fèi)過長，不是首選壓縮方式。

綜合考慮各種因素，LZ4與Snappy是比較推薦的壓縮方式，性能和效率都還不錯(cuò)。LZ4由于推出較晚，因?yàn)檫@樣，Snappy目前成為使用最普遍的壓縮方式。

由于集群中并不是所有數(shù)據(jù)都會被壓縮，通常來說，我們考慮集群的冷熱數(shù)據(jù)比為6:4，即60%的數(shù)據(jù)為冷數(shù)據(jù)，這部分?jǐn)?shù)據(jù)被壓縮，而剩下40%為熱數(shù)據(jù)，這部分?jǐn)?shù)據(jù)不壓縮。假設(shè)使用Snappy的壓縮機(jī)制，參考上表假設(shè)壓縮比為數(shù)據(jù)，那么整體數(shù)據(jù)在壓縮完成后約為原始數(shù)據(jù)量的75%。

這樣的話有一個(gè)參考，如果原來啟用3副本機(jī)制，那么存儲只需規(guī)劃數(shù)據(jù)量的2.25倍即可。如果原來使用EC糾刪碼機(jī)制，那么存儲只需規(guī)劃數(shù)據(jù)量的1.5倍即可(同時(shí)使用EC糾刪碼和壓縮的情況下對CPU要求會非常高，并不推薦)。

討論完了HDFS的容量考慮與數(shù)據(jù)壓縮的問題；

如何選擇合適的硬件以支持HDFS服務(wù)呢？

HDFS底層可以是本地磁盤，可以是傳統(tǒng)的存儲設(shè)備，哪一個(gè)好一些？

首先，關(guān)于硬件選擇沒有好不好的問題，只有合不合適的范疇。在數(shù)據(jù)量不大的初期，使用本地磁盤絕對是個(gè)性價(jià)比更好的方案，另外在數(shù)據(jù)讀寫效率上，本地磁盤也比存儲設(shè)備要優(yōu)秀的多。

而在數(shù)據(jù)量上升到一定程度，3副本帶來的磁盤經(jīng)濟(jì)成本和管理成本迅速上升時(shí)，低端的存儲設(shè)備優(yōu)勢開始表現(xiàn)出來：可以做數(shù)據(jù)分層，歸檔，監(jiān)控?cái)?shù)據(jù)情況，管理便捷等，畢竟在不考慮性價(jià)比的情況下，存儲設(shè)備的功能是很強(qiáng)大的。

但數(shù)據(jù)量再繼續(xù)上升(PB往上)，存儲設(shè)備的擴(kuò)展性開始受到了局限，而磁盤仍然可以繼續(xù)線性增加。所以在一個(gè)”大數(shù)據(jù)”量級的場景下，本地磁盤可能是一個(gè)”沒得選”的選擇。

如果用本地磁盤作為HDFS的存儲硬件，磁盤又該怎么選擇？

是用SSD盤，還是用SAS盤，還是用SATA盤?

從性價(jià)比的角度來講，一般不考慮把SSD盤用作HDFS的底層磁盤，畢竟當(dāng)容量超過TB級別后，SSD的價(jià)格非常昂貴，當(dāng)然財(cái)大氣粗的公司請無視該建議。而對于同等容量的SAS盤與SATA盤，目前市場上的價(jià)格差異上已經(jīng)不大了，考慮速寫效率以及性能穩(wěn)定性等因素，建議首選SAS盤。

大盤好還是小盤好？回答這個(gè)問題前，先了解幾個(gè)背景因素：

一、SAS盤分為大盤和小盤，其中大盤3.5寸，小盤2.5寸，市場上兩種尺寸的磁盤容量包括：

● 2.5寸：300G, 600G, 900G, 1.2T, 1.8T, 2.4T, 1T, 2T

● 3.5寸：1T，2T，4T，6T，8T，10T

二、2.5寸的盤通常有三種轉(zhuǎn)速，分別是7.2K rpm, 10K rpm, 15K rpm，具體為：

● 7.2K rpm：1T，2T

● 10K rpm：1.2T，1.8T，2.4T

● 15K rpm：300G, 600G, 900G

而3.5寸的盤統(tǒng)一只能達(dá)到7.2K rpm。

在了解以上兩個(gè)要素后，我們討論一下磁盤的性能問題，首先需要說明的是，磁盤的讀寫性能和其容量大小無關(guān)。

影響磁盤性能的有兩個(gè)指標(biāo)。一個(gè)是磁盤的IOPS，全稱是磁盤每秒處理的I/O請求數(shù)量。另一個(gè)磁盤數(shù)據(jù)傳輸率。一般數(shù)據(jù)傳輸率更多的依賴于磁盤的接口，對于同種接口數(shù)據(jù)傳輸率幾乎相同，因此IOPS是評價(jià)磁盤性能最重要的指標(biāo)。理論上，磁盤的IOPS計(jì)算公式如下：

1s/(Tseek+Trotation)

其中，Tseek是尋道時(shí)間，一般SAS盤的Tseek為4-8ms。具體來說，15K rpm的Tseek約為4ms,10K rpm的Tseek約為6ms，7.2K rpm的Tseek約為8ms。

Trotation為盤片旋轉(zhuǎn)延時(shí)，通常為磁盤旋轉(zhuǎn)半圈的時(shí)間表示，15K rpm磁盤的延時(shí)為60*1000/15000/2=2ms,同理，10K rpm的延時(shí)為3ms,7.2Krpm的延時(shí)為4ms。

則根據(jù)以上理論，可以得出：

15K rpm磁盤：IOPS=1000/(4+2)=166

10K rpm磁盤：IOPS=1000/(6+3)=111

7.2K rpm磁盤：IOPS=1000/(8+4)=83

由以上數(shù)據(jù)可以得出，使用15KPM的磁盤性能會是7.2KPM磁盤性能的2倍。使用10K rpm的磁盤性能會是7.2KPM磁盤性能的1.33倍。

15K rpm的磁盤由于其容量太小，一般不在實(shí)際的使用考慮之中，而10K rpm和7.2K rpm是實(shí)踐中用的最多的磁盤。10K rpm最大磁盤容量為2.4T，7.2K rpm最大磁盤容量為10T，幾乎為前者的4倍。

由此，在實(shí)際選擇中，如果HDFS的數(shù)據(jù)量不大且為計(jì)算密集型集群，對實(shí)時(shí)響應(yīng)要求較高時(shí)，建議使用10K rpm的小盤；如果HDFS有海量數(shù)據(jù)存儲的需求，那么還是10T的大盤好一些，即便這意味著讓渡一些性能出來，雖然集群數(shù)據(jù)處理的慢一些，但是它能處理更多的數(shù)據(jù)。