作者 | 大尊

hdfs是hadoop的分散式檔案系統，即Hadoop Distributed Filesystem。下面主要講下HDFS設計中的比較重要的點，使讀者能透過簡短的文章一窺HDFS的全貌，適合對HDFS有一點了解，但是對HDFS又感到困惑的初學者。本文主要參考的是hadoop 3.0的官方文件。

連結：[http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html](http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html)

當資料集的大小超過了一臺物理機所能儲存的能力時，就需要將它進行分割槽並儲存到若干不同的獨立的計算機上，其中管理跨多臺計算機儲存的檔案系統稱為分散式檔案系統。

#### 目錄

-   使用HDFS的場景
    
-   HDFS的工作模式
    
-   檔案系統名稱空間（namespace）
    
-   資料複製
    
-   檔案系統後設資料的持久化
    
-   通訊協議
    
-   健壯性
    
-   資料組織
    
-   可訪問性
    
-   儲存空間回收

### 1、使用HDFS的場景

HDFS適合於以流式資料訪問模式來儲存超大的檔案。即一次寫入，多次讀取，在資料集上長時間進行各種分析，每次分析都涉及該資料集資料的大部分甚至全部，對於超大檔案，hadoop目前以支援儲存PB級資料。

HDFS並不適合要求低時間延遲資料訪問的應用，因為HDFS是為高資料吞吐量應用而最佳化的，這就有可能以時間延遲大為代價。

HDFS檔案系統所能儲存的檔案總數受限於namenode的記憶體容量，根據經驗，100百萬的檔案，且每個檔案佔一個資料塊，那至少需要300MB的記憶體。

目前hadoop檔案可能只有一個writer,而且寫操作總是將資料新增在檔案末尾，不支援在檔案的任意位置進行修改。

相對於普通檔案系統的資料塊，HDFS也有塊的概念，預設是128MB，HDFS上的檔案也被劃分成塊大小的多個分塊，作為獨立的儲存單元，不過HDFS中小於一個塊大小的檔案不會佔據整個塊的空間。如果沒有特別指出，文中提到的塊特指HDFS的塊。

為何HDFS的塊如此之大，其目的是為了最小化定址開銷。這個數也不能設定的過大，mapreduce中的map任務通常一次只處理一個塊中的資料，因此如果任務數太少，作業的執行速度就會比較慢。

### 2、HDFS的工作模式

HDFS採用master/slave架構，即一個namenode(管理者)多個datanode(工作者)。

namenode負責管理檔案系統的名稱空間。維護著檔案系統樹和整個樹內所有的檔案和目錄，這些資訊都儲存在兩個檔案中，名稱空間映象檔案和編輯日誌檔案。namenode也記錄了每個檔案中各個塊所在的資料節點資訊。datanode是檔案系統的工作節點，它們需要儲存並檢索資料塊（受客戶端或namenode排程），並定期向namenode傳送它們所儲存的塊的列表。

如果沒有namenode,檔案系統將無法使用，因為我們不知道如何根據datanode的塊重建檔案，所以對namenode進行容錯是非常重要的。為此hadoop提供了兩種機制。

第一種機制是備份那些組成檔案系統後設資料持久狀態的檔案。一般，在將持久化檔案寫入本地磁碟的同時，寫入遠端掛載的NFS。

第二種方法是執行一個輔助namenode，這個輔助namenode定期透過編輯日誌合併名稱空間映象，並在本地儲存合併後的名稱空間映象的副本，在namenode發生故障時啟用。但是在主節點失效時，難免會丟失部分資料，這時可以把儲存在NFS的namenode後設資料複製到輔助的namenode上作為新的namenode執行。這其中涉及到故障轉移的機制。稍後會做一點分析。

### 3、檔案系統名稱空間（namespace）

HDFS支援傳統的層次型檔案組織結構。使用者或者應用程式可以建立目錄，然後將檔案儲存在這些目錄裡。

檔案系統名字空間的層次結構和大多數現有的檔案系統類似：使用者可以建立、刪除、移動或重新命名檔案。HDFS支援使用者磁碟配額和訪問許可權控制，目前還不支援硬連結和軟連結。但是HDFS架構並不妨礙實現這些特性。

Namenode負責維護檔案系統的名字空間，任何對檔案系統名字空間或屬性的修改都將被Namenode記錄下來。應用程式可以設定HDFS儲存的檔案的副本數目。檔案副本的數目稱為檔案的副本系數，這個資訊也是由Namenode儲存的。

### 4、資料複製

HDFS被設計成能夠在一個大叢集中跨機器可靠地儲存超大檔案。它將每個檔案儲存成一系列的資料塊，除了最後一個，所有的資料塊都是同樣大小的。

為了容錯，檔案的所有資料塊都會有副本。每個檔案的資料塊大小和副本系數都是可配置的。 應用程式可以指定某個檔案的副本數目。副本系數可以在檔案建立的時候指定，也可以在之後改變。

HDFS中的檔案都是一次性寫入的，並且嚴格要求在任何時候只能有一個寫入者。

Namenode全權管理資料塊的複製，它週期性地從叢集中的每個Datanode接收心跳訊號和塊狀態報告(Blockreport)。當一個Datanode啟動時，它會掃描本地檔案系統，產生一個這些本地檔案對應的所有HDFS資料塊的列表，然後作為報告傳送到Namenode，這個報告就是塊狀態報告。接收到心跳訊號意味著該Datanode節點工作正常。塊狀態報告包含了一個該Datanode上所有資料塊的列表。

資料塊列表獲取。檢視資料塊的健康狀態：hdfs fsck / -files -block或者hdfs fsck /

![](https://user-gold-cdn.xitu.io/2019/7/18/16c03237f7f9c9bb?w=1080&h=400&f=png&s=224708)

HDFS的資料塊儲存在以_blk為字首名的檔案中，每個塊還有一個相關的帶有.meta字尾的後設資料檔案，後設資料檔案包括頭部和該塊各區段的一系列校驗和。

當資料塊的數量增加到一定規模時，datanode會建立一個子目錄來存放新的資料塊及後設資料資訊。如果當前目錄已經儲存了64個（透過dfs.datanode.numlocks屬性設定）資料塊時，就建立一個子目錄，終極目標是設計一顆高扇出的目錄樹。

如果dfs.datanode.data.dir屬性指定了不同磁碟的多個目錄，那麼資料塊會以輪轉（round-robin）的方式寫入到各個目錄中。

在每個datanode上也會執行一個塊掃描器，定期檢測本節點上的所有塊，從而在客戶端讀取到壞塊之前就及時的檢測和修復壞塊。預設情況下每隔3週會測試塊的狀態，並對可能的故障進行修復。

使用者可以透過http://datanode:50070/blockScannerReport獲取該datanode的塊檢測報告。

**副本存放**

副本的存放是HDFS可靠性和效能的關鍵。最佳化的副本存放策略是HDFS區分於其他大部分分散式檔案系統的重要特性。這種特性需要做大量的調優，並需要經驗的積累。HDFS採用一種稱為機架感知(rack-aware)的策略來改進資料的可靠性、可用性和網路頻寬的利用率。目前實現的副本存放策略只是在這個方向上的第一步。

透過一個機架感知的過程，Namenode可以確定每個Datanode所屬的機架id。一個簡單但沒有最佳化的策略就是將副本存放在不同的機架上。這樣可以有效防止當整個機架失效時資料的丟失，並且允許讀資料的時候充分利用多個機架的頻寬。這種策略設定可以將副本均勻分佈在叢集中，有利於當元件失效情況下的負載均衡。但是，因為這種策略的一個寫操作需要傳輸資料塊到多個機架，這增加了寫的代價。

在大多數情況下，副本系數是3，HDFS的存放策略是將一個副本存放在本地機架的節點上，一個副本放在同一機架的另一個節點上，最後一個副本放在不同機架的節點上。這種策略減少了機架間的資料傳輸，這就提高了寫操作的效率。

而在現實中，在hadoop2.0中，datanode資料副本存放磁碟選擇策略有兩種方式：

第一種是沿用hadoop1.0的磁碟目錄輪詢方式，實現類：

RoundRobinVolumeChoosingPolicy.java

第二種是選擇可用空間足夠多的磁碟方式儲存，實現類：AvailableSpaceVolumeChoosingPolicy.java

第二種策略對應的配置項是：

![](https://user-gold-cdn.xitu.io/2019/7/18/16c0323bd122b48e?w=1080&h=341&f=png&s=110213)

如果不配置，預設使用第一種方式，既輪詢選擇磁碟來儲存資料副本，但是輪詢的方式雖然能夠保證所有磁碟都能夠被使用，但是經常會出現各個磁碟直接資料儲存不均衡問題，有的磁碟儲存得很滿了，而有的磁碟可能還有很多儲存空間沒有得到利用，所有在hadoop2.0叢集中，最好將磁碟選擇策略配置成第二種，根據磁碟空間剩餘量來選擇磁碟儲存資料副本，這樣一樣能保證所有磁碟都能得到利用，還能保證所有磁碟都被利用均衡。

在採用第二種方式時還有另外兩個引數會用到：

![](https://user-gold-cdn.xitu.io/2019/7/18/16c03240e6d5e575?w=1080&h=399&f=png&s=118771)

預設值是10737418240，既10G，一般使用預設值就行。官方解釋為，首先計算出兩個值，一個是所有磁碟中最大可用空間，另外一個值是所有磁碟中最小可用空間，如果這兩個值相差小於該配置項指定的閥值時，則就用輪詢方式的磁碟選擇策略選擇磁碟儲存資料副本。

![](https://user-gold-cdn.xitu.io/2019/7/18/16c0324333bd0d58?w=1080&h=327&f=png&s=92391)

預設值是0.75f，一般使用預設值就行。官方解釋為，有多少比例的資料副本應該儲存到剩餘空間足夠多的磁碟上。該配置項取值範圍是0.0-1.0，一般取0.5-1.0，如果配置太小，會導致剩餘空間足夠的磁碟實際上沒分配足夠的資料副本，而剩餘空間不足的磁碟取需要儲存更多的資料副本，導致磁碟資料儲存不均衡。

**副本選擇**

為了降低整體的頻寬消耗和讀取延時，HDFS會盡量讓讀取程式讀取離它最近的副本。如果在讀取程式的同一個機架上有一個副本，那麼就讀取該副本。如果一個HDFS叢集跨越多個資料中心，那麼客戶端也將首先讀本地資料中心的副本。

**安全模式**

Namenode啟動後會進入一個稱為安全模式的特殊狀態。 處於安全模式的Namenode是不會進行資料塊的複製的。Namenode從所有的 Datanode接收心跳訊號和塊狀態報告。塊狀態報告包括了某個Datanode所有的資料塊列表。每個資料塊都有一個指定的最小副本數。

當Namenode檢測確認某個資料塊的副本數目達到這個最小值(最小值預設是1，由dfs.namenode.replication.min屬性設定)，那麼該資料塊就會被認為是副本安全(safely replicated)的；在一定百分比（這個引數可配置,預設是0.999f,屬性值為dfs.safemode.threshold.pct）的資料塊被Namenode檢測確認是安全之後（加上一個額外的30秒等待時間），Namenode將退出安全模式狀態。接下來它會確定還有哪些資料塊的副本沒有達到指定數目，並將這些資料塊複製到其他Datanode上。

如果datanode丟失的block達到一定的比例,namenode就會一直處於安全模式即只讀模式。

當namenode處於安全模式時，該怎麼處理？

找到問題所在，進行修復（比如修復當機的datanode)。

或者可以手動強行退出安全模式（沒有真正解決問題）： hdfs namenode --safemode leave。

在hdfs叢集正常冷啟動時，namenode也會在safemode狀態下維持相當長的一段時間，此時你不需要去理會，等待它自動退出安全模式即可。

使用者可以透過dfsadmin -safemode value 來操作安全模式，引數value的說明如下：

enter - 進入安全模式

leave - 強制NameNode離開安全模式

get - 返回安全模式是否開啟的資訊

wait - 等待，在執行某條命令前先退出安全模式。

### 5、檔案系統後設資料的持久化

Namenode上儲存著HDFS的名字空間。對於任何對檔案系統後設資料產生修改的操作，Namenode都會使用一種稱為EditLog的事務日誌記錄下來。例如，在HDFS中建立一個檔案，Namenode就會在Editlog中插入一條記錄來表示；同樣地，修改檔案的副本系數也將往Editlog插入一條記錄。Namenode在本地作業系統的檔案系統中儲存這個Editlog。

整個檔案系統的名字空間，包括資料塊到檔案的對映、檔案的屬性等，都儲存在一個稱為FsImage的檔案中，這個檔案也是放在Namenode所在的本地檔案系統上。

Namenode在記憶體中儲存著整個檔案系統的名字空間和檔案資料塊對映(Blockmap)的映像(即FsImage)。這個關鍵的後設資料結構設計得很緊湊，因而一個有4G記憶體的Namenode足夠支撐大量的檔案和目錄。

當Namenode啟動時，或者檢查點達到配置檔案中的閥值，它從硬碟中讀取Editlog和FsImage，將所有Editlog中的事務作用在記憶體中的FsImage上，並將這個新版本的FsImage從記憶體中儲存到本地磁碟上，然後刪除舊的Editlog，因為這個舊的Editlog的事務都已經作用在FsImage上了。這個過程稱為一個檢查點(checkpoint)。

hdfs dfsadmin -fetchImage fsimage.backup

//手動從namenode獲取最新fsimage檔案，並儲存為本地檔案。

因為編輯日誌會無限增長，那麼恢復編輯日誌的過程就會比較長，解決方案是，執行輔助namenode,為主namenode記憶體中的檔案系統後設資料建立檢查點。最終主namenode擁有最新的fsimage檔案和更小的edits檔案。

這也解釋了輔助namenode和主namenode擁有相近記憶體需求的原因（輔助namenode也需要把fsimage檔案載入記憶體）。

建立檢查點的觸發條件受兩個配置引數控制，

dfs.namenode.checkpoint.period屬性（輔助namenode每隔一段時間就建立檢查點，單位s）。dfs.namenode.checkpoint.txns,如果從上一個檢查點開始編輯日誌大小達到多少的事務數時，建立檢查點。

在主namenode發生故障時（假設沒有備份），就可以從輔助的namenode上恢復資料。有兩種實現方式。

方法一，將相關的儲存目錄複製到新的namenode中 。

方法二，使用-importCheckpoint選項啟動namenode守護程式，從而將輔助namenode用作新的主namenode,有個前提時，dfs.namenode.dir屬性定義的目錄中沒有後設資料時。

### 6、通訊協議

所有的HDFS通訊協議都是建立在TCP/IP協議之上。客戶端透過一個可配置的TCP埠連線到Namenode，透過ClientProtocol協議與Namenode互動。而Datanode使用DatanodeProtocol協議與Namenode互動。

一個遠端過程呼叫(RPC)模型被抽象出來封裝ClientProtocol和Datanodeprotocol協議。在設計上，Namenode不會主動發起RPC，而是響應來自客戶端或 Datanode 的RPC請求。

### 7、健壯性

HDFS的主要目標就是即使在出錯的情況下也要保證資料儲存的可靠性。

常見的三種出錯情況是：Namenode出錯, Datanode出錯和網路割裂(network partitions)。

心跳檢測,磁碟資料錯誤和重新複製。

每個Datanode節點週期性地向Namenode傳送心跳訊號。網路割裂可能導致一部分Datanode跟Namenode失去聯絡。Namenode透過心跳訊號的缺失來檢測這一情況，並將這些近期不再傳送心跳訊號Datanode標記為當機，不會再將新的IO請求發給它們。任何儲存在當機Datanode上的資料將不再有效。

Datanode的當機可能會引起一些資料塊的副本系數低於指定值，Namenode不斷地檢測這些需要複製的資料塊，一旦發現就啟動複製操作。

設定合適的datanode心跳超時時間，避免用datanode不穩定導致的複製風暴。

在下列情況下，也可能需要重新複製：某個Datanode節點失效，某個副本遭到損壞，Datanode上的硬碟錯誤，或者檔案的副本系數增大。

**叢集均衡（針對datanode）**

HDFS的架構支援資料均衡策略。如果某個Datanode節點上的空閒空間低於特定的臨界點，按照均衡策略系統就會自動地將資料從這個Datanode移動到其他空閒的Datanode。

個檔案的請求突然增加，那麼也可能啟動一個計劃建立該檔案新的副本，並且同時重新平衡叢集中的其他資料。這個均衡策略目前還沒有實現。

**資料完整性（針對datanode）**

從某個Datanode獲取的資料塊有可能是損壞的，損壞可能是由Datanode的儲存裝置錯誤、網路錯誤或者軟體bug造成的。HDFS客戶端軟體實現了對HDFS檔案內容的校驗和(checksum)檢查。

當客戶端建立一個新的HDFS檔案，會計算這個檔案每個資料塊的校驗和，並將校驗和作為一個單獨的隱藏檔案儲存在同一個HDFS名字空間下。當客戶端獲取檔案內容後，它會檢驗從Datanode獲取的資料跟相應的校驗和檔案中的校驗和是否匹配，如果不匹配，客戶端可以選擇從其他Datanode獲取該資料塊的副本。

**後設資料磁碟錯誤（針對namenode出錯）**

FsImage和Editlog是HDFS的核心資料結構。如果這些檔案損壞了，整個HDFS例項都將失效。因而，Namenode可以配置成支援維護多個FsImage和Editlog的副本。任何對FsImage或者Editlog的修改，都將同步到它們的副本上。這種多副本的同步操作可能會降低Namenode每秒處理的名字空間事務數量。然而這個代價是可以接受的，因為即使HDFS的應用是資料密集的，它們也非後設資料密集的。當Namenode重啟的時候，它會選取最近的完整的FsImage和Editlog來使用。

另外一個可選方案是透過共享儲存NFS或一個分散式編輯日誌（也叫journal）實現多namenode節點(HA)，來增強故障恢復能力。

在HDFS HA的實現中，配置了一對active-standby的namenode,當活動的namenode失效，備用的namenode就會接管它的任務並開始服務於客戶端的請求。

實現HA需要在架構上做如下修改：

namenode之間透過高可用共享儲存實現編輯日誌的共享，當備用namenode接管工作之後，它將通讀共享編輯日誌直到末尾，實現與active namenode狀態同步，並繼續讀取由活動namenode寫入的新條目。

datanode需要同時向兩個namenode傳送資料塊處理報告，因為資料塊對映資訊存在namenode的記憶體，而非硬碟。

客戶端使用特定的機制處理namenode的失效，這一機制對於使用者是透明的。

輔助namenode的角色被namenode所包含，備用namenode為活動的namenode名稱空間設定週期性檢查。

**快照**

快照支援某一特定時刻的資料的複製備份。利用快照，可以讓HDFS在資料損壞時恢復到過去一個已知正確的時間點。

### 8、資料組織

**資料塊**

HDFS被設計成支援大檔案，適用HDFS的是那些需要處理大規模的資料集的應用。這些應用都是隻寫入資料一次，但卻讀取一次或多次，並且讀取速度應能滿足流式讀取的需要。HDFS支援檔案的“一次寫入多次讀取”語義。一個典型的資料塊大小是128MB。因而，HDFS中的檔案總是按照128M被切分成不同的塊，每個塊儘可能地儲存於不同的Datanode中。

**流水線複製**

當客戶端向HDFS檔案寫入資料的時候，一開始是寫到本地臨時檔案中。假設該檔案的副本系數設定為3，當本地臨時檔案累積到一個資料塊的大小時，客戶端會從Namenode獲取一個Datanode列表用於存放副本。然後客戶端開始向第一個Datanode傳輸資料，第一個Datanode一小部分一小部分(4 KB)地接收資料，將每一部分寫入本地倉庫，並同時傳輸該部分到列表中第二個Datanode節點。第二個Datanode也是這樣，一小部分一小部分地接收資料，寫入本地倉庫，並同時傳給第三個Datanode。最後，第三個Datanode接收資料並儲存在本地。

因此，Datanode能流水線式地從前一個節點接收資料，並在同時轉發給下一個節點，資料以流水線的方式從前一個Datanode複製到下一個。

### 9、可訪問性

HDFS給應用提供了多種訪問方式。使用者可以透過Java API介面訪問，也可以透過C語言的封裝API訪問，還可以透過瀏覽器的方式訪問HDFS中的檔案。透過WebDAV協議訪問的方式正在開發中。

**DFSShell**

HDFS以檔案和目錄的形式組織使用者資料。它提供了一個命令列的介面(DFSShell)讓使用者與HDFS中的資料進行互動。命令的語法和使用者熟悉的其他shell(例如 bash, csh)工具類似。下面是一些動作/命令的示例：

![](https://user-gold-cdn.xitu.io/2019/7/18/16c0322ab20667da?w=936&h=493&f=png&s=115064)

**DFSAdmin**

DFSAdmin 命令用來管理HDFS叢集。這些命令只有HDSF的管理員才能使用。下面是一些動作/命令的示例：

![](https://user-gold-cdn.xitu.io/2019/7/18/16c0322ab23441c8?w=933&h=442&f=png&s=98534)

**瀏覽器介面**

一個典型的HDFS安裝會在一個可配置的TCP埠開啟一個Web伺服器用於暴露HDFS的名字空間。使用者可以用瀏覽器來瀏覽HDFS的名字空間和檢視檔案的內容。

[http://ip:50070](http://ip:50070/)

### 10、儲存空間回收

**檔案的刪除和恢復**

當垃圾回收生效時，透過fs shell刪除的檔案並沒有立刻從HDFS中刪除。實際上，HDFS會將這個檔案重新命名轉移到user//.Trash目錄。只要檔案還在.Trash目錄中，該檔案就可以被迅速地恢復。檔案在Trash中儲存的時間是可配置的，當超過這個時間時，Namenode就會將該檔案從名字空間中刪除。刪除檔案會使得該檔案相關的資料塊被釋放。注意，從使用者刪除檔案到HDFS空閒空間的增加之間會有一定時間的延遲。

只要被刪除的檔案還在.Trash目錄中，使用者就可以恢復這個檔案。如果使用者想恢復被刪除的檔案，他/她可以瀏覽.Trash目錄找回該檔案。

**減少副本系數**

當一個檔案的副本系數被減小後，Namenode會選擇過剩的副本刪除。下次心跳檢測時會將該資訊傳遞給Datanode。Datanode遂即移除相應的資料塊，叢集中的空閒空間加大。同樣，在呼叫setReplication API結束和叢集中空閒空間增加間會有一定的延遲。

【本文為數瀾使用者原創內容，轉載時必須標註文章的來源，文章連結，文章作者等基本資訊】

淺析HDFS架構和設計

相關文章