HDFS架構指南

本文翻譯自《HDFS Architecture Guide》 來源於Apache開源社群的Hadoop Apache Project 文獻引用為：

Borthakur D. HDFS architecture guide[J]. Hadoop Apache Project, 2008,53: 1-13.

作者：Dhruba Borthakur

目錄

1 介紹 2 假設和目標    2.1 硬體故障    2.2 流資料訪問    2.3 大資料集    2.4 簡單一致性模型    2.5 “移動計算比移動資料便宜”    2.6 異構硬體和軟體平臺的可移植性 3 NameNode和DataNodes 4 檔案系統名稱空間 5 資料複製     5.1 複製品放置：第一個嬰兒步驟    5.2 副本選擇    5.3 安全模式 6 檔案系統元資料的永續性 7 通訊協議 8 穩健性     8.1 資料磁碟故障，心跳和重新複製    8.2 叢集重新平衡     8.3 資料完整性    8.4 元資料磁碟故障    8.5 快照 9 資料組織    9.1 資料塊    9.2 分期    9.3 複製流水線 10 可訪問性    10.1 FS shell    10.2 DFSAdmin    10.3 瀏覽器介面 11 空間回收    11.1檔案刪除與取消刪除    11.2減少複製因子 12 參考

1 Introduction

Hadoop分散式檔案系統（HDFS）是一個旨在執行在商品硬體上的分散式檔案系統。 它與現有的分散式檔案系統有許多相似之處。但是，與其他分散式檔案系統的差異很大。 HDFS具有高度容錯能力，旨在部署在低成本硬體上。 HDFS提供高吞吐量訪問應用程式資料，適用於具有大型資料集的應用程式。HDFS放寬了一些POSIX要求，以實現對檔案系統資料的流式訪問。HDFS最初是作為Apache Nutch網路搜尋引擎專案的基礎設施而構建的。HDFS現在是Apache Hadoop子專案。 專案網址是 http://hadoop.apache.org/hdfs / 。

2 Assumptions and Goals

2.1 Hardware Failure

硬體故障是常態而非例外。 HDFS例項可能包括數百或數千臺伺服器機器，每臺伺服器機器儲存檔案系統資料的一部分。存在大量元件並且每個元件都有一個非常重要的失敗概率，意味著HDFS的某些組成部分始終無法正常執行。因此，故障檢測並從中快速自動恢復是核心架構HDFS的目標。

2.2 Streaming Data Acess

在HDFS上執行的應用程式需要對其資料集進行流式訪問。 他們不是一般的通常在通用檔案系統上執行的目的應用程式。 HDFS的設計更多用於批處理而不是用於使用者的互動式使用。 重點是高資料訪問的吞吐量而不是資料訪問的低延遲。 POSIX強加許多針對HDFS的應用程式不需要的硬性要求。 POSIX已經交換了幾個關鍵領域的語義以提高資料吞吐率。

2.3 Large Data Sets

在HDFS上執行的應用程式具有大型的資料集。 HDFS中的典型檔案是千兆位元組太位元組大小（ gigabytes to terabytes in size）。 因此，HDFS被調整為支援大檔案。 它應該提供高聚合資料頻寬並擴充套件到單個叢集中的數百個節點。 它應該在單個例項中支援數千萬個檔案。

2.4 Simple Coherency Model 簡單一致性模型

HDFS應用程式需要一個一次寫入多次讀取的檔案訪問模型。 檔案一旦建立，寫入，關閉不需要改變。 該假設簡化了資料一致性問題並實現高吞吐量資料訪問。 MapReduce應用程式或Web爬網程式應用程式完全適合此模型。 有計劃在將來支援對檔案的追加寫入。

2.5 “Moving Computation is Cheaper than Moving Data”

如果在它運作的資料附近執行，則應用程式請求的計算效率更高。 當資料集的大小很大時尤其如此。 這個最大限度地減少網路擁塞並提高系統的整體吞吐量。 該假設通常更好地將計算遷移到更接近資料的位置找到而不是將資料移動到執行應用程式的位置。 HDFS為應用程式提供介面來移動它們自己，以便到達更靠近資料所在的位置。

2.6 Portability Across Heterogeneous Hardware and Software Platforms

HDFS的設計便於從一個平臺移植到另一個平臺。 這有利於廣泛採用HDFS作為大量應用程式的首選平臺。

3 NameNode and DataNodes

HDFS具有主/從架構。 HDFS叢集由單個的NameNode，管理檔案系統名稱空間的主伺服器（master server），用於管理對檔案的訪問客戶端（client）；此外，還有許多DataNode，通常是叢集中每個節點一個，它管理附加到它們執行的節點的儲存。 HDFS公開檔案系統名稱空間並允許使用者資料儲存在檔案中。 在內部，檔案被拆分為一個或更多塊，這些塊儲存在一組DataNode中。 NameNode執行檔案系統名稱空間操作，如開啟，關閉和重新命名檔案和目錄；它還確定了塊到DataNode的對映。 DataNodes負責提供來自檔案系統客戶端的讀寫請求。 DataNode還根據NameNode的指令執行塊建立，刪除和複製。

NameNode和DataNode是設計用於執行在商業機器上的軟體。 這些機器通常執行GNU / Linux作業系統（OS）。 HDFS是使用Java語言構建; 任何支援Java的機器都可以執行NameNode或DataNode軟體。 使用高度可移植的Java語言意味著HDFS可以部署在各種機器上。 典型部署具有專用機器只執行NameNode軟體。 群集中的每臺其他計算機都執行一臺DataNode軟體的例項。 該體系結構不排除執行多個DataNodes位於同一臺計算機上，但在實際部署中很少出現這種情況。叢集中存在單個NameNode極大地簡化了叢集的體系結構系統。 NameNode是所有HDFS元資料的仲裁者和儲存庫。 該系統是以這樣的方式設計，即使用者資料永遠不會流經NameNode。

4 The File System Namespace

HDFS支援傳統的分層檔案組織。 使用者或應用程式可以建立這些目錄中的目錄和儲存檔案。 檔案系統名稱空間層次結構是類似於大多數其他現有檔案系統; 可以建立和刪除檔案，從中移動檔案一個目錄到另一個目錄，或重新命名檔案。 HDFS尚未實現使用者配額。 HDFS不支援硬連結或軟連結。 但是，HDFS架構並不排除實現這些功能。NameNode維護檔案系統名稱空間。 對檔案系統的任何更改名稱空間或其屬性由NameNode記錄。 應用程式可以指定應由HDFS維護的檔案的副本數。 a的副本數量file被稱為該檔案的複製因子。 該資訊由NameNode儲存。

5 Data Replication

HDFS旨在跨大型叢集中的計算機可靠地儲存非常大的檔案。 它儲存每個檔案作為一系列塊; 除最後一個塊之外的檔案中的所有塊都具有相同的大小。複製檔案的塊以實現容錯。 塊大小和複製因子可以按檔案配置。 應用程式可以指定檔案的副本數。 該複製因子可以在檔案建立時指定，並可以在以後更改。 檔案HDFS是一次寫入的，並且在任何時候都只有一個寫入器（意思是不能並行寫入）。NameNode做出有關塊複製的所有決定。 它會定期收到來自群集中每個DataNode的Heartbeat和Blockreport。 收到一份Heartbeat意味著DataNode正常執行。 Blockreport包含一個列表DataNode上的所有塊。

5.1 Replica Placement: The First Baby Steps

複製品的放置對HDFS的可靠性和效能至關重要。 ”優化副本的放置“將HDFS與大多數其他分散式檔案系統區分開來。 這個功能需要大量的調整和經驗。 機架感知副本放置策略的目的旨在提高資料可靠性，可用性和網路頻寬利用率。 目前副本放置策略的實現是朝著這個方向邁出的第一步。實施此政策的短期目標是在生產系統上對其進行驗證，瞭解其行為，併為測試和研究更復雜的策略奠定基礎。大型HDFS例項在通常分佈在許多計算機上的計算機叢集上執行機架。 不同機架中兩個節點之間的通訊必須通過交換機。 在大多數情況下，同一機架中的機器之間的網路頻寬大於網路不同機架中機器之間的頻寬。 NameNode通過概在Hadoop Rack Awareness.中的處理框架確定每個DataNode所屬的機架ID。 一個簡單但非最優的策略是將副本放在唯一（單獨的）的機架上。 這可以防止在整個機架出現故障時丟失資料並允許使用頻寬從多個機架讀取資料。 此策略在叢集中均勻分佈副本，並可以輕鬆平衡元件故障時的負載。 但是，這項政策會增加成本寫入因為寫入需要將塊傳輸到多個機架。 對於常見情況，當複製因子為3時，HDFS的放置策略為將一個副本放在本地機架中的一個節點上，另一個副本放在另一個節點上（遠端）機架，最後一個副本在同一個遠端機架中的另一個節點上。 這項政策削減了機架寫入流量，通常可以提高寫入效能。 機架故障的可能性是遠遠少於節點故障; 此策略不會影響資料的可靠性和可用性擔保。 但是，它確實減少了讀取時使用的聚合網路頻寬資料，因為一個塊只放在兩個獨特的機架而不是三個。 有了這個政策，檔案的副本不是均勻分佈在機架上。 三分之一的複製品在一個節點，三分之二的副本位於一個機架上，？另外三分之一均勻分佈在剩下的貨架。 此策略可提高寫入效能，而不會影響資料可靠性或讀取效能。此處描述的當前預設副本放置策略是正在進行的工作。

5.2 Replica Selection

為了最大限度地減少全域性頻寬消耗和讀取延遲，HDFS通過讀取來自最接近讀者的副本來努力滿足讀取要求請求。 如果同一機架上存在副本和讀取器節點，則該副本優選滿足讀取請求。 如果是angg / HDFS群集跨越多個數據中心，然後是駐留在本地資料中心的副本優先於任何遠端副本。

5.3 Safemode

啟動時，NameNode進入一個名為Safemode的特殊狀態。 當NameNode處於Safemode狀態時資料塊的複製是不會發生的。 NameNode收到來自DataNodes的Heartbeat和Blockreport訊息。 Blockreport包含DataNode正在託管的資料塊的列表。 每個塊都有指定的最小數量副本。 當最小數量的副本已經在NameNode檢測到時，會認為是已經安全複製的。 經過可配置的安全複製的資料塊的百分比在NameNode檢查（再加上30秒），NameNode退出Safemode狀態。 然後它接下來確定仍然少於指定數量副本的資料塊列表（如果有的話）。 NameNode然後複製這些資料塊到其他DataNode。

6 The Persistence of File System Metadata

HDFS名稱空間由NameNode儲存。 NameNode使用事務日誌呼叫EditLog來持久記錄檔案系統元資料發生的每個更改。例如，在HDFS中建立新檔案會導致NameNode將插入一條記錄到EditLog來標記這個操作。 同樣，更改檔案的複製因子會導致新的要插入EditLog的記錄。 NameNode在其本地主機OS檔案系統中使用檔案用於儲存EditLog的系統。 整個檔案系統名稱空間，包括對映塊到檔案和檔案系統屬性，都儲存在名為FsImage的檔案中。 FsImage也作為檔案儲存在NameNode的本地檔案系統中。 NameNode保留整個檔案系統名稱空間和檔案Blockmap的映象在memory中。 該關鍵元資料項被設計為緊湊的，比如NameNode帶有4 GB的RAM足以支援大量的檔案和目錄。 當NameNode啟動的時候，它從磁碟讀取FsImage和EditLog，應用所有事務從EditLog到FsImage的記憶體中表示，並重新整理的它新版本到磁碟上的新FsImage。 然後它可以截斷舊的EditLog，因為它的事務已應用於永續性FsImage。 此過程稱為檢查點。在當前實現中，僅在NameNode啟動時才會發生檢查點。 支援定期檢查點工作正在進行中，在不久的將來會實現。 DataNode將HDFS資料儲存在其本地檔案系統中的檔案中 DataNode沒有有關HDFS檔案的知識。 它將每個HDFS資料塊儲存在本地檔案系統的單獨檔案中。 DataNode不會在同一目錄中建立所有檔案。 相反，它使用了啟發式確定每個目錄的最佳檔案數並適當建立子目錄。 在同一目錄中建立所有本地檔案並不是最佳選擇，因為本地檔案系統可能無法有效地支援大量單個檔案的檔案目錄。 當DataNode啟動時，它會掃描其本地檔案系統，生成一個列表。所有與這些本地檔案對應的HDFS資料塊，並將此報告發送給NameNode：這是Blockreport。

7 The Communication Protocols

所有HDFS通訊協議都分層構建在TCP / IP協議之上。 一個client建立與NameNode計算機上可配置TCP埠的連線。 client通過ClientProtocol與NameNode交談。 DataNodes使用DataNode Protocol與NameNode對話。 遠端過程呼叫（RPC，Remote Procedure Call—遠端過程呼叫，它是一種通過網路從遠端計算機程式上請求服務，而不需要了解底層網路技術的協議。）抽象包裝client Protocol和DataNode Protocol。 按照設計，NameNode永遠不會初始化啟用任何RPC。相反，它只響應DataNodes或 clients發出的RPC請求。

8 Robustness

HDFS的主要目標是即使在出現故障時也能可靠地儲存資料。三種常見的故障型別是NameNode故障，DataNode故障和網路分割槽

8.1 Data Disk Failure, Heartbeats and Re-Replication

每個DataNode定期向NameNode傳送Heartbeat訊息。 一個網路分割槽可能導致DataNode的一個子集失去與NameNode的連線。 該NameNode通過Heartbeat訊息的缺失來檢測此情況。 NameNode通過沒有最近的Heartbeats來標記DataNodes為死亡狀態，並且不向它們轉發任何新的IO請求。 註冊為死亡狀態的DataNode的任何資料都不可用於HDFS。 DataNode的死亡可能導致某些塊的複製因子低於其塊的複製因子指定值。 NameNode不斷跟蹤需要複製的塊必要時啟動複製。 重新複製的必要性可能是由於原因很多：DataNode可能變得不可用，副本可能會損壞，DataNode上的硬碟可能會失敗，或者檔案的複製因子可能會增加。

8.2 Cluster Rebalancing

HDFS架構與資料重新平衡方案相容。 一個方案如下，如果DataNode上的可用空間低於某個閾值，則自動將資料從一個DataNode移動到另一個DataNode。 如果對特定檔案有突然的高需求，一個方案可以動態建立額外的副本並重新平衡群集中的其他資料。這些型別的資料重新平衡方案尚未實現。

8.3 Data Integrity

從DataNode獲取的資料塊可能已損壞。 這種損壞可能由於儲存裝置中的故障，網路故障或有缺陷的軟體而發生。 HDFS客戶端軟體實現對HDFS檔案內容的校驗和檢查。 當一個client建立一個HDFS檔案，它計算檔案每個塊的校驗和並存儲這些’校驗和‘於位於同一HDFS名稱空間下的單獨隱藏檔案中。 當客戶端檢索檔案內容，它驗證從每個DataNode收到的資料校驗和是否匹配儲存在其相關聯的校驗和檔案中的資料。 如果沒有，則客戶端可以選擇另一個具有該塊副本的DataNode來檢索該塊。

8.4 Metadata Disk Failure

FsImage和EditLog是HDFS的中心資料結構。 這些檔案的損壞可能導致HDFS例項無法正常執行。 出於這個原因，NameNode可以配置為支援維護FsImage和EditLog的多個副本。 任何FsImage或EditLog的更新會導致每個FsImages和EditLogs都得到同步更新。 這種同步更新FsImage和EditLog的多個副本可能會降低NameNode名稱空間每秒支援事務的速率。 但是，這種降級是可以接受的，因為雖然HDFS應用程式是它本質上是資料密集型的，但它們不是元資料密集型的。 當NameNode重新啟動時，它選擇使用最新的一致的FsImage和EditLog。NameNode計算機是HDFS叢集的單點故障。 如果是NameNode機器出現故障，需要手動干預。 目前，NameNode軟體自動重啟和故障轉移到另一臺機器暫不支援。

8.5 Snapshots

快照支援在特定時刻儲存資料副本。 一種用法快照功能可能是將損壞的HDFS例項回滾到先前已知的正常執行的時間點。 HDFS目前不支援快照，但將來會發布。

9 Data Organization

9.1 Data Blocks

HDFS旨在支援非常大的檔案。 與HDFS相容的應用程式是處理大型資料集的。 這些應用程式只寫入一次他們的資料，但是讀取資料一次或多次，並要求在流式速度下滿足這些讀取。 HDFS支援檔案上的write-once-read-many語義。 HDFS使用的典型塊大小為64MB。 因此，HDFS檔案被切碎為64 MB塊，如果可能，每個塊將會駐留在不同的DataNode上。

9.2 Staging

建立檔案的client請求不會立即到達NameNode。 事實上，最初HDFS client 將檔案資料快取到臨時本地檔案中。 應用程式的寫入被透明地重定向到這個臨時本地檔案。 當本地檔案累積資料時值得超過一個HDFS塊大小，client聯絡NameNode。 NameNode將檔名插入到檔案系統層次結構併為其分配資料塊。 NameNode使用DataNode的標識和目標資料塊的標識來響應客戶端請求。 然後，客戶端將資料塊從本地臨時檔案重新整理到指定的資料節點。 關閉檔案時，臨時本地檔案中剩餘的未重新整理資料將被轉移到DataNode。 然後客戶端向NameNode傳達檔案已關閉。 在此時，NameNode將檔案建立操作提交到永續性儲存中。 如果NameNode在檔案關閉之前死亡，則檔案丟失。 在仔細考慮了目標應用之後，採用了上述方法在HDFS上執行。 這些應用程式需要流式寫入檔案。 如果client寫入遠端檔案直接沒有任何客戶端緩衝，網路速度和擁塞網路大大影響吞吐量。 這種方法並非沒有先例。 之前的分散式檔案系統（例如AFS）使用客戶端快取來提高效能。 一個POSIX要求已經放寬，以實現更高的資料上傳效能。 9.3 Replication Pipelining 當client將資料寫入HDFS檔案時，其資料首先寫入本地檔案在上一節中解釋過。 假設HDFS檔案的複製因子為3。當本地檔案累積出一個完整的使用者資料塊時，客戶端將檢索NameNode中的DataNode列表。 此列表包含即將託管那個塊副本的DataNodes。 然後，客戶端將資料塊重新整理到第一個DataNode。 第一個DataNode開始以小部分（4 KB）接收資料，將每個部分寫入其本地儲存庫並將該部分傳輸到列表中的第二個DataNode。 反過來，第二個DataNode開始接收資料塊的每個部分，將該部分寫入其儲存庫然後將該部分重新整理到第三個DataNode。 最後，第三個DataNode將資料寫入它的本地儲存庫。 因此，DataNode可以從流水線中接收前一個的資料，同時將資料轉發到流水線中的下一個。 因此，資料是從一個DataNode流向下一個。

10 Accessibility

可以通過多種不同方式從應用程式訪問HDFS。 在本地，HDFS提供了一個用於要使用的應用程式的 Java API 。 此Java API的A C語言包裝器也可用。 在此外，還可以使用HTTP瀏覽器瀏覽HDFS例項的檔案。 通過WebDAV協議公開HDFS的工作正在進行。

10.1 FS Shell

HDFS允許以檔案和目錄的形式組織使用者資料。 它提供了一個命令列介面，稱為FS shell，允許使用者與HDFS中的資料進行互動。 該此命令集的語法類似於使用者已經使用的其他shell（例如bash，csh）熟悉。 以下是一些示例操作/命令對： 行動 命令 建立一個名為 / foodir 的目錄 bin / hadoop dfs -mkdir / foodir 刪除名為 / foodir 的目錄 bin / hadoop dfs -rmr / foodir 檢視名為 / foodir / myfile.txt的檔案的內容 bin / hadoop dfs -cat / foodir /myfile.txt檔案 FS shell適用於需要指令碼語言與儲存互動的應用程式資料。

10.2 DFSAdmin

DFSAdmin命令集用於管理HDFS叢集。 這些是僅由HDFS管理員使用的命令。 以下是一些示例動作/命令對： 行動 命令 將群集放在Safemode中bin / hadoop dfsadmin -safemode 輸入生成DataNode列表bin / hadoop dfsadmin -report 重新發布或退役DataNode（s）bin / hadoop dfsadmin -refreshNodes

10.3 Browser Interface

典型的HDFS安裝配置Web伺服器以通過一個可配置的TCP埠公開HDFS名稱空間。 這允許使用者導航HDFS名稱空間並使用Web瀏覽器檢視其檔案的內容。

11 Space Reclamation

11.1 File Deletes and Undeletes

當用戶或應用程式刪除檔案時，不會立即從HDFS中刪除該檔案。相反，HDFS首先將其重新命名為 / trash目錄中的檔案。 該檔案可以恢復只要它留在 /垃圾桶裡 就很快 。 檔案保留在/ trash中以進行配置多少時間。 在 / trash中 生命到期後 ，NameNode將從中刪除該檔案HDFS名稱空間。 刪除檔案會導致與檔案關聯的塊釋放。 請注意，檔案刪除之間可能存在明顯的時間延遲使用者以及HDFS中可用空間相應增加的時間。使用者可以在刪除檔案後取消刪除檔案，只要它保留在 / trash目錄中即可。如果使用者想要取消刪除他/她已刪除的檔案，他/她可以導航 /垃圾目錄並檢索檔案。 在 / trash目錄僅包含的最新副本已刪除的檔案。 在 / trash目錄僅僅是想用一個特別的任何其他目錄功能：HDFS應用指定的策略自動刪除此目錄中的檔案。 該當前預設策略是從 / trash 刪除超過6小時的檔案。 在裡面未來，該政策將通過定義明確的介面進行配置

11.2 Decrease Replication Factor

當檔案的複製因子減少時，NameNode選擇可以刪除的多餘副本。 下一個Heartbeat將此資訊傳輸到DataNode。 該然後，DataNode刪除相應的塊，並顯示相應的可用空間在群集中。 再重申一次，完成setReplication API呼叫與叢集中可用空間出現之間可能會有一段時間延遲。

12 References