基于HDFS的分布式存儲策略分析

王來　翟健宏

摘 要：本文重點對HDFS機架感知和副本存放策略方面對HDFS分布式存儲進行剖析。副本存放策略和機架感知主要通過Datanode節點形成的樹狀網絡拓撲圖來讓Namenode節點獲取，從而確定副本存放的位置，這樣方式保證了對于數據的極高的容錯性的同時也兼顧了數據本地化，即提高了數據在集群網絡中的傳輸效率。基于此，提出一個設想，希望通過對副本存放策略的深入挖掘，根據Datanode數據節點的實時狀態信息，實現對于數據塊副本的定向存儲，再由數據驅動任務分配，來為每一個Datanode數據節點分配更適合的任務，從而達到負載均衡提高資源利用率的作用。

關鍵字：HDFS；分布式存儲；副本存放策略；數據驅動

中圖分類號：TP391.41 文獻標識碼：A 文章編號：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 引 言

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

因此，深入了解HDFS分布式文件系統的存儲策略，對于未來應用與改善HDFS分布式文件系統有著重要意義。

1 副本機制

HDFS將每一個文件的數據進行分塊存儲，同時每一個數據塊保存有多個副本，具體副本的個數可在hdfs-site.xml中dfs.replication屬性中配置[3]。相應數據塊副本分布在不同的機器節點上，這種數據分塊存儲+副本的策略即是HDFS保證可靠性和性能的關鍵，主要是因為：

（1）文件分塊存儲之后按照數據塊來讀，提高了文件隨機讀的效率和并發讀的效率；

（2）保存數據塊若干副本到不同的機器節點，在實現可靠性的同時，也提高了同一數據塊的并發讀效率；

（3）數據分塊是高度切合MapReduce中任務切分的思想。此處，副本的存放策略又是HDFS實現高可靠性和高性能的重點決定性主題。

2 機架感知

HDFS采用一種稱為機架感知的策略來改進數據的可靠性、可用性和網絡帶寬的利用率。通過一個機架感知的過程，Namenode可以確定每一個Datanode所屬的機架id。實際上，Namenode把注冊的Datanode節點按照相關的ip地址存儲到一個樹狀網絡拓撲圖中，然后Namenode調用ReplicationTargetChooser來為每一個數據塊副本選擇合適的存儲節點。但是，Hadoop對機架的感知并非是自適應的，即Hadoop集群分辨某臺slave機器是屬于哪個rack并非是系統自我感知的，而是需要Hadoop的管理者人為告知Hadoop哪臺機器屬于哪個rack，這樣在Hadoop的Namenode啟動初始化時，就會將這些機器與rack的對應信息保存在內存中[4]。

默認情況下，Hadoop的機架感知是沒有被啟用的。所以，在通常情況下，Hadoop集群的HDFS都是隨機選擇機器的，也就是說，很有可能在寫數據時，Hadoop將第一塊數據block1寫到了rack1上，然后在隨機的選擇下將block2寫入到了rack2下，此時兩個rack之間產生了數據傳輸的流量，再接下來，也在隨機的情況下，又將block3重新又寫回了rack1，此時，兩個rack之間又產生了一次數據流量。這樣job的數據處理量將非常巨大，或者向Hadoop推送的數據量也跡近龐大的時候，就會造成rack之間的網絡流量成倍上升，由此成為性能的瓶頸，進而影響作業的性能以至于整個集群的服務。

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

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

編寫腳本的時候，需要將真實的網絡拓撲情況和機架信息了解清楚后，通過該腳本將機器的IP地址正確地映射到相應的機架上去。一個簡單的實現如圖2所示，研究中設置了三個Datanode節點，將其分別設置在rack-1和rack-2。

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

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

設計實現了機架感知后，Namenode就可以畫出如圖3所示的Datanode網絡拓撲圖，實際上就是對應Networktopology類的一個實例。圖3中，D1，R1都是交換機，最底層的葉子節點是Datanode。則H1的rackid=/D1/R1/H1，H1的parent是R1，R1的parent是D1。這些rackid信息可以通過topology.script.file.name提供相應配置。而獲得了這些rackid信息后，就可以計算出任意兩臺Datanode之間的距離：

3 副本存放策略

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

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

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

3.1選擇一個本地節點

這里所說的本地節點是相對于客戶端來說的，也就是說某一個用戶正在通過一個客戶端而將數據寫入HDFS中，如果該客戶端上有數據節點，那么就應該最優先考慮把正在寫入的數據的一個副本保存在這個客戶端的數據節點上，如此即被看作是本地節點，但是如果這個客戶端上的數據節點空間不足或者是當前負載過重，則應該從該數據節點所在的機架中選擇一個合適的數據節點作為此時這個數據塊的本地節點。

3.2選擇一個本地機架節點

選擇本地機架節點和遠程機架節點都需要以一個節點為參考，如果參考點為空，則從整個集群中隨機選擇一個合適的數據節點作為此時的本地機架節點[7]；否則就從參考節點所在的機架中隨機選擇一個合適的數據節點作為此時的本地機架節點。

3.3選擇一個遠程機架節點

選擇一個遠程機架節點就是隨機選擇一個合適的不在參考點所在機架中的數據節點，如果沒有找到這個合適的數據節點的話，就只能從參考點所在機架中選擇一個合適的數據節點作為此時的遠程機架節點。

3.4隨機選擇若干數據節點

這里，隨機選擇若干個數據節點實際上指的是從某一個范圍內隨機地選擇若干個節點，其具體實現需要利用NetworkTopology類的數據結構。隨機選擇所使用的范圍本質上指的是一個路徑，這個路徑展現的是NetworkTopology所表示的樹狀網絡拓撲圖中的一個非葉子節點，隨機選擇針對的就是這個節點的所有葉子節點，即Datanode數據節點。

副本位置確定之后，便涉及到了數據的傳輸問題。HDFS對于Block的副本copy采用的是流水線作業的方式：client把數據Block只傳給一個Datanode，這個Datanode收到Block之后，傳給下一個Datanode，依次類推，最后一個Datanode就不需要下傳數據Block了。所以，在為一個數據塊確定所有的副本存放的位置之后，就需要確定這種數據節點之間流水復制的順序，確定后的順序應該使得數據傳輸時花費的網絡延時最小。這是由ReplicationTargetChooser類來負責執行的。副本傳輸路徑如圖5所示。

4 結束語

企業數據不斷增加，數據存儲至關重要。傳統文件系統存儲在數據安全和效率上達不到企業數據存儲要求。另外近年Hadoop 受到國內外各大公司青睞，并將其作為數據存儲和數據處理的一個解決方案。而HDFS 作為Hadoop 的核心，主要負責數據存儲，本文即重點針對基于HDFS 的分布式數據存儲的數據塊副本存放機制問題做了相關研究，描述了HDFS文件系統的副本機制，實現機架感知的相關配置原理，以及數據副本的存放機制，這里的關鍵是讓主機能夠知道集群存儲節點的網絡位置，并以此為依據，在數據塊存儲的時候選擇合適節點存儲，這樣不僅保證數據安全性和可靠性，還提高了數據訪問效率。

通過對HDFS副本存放策略的深入了解，筆者提出一個設想，因為HDFS分布式文件系統采用隨機的副本放置策略，使得系統在運行一段時間后會出現數據分布不均衡的情況，從而降低數據的可靠性和讀取速率.為解決HDFS默認副本放置策略存在的問題，對HDFS 副本放置策略實施一定改進：在副本放置選擇時，根據Datanode數據節點發給Namenode節點的心跳解析出每個Datanode數據節點的實時狀態信息，為每個數據塊結合本地化原則，優先考慮發送給存儲使用率低的Datanode數據節點，再將這些Datanode節點作為數據塊的優先目標發送節點。

在確定數據塊的目標發送節點后，研究需要實現數據塊向Datanode節點的定向發送，而不是Hadoop默認狀態下的隨機選擇目標Datanode數據節點。為了實現這一操作，根據HDFS機架感知的設置，因為用戶可以自行設置Datanode數據節點的IP解析腳本，也就是用戶可以自行構造Datanode數據節點的樹狀網絡拓撲圖。因此通過動態改變集群數據節點的樹狀網絡拓撲圖，研究即能實現數據塊向Datanode節點的定向發送。

上述想法是筆者的一個設想，現在已經實現了對Datanode數據節點的樹狀網絡拓撲圖的自行構造操作，但后續的具體操作卻仍未付諸實現，最終希望通過實驗來得到基于數據驅動的副本存儲策略，如此則將起到負載均衡和提高資源利用率的作用。

參考文獻：

[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 分布式文件系統的分析與研究.計算機光盤軟件與應用，2011（9）： 161-162.

[7] 翟永東. Hadoop 分布式文件系統（HDFS）可靠性的研究與優化[D].武漢： 華中科技大學， 2011.