概述
Hadoop分布式文件系統（HDFS）是一種分布式文件系統，用於在普通商用硬件上運行。它與現有的分布式文件系統有許多相似之處。然而，與其他分布式文件系統的區別很大。HDFS具有高度的容錯能力，旨在部署在低成本的硬件上。HDFS提供對應用程序數據的高吞吐量訪問，適用於具有大數據集的應用程序。HDFS放寬了一些POSIX要求，以便對文件系統數據進行流式訪問。HDFS最初是作為Apache Nutch Web搜索引擎項目的基礎架構構建的。HDFS是Apache Hadoop Core項目的一部分。http://hadoop.apache.org/
設想和目標
硬件容錯
硬件故障很常見而不例外。HDFS實例可以由數百或數千台服務器機器組成，每台服務器存儲部分文件系統的數據。事實上，有大量的組件，並且每個組件具有不一定的故障概率，這意味着HDFS的某些組件總是不起作用的。因此，故障檢測和快速自動恢復是HDFS的核心架構。
流數據訪問
在HDFS上運行的應用程序需要對其數據集進行流式訪問。HDFS不是用於提供普通應用訪問的文件系統。HDFS的設計更多用於批量處理，而不是用戶的交互式使用。重點是數據訪問的高吞吐量，而不是數據訪問的低延遲。POSIX施加了許多難於為HDFS定位的應用程序所需的硬要求。POSIX語義在幾個關鍵領域已被交易，以提高數據吞吐率。
大數據集
在HDFS上運行的應用程序具有較大的數據集。HDFS中的典型文件大小為千兆字節。因此，HDFS被調整為支持大文件。它應該提供高聚合數據帶寬並擴展到單個集群中的數百個節點。它應該在一個實例中支持數千萬個文件。
簡單一致性模型
HDFS數據訪問模式為一次寫入多次讀取。文件一旦創建、寫入和關閉后，除了追加和截斷，文件內容不再變化。將內容附加到文件的末尾是受支持的，但不能隨意更新。該假設簡化了數據一致性問題，並實現了高吞吐量數據訪問。MapReduce應用程序或Web爬蟲程序應用程序與此模型完美匹配。
“移動計算比移動數據便宜”
如果應用程序能夠很近德運行在其需要的數據，則應用程序所請求的計算效率更高【應用處理本機數據比遠程數據更快】。當數據集很大時，這一點尤其如此。這樣可以最大限度地減少網絡擁塞並提高系統的整體吞吐量。假設通常更好地將計算遷移到更接近數據位置的位置，而不是將數據移動到應用程序運行的位置。HDFS為應用程序提供接口，使其更接近數據所在的位置。
跨越異構硬件和軟件平台的可移植性
HDFS被設計為可以從一個平台輕松地移植到另一個平台。這有助於HDFS作為大型應用程序的首選平台。
NameNode DataNodes
HDFS具有主/從結構。HDFS集群包含單一的NameNode作為master服務器，用於管理文件系統命名空間，並調節客戶端對文件的訪問。此外，還有一些DataNodes，通常是集群中每個節點的一個，它們管理連接到運行的節點的存儲。HDFS公開了文件系統命名空間，並允許將用戶數據存儲在文件中。在內部，文件被分割成一個或多個塊，並且這些塊被存儲在一組DataNodes中。NameNode執行文件系統命名空間操作，如打開，關閉和重命名文件和目錄。它還確定塊到DataNodes的映射。DataNodes負責從文件系統的客戶端提供讀取和寫入請求。DataNode還可以根據NameNode的指示執行塊創建，刪除和復制。
NameNode和DataNode是用於在商用機上運行的軟件。這些機器通常運行GNU / Linux操作系統（OS）。HDFS使用Java語言構建;任何支持Java的機器都可以運行NameNode或DataNode軟件。高度可移植的Java語言的使用意味着HDFS可以部署在廣泛的機器上。典型的部署具有僅運行NameNode軟件的專用機器。集群中的每個其他計算機都運行DataNode軟件的一個實例。該架構並不排除在同一台機器上運行多個DataNodes，而是在很少出現的實際部署中。
集群中單個NameNode的存在大大簡化了系統的體系結構。NameNode是所有HDFS元數據的仲裁器和存儲庫。該系統的設計方式使得用戶數據不會流經NameNode。
文件系統命名
HDFS支持傳統的分層文件組織。用戶或應用程序可以創建目錄並將文件存儲在這些目錄中。文件系統命名空間層次結構與大多數其他現有文件系統類似;可以創建和刪除文件，將文件從一個目錄移動到另一個目錄，或者重命名文件。HDFS支持用戶配額和訪問權限。HDFS不支持硬鏈接或軟鏈接。然而，HDFS架構並不排除實現這些功能。
NameNode維護文件系統命名空間。文件系統名稱空間或其屬性的任何更改都由NameNode記錄。應用程序可以指定應由HDFS維護的文件的副本數。文件的副本數稱為該文件的復制因子。該信息由NameNode存儲。
數據復制
HDFS設計用於在大型集群中的機器之間可靠地存儲非常大的文件。它將每個文件存儲為一系列塊。復制文件的塊以進行容錯。塊大小和復制因子是可配置的每個文件。【hdfs-site.xml dfs.block.size dfs.replication】
除了最后一個塊之外的文件中的所有塊都是相同的大小，而用戶可以在將可變長度塊的支持添加到追加和hsync之后啟動一個新的塊，而不會將最后一個塊填充到配置的塊大小。
應用程序可以指定文件的副本數。可以在文件創建時指定復制因子，稍后更改。HDFS中的文件是一次寫入（除了附加和截斷之外），並且在任何時候都有一個作者。
NameNode做出關於塊復制的所有決定。它周期性地從集群中的每個DataNode接收到一個心跳和一個阻塞報告。收到心跳意味着DataNode正常運行。Blockreport包含DataNode上所有塊的列表。
復本安置：第一步
復制品的放置對於HDFS的可靠性和性能至關重要。優化復制放置將HDFS與大多數其他分布式文件系統區分開來。這是一個需要大量調整和體驗的功能。機架感知復制放置策略的目的是提高數據可靠性，可用性和網絡帶寬利用率。目前的復制放置政策的實施是朝這個方向努力的第一步。實施這一政策的短期目標是在生產系統上進行驗證，更多地了解其行為，並為更復雜的政策進行測試和研究奠定基礎。
大型HDFS實例在通常分布在多個機架上的計算機集群上運行。不同機架中的兩個節點之間的通信必須經過交換機。在大多數情況下，同一機架中的機器之間的網絡帶寬大於不同機架中的機器之間的網絡帶寬。
NameNode通過Hadoop機架意識【http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/RackAwareness.html】中概述的過程來確定每個DataNode所屬的機架ID。一個簡單但不是最優的策略是將副本放在獨特的機架上。這可以防止整個機架發生故障時丟失數據，並允許在讀取數據時使用多個機架的帶寬。該策略在集群中均勻分配副本，這使得輕松平衡組件故障時的負載。但是，這種策略會增加寫入的成本，因為寫入需要將塊傳輸到多個機架。
對於常見情況，當復制因子為3時，HDFS的放置策略是將一個副本放在本地機架中的一個節點上，另一個在本地機架上的另一個節點上，最后在不同機架中的不同節點上。該策略可以減少機架間的寫入流量，這通常會提高寫入性能。機架故障的機會遠小於節點故障的機會;此政策不影響數據的可靠性和可用性保證。然而，它確實減少了在讀取數據時使用的總體網絡帶寬，因為塊僅放置在兩個獨特的機架中，而不是三個。使用此策略，文件的副本不會均勻分布在機架中。三分之一的副本在一個節點上，三分之二的副本在一個機架上，另外三個是均勻分布在剩余的機架上。此策略可改善寫入性能，而不會影響數據的可靠性或讀取性能。
如果復制因子大於3，則隨機確定第4個和以后副本的位置，同時保持每個機架的副本數量低於上限（基本為（復制1）/機架2））。
由於NameNode不允許DataNodes具有相同塊的多個副本，所以創建的副本的最大數目是當時的DataNodes的總數。
在將存儲類型和存儲策略【http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/ArchivalStorage.html】的支持添加到HDFS之后，除了上述的機架感知之外，NameNode還會將策略考慮在副本位置。NameNode首先根據機架識別選擇節點，然后檢查候選節點是否具有與文件關聯的策略所需的存儲。如果候選節點沒有存儲類型，則NameNode將查找另一個節點。如果在第一個路徑中找不到足夠的放置副本的節點，則NameNode將在第二個路徑中查找具有備用存儲類型的節點。
此處描述的當前，默認的復制放置策略是一項正在進行的工作。
復本選擇
為了最大限度地減少全局帶寬消耗和讀取延遲，HDFS會嘗試從最接近讀卡器的副本獲取讀取請求。如果在與讀取器節點相同的機架上存在副本，則該副本優選滿足讀取請求。如果HDFS群集跨越多個數據中心，則駐留在本地數據中心的副本優先於任何遠程副本。
安全模式
在啟動時，NameNode進入一個稱為Safemode的特殊狀態。NameNode處於Safemode狀態時，不會復制數據塊。NameNode從DataNodes接收心跳和Blockreport消息。Blockreport包含DataNode承載的數據塊列表。每個塊具有指定的最小數量的副本。當使用NameNode檢入數據塊的最小副本數時，塊被認為是安全復制的。在可配置百分比的安全復制數據塊使用NameNode（加上另外30秒）之后，NameNode退出Safemode狀態。然后，它確定仍然具有少於指定數量的副本的數據塊（如果有）的列表。NameNode然后將這些塊復制到其他DataNodes。
持久化文件系統元數據
元數據信息
1.EditLog
2.FsImage
HDFS命名空間由NameNode存儲。NameNode使用名為EditLog的事務日志持續記錄文件系統元數據發生的每個更改。例如，在HDFS中創建一個新文件會導致NameNode將一個記錄插入到EditLog中。類似地，更改文件的復制因子將導致將新記錄插入到EditLog中。NameNode使用其本地主機OS文件系統中的文件來存儲EditLog。整個文件系統命名空間（包括將塊映射到文件和文件系統屬性）存儲在一個名為FsImage的文件中。FsImage作為文件存儲在NameNode的本地文件系統中。
檢查點
checkpoint 用於合並EditLog至FsImage，FsImage是文件系統最新的元數據，但不直接更新FsImage，而是定時合並EditLog至FsImage
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端口建立連接。利用ClientProtocol協議與NameNode進行通信。DataNode使用DataNode協議與NameNode進行通信。遠程過程調用（RPC）抽象包含客戶端協議和數據節點協議。按照設計，NameNode從不啟動任何RPC。相反，它只響應DataNodes或客戶端發出的RPC請求。
穩定性
HDFS的主要目標是即使存在故障也能夠可靠地存儲數據。三種常見的故障類型是NameNode故障，DataNode故障和網絡分區
數據磁盤故障，心跳和重新復制
每個DataNode定期向NameNode發送一個心跳信息。網絡分區可能導致DataNodes的一個子集與NameNode失去連接。NameNode通過不存在心跳消息來檢測此情況。NameNode將DataNodes標記為沒有最近的Heartbeats死機，並且不會向其轉發任何新的IO請求。任何已注冊到死亡數據節點的數據不再適用於HDFS。DataNode死亡可能導致某些程序段的復制因子低於其指定值。NameNode不斷跟蹤哪些塊需要復制，並在必要時啟動復制。重復復制的必要性可能由於許多原因：DataNode可能變得不可用，副本可能會損壞，DataNode上的硬盤可能會失敗，或者可能會增加文件的復制因素。
標記DataNodes死機的超時保守長（默認為10分鍾以上），以避免DataNodes的狀態拍攝引起的復制風暴。用戶可以設置更短的間隔，將DataNodes標記為過時，並通過配置讀取和/或寫入性能敏感工作負載來避免過時的節點。
集群再平衡
HDFS架構與數據重新平衡方案兼容。如果DataNode上的可用空間低於某個閾值，則方案可能會自動將數據從一個DataNode移動到另一個DataNode。在特定文件需求突然增加的情況下，方案可能會動態創建其他副本並重新平衡群集中的其他數據。這些類型的數據重新平衡計划尚未實施。
數據的完整性
從DataNode獲取的數據塊可能會被破壞。這可能是由於存儲設備故障，網絡故障或錯誤的軟件而導致的。HDFS客戶端軟件對HDFS文件的內容執行校驗和檢查。當客戶端創建一個HDFS文件時，它計算文件的每個塊的校驗和，並將這些校驗和存儲在同一HDFS命名空間中的單獨的隱藏文件中。當客戶端檢索文件內容時，它會驗證其從每個DataNode接收到的數據與存儲在相關校驗和文件中的校驗和相匹配。如果沒有，則客戶端可以選擇從另一個具有該塊副本的DataNode中檢索該塊。
元數據磁盤故障
FsImage和EditLog是HDFS的中心數據結構。這些文件的損壞可能導致HDFS實例不起作用。因此，NameNode可以配置為支持維護FsImage和EditLog的多個副本。對FsImage或EditLog的任何更新都會導致FsImages和EditLogs中的每一個被同步更新。FsImage和EditLog的多個副本的此同步更新可能降低NameNode可以支持的每秒命名空間事務的速率。然而，這種降級是可以接受的，因為即使HDFS應用程序本質上是非常數據密集的，它們也不是元數據密集型的。當NameNode重新啟動時，它會選擇最新一致的FsImage和EditLog來使用。
快照
快照支持在特定時刻存儲數據副本。快照功能的一個用法可能是將損壞的HDFS實例回滾到先前已知的好時間點。
數據組織
數據塊
HDFS旨在支持非常大的文件。與HDFS兼容的應用程序是處理大型數據集的應用程序。這些應用程序只寫一次數據，但它們讀取一次或多次，並要求這些讀取在流速下滿足。HDFS支持對文件的一次讀取多語義。HDFS使用的典型塊大小是128 MB。因此，將HDFS文件切成128 MB塊，如果可能，每個塊將駐留在不同的DataNode上。
分階段
創建文件的客戶端請求不會立即到達NameNode。實際上，最初，HDFS客戶端將文件數據緩存到本地緩沖區中。應用程序寫入被透明地重定向到本地緩沖區。當本地文件累積超過一個塊大小的數據時，客戶端將連接NameNode。NameNode將文件名插入到文件系統層次結構中，為其分配一個數據塊。NameNode使用DataNode和目標數據塊的標識響應客戶端請求。然后客戶端將數據塊從本地緩沖區刷新到指定的DataNode。關閉文件時，本地緩沖區中剩余的未刷新數據將傳輸到DataNode。客戶端然后告訴NameNode該文件是關閉的。此時，NameNode將文件創建操作提交到持久存儲。如果NameNode在文件關閉之前死機，該文件將丟失。
上述方法在仔細考慮了在HDFS上運行的目標應用程序后才采用。這些應用程序需要流式寫入文件。如果客戶端直接寫入遠程文件而沒有任何客戶端緩沖，網絡速度和網絡擁塞就會大大影響吞吐量。這種做法並非沒有先例。早期的分布式文件系統，例如AFS使用客戶端緩存來提高性能。POSIX要求已放寬，以實現更高性能的數據上傳。
復制管道
當客戶端將數據寫入HDFS文件時，首先將其數據寫入本地緩沖區，如上一節所述。假設HDFS文件的復制因子為3。當本地緩沖區累積一大批用戶數據時，客戶端將從NameNode中檢索一個DataNodes列表。該列表包含將承載該塊的副本的DataNodes。然后，客戶端將數據塊刷新到第一個DataNode。第一個DataNode開始以小部分接收數據，將每個部分寫入其本地存儲庫，並將該部分傳輸到列表中的第二個DataNode。第二個DataNode又開始接收數據塊的每個部分，將該部分寫入其存儲庫，然后將該部分刷新到第三個DataNode。最后，第三個DataNode將數據寫入本地存儲庫。因此，DataNode可以在流水線中接收來自前一個數據的數據，並且同時將數據轉發到流水線中的下一個數據。因此，數據從一個DataNode流水線到下一個。
訪問能力
HDFS可以從應用程序以許多不同的方式訪問。本來，HDFS提供了一個FileSystem Java API，供應用程序使用。此Java API和REST API的C語言包裝器也可用。另外，HTTP瀏覽器還可以用來瀏覽HDFS實例的文件。通過使用NFS網關，HDFS可以作為客戶端本地文件系統的一部分進行安裝。
FS Shell
HDFS允許以文件和目錄的形式組織用戶數據。它提供了一個名為FS shell的命令行接口，可讓用戶與HDFS中的數據進行交互。該命令集的語法類似於用戶已經熟悉的其他shell（例如bash，csh）。以下是一些示例操作/命令對：
| Action | Command |
|---|---|
| Create a directory named /foodir | bin/hadoop dfs -mkdir /foodir |
| Remove a directory named /foodir | bin/hadoop fs -rm -R /foodir |
| View the contents of a file named /foodir/myfile.txt | bin/hadoop dfs -cat /foodir/myfile.txt |
FS shell針對需要使用腳本語言與存儲數據進行交互的應用程序。
DFSAdmin
DFSAdmin命令集用於管理HDFS集群。這些是僅由HDFS管理員使用的命令。以下是一些示例操作/命令對：
| Action | Command |
|---|---|
| Put the cluster in Safemode | bin/hdfs dfsadmin -safemode enter |
| Generate a list of DataNodes | bin/hdfs dfsadmin -report |
| Recommission or decommission DataNode(s) | bin/hdfs dfsadmin -refreshNodes |
瀏覽器
典型的HDFS安裝配置Web服務器以通過可配置的TCP端口公開HDFS命名空間。這允許用戶瀏覽HDFS命名空間，並使用Web瀏覽器查看其文件的內容。
空間管理
文件刪除和取消刪除
如果啟用垃圾箱配置，FS Shell刪除的文件不會立即從HDFS中刪除。相反，HDFS將其移動到垃圾目錄（每個用戶在/user/<username>/.Trash下都有自己的垃圾文件目錄）。只要文件保留在垃圾箱中，文件可以快速恢復。
大多數最近刪除的文件被移動到當前垃圾桶目錄（/user/<username>/.Trash/Current），並且在可配置的時間間隔內，HDFS創建檢查點（在/ user / <username> /。垃圾桶/ <date>下）對於當前垃圾目錄中的文件，並在舊的檢查點過期時刪除它們。請參閱FS shell關於檢查垃圾的清除命令。
Trash生命周期到期時，Namenode從HDFS命名空間中刪除該文件。刪除文件會導致與文件關聯的塊被釋放。請注意，在用戶刪除文件的時間與HDFS中可用空間相應增加的時間之間可能會有明顯的時間延遲。
以下是一個示例，顯示如何從FS Shell從HDFS中刪除文件。我們創建了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:9820/user/hadoop/delete/test1 to trash at: hdfs://localhost:9820/user/hadoop/.Trash/Current
現在我們將使用skipTrash選項刪除該文件，該選項不會將文件發送到Trash。它將從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調用和集群中可用空間的外觀之間可能會有時間延遲。
References
Hadoop JavaDoc API.
HDFS source code: http://hadoop.apache.org/version_control.html