HDFS 架構指南 2.6.0 -- 譯

標籤：

HDFS 架構指南 2.6.0

本文是對下面連結中文字的翻譯

http://hadoop.apache.org/docs/r2.6.0/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html

 

簡介

 

HDFS 是一個可以運行在普通硬體上的Distributed File System。跟現有的分布式系統相比，它有不少相似性。然而，區別也是很大的。 HDFS是高度容錯性，設計的初衷就是可在低成本的硬體上部署。HDFS提供高輸送量的訪問，適用於擁有大容量資料集的應用。 HDFS突破了一些POSIX需求，允許了對檔案系統資料的流式訪問。HDFS的初衷是為Apache Nutch 網路搜尋引擎項目作為基礎。目前HDFS是一個Apache Hadoop 的子項目。項目連結是http://hadoop.apache.org/hdfs/.

 

假設和目標

硬體故障

硬體故障是常態，而不是例外。 一個HDFS執行個體可能包含成千上萬的伺服器，每個伺服器都儲存著檔案系統的部分資料。如此眾多的組件以及每個組件都有可能發生故障，這個實際情況疑為這HDFS的一些組件總是不會正常工作的。因此，故障檢測和快速，自動的恢複是HDFS核心的架構目標。

 

資料流式訪問

運行在HDFS上的應用需要流式訪問資料。沒有通過目標的應用運行在通用的檔案系統上。 HDFS設計上，側重於批處理，而不是使用者的互動式操作。 強調的重點是大量資料訪問的高吞吐速率，而不是資料訪問的低延時。POSIX很多硬性的要求並不適用於運行在HDFS上的應用。 POSIX標準在一些關鍵領域已經做了修改，以提高資料吞吐速率。

 

大資料集

運行在HDFS上的應用處理大資料集。 典型的HDFS上的檔案大小從幾個G到幾個T。因此，HDFS為支援大檔案做了最佳化。一方面要再一個叢集中提供比較大的總的資料頻寬，並能擴充到基本個節點，另一方面面一個執行個體應該能支援上千萬個檔案。

 

簡單的彙總模型

HDFS應用對檔案的訪問模式是寫一次，讀多次。一旦一個檔案建立，關閉，檔案就不會在改變了。這個假定簡化了資料彙總問題，方便了資料的高輸送量訪問。一個MapReduce應用或者一個網路爬蟲應用就非常適合這種模式。當然，將來會支援後續附加的檔案寫入模式，已經有一個開發計劃。

 

“移動計算比移動資料要合算”

應用發起的計算在靠近資料的地方運行更加有效率，尤其是資料量巨大的時候，因為這樣減少了網路擁塞，提高了系統總的吞吐效率。移動計算到資料，而不是移動資料到計算啟動並執行地方。應用可以藉助HDFS提供的介面，把自己移動到資料所在的地方。

 

跨多種硬體和軟體平台的可移植性

HDFS的設計允許跨平台的移植性。這個設計促進大量的應用選擇HDFS。

 

NameNode和DataNodes

HDFS 是一個主從架構。一個HDFS叢集包含單個NameNode。 NameNode是一個主伺服器，管理檔案系統的名字空間，控制著用戶端對於檔案的訪問。HDFS包含多個DataNodes，通常是一個叢集中每個節點有一個DataNode。DataNode管理著資料。HDFS對外呈現的是一個檔案系統的名字空間，使用者的資料存放於檔案之中。HDFS內部則是把一個檔案分成一個或者多個檔案塊，儲存於一組DataNodes中。NameNode負責執行檔案系統的操作，比如開啟檔案，關閉檔案，重新命名檔案或者目錄，也決定了內部的檔案塊和DataNode的映射。DataNodes負責提供檔案系統用戶端的資料讀寫請求，和執行檔案塊的建立，刪除，複製（響應NameNode指令）

 

 NameNode和DataNode可以運行在普通機器上的軟體。這些機器通常是運行GNU/Linux作業系統。HDFS用Java 語言編寫。任何支援Java的機器都可以運行NameNode和DataNode。用Java這種感覺可移植性性的語言意味著HDFS可以部署在各種類型的機器上。一個典型的部署有一個單獨的機器只運行NameNode，而其他叢集中的機器每個運行一個DataNode。HDFS的架構並沒有限制一台機器上可以運行多個DataNodes，但是，很少有這樣部署的。

 

一個叢集中只有一個NameNode極大地簡化了系統的架構。NameNode控制和管理著所有的HDFS中繼資料。使用者資料永遠也不會儲存到NameNode上。

 

檔案系統的命名空間

HDFS支援傳統的檔案系統的層級架構。一個使用者或者應用程式可以建立目錄，進而在目錄中隱藏檔。檔案系統給的名字空間層級架構跟現有的檔案系統非常類似。檔案可以長久，刪除，從一個目錄移動到另一個目錄，或者重新命名。HDFS目前還沒有實現使用者的配額機制。HDFS不支援軟永久連結，儘管架構上並沒有限制這些功能的實現。

 

NameNode維護著一個檔案系統的名字空間。對檔案系統名字空間或者屬性的任何改變都記錄在NameNode中。應用能指定一個檔案可以有多少個副本。一個檔案副本的數目成為檔案的複製因子，儲存在NameNode中。

資料複製

在大的叢集中，HDFS可以跨機器可靠地儲存非常大的檔案。每個檔案被儲存為一系列的塊。除了最後以個塊，其他所有的檔案塊大小都一樣。為了容錯，檔案塊會被複製。每個檔案的塊的大小和複製因子都可以單獨配置。一個應用可以指定一個檔案的副本的數目，複製因子既可以在檔案建立的時候指定，也可以檔案建立以後修改。HDFS中的檔案只能寫一次，任何時候只能有一個寫的執行個體。

 

NameNode負責所有關於塊的複製 決定。它周期性地從叢集中每個DataNode接收心跳訊號和塊彙報。心跳訊號標記著DataNode工作正常，塊彙報包含了DataNode上所有的檔案塊。

 

 

 

副本放置： 首孩步驟

副本的放置對於HDFS的可靠性和效能至關重要。副本放置的最佳化是HDFS區別於其他Distributed File System的重要標誌。這個特性需要大量的調試和經驗。機架感知的副本放置策略的目的是提高資料的可靠性，可用性，並能節省網路頻寬的使用。目前的實現策略是朝著這個目標邁出的第一步。短期目的是在生產系統上驗證，更多的瞭解其行為，為測試和研究更加複雜的策略打好基礎。

 

大型HDFS應用執行個體運行在一個跨多個機架的電腦叢集上。不同機架上的兩個節點的資料互動需要通過交換器。大多數情況下，同一個機架上的兩個節點之間的網路頻寬高於不同機架上的頻寬。

 

NameNode 根據Hadoop Rack Awareness 流程確定了每個DataNode的機架Id。 一個簡單可是不太最佳化的策略是把副本放在不同的機架上。在一個機架出故障的時候，資料不會丟失，而且，讀取資料的時候，可以充分利用多個機架的頻寬。這個策略可以平滑的把副本放置在叢集中的機器上，在組件故障是容易實現負載平衡。然而，這個策略提高了寫檔案的成本，因為每次寫操作都需要把檔案塊傳輸到多個機架。

 

通常情況下，當副本因子參數設為3的時候，HDFS放置的策略是吧一個副本放到同一個機架上的節點上，另外兩個放到跟這個機架不同的同一個機架的兩個不同節點上。這策略節省了跨機架的流量，提升了寫檔案的效能。機架出故障的機率遠小於一個節點出故障的機率，因而該策略沒有影響資料的可靠性和可用性。它減少了在讀資料的時候網路頻寬的使用，因為一個檔案塊放置在了兩個不同的機架上，而不是說那個。在此策略下，檔案的複製不會平滑的分布到不同的機架上。 1/3的副本在同一個節點上，2/3的副本在同一個機架上， 另外的1/3平滑的分布在剩餘的機架上。該策略提高了寫的效能，但並沒有犧牲資料的可靠性和讀取的效能。

 

副本的選擇

為了減少頻寬的使用和讀取的延遲，HDFS盡量讀取跟reader接近的副本。同節點，同機架，同機房的副本優先讀取。

 

安全模式

啟動的時候，NameNode進入一個安全模式。在安全模式中，不會進行資料的複製。NameNode從DataNode接收心跳和塊彙報資訊。 一個塊彙報資訊包含一個DataNode含有的所有的塊的資訊。每個塊都有一個指定的最少數量的副本。只有當一個塊指定的最少數量的副本都報道了，此塊才認為是安全複製了。當一定比例的安全複製的塊報道了，再過30秒後，NameNode退出安全模式。然後，它檢查所有尚未安全複製的塊，進而複製。

 

檔案系統中繼資料的持久化

NameNode儲存了HDFS的名子空間。NameNode用一個事務記錄(EditLog)來持久性地記錄檔案系統的每一次改變。 比如，在HDFS中建立一個檔案時，NameNode會在EditLog中插入一條記錄。同樣，改變複製參數也會在EditLog中增加一條記錄。NameNode會在本地檔案系統中儲存EditLog。整個檔案系統的名字空間，包含檔案塊和檔案的映射，以及檔案系統給的屬性，儲存在一個叫FsImage的檔案中，同樣儲存於本地檔案系統中。

 

NameNode在記憶體中維護著整個檔案系統命名空間的檔案區塊對應。關鍵中繼資料有較緊湊的設計，比如， 一個4GB的RAM可以儲存大量的檔案和目錄。當NameNode啟動的時候，它先讀取FsImage和EditLog，把所有的事務施加到FsImge上。 然後，儲存一個新的FsImge。然後丟掉舊的EditLog，因為之前所有的事務都已經固化到FsImage中。這個過程成為一個checkpoint. 目前的實現，checkpoint只在NameNode 啟動的時候執行。周期性的checkpoint是以後要實現的功能。

 

DataNode在本地檔案系統中儲存HDFS資料。DataNode沒有HDFS檔案的概念，它只是在本地檔案系統中儲存了每個檔案塊的資料。DataNode不會在同一個目錄中建立所有的檔案，而是用啟發學習法的確定每個目錄有多少個檔案合適。當一個DataNode啟動的時候，它首先掃描本地的檔案系統，產生一個含所有HDFS資料區塊的列表發送給NameNode,這就是塊報告 BlockReport

 

通訊協議

所有的HDFS通訊協議基於TCP/IP. 一個用戶端通過一個可配置的TCP連接埠號碼與NameNode機器建立連線協定是 ClientProtocol。 DataNode和NameNode之間的協議是DataNode protocol。 一個RPC抽象隱藏了這兩種協議。 NameNode從不會發起RPC請求，總是響應來自於DataNode和用戶端的請求。

 

健壯性

HDFS組要的目標是實現資料存放區的可靠性，即使在發生故障的時候。這裡主要說三種故障： NameNode故障， DataNode故障， 和網路分割 partitions。

 

資料磁碟故障，心跳和重新複製

每個DataNode為周期性地給NameNode發送心跳訊號。 一個網路故障能引起一組DataNode失去跟NameNode的串連。NameNode檢測到這種情況，標記響應的DataNode為失效，後面就不會轉寄新的Io請求道失效的DataNode上去了。任何在失效的DataNode上的資料都不能訪問了。 失效的DataNode可能會導致一些檔案塊的複製因子遠小於指定的值，這時，NameNode 會觸發新的複製。重新複製的必要性有多種原因： 一個DataNode不能訪問了，一個副本損壞了，一個硬碟出故障了，或者一個檔案的複製因子提高了

 

叢集重新平衡

HDFS架構跟資料的重新平衡是相容的。資料可能從一個DataNode移動到另外一個，如果剩餘的空間到了一定的門檻。對某個檔案的讀取請求突然大幅提升的時候，更多的副本可能會建立出來。這些還沒實現呢。

 

資料完整性

從DataNode中提取的資料可能是損壞的。原因可能是存放裝置的故障，網路問題，或者軟體問題。HDFS用戶端實現對HDFS資料的校正。當用戶端建立一個HDFS時，它會為每一個塊算一個校正碼，並把校正碼儲存在一個單獨的隱藏的檔案中。當用戶端取得檔案內容時，校正碼會重新計算，並跟之前儲存的校正碼比較。如果不一致，用戶端就從另外一個DataNode讀取資料區塊。

 

中繼資料磁碟故障

FSImge和EditLog 是HDFS的中心資料結構。這兩個檔案出問題，會使得HDFS執行個體出問題。處於這樣的原因，NameNode能配置成支援維護多個FsImage和EditLog。 任何的FsImage、EditLog的更改，都同步到其他的副本上去。這種同步可能會降低HDFS的效能，然而，這是可以接受的，因為HDFS是大量資料操作，而不是大量中繼資料操作。當NameNode啟動時，他選擇最近的一致的FsImage和EditLog使用。

 

在2.6 時， NameNode仍舊是single point of failure

 

快照

HDFS目前不支援Snapshot

 

 

資料的組織：

資料區塊

HDFS設計支援非常大的檔案。使用HDFS的應用會處理非常大的資料。這些應用一次寫好資料後，讀取多次，而且需要這些讀取有流式讀取的速度。HDFS 支援一次寫，多次讀。一個典型的塊尺寸是64M。 因此，HDFS檔案被分割成64M的塊，分部在不同的DataNode上。

 

Staging 分布

一個用戶端要求建立一個檔案並不能立即能夠訪問到NameNode。實際上，HDFS首先把檔案資料緩衝到本地的臨時檔案中。應用的寫操作被重新導向到這些臨時檔案。當本地檔案大小達到一個資料區塊的尺寸的時候，用戶端對NameNode發起請求。NameNode把檔案名稱字放到檔案層級中，並分配一個檔案塊。 NameNode回複用戶端，返回的資料包含DataNode的標誌和目標資料區塊。然後用戶端把資料從臨時檔案儲存體到DataNode上。 當一個檔案關閉的時候，剩餘的尚沒有寫入檔案塊的臨時檔案中的資料會被轉移到DataNode中。用戶端然後告訴NameNode檔案關閉了。這時，NameNode把檔案的建立操作固定下來。如果NameNode出故障先於檔案關閉，檔案就丟失了。

 

選擇上面的方法經過了對運行於HDFS的應用的深思熟慮。 這些應用需要流式寫操作到檔案。如果一個檔案直接寫一個遠程檔案，沒有用戶端的緩衝，那麼，網路速度和擁塞會影響寫入操作的輸送量。當然，這個方法也不是首創的，早先的Distributed File System， AFS，已經用用戶端緩衝來提高效能。 為了實現資料轉送更高的效能，POSIX規範沒有完全遵守。

 

複製的流水線

當一個用戶端寫資料到HDFS檔案中是，像上文介紹的，資料先寫到一個本地檔案中。加入HDFS檔案有個複製參數為3。當本地檔案積累到一個塊的資料後，用戶端從NameNode擷取一組DataNode資訊。用戶端就把資料寫到第一個DataNode。第一個DataNode開始接收資料，一部分一部分的，先寫到當地的檔案，然後把資料轉移到第二個DataNode。第二個DataNode如法炮製。最後，第三個DataNode把資料寫入本地檔案系統。所以，一個DataNode可以從流水線中前面的DataNode接收資料，同時，把資料轉寄到流水線中的另外DateNode。

 

可訪問性

應用程式可以用多種方式訪問HDFS中的資料。原生的，HDFS提供了檔案系統JavaAPI http://hadoop.apache.org/docs/current/api/. C語言的包轉也有。而且，HTTP瀏覽器也可以瀏覽HDFS中的檔案。 WebDAV協議的支援正在構建之中。

 

FS Shell

HDFS可以讓使用者資料群組織為檔案和目錄。它提供了一個命令列的介面，叫做FS Shell。使用者可以通過FS Shell與HDFS中的資料互動。 文法於其他shell 類似。

建立 /foodir             bin/hadoop dfs –mkdir /foodir

刪除/foodir              bin/hadoop dfs –rmr /foodir

看一個檔案內容 /foodir/myfile.txt       bin/hadoop dfs –cat /foodir/myfile.txt

 

FS Shell 主要為指令碼語言用來與儲存的資料互動。

 

DFSAdmin

DFSAdmin命令主要管理HDFS叢集。 這些命令是HDFS管理員使用的。

把叢集置於安全模式              bin/hadoop dfsadmin –safemode enter

產生DataNode的列表           bin/haddop dfsadmin –report

重新整理DataNode                          bin/haddop dfsadmin –refershNodes ？？？

 

瀏覽器介面

通常HDFS會配置一個網路伺服器，通過一個TCP連接埠可以訪問HDFS命名空間。 使用者可以通過瀏覽器瀏覽HDFS目錄，產看檔案內容

 

 

空間回收

檔案刪除和反刪除

 

當使用者或者應用刪除一個檔案時，檔案並不會立即從HDFS中刪除。而是，先被重新命名到/trash目錄。只要它還在transh目錄，就可以很快恢複。留在該目錄中的時間可以配置。時間過了後，NameNode從名字空間中刪除。進而跟檔案對應的檔案塊釋放。需要注意的是，從一個檔案被是使用者刪除到HDFS系統空間增加會有相當的延遲。

 

使用者可以恢複一個檔案，只要它還在/trash目錄中。方法是進入/trash 目錄，訪問檔案。Core-site.xml中的fs.trash.interval 參數控制著檔案在/trash目錄中的時間。

 

降低副本因子

當副本因子減小的時候，NameNode選擇可以刪除的多出來的副本。下一次心跳的時候，就把這個資訊傳遞到DataNode。DateNode就刪除相對應的檔案塊。

 

References

Hadoop JavaDoc API.

HDFS source code: http://hadoop.apache.org/version_control.html

 

HDFS 架構指南 2.6.0 -- 譯