基于HDFS的分布式存儲(chǔ)策略分析

王來　翟健宏

摘 要：本文重點(diǎn)對(duì)HDFS機(jī)架感知和副本存放策略方面對(duì)HDFS分布式存儲(chǔ)進(jìn)行剖析。副本存放策略和機(jī)架感知主要通過Datanode節(jié)點(diǎn)形成的樹狀網(wǎng)絡(luò)拓?fù)鋱D來讓Namenode節(jié)點(diǎn)獲取，從而確定副本存放的位置，這樣方式保證了對(duì)于數(shù)據(jù)的極高的容錯(cuò)性的同時(shí)也兼顧了數(shù)據(jù)本地化，即提高了數(shù)據(jù)在集群網(wǎng)絡(luò)中的傳輸效率。基于此，提出一個(gè)設(shè)想，希望通過對(duì)副本存放策略的深入挖掘，根據(jù)Datanode數(shù)據(jù)節(jié)點(diǎn)的實(shí)時(shí)狀態(tài)信息，實(shí)現(xiàn)對(duì)于數(shù)據(jù)塊副本的定向存儲(chǔ)，再由數(shù)據(jù)驅(qū)動(dòng)任務(wù)分配，來為每一個(gè)Datanode數(shù)據(jù)節(jié)點(diǎn)分配更適合的任務(wù)，從而達(dá)到負(fù)載均衡提高資源利用率的作用。

關(guān)鍵字：HDFS；分布式存儲(chǔ)；副本存放策略；數(shù)據(jù)驅(qū)動(dòng)

中圖分類號(hào)：TP391.41 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：2095-2163（2015）05-

Abstract： This article focuses on the strategy of ReplicationTargetChooser and Rack-Awareness to analyze HDFS distributed storage. To realize the strategy of ReplicationTargetChooser and Rack-Awareness， the HDFS forms a network topology tree of Datanode primarily to let Namenode nodes determine the location of replication， in such a way to ensure that for extremely high data fault tolerance while taking into account the data locally， and to improve the efficiency of data transmission in the cluster network. Based on this， the paper proposes an idea， hope to learn more of the strategy of ReplicationTargetChooser， based on real-time status information Datanode nodes to achieve the orientation for the data block， data-driven task redistribution to Datanode data for each node assign tasks better suited to achieve the effect of load balancing and improve resource utilization.

Keywords： HDFS； Distributed Storage； Replications Strategy； Data-driven

0 引 言

在二十一世紀(jì)的今天，社會(huì)已處于信息時(shí)代，其中的每一天都會(huì)產(chǎn)生海量的數(shù)據(jù)，如何對(duì)這些海量數(shù)據(jù)進(jìn)行存儲(chǔ)和利用，即已成為信息科技工作者們頻繁遭遇并日漸關(guān)注的熱點(diǎn)研究問題。然而無論在存儲(chǔ)空間，存儲(chǔ)速度方面，還是在數(shù)據(jù)的存儲(chǔ)安全方面，傳統(tǒng)的文件系統(tǒng)都已經(jīng)達(dá)不到時(shí)下的處理要求[1]。直到近年來Hadoop的出現(xiàn)，這一問題才獲得了突破性的解決辦法。Hadoop提出了一種存儲(chǔ)和處理大規(guī)模海量數(shù)據(jù)的現(xiàn)實(shí)有效方案，正因如此，Hadoop受到了Google，Yahoo，亞馬遜等知名IT公司的熱捧，而國內(nèi)的一些公司如騰訊、阿里、百度、華為等都將Hadoop作為公司處理海量數(shù)據(jù)的一種解決方案[2]。其中的HDFS分布式文件系統(tǒng)是Hadoop的核心組件，也是解決大規(guī)模海量數(shù)據(jù)存儲(chǔ)和利用的重要技術(shù)手段。

因此，深入了解HDFS分布式文件系統(tǒng)的存儲(chǔ)策略，對(duì)于未來應(yīng)用與改善HDFS分布式文件系統(tǒng)有著重要意義。

1 副本機(jī)制

HDFS將每一個(gè)文件的數(shù)據(jù)進(jìn)行分塊存儲(chǔ)，同時(shí)每一個(gè)數(shù)據(jù)塊保存有多個(gè)副本，具體副本的個(gè)數(shù)可在hdfs-site.xml中dfs.replication屬性中配置[3]。相應(yīng)數(shù)據(jù)塊副本分布在不同的機(jī)器節(jié)點(diǎn)上，這種數(shù)據(jù)分塊存儲(chǔ)+副本的策略即是HDFS保證可靠性和性能的關(guān)鍵，主要是因?yàn)椋?/p>

（1）文件分塊存儲(chǔ)之后按照數(shù)據(jù)塊來讀，提高了文件隨機(jī)讀的效率和并發(fā)讀的效率；

（2）保存數(shù)據(jù)塊若干副本到不同的機(jī)器節(jié)點(diǎn)，在實(shí)現(xiàn)可靠性的同時(shí)，也提高了同一數(shù)據(jù)塊的并發(fā)讀效率；

（3）數(shù)據(jù)分塊是高度切合MapReduce中任務(wù)切分的思想。此處，副本的存放策略又是HDFS實(shí)現(xiàn)高可靠性和高性能的重點(diǎn)決定性主題。

2 機(jī)架感知

HDFS采用一種稱為機(jī)架感知的策略來改進(jìn)數(shù)據(jù)的可靠性、可用性和網(wǎng)絡(luò)帶寬的利用率。通過一個(gè)機(jī)架感知的過程，Namenode可以確定每一個(gè)Datanode所屬的機(jī)架id。實(shí)際上，Namenode把注冊的Datanode節(jié)點(diǎn)按照相關(guān)的ip地址存儲(chǔ)到一個(gè)樹狀網(wǎng)絡(luò)拓?fù)鋱D中，然后Namenode調(diào)用ReplicationTargetChooser來為每一個(gè)數(shù)據(jù)塊副本選擇合適的存儲(chǔ)節(jié)點(diǎn)。但是，Hadoop對(duì)機(jī)架的感知并非是自適應(yīng)的，即Hadoop集群分辨某臺(tái)slave機(jī)器是屬于哪個(gè)rack并非是系統(tǒng)自我感知的，而是需要Hadoop的管理者人為告知Hadoop哪臺(tái)機(jī)器屬于哪個(gè)rack，這樣在Hadoop的Namenode啟動(dòng)初始化時(shí)，就會(huì)將這些機(jī)器與rack的對(duì)應(yīng)信息保存在內(nèi)存中[4]。

默認(rèn)情況下，Hadoop的機(jī)架感知是沒有被啟用的。所以，在通常情況下，Hadoop集群的HDFS都是隨機(jī)選擇機(jī)器的，也就是說，很有可能在寫數(shù)據(jù)時(shí)，Hadoop將第一塊數(shù)據(jù)block1寫到了rack1上，然后在隨機(jī)的選擇下將block2寫入到了rack2下，此時(shí)兩個(gè)rack之間產(chǎn)生了數(shù)據(jù)傳輸?shù)牧髁浚俳酉聛?，也在隨機(jī)的情況下，又將block3重新又寫回了rack1，此時(shí)，兩個(gè)rack之間又產(chǎn)生了一次數(shù)據(jù)流量。這樣job的數(shù)據(jù)處理量將非常巨大，或者向Hadoop推送的數(shù)據(jù)量也跡近龐大的時(shí)候，就會(huì)造成rack之間的網(wǎng)絡(luò)流量成倍上升，由此成為性能的瓶頸，進(jìn)而影響作業(yè)的性能以至于整個(gè)集群的服務(wù)。

要對(duì)Hadoop機(jī)架感知進(jìn)行功能啟用，配置非常簡單，即在Namenode所在機(jī)器的core-site.xml配置文件中配置一個(gè)選項(xiàng)：topology.script.file.name，如圖1所示，這個(gè)屬性的value是一個(gè)路徑，該路徑指向一個(gè)可執(zhí)行文件（或者腳本）， 該文件可以由Python或者C或C++實(shí)現(xiàn)編寫。如果topology.script.file.name沒有設(shè)定，則每個(gè)IP都會(huì)翻譯成/default-rack[5]。

該可執(zhí)行文件（或者腳本）需要提供IP->rackid的翻譯。Namenode通過翻譯結(jié)果得到集群中各個(gè)Datanode機(jī)器的rackid。該可執(zhí)行文件（或者腳本）接受一個(gè)參數(shù)，輸出一個(gè)值。接受的參數(shù)通常為某臺(tái)Datanode機(jī)器的IP地址，而輸出的值則多為該IP地址對(duì)應(yīng)的Datanode所在的rack，例如”/rack-1”。Namenode啟動(dòng)時(shí)，會(huì)判斷該配置選項(xiàng)是否為空，如果非空，則表示已經(jīng)用機(jī)架感知的配置，此時(shí)Namenode會(huì)根據(jù)配置尋找該腳本，并在接收到每一個(gè)Datanode的heartbeat時(shí)，將該Datanode的IP地址作為參數(shù)傳給該腳本運(yùn)行，再將得到的輸出作為該Datanode所屬的機(jī)架，保存到內(nèi)存的一個(gè)map中[6]。

編寫腳本的時(shí)候，需要將真實(shí)的網(wǎng)絡(luò)拓?fù)淝闆r和機(jī)架信息了解清楚后，通過該腳本將機(jī)器的IP地址正確地映射到相應(yīng)的機(jī)架上去。一個(gè)簡單的實(shí)現(xiàn)如圖2所示，研究中設(shè)置了三個(gè)Datanode節(jié)點(diǎn)，將其分別設(shè)置在rack-1和rack-2。

重啟Namenode，如果配置成功，腳本可以返回如： rack-1 類似的字符串，同時(shí)在Namenode日志中會(huì)輸出：INFO org.apache.hadoop.net.NetworkTopology： Adding a new node： /rack1/192.168.56.2：50010 。

實(shí)際上，對(duì)用戶來說有兩種方式可以實(shí)現(xiàn)用戶自定義的機(jī)架感知IP解析，其一就是上面的用戶自行編輯腳本實(shí)現(xiàn)，也就是一種插件方式，即插即用；其二則是直接實(shí)現(xiàn)DNSToSwitchMapping接口，并將這個(gè)實(shí)現(xiàn)類配置到配置文件的項(xiàng)。就可擴(kuò)展行而言，第一種方式為佳，就性能而言，第二種方式為佳，現(xiàn)實(shí)最終還將取決于用戶自身的應(yīng)用場景。

設(shè)計(jì)實(shí)現(xiàn)了機(jī)架感知后，Namenode就可以畫出如圖3所示的Datanode網(wǎng)絡(luò)拓?fù)鋱D，實(shí)際上就是對(duì)應(yīng)Networktopology類的一個(gè)實(shí)例。圖3中，D1，R1都是交換機(jī)，最底層的葉子節(jié)點(diǎn)是Datanode。則H1的rackid=/D1/R1/H1，H1的parent是R1，R1的parent是D1。這些rackid信息可以通過topology.script.file.name提供相應(yīng)配置。而獲得了這些rackid信息后，就可以計(jì)算出任意兩臺(tái)Datanode之間的距離：

3 副本存放策略

在大多數(shù)情況下，副本系數(shù)是3，HDFS的存放策略是將一個(gè)副本存放在本地機(jī)架節(jié)點(diǎn)上，還有一個(gè)副本存放在同一個(gè)機(jī)架的另一個(gè)節(jié)點(diǎn)上，最后一個(gè)副本則存放在不同機(jī)架的節(jié)點(diǎn)上。這種策略減少了機(jī)架間的數(shù)據(jù)傳輸，提高了寫操作的效率。機(jī)架的錯(cuò)誤要遠(yuǎn)遠(yuǎn)小于節(jié)點(diǎn)的錯(cuò)誤，所以這種策略不會(huì)影響到數(shù)據(jù)的可靠性和可用性。與此同時(shí)，因?yàn)閿?shù)據(jù)塊只存放在兩個(gè)不同的機(jī)架上，最終也就減少了讀取數(shù)據(jù)時(shí)需要的網(wǎng)絡(luò)傳輸總帶寬。同時(shí)，在該種策略下，副本并不是均勻分布在不同的機(jī)架上：三分之一的副本在一個(gè)節(jié)點(diǎn)上，三分之二的副本在一個(gè)機(jī)架上，其它副本均勻分布在剩余機(jī)架中，從而在不損害數(shù)據(jù)可靠性和讀取性能的情況下改進(jìn)了寫的性能。

在Hadoop-1.X版本中，Namenode是通過ReplicationTargetChooser類來為每一分?jǐn)?shù)據(jù)塊選擇副本存放位置的，該類的一般處理過程如圖4所示。

下面將逐一介紹HDFS副本存放策略所涉及的四個(gè)主要函數(shù)：

3.1選擇一個(gè)本地節(jié)點(diǎn)

這里所說的本地節(jié)點(diǎn)是相對(duì)于客戶端來說的，也就是說某一個(gè)用戶正在通過一個(gè)客戶端而將數(shù)據(jù)寫入HDFS中，如果該客戶端上有數(shù)據(jù)節(jié)點(diǎn)，那么就應(yīng)該最優(yōu)先考慮把正在寫入的數(shù)據(jù)的一個(gè)副本保存在這個(gè)客戶端的數(shù)據(jù)節(jié)點(diǎn)上，如此即被看作是本地節(jié)點(diǎn)，但是如果這個(gè)客戶端上的數(shù)據(jù)節(jié)點(diǎn)空間不足或者是當(dāng)前負(fù)載過重，則應(yīng)該從該數(shù)據(jù)節(jié)點(diǎn)所在的機(jī)架中選擇一個(gè)合適的數(shù)據(jù)節(jié)點(diǎn)作為此時(shí)這個(gè)數(shù)據(jù)塊的本地節(jié)點(diǎn)。

3.2選擇一個(gè)本地機(jī)架節(jié)點(diǎn)

選擇本地機(jī)架節(jié)點(diǎn)和遠(yuǎn)程機(jī)架節(jié)點(diǎn)都需要以一個(gè)節(jié)點(diǎn)為參考，如果參考點(diǎn)為空，則從整個(gè)集群中隨機(jī)選擇一個(gè)合適的數(shù)據(jù)節(jié)點(diǎn)作為此時(shí)的本地機(jī)架節(jié)點(diǎn)[7]；否則就從參考節(jié)點(diǎn)所在的機(jī)架中隨機(jī)選擇一個(gè)合適的數(shù)據(jù)節(jié)點(diǎn)作為此時(shí)的本地機(jī)架節(jié)點(diǎn)。

3.3選擇一個(gè)遠(yuǎn)程機(jī)架節(jié)點(diǎn)

選擇一個(gè)遠(yuǎn)程機(jī)架節(jié)點(diǎn)就是隨機(jī)選擇一個(gè)合適的不在參考點(diǎn)所在機(jī)架中的數(shù)據(jù)節(jié)點(diǎn)，如果沒有找到這個(gè)合適的數(shù)據(jù)節(jié)點(diǎn)的話，就只能從參考點(diǎn)所在機(jī)架中選擇一個(gè)合適的數(shù)據(jù)節(jié)點(diǎn)作為此時(shí)的遠(yuǎn)程機(jī)架節(jié)點(diǎn)。

3.4隨機(jī)選擇若干數(shù)據(jù)節(jié)點(diǎn)

這里，隨機(jī)選擇若干個(gè)數(shù)據(jù)節(jié)點(diǎn)實(shí)際上指的是從某一個(gè)范圍內(nèi)隨機(jī)地選擇若干個(gè)節(jié)點(diǎn)，其具體實(shí)現(xiàn)需要利用NetworkTopology類的數(shù)據(jù)結(jié)構(gòu)。隨機(jī)選擇所使用的范圍本質(zhì)上指的是一個(gè)路徑，這個(gè)路徑展現(xiàn)的是NetworkTopology所表示的樹狀網(wǎng)絡(luò)拓?fù)鋱D中的一個(gè)非葉子節(jié)點(diǎn)，隨機(jī)選擇針對(duì)的就是這個(gè)節(jié)點(diǎn)的所有葉子節(jié)點(diǎn)，即Datanode數(shù)據(jù)節(jié)點(diǎn)。

副本位置確定之后，便涉及到了數(shù)據(jù)的傳輸問題。HDFS對(duì)于Block的副本copy采用的是流水線作業(yè)的方式：client把數(shù)據(jù)Block只傳給一個(gè)Datanode，這個(gè)Datanode收到Block之后，傳給下一個(gè)Datanode，依次類推，最后一個(gè)Datanode就不需要下傳數(shù)據(jù)Block了。所以，在為一個(gè)數(shù)據(jù)塊確定所有的副本存放的位置之后，就需要確定這種數(shù)據(jù)節(jié)點(diǎn)之間流水復(fù)制的順序，確定后的順序應(yīng)該使得數(shù)據(jù)傳輸時(shí)花費(fèi)的網(wǎng)絡(luò)延時(shí)最小。這是由ReplicationTargetChooser類來負(fù)責(zé)執(zhí)行的。副本傳輸路徑如圖5所示。

4 結(jié)束語

企業(yè)數(shù)據(jù)不斷增加，數(shù)據(jù)存儲(chǔ)至關(guān)重要。傳統(tǒng)文件系統(tǒng)存儲(chǔ)在數(shù)據(jù)安全和效率上達(dá)不到企業(yè)數(shù)據(jù)存儲(chǔ)要求。另外近年Hadoop 受到國內(nèi)外各大公司青睞，并將其作為數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)處理的一個(gè)解決方案。而HDFS 作為Hadoop 的核心，主要負(fù)責(zé)數(shù)據(jù)存儲(chǔ)，本文即重點(diǎn)針對(duì)基于HDFS 的分布式數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)塊副本存放機(jī)制問題做了相關(guān)研究，描述了HDFS文件系統(tǒng)的副本機(jī)制，實(shí)現(xiàn)機(jī)架感知的相關(guān)配置原理，以及數(shù)據(jù)副本的存放機(jī)制，這里的關(guān)鍵是讓主機(jī)能夠知道集群存儲(chǔ)節(jié)點(diǎn)的網(wǎng)絡(luò)位置，并以此為依據(jù)，在數(shù)據(jù)塊存儲(chǔ)的時(shí)候選擇合適節(jié)點(diǎn)存儲(chǔ)，這樣不僅保證數(shù)據(jù)安全性和可靠性，還提高了數(shù)據(jù)訪問效率。

通過對(duì)HDFS副本存放策略的深入了解，筆者提出一個(gè)設(shè)想，因?yàn)镠DFS分布式文件系統(tǒng)采用隨機(jī)的副本放置策略，使得系統(tǒng)在運(yùn)行一段時(shí)間后會(huì)出現(xiàn)數(shù)據(jù)分布不均衡的情況，從而降低數(shù)據(jù)的可靠性和讀取速率.為解決HDFS默認(rèn)副本放置策略存在的問題，對(duì)HDFS 副本放置策略實(shí)施一定改進(jìn)：在副本放置選擇時(shí)，根據(jù)Datanode數(shù)據(jù)節(jié)點(diǎn)發(fā)給Namenode節(jié)點(diǎn)的心跳解析出每個(gè)Datanode數(shù)據(jù)節(jié)點(diǎn)的實(shí)時(shí)狀態(tài)信息，為每個(gè)數(shù)據(jù)塊結(jié)合本地化原則，優(yōu)先考慮發(fā)送給存儲(chǔ)使用率低的Datanode數(shù)據(jù)節(jié)點(diǎn)，再將這些Datanode節(jié)點(diǎn)作為數(shù)據(jù)塊的優(yōu)先目標(biāo)發(fā)送節(jié)點(diǎn)。

在確定數(shù)據(jù)塊的目標(biāo)發(fā)送節(jié)點(diǎn)后，研究需要實(shí)現(xiàn)數(shù)據(jù)塊向Datanode節(jié)點(diǎn)的定向發(fā)送，而不是Hadoop默認(rèn)狀態(tài)下的隨機(jī)選擇目標(biāo)Datanode數(shù)據(jù)節(jié)點(diǎn)。為了實(shí)現(xiàn)這一操作，根據(jù)HDFS機(jī)架感知的設(shè)置，因?yàn)橛脩艨梢宰孕性O(shè)置Datanode數(shù)據(jù)節(jié)點(diǎn)的IP解析腳本，也就是用戶可以自行構(gòu)造Datanode數(shù)據(jù)節(jié)點(diǎn)的樹狀網(wǎng)絡(luò)拓?fù)鋱D。因此通過動(dòng)態(tài)改變集群數(shù)據(jù)節(jié)點(diǎn)的樹狀網(wǎng)絡(luò)拓?fù)鋱D，研究即能實(shí)現(xiàn)數(shù)據(jù)塊向Datanode節(jié)點(diǎn)的定向發(fā)送。

上述想法是筆者的一個(gè)設(shè)想，現(xiàn)在已經(jīng)實(shí)現(xiàn)了對(duì)Datanode數(shù)據(jù)節(jié)點(diǎn)的樹狀網(wǎng)絡(luò)拓?fù)鋱D的自行構(gòu)造操作，但后續(xù)的具體操作卻仍未付諸實(shí)現(xiàn)，最終希望通過實(shí)驗(yàn)來得到基于數(shù)據(jù)驅(qū)動(dòng)的副本存儲(chǔ)策略，如此則將起到負(fù)載均衡和提高資源利用率的作用。

參考文獻(xiàn)：

[1] LIAN Qiao， CHEN Wei， ZHANG Zheng. On the impact of replica placement to the reliability of distributed brick storage systems[C]//Proceedings of 25th IEEE International Conference on Distributed Computing Systems，[S.l.]：IEEE， 2005： 187-196.

[2] DEAN J， GHEMAWAT S. MapReduce： Simplied data processing on large clusters[C]//Proceedings of the 6th Symposium on Operating System Design and Implementation， New York： ACM Press， 2004： 137-150.

[3] ZHU Yifeng， JIANG Hong， WANG Jun， et al. HBA： Distributrd metadata management For large cluster-based storage systems[J]. IEEE Transactions On Parallel And Distributed Systems， 2008， 19（6）： 750-762.

[4] KON F. Distributed file systems past present and future a distributed file system for 2006[J]. Computer and Information Science， 1996， 3（6）： 1-12.

[5] KO B J. Scalable service differentiation in a shared storage cache[C]/ /Proc of the 23rd International Conference on Distributed Computing Systems. Washington，DC，USA：IEEE，2003： 184-194.

[6] 王躍. 基于Hadoop 分布式文件系統(tǒng)的分析與研究.計(jì)算機(jī)光盤軟件與應(yīng)用，2011（9）： 161-162.

[7] 翟永東. Hadoop 分布式文件系統(tǒng)（HDFS）可靠性的研究與優(yōu)化[D].武漢： 華中科技大學(xué)， 2011.