Hadoop分佈式文件系統:結構與設計

Hadoop分佈式文件系統:結構與設計

目錄

 

1. 介紹

Hadoop 分佈式文件系統 (HDFS)是一個設計爲用在普通硬件設備上的分佈式文件系統。它與現有的分佈式文件系統有很多近似的地方,但又和這些文件系統有很明顯的不同。HDFS是高容錯的,設計爲部署在廉價硬件上的。HDFS對應用程序的數據提供高吞吐量,而且適用於那些大數據集應用程序。HDFS開放了一些POSIX的必須接口,容許流式訪問文件系統的數據。HDFS最初是爲了Apache Nutch網絡搜索引擎項目的下層構件而設計的。是Hadoop項目的一部分,而這又是Apache Lucene項目的一部分。本項目的地址是:http://projects.apache.org/projects/hadoop.html

 

2. 假設與目標

2.1. 硬件錯誤

       硬件錯誤是正常的,而不是異常。HDFS實例由成百上千個服務器組成,每個都存儲着文件系統的一部分數據。事實上,這就會有大量的組件,而每個組件出故障的可能性都很大,這意味着HDFS總有一些組件是不能工作的。因此,檢測錯誤並快速自動恢復就成了HDFS的核心設計目標。

 

2.2. 流式數據訪問

       運行在HDFS上的應用程序需要流式的訪問它們的數據集,它們也不是通常運行在普通文件系統上的普通應用程序。HDFS爲了那些批量處理而設計的,而不是爲普通用戶的交互使用。強調的是數據訪問的高吞吐量而不是數據訪問的低反應時間。POSIX強加的很多硬性需求是HDFS上應用程序所不需要的, 這些POSIX語義在一些關鍵環境下被用來提高數據的吞吐頻率。

 

2.3. 大數據集

       運行在HDFS上的應用程序使用大數據集。HDFS一個典型的文件可能是幾GB的或者幾TB的。因此,HDFS適用於大文件。這將提供高集成帶寬,並在一幾集羣中提供上百個結點。一個實例可能支持上千萬個文件。

2.4. 簡單一致性模型

HDFS的應用程序需要對文件實行一次性寫,多次讀的訪問模式。文件一旦建立後寫入,文件就不需要再更改了。這樣的假定簡化了數據一致性問題並使高數據吞吐量成爲可能。MapReduce程序或者網絡爬蟲程序就很適合使用這樣的模型。當然未來計劃支持增量寫。

 

 

2.5. 移動計算環境比移動數據划算

如果就在數據的旁邊就執行對這些數據的操作,那麼程序所使用的設備就會很高效。這當文件相當巨大的時候就尤其正確。這可以減少網絡的擁塞和提高系統的吞吐量。這個假設還意味着,常常是把計算遷移到數據存儲的近處更好,而不是把數據傳輸到程序運行的地方。HDFS提供了程序接口以便把他們自己移動到數據存儲的地方執行。

 

2.6. 跨硬件和軟件平臺的移動

       HDFS設計爲容易的從一個平臺移動到另一個平臺。這有助於HDFS被採用做爲一個大程序集合的工作平臺。

 

3. 名字結點和數據結點

       HDFS是主/從結構的。一個集羣有一個名字結點,也就是主控制服務器,負責管理文件系統的名字空間並協調客戶對文件的訪問。還有一堆數據結點,一般一個物理結點上部署一個,負責它們所在的物理結點上的存儲管理。HDFS開放文件系統的名字空間以便讓用戶數據存儲的文件中。內部,一個文件被分割爲一個或者多個數據塊,這些數據塊存儲在一組數據結點中。名字結點執行文件系統的名字空間操作,比如打開、關閉、重命名文件或目錄,還決定數據塊從數據結點的映射。數據結點負責提供客戶的讀寫請求。數據結點還依照名字結點的指令執行數據塊的創建、刪除複製工作。

名字結點和數據結點是設計爲運行在普通機器上的軟件組件。這些機器大多運行GNU/Linux操作系統。HDFS使用JAVA語言來實現;任何支持JAVA的機器都可以運行名字結點和數據結點軟件。使用高度可以移植的JAVA語言意味着HDFS可以被很多種機器使用。一個典型的部署有一臺指定的機器只運行名字結點,體系結構並不排除在那臺機器上也運行數據結點,但是現實中的部署很少那樣使用。

 

一個集羣中只有一個名字結點大大簡化了系統機構。名字結點做爲所有系統元數據的存儲和仲裁者。系統這樣設計就會使用戶數據從不會流經名字結點。

4. 文件系統的名字空間

HDFS支持傳統的文件組織體系結構。用戶或者程序可以創建目錄,並在目錄中存儲文件。名字空間的結構和大多現有文件系統類似。你可以創建、刪除文件,把文件從一個目錄移動到另一個目錄,或者重命名文件。HDFS還沒有實現用戶配額和訪問權限控制,也不支持硬連接和軟連接。當然體系也不妨礙實現這些特性。

 

       名字結點維護系統的名字空間,它將記錄名字空間內的任何改動或者名字空間本身的屬性改動。用戶可以指定HDFS中文件複製的份數,這個份數稱爲複製因子,由名字結點記錄。

5. 數據複製

HDFS被設計爲在一個大集羣裏跨機器、可靠的存儲非常大的文件。每個文件都存儲爲一系列的塊,同一文件中除最後一塊以外的所有塊都是一樣大的。文件的塊都通過複製來保證容錯。每個文件的塊的大小和複製因子都是可以配置的。程序可以指定文件複製的次數,複製因子可以在文件創建時候指定,也可以在以後指定。HDFS的文件都是一次性寫入的,並且嚴格限制任何時候都只有一個寫用戶。

 

名字結點根據塊複製狀態做出所有決定,它會週期的收到來自集羣內數據結點的心跳和塊報告。能收到心跳證明數據結點工作是正常的。一個塊報告應該包括數據結點上所有塊的列表。

5.1. 複製品的位置:嬰兒起步

複製品的位置對於HDFS的可靠性和性能來說是很關鍵的,和其他分佈式文件系統最大的區別就是它能優化複製品的位置,這個特性需要大量的調整和經驗。小心衡量複製品的放置是爲了提高數據的可靠性、可用性、網絡帶寬利用率。目前對於複製品放置的策略只是朝這個方向努力的第一步,短期的目標是要在生產系統中驗證,更多學習它的行爲,並建立一個基礎來測試和研究更復雜的策略。

 

大的HDFS實體在一大堆機器上運行着,這些機器可能要跨幾個機櫃來放。不同櫃子裏的兩個結點通信的時候要通過交換機。大多數情況下,同一個機櫃的機器間的帶寬比不同機櫃的機器間的帶寬要大。

 

啓動的時候,每個數據結點確定自己所在的機櫃並通知名字結點註冊表中此機櫃的IDHDFS提供一些API,以方便可拆卸模塊用來確定自己所在的機櫃的ID

有個簡單但不是很理想的策略是:在不同機櫃上放置複製品。這防止在整個機櫃宕掉的時候丟失數據,還容許在讀數據的時候使用多個機櫃的帶寬。這個策略還可以均勻的放置複製品,以便在組件失敗的時候平衡負載。但是,這個策略會增加寫的代價,寫操作需要跨機櫃的傳輸數據塊。

 

對於一般的情況,當複製因子是3的時候,HDFS的部署策略是:在本地機櫃放置一個結點,此機櫃再放一個不同的結點,然後在另一個機櫃放一個結點。這樣的策略砍掉了機櫃內部寫操作的傳輸,這將提高了寫的性能。機櫃壞掉的概率比一個結點壞掉的概率要小的多;這個策略不會影響數據的可靠性和可用性的保證。

實際上,當從兩個不同的機櫃上讀數據塊的時候,對比從三個上讀,並不減少總使用帶寬。使用此策略,文件的複製品不能跨機櫃均勻的分配。

 

1/3的複製品放在一個結點上,(這樣就有)2/3複製品放在同一個機櫃上,最後的1/3均勻的放在其他的機櫃的結點上。

 

這個策略提高了寫的性能而沒有對數據可靠性或讀性能造成損失。當前,缺省的複製品放置策略,也就是這裏討論的策略還是一個正在進行中的工作。

 

5.2. 複製品選擇

爲了減少總帶寬消耗和讀延時,HDFS會試圖使用離讀客戶最近的複製品來滿足讀請求。如果在讀結點的同一個機櫃有一個複製品,那麼這個複製品將是最合適滿足這個讀請求的。如果HDFS機羣跨了多個數據中心,那麼駐留在本地數據中心的複製品就比遠程的複製品更合適。

 

5.3. 安全模式

啓動的時候,名字結點進入一個特殊的狀態叫做安全模式,此時不會出現數據塊的複製。名字結點會收到數據結點的心跳和數據塊報告。數據塊報告包括一個數據結點所擁有的數據塊列表。每個數據塊裏都有指定數目的複製品。當某個名字結點登記過數據複製品的最小數目,數據塊就被認爲是安全複製了。在那麼可配置百分比安全複製的數據塊在名字結點登記後(加上附加的30秒),名字結點退出安全模式。它將確定數據塊(如果有的話)比指定的複製品數據要少的那些,然後對這些數據塊進行復制。

 

 

6. 文件系統元數據的持久性

HDFS的命名空間存儲在名字結點上,名字結點使用叫做“編輯日誌”的事務日誌來持久化記錄文件系統元數據的每次變化。例如,當在HDFS中創建一個文件的時候,名字結點就會在“編輯日誌”中插入一條記錄。類似的,當文件的複製因子也會引起一條新的記錄被插入“編輯日誌”。名字結點使用本地操作系統的文件才存儲“編輯日誌”。整個文件系統的命名空間,包括塊到文件的影射,文件系統的屬性,都存儲在一個叫做“文件系統鏡象”的文件裏,這個文件也是放在名字結點本地操作系統上的。

 

名字結點在內存裏保持一份含有整個系統的命名空間以及文件塊影射的鏡象。關鍵的元數據條目設計的很簡潔,這樣一個有4GB內存的名字結點就足以支持大量的目錄和文件。當名字結點啓動的時候,它會從磁盤讀取“文件系統鏡象”和“編輯日誌”,把“編輯日誌”的事務都應用到內存中的文件鏡象上,然後在新的文件鏡象刷新到硬盤上,這時因爲事務因爲已經被持久化了,就可以把舊的“編輯日誌”截短了。這個過程叫做檢查點。在當前的實現中,檢查點只出現在名字結點啓動的時候,關於在未來支持週期性檢查點的工作還在進行中。

 

數據結點使用本地文件系統來存儲HDFS的數據。數據結點對HDFS的文件一無所知,它只是用一個個文件存儲HDFS的每個數據塊。數據結點並不在同一個目錄中創建所有的文件,而是用一個啓發式算法來確定每個目錄的最佳文件個數,並適當的建立字目錄。在同一個目錄建立所有的文件不是最理想的,這是因爲本地文件系統可能不支持在同一個目錄放數目巨多的文件。當數據結點啓動的時候,它會遍歷本地文件系統,會產生一份HDFS數據塊和本地文件對應關係的列表,並把這個報告發給名字結點:這就是塊報告。

 

7. 通信協議

HDFS的所有通信協議都是在TCP/IP協議上層分層的。客戶去連接名字結點上一個可配置的TCP端口,使用“客戶協議”與名字結點交互。數據結點和名字結點使用“數據結點協議”交互。一個遠程過程調用(RPC)則封裝了這兩個協議。按照設計,名字結點永遠不會啓動任何的RPC,它只負責響應數據結點或客戶發起的請求。

 

8. 健壯性

HDFS的首要目的就是要保證數據的可靠性,甚至出錯的時候也是。三個最常見的錯誤就是,名字結點或數據結點故障,和網絡斷開。

 

8.1.數據磁盤故障,心跳和重複制

 

每個數據結點都週期性的向名字結點發送心跳數據包。網絡阻斷可能會造成一些數據結點失去到名字結點的連接。名字結點通過心跳的丟失來檢測這樣的情況。名字結點會標記沒有最近沒有心跳的數據結點爲宕機,並不轉發給他們任何新的IO請求。任何註冊在已宕機數據結點的數據對HDFS來說都是不在可用的了。數據結點的宕機會造成一些數據塊的複製因子下降並低於指定值。名字結點會一直跟蹤哪些數據塊需要被複制,並在需要的時候開始複製。這樣必要的重複制的引發可能有多種原因:數據結點不可用,一個複製品損壞,數據結點上某個磁盤損壞,某個文件複製因子被提升了。

 

8.2. 機羣的重配平

HDFS的結構是和數據重配平方案相適應的。如果某個數據結點的剩餘磁盤空間下降到某個極限,方案自動把數據從此數據結點移動到另一個結點。當出現對某個文件有很高的需求的時候,方案會動態增加更多的複製品,並平衡機羣中的其他數據。這些數據配平方案還沒有實現。

 

8.3. 數據完整性

有種可能是從數據結點拿到的數據卻是損壞的,這樣的錯誤可能是由於存儲設備錯誤,網絡故障或者軟件的BUGHDFS的客戶軟件實施對HDFS文件內容的校驗和檢查。當一個客戶創建HDFS文件,它先計算文件每個塊的校驗和,並存儲到同命名空間下的隱藏文件裏。

當客戶收到文件內容後,會檢查各個數據結點取出的數據和相應的校驗和相匹配。如果不匹配那麼客戶就選擇其他有複製品的數據結點取一份數據。

 

8.4. 元數據磁盤失效

 “文件系統鏡象”和“編輯日誌”是HDFS的中心重要結構,這些文件損壞了會導致HDFS實例不可用。

因此,名字結點可以配置爲支持保存“文件系統鏡象”和“編輯日誌”的多份拷貝。它們的每次更新,都會引發文件的多份拷貝的同步更新。但是這樣的同步會降低名字結點上命名空間的傳輸速度。實際上,變慢的程度是可以接受的,因爲即便是程序是對數據非常的敏感,但是也不是對元數據敏感。當名字結點重新啓動的時候,它回選擇最新的文件拷貝。

名字結點機器只是HDFS機羣的一個單點故障。如果名字結點真的宕掉了,那麼手動干預就是必須的了。當前,對命名結點自動重啓或把宕掉的軟件恢復到其他機器上還不支持。

 

8.5. 快照

快照支持存儲某一點時間的數據拷貝。這個特性的一個應用就是:把損壞的HDFS實例回滾到以前某個正常的時間點。目前還不支持這個特性,未來版本會支持。

 

9. 數據組織結構

9.1. 數據塊

HDFS被設計爲支持非常大的文件。並且與HDFS相一致的程序也是處理大數據集的。程序一次性寫入數據,但是會一次或多次讀取,並希望能得到線速的讀取。HDFS支持文件語義上一次寫多次讀,它所使用的塊大小通常是64M。因此,HDFS的文件都被切割爲64M的塊,還有可能,每個數據塊駐留在不動的數據結點上。

 

 

9.2. Staging

客戶創建文件的請求不是立即到達名字結點,而是HDFS客戶把數據緩存到本地的一個文件裏。程序的寫操作顯式重定向到這個本地臨時文件。當本地的文件積聚的數據超過了HDFS數據塊的大小客戶才和名字結點聯繫。名字結點在系統的體系中插入文件名,並申請一個數據塊給它。名字結點應答給客戶數據結點的的ID和目標數據塊ID,這樣客戶就把數據從本地的緩存刷新到目的的數據塊中。當文件關閉後,臨時文件中剩餘的未刷新數據也會被傳輸到數據結點中,客戶這時就可以告訴名字結點文件被關閉了。這一時間點,名字結點完成了在持久存儲中創建文件的操作。如果名字結點在文件關閉之前宕掉了,那麼文件就丟失了。

 

在對運行HDFS在上應用軟件仔細權衡以後,上述的方法已經被接受了。這些程序需要流式寫入到文件。如果客戶直接寫到遠程的文件而沒有任何緩存的話,網絡中的速度和擁塞就會對輸出影響很大。這樣的方法也不是沒有先例。早期的分佈文件系統比如,AFS就已經採用了客戶緩存來提高性能。爲了得到數據上傳的更好性能,POSIX的相關要求已經被放棄不用了。

 

 

9.3. 複製流水線

當客戶要寫數據到HDFS的文件中,就象前一節解釋的那樣,數據會首先寫到一個本地文件裏。假設HDFS文件的複製因子是3,當本地文件積聚到數據塊那麼大的時候,用戶從名字結點獲得一個數據結點列表,列表中的數據結點都將保存那個數據塊一份拷貝。客戶就把數據塊刷新到第一個數據結點上,這個結點開始用(4K)的小塊來接收數據,把每個塊寫到本地庫中,並傳遞給列表中的第二個數據結點,第二個結點開始每個小數據塊,寫到自己本地庫中,並把這塊數據刷新給第3個結點。最後,第3個結點把數據寫到自己的庫中。因此,數據結點就可以同時從前一個結點那裏收數據,並同時流水線的把數據傳給後面的數據結點。也就是,數據形成了流水線,從一個數據結點傳遞給下一個。

 

 

10. 可訪問性

從應用程序有很多方式訪問HDFS,自然而然的,它提供了一組Java API供程序使用。 並且對這組APIC語言封裝也是可用的。HTTP瀏覽器也可以用來瀏覽一個HDFS實例的文件。使用WebDAV協議訪問的工作還在進行中。

 

10.1. 分佈式文件系統的命令解釋器

HDFS使用文件和目錄的形式組織用戶的數據,它提供了命令接口DFSShell讓用戶和其中的數據交互。這些命令的語法和其他用戶已經熟悉的Shell都很相似,這裏提供了一個示例:

DFSShell是爲了那些使用腳本和存儲數據交互的程序而設計的。

10.2. DFS管理

HDFS管理命令組是爲了管理一個HDFS機羣而設計的,這些命令只能由管理員來使用,這裏是一些示例:

Action

Command

Put a cluster in SafeMode

bin/hadoop dfsadmin -safemode enter

Generate a list of Datanodes

bin/hadoop dfsadmin -report

Decommission Datanode datanodename

bin/hadoop dfsadmin -decommission datanodename

 

10.3. 瀏覽器接口

一個典型的HDFS安裝會配置一個WEB服務器開放自己的命名空間,其TCP端口是可配的。這樣用戶就可以通過WEB瀏覽器遍歷HDFS的命名空間並查看文件內容。

 

11. 空間回收

11.1. 文件的刪除和取消

當文件被用戶或者程序刪除了,並不是立即就從HDFS中移走了。而是HDFS先把它移動到/trash目錄裏。只要還在這個目錄裏,文件就可以被恢復。文件在這個目錄裏的時間是可以配置的,超過了生命週期,系統就把它從命名空間中刪除了。文件的刪除操作會引起相應數據塊的釋放。注意一點:從用戶執行刪除操作到從系統中看到剩餘空間的增加可能需要相當長的時間。

 

用戶可以在刪除後取消操作,只要文件還在回收站裏。當用戶想取消的時候,可以瀏覽這個目錄,並取回文件。這個目錄只包含最近被刪除的文件,這個目錄有個特性就是HDFS使用策略自動刪除文件。當前默認的策略是:超過6個小時以後自動刪除文件。在未來版本里,這個策略是一個通過良好定義的接口來配置的。

 

11.2. 降低複製因子

當一個文件發覆制因子減低了,名字結點會選出一些多處的可以刪除的複製品。下一個心跳將傳遞這些信息到數據結點,數據結點就刪除相應的塊,機羣中就會出現相應的剩餘空間。再一次說明,當調用setReplication函數和看到剩餘空間之間會有一個延時。

12. 參考

HDFS Java API: http://lucene.apache.org/hadoop/api/

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

 

 

問題:

1)            名字結點的穩定性

2)            多進程同時訪問的安全性

3)            小文件怎麼解決

 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章