翻譯： http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
版本：2.9.0
介紹
Hadoop分布式文件系統（HDFS）是一種分布式文件系統，設計用于在商品硬件上運行。它與現有的分布式文件系統有許多相似之處。但是，與其他分布式文件系統的差異也很大。HDFS具有高度容錯能力，旨在部署在低成本硬件上。HDFS提供對應用程序數據的高吞吐量訪問，適用于具有大型數據集的應用程序。HDFS放寬了一些POSIX要求，以啟用對文件系統數據的流式訪問。HDFS最初是作為Apache Nutch網絡搜索引擎項目的基礎架構而構建的。HDFS是Apache Hadoop Core項目的一部分。項目URL是http://hadoop.apache.org/。
假設和目標
硬件故障
硬件故障是常態而非例外。一個HDFS實例可能由數百或數千個服務器機器組成，每個服務器都只存儲文件系統的部分數據。事實上，有大量的組件，并且每個組件具有不可忽略的失敗概率，這意味著HDFS的某個組件始終不起作用的概率非常大。因此，檢測故障并快速自動恢復是HDFS的核心架構目標。
流數據訪問
在HDFS上運行的應用程序需要流式訪問其數據集。它們不是行在通用文件系統上的通用的應用程序 。HDFS的設計更多用于批處理，而不是用戶交互式使用。重點是數據訪問的高吞吐量，而不是數據訪問的低延遲。POSIX強加了HDFS所針對的應用程序所不需要的許多硬性要求。一些關鍵領域的POSIX語義已被變更用來提高數據吞吐率。
大型數據集
在HDFS上運行的應用程序具有大量數據集。HDFS支持大文件，HDFS中典型文件的大小為千兆字節至兆兆字節。因此應該為單個群集中的數百個節點提供高聚合數據帶寬和規模。在單個實例中支持數千萬個文件。
簡單一致性模型
HDFS應用程序是一個一次寫入多次讀取的文件訪問模型。一旦文件創建，寫入和關閉則不再進行其他更改，除了追加和截斷之外。支持將內容附加到文件末尾，但不能在任意點附加。這種假設簡化了數據一致性問題并實現了高吞吐量數據訪問。MapReduce應用程序或Web爬行器應用程序完全符合此模型。
“移動計算比移動數據便宜”
如果應用程序在其操作的數據附近執行，則應用程序所請求的計算效率會更高。當數據集的大小很大時尤其如此。這可以最大限度地減少網絡擁塞并提高系統的整體吞吐量。我們的假設是，將計算遷移到更接近數據所在的位置通常會更好，而不是將數據移動到應用程序正在運行的位置。HDFS為應用程序提供接口，使它們更接近數據所在的位置。
在異構硬件和軟件平臺上的可移植性
HDFS的設計很容易從一個平臺移植到另一個平臺。這有利于處理大數據量的應用采用HDFS平臺。
NameNode和DataNodes
HDFS具有主/從架構。一個HDFS集群包含一個NameNode（一個主服務器），用于管理文件系統名稱空間并管理客戶端對文件的訪問。此外，還有許多DataNode，通常是群集中的每個節點一個DataNode，用于數據存儲。HDFS對外暴露文件系統名稱空間并允許用戶數據存儲在文件中。在內部，文件被分成一個或多個塊，這些塊存儲在一組DataNode中。NameNode執行文件系統命名空間操作，如打開，關閉和重命名文件和目錄。它還確定塊到DataNode的映射。DataNode負責提供來自文件系統客戶端的讀取和寫入請求。DataNode還在NameNode的指令下執行塊創建，刪除，復制。
NameNode和DataNode是設計用于在商品機器上運行的軟件。這些機器通常運行GNU / Linux操作系統（OS）。HDFS使用Java語言構建; 任何支持Java的機器都可以運行NameNode或DataNode。使用高度可移植的Java語言意味著HDFS可以部署在各種機器上。典型的部署有一臺專用機器只運行NameNode。群集中的每臺其他機器運行DataNode。該體系結構不排除在同一臺計算機上運行多個DataNode，但在實際部署中很少出現這種情況。
集群中單個NameNode的存在極大地簡化了系統的體系結構。NameNode是所有HDFS元數據的仲裁者和存儲庫。該系統的設計方式是用戶數據永遠不會流經NameNode。
文件系統命名空間
HDFS支持傳統的分層文件組織。用戶或應用程序可以在這些目錄內創建目錄并存儲文件。文件系統名稱空間層次與大多數其他現有文件系統類似; 可以創建和刪除文件，將文件從一個目錄移動到另一個目錄，或者重命名文件。HDFS支持用戶配額和訪問權限。HDFS不支持硬鏈接或軟鏈接。但是，HDFS體系結構并不排除實現這些功能。
NameNode維護文件系統名稱空間。NameNode記錄對文件系統名稱空間或其屬性的任何更改。應用程序可以指定HDFS應該維護的文件的副本數量。文件的副本數稱為該文件的復制因子。這些信息由NameNode存儲。
數據復制
HDFS旨在可靠地在大型群集中的機器上存儲超大型文件。它將每個文件存儲為一系列的塊。文件的塊被復制以實現容錯。塊大小和復制因子可以針對每個文件進行配置。
一個文件中除最后一個塊之外的所有塊都具有相同的大小，而用戶可以在最后一個塊未達到所配置的塊大小的情況下啟動新塊。
應用程序可以指定文件的副本數量。復制因子可以在文件創建時指定，并可以稍后更改。HDFS中的文件是一次寫入的（附加和截斷除外），并且在任何時候都嚴格限定只有一個writer。
NameNode做出關于塊復制的所有決定。它定期從集群中的每個DataNode接收Heartbeat和Blockreport。收到Heartbeat意味著DataNode運行正常。Blockreport包含DataNode上所有塊的列表。
副本放置：第一步
復制品的放置對于HDFS的可靠性和性能至關重要。優化副本位置可將HDFS與大多數其他分布式文件系統區分開來。這是一項需要大量調整和體驗的功能。機架感知復制品放置策略的目的是提高數據可靠性，可用性和網絡帶寬利用率。復制品放置策略的當前實現是朝這個方向的第一步。實施這項政策的短期目標是在生產系統上對其進行驗證，更多地了解其行為，并為測試和研究更復雜的策略奠定基礎。
大型HDFS實例通常運行在有多個機架上的一組計算機上。不同機架中兩個節點之間的通信必須通過交換機。在大多數情況下，同一機架中機器之間的網絡帶寬大于不同機架中機器之間的網絡帶寬。
NameNode通過Hadoop Rack Awareness中描述的過程確定每個DataNode所屬的機架標識。一個簡單但非最佳的策略是將副本放在獨特的機架上。這可以防止整個機架出現故障時丟失數據，并允許在讀取數據時從多個機架使用帶寬。此策略在集群中均勻分配副本，以便輕松平衡組件故障時的負載。但是，此策略會增加寫入成本，因為寫入需要將塊傳輸到多個機架。
對于常見情況，如果復制因子為3，則HDFS的放置策略是在本地機器上放置一個副本（如果寫入器位于datanode上），否則放置在隨機數據節點上；第二個副本復制在另一個遠程機架的節點上，最后一個副本放在與第一個副本存放節點相同的機架上的其他節點上。該策略可以減少機架間寫入流量，這通常會提高寫入性能。機架故障的機會遠遠小于節點故障的機會; 此策略不會影響數據可靠性和可用性保證。但是，它確實降低了讀取數據時使用的總體網絡帶寬，因為塊僅放置在兩個獨特的機架中，而不是三個。使用此策略，文件的副本不會均勻分布在機架上。三分之一的副本位于一個節點，三分之二的副本位于一個機架上，另外三分之一均勻分布在其余機架上。此策略可提高寫入性能，而不會影響數據可靠性或讀取性能。
如果復制因子大于3，則隨機確定第4個副本和后續副本的位置，同時將每個機架的副本數保持在上限以下（(replicas - 1) / racks + 2）。
由于NameNode不允許一個DataNode具有同一個塊的多個副本，因此創建的最大副本數是當時的DataNode總數。
在對HDFS添加了對存儲類型和存儲策略的支持后，除了上述的機架認知之外，NameNode還將副本放置的策略考慮在內。NameNode首先選擇基于機架感知的節點，然后檢查候選節點是否具有所需的存儲空間。如果候選節點不具有，NameNode會查找另一個節點。如果在第一個路徑中找不到足夠的節點來放置副本，則NameNode將在第二個路徑中查找具有回退存儲類型的節點。
此處描述的當前默認副本放置策略是一項正在進行的工作。
副本選擇
為了盡量減少全局帶寬消耗和讀取延遲，HDFS會嘗試選擇最接近讀請求的塊。如果在讀節點的同一機架上存在副本，則該副本優先滿足讀取請求。如果HDFS群集跨越多個數據中心，則駐留在本地數據中心的副本優先于任何遠程副本。
安全模式
在啟動時，NameNode進入一個稱為Safemode的特殊狀態。當NameNode處于安全模式狀態時，不會發生數據塊的復制。NameNode接收來自DataNode的Heartbeat和Blockreport消息。Blockreport包含DataNode托管的數據塊列表。每個塊都具有副本的最小數量值。如果NameNode檢測到該數據塊達到要求的最小副本數，則認為該塊已被安全的復制了。當已被安全復制塊的百分比達到一定值（再加上30秒）之后，NameNode退出安全模式狀態。NameNode然后根據未達標的數據塊的列表（如果有的話），將這些塊復制到其他DataNode。
文件系統元數據的持久性
HDFS名稱空間由NameNode存儲。NameNode使用名為EditLog的事務日志來持久記錄文件系統元數據發生的每一個變化。例如，在HDFS中創建一個新文件會導致NameNode向EditLog中插入一條記錄。同樣，更改文件的復制因子會導致將新記錄插入到EditLog中。NameNode使用其本地主機OS文件系統來存儲EditLog。整個文件系統名稱空間（包括塊到文件和文件系統屬性的映射）存儲在名為FsImage的文件中。FsImage也作為文件存儲在NameNode的本地文件系統中。
NameNode將整個文件系統名稱空間和文件Blockmap的圖像保存在內存中。當NameNode啟動或檢查點觸發（可配置閾值）時，它從磁盤讀取FsImage和EditLog，將EditLog中的所有事務應用到FsImage的內存中表示，并將此新版本刷新為磁盤上的新FsImage。它將刪除舊的EditLog，因為它的事務已經被應用到持久的FsImage。這個過程被稱為檢查點。檢查點的目的是通過文件系統元數據的快照并將其保存到FsImage來確保HDFS具有文件系統元數據的一致視圖。即使直接讀取FsImage是有效的，但直接對FsImage進行增量編輯效率并不高。我們沒有為每個編輯修改FsImage，而是將編輯保存在Editlog中。在檢查點期間，Editlog中的更改將應用??于FsImage。檢查點可以在給定的時間間隔觸發（dfs.namenode.checkpoint.period以秒表示），或者在給定數量的文件系統事務累積之后（ dfs.namenode.checkpoint.txns ）觸發。如果這兩個屬性都已設置，則要達到的第一個閾值會觸發檢查點。
DataNode將HDFS數據存儲在本地文件系統中的文件中。DataNode沒有關于HDFS文件的知識。它將每個HDFS數據塊存儲在本地文件系統中的單獨文件中。DataNode不會在同一目錄中創建所有文件。相反，它使用啟發式來確定每個目錄的最佳文件數量并適當地創建子目錄。在同一目錄中創建所有本地文件并不是最佳選擇，因為本地文件系統可能無法有效地支持單個目錄中的大量文件。當DataNode啟動時，它會掃描本地文件系統，生成與這些本地文件相對應的所有HDFS數據塊的列表，并將此報告發送給NameNode。該報告稱為Blockreport。
通信協議
所有HDFS通信協議都在TCP / IP協議之上 。客戶端建立到NameNode機器上可配置TCP端口的連接，它與NameNode使用ClientProtocol通訊。DataNode使用DataNode協議與NameNode進行通信。遠程過程調用（RPC）包括客戶端協議和數據節點協議。根據設計，NameNode永遠不會啟動任何RPC。相反，它只響應DataNode或客戶端發出的RPC請求。
穩健性（Robustness）
HDFS的主要目標是即使在出現故障時也能可靠地存儲數據。三種常見類型的故障是NameNode故障，DataNode故障和網絡故障。
數據磁盤故障，心跳和重新復制
每個DataNode定期向NameNode發送一個Heartbeat消息。網絡故障可能導致DataNode的一個子集失去與NameNode的連接。NameNode通過Heartbeat消息來檢測這種情況。NameNode將最近沒有Heartbeats的DataNode標記為死亡，并且不會向它們轉發任何新的IO請求。任何注冊到死亡DataNode的數據將不再可用。DataNode死亡可能導致某些塊的復制因子降到其指定值以下。NameNode會不斷跟蹤哪些塊需要復制，并在需要時啟動復制。重新復制的必要性可能由于以下原因而產生：DataNode可能變得不可用，副本可能會損壞，DataNode上的硬盤可能會損壞，或者文件的復制因子增大。
標記DataNode死亡的超時時間比較長（默認情況下超過10分鐘），以避免由DataNode的狀態震蕩引起的復制風暴。用戶可以設置較短的時間間隔，以避免在讀取和/或寫入性能敏感工作時出現問題。
群集重新平衡
HDFS架構與數據重新平衡方案兼容。如果DataNode上的可用空間低于某個閾值，則文件系統可能會自動將數據從一個DataNode移動到另一個DataNode。在特定文件突然高需求的情況下，可能會動態創建額外的副本并重新平衡群集中的其他數據。這些類型的數據重新平衡方案尚未實施。
數據的完整性
從DataNode獲取的數據塊可能會損壞。可能會發生此損壞的原因包括存儲設備故障，網絡故障或軟件錯誤。HDFS客戶端軟件對HDFS文件的內容執行校驗和檢查。當客戶端創建HDFS文件時，它會計算文件每個塊的校驗和，并將這些校驗和存儲在同一個HDFS名稱空間中的單獨隱藏文件中。當客戶端檢索文件內容時，它會驗證從每個DataNode收到的數據是否與存儲在相關校驗和文件中的校驗和相匹配。如果不是，那么客戶端可以選擇從另一個具有該塊的副本的DataNode中檢索該塊。
元數據磁盤失敗
FsImage和EditLog是HDFS的中心數據結構。這些文件的損壞可能會導致HDFS實例失效。由于這個原因，NameNode可以配置為支持維護FsImage和EditLog的多個副本。對FsImage或EditLog的任何更新都會導致每個FsImages和EditLog同步更新。同步更新FsImage和EditLog的多個副本可能會降低NameNode每秒可支持的名稱空間事務處理速度。但是，這種降級是可以接受的，因為即使HDFS應用程序本質上是非常密集的數據，它們也不是元數據密集型的（沒看懂，應該是應用程序數據不如元數據重要）。當NameNode重新啟動時，它會選擇最新的一致的FsImage和EditLog來使用。
另一個增加彈性以抵御故障的方法是使用多個NameNode啟用高可用性，使用NFS上的共享存儲或使用分布式編輯日志（稱為日記）。后者是推薦的方法。
快照
快照支持在特定時刻存儲數據副本。快照功能的一種用法可能是將損壞的HDFS實例回滾到先前已知的良好時間點。
數據組織
數據塊
HDFS旨在支持非常大的文件。與HDFS兼容的應用程序是處理大型數據集的應用程序。這些應用程序只寫入其數據一次，但他們讀取一次或多次，并要求在流速下讀取。HDFS支持在文件上一次寫入多次讀取語義。HDFS使用的典型塊大小為128 MB。因此，一個HDFS文件被分成128 MB塊，如果可能的話，每個塊將駐留在不同的DataNode上。
復制流水線
當客戶端將數據寫入復制因子為3的HDFS文件時，NameNode使用復制目標選擇算法檢索DataNode列表。該列表包含將承載該塊的副本的DataNodes。客戶端然后寫入第一個DataNode。第一個DataNode開始接收部分數據，將每個部分寫入其本地存儲庫并將該部分傳輸到列表中的第二個DataNode。第二個DataNode也開始接收數據塊的每個部分，將該部分寫入其存儲庫，然后將該部分傳輸到第三個DataNode。最后，第三個DataNode將數據寫入其本地存儲庫。因此，DataNode可以從流水線中的前一個接收數據，并且同時將數據轉發到流水線中的下一個數據。從而，數據是以流水線的方式從一個datanode傳輸到下一個。
無障礙
HDFS可以通過許多不同的訪問方式。從本質上講，HDFS 為應用程序提供了一個FileSystem Java API。C語言包封裝API和REST API也是可用的。另外還有一個HTTP瀏覽器，也可以用來瀏覽HDFS實例的文件。通過使用NFS網關，可以將HDFS掛載為本地文件系統的一部分。
FS Shell
HDFS允許用戶數據以文件和目錄的形式進行組織。它提供了一個名為FS shell的命令行界面，可讓用戶與HDFS中的數據進行交互。這個命令集的語法類似于用戶已經熟悉的其他shell（例如bash，csh）。以下是一些示例操作/命令對：
FS外殼針對需要腳本語言與存儲數據進行交互的應用程序。
DFSAdmin
DFSAdmin命令集用于管理HDFS集群。這些是僅由HDFS管理員使用的命令。以下是一些示例操作/命令對：
瀏覽器界面
典型的HDFS將安裝配置一個Web服務器公開HDFS名稱空間。這允許用戶使用Web瀏覽器瀏覽HDFS名稱空間并查看其文件。
空間回收
文件刪除和取消刪除
如果啟用垃圾箱配置，FS Shell刪除的文件不會立即從HDFS中刪除。相反，HDFS將其移動到垃圾目錄（每個用戶在< /user/<username>/.Trash下都有自己的垃圾目錄）。只要文件保留在垃圾箱中，文件可以快速恢復。
最近刪除的文件移動到當前的垃圾目錄（ /user/<username>/.Trash），并且在一個可配置的時間間隔內，HDFS為當前垃圾目錄中的文件創建檢查點，并在舊的檢查點過期時刪除它們。查看關于垃圾檢查點的FS shell的刪除命令。
在廢物生命周期結束后，NameNode將從HDFS命名空間中刪除該文件。刪除文件會導致與文件關聯的塊被釋放。請注意，在用戶刪除文件的時間與HDFS中相應增加空閑空間的時間之間可能存在明顯的時間延遲。
以下是一個將顯示FS Shell如何從HDFS中刪除文件的示例。我們在目錄delete下創建了2個文件（test1＆test2）
$ hadoop fs -mkdir -p delete/test1
$ hadoop fs -mkdir -p delete/test2
$ hadoop fs -ls delete/
Found 2 items
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:39 delete/test1
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:40 delete/test2
我們將刪除文件test1。下面的注釋顯示該文件已被移至垃圾箱目錄。
$ hadoop fs -rm -r delete/test1
Moved: hdfs://localhost:8020/user/hadoop/delete/test1 to trash at: hdfs://localhost:8020/user/hadoop/.Trash/Current
現在我們將使用skipTrash選項刪除文件，該選項不會將文件發送到垃圾箱。它將從HDFS中完全刪除。
$ hadoop fs -rm -r -skipTrash delete/test2
Deleted delete/test2
我們現在可以看到垃圾目錄僅包含文件test1。
$ hadoop fs -ls .Trash/Current/user/hadoop/delete/
Found 1 items\
drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:39 .Trash/Current/user/hadoop/delete/test1
所以文件test1進入垃圾箱，文件test2被永久刪除。
降低復制因子
當文件的復制因子減少時，NameNode選擇可以刪除的多余副本。下一個Heartbeat將此信息傳輸到DataNode。DataNode然后刪除相應的塊，并在群集中出現相應的可用空間。再一次，setReplication API調用完成和群集中可用空間的出現之間可能存在時間延遲。
參考
Hadoop JavaDoc API。
