本文主要是作者自己的學習過程，主要是對原文的翻譯及理解，某些地方根據自己的理解，在表述上稍做些改動，以便更易於理解。
官方原文
hdfs與現有的分佈式文件系統有許多相似之處。但是，與其他分佈式文件系統的區別非常明顯。HDFS是高度容錯的，設計用於部署在低成本硬件上。HDFS提供對應用程序數據的高吞吐量訪問，適用於具有大數據集的應用程序。HDFS放寬了一些POSIX要求，以支持對文件系統數據的流式訪問。
硬件故障
首先明確：硬件故障是常態而不是意外。檢測到錯誤並且自動的，快速的恢復是hdfs的核心架構目標
流式數據訪問
運行在HDFS上的應用程序需要對其數據集進行流訪問。它們不是通常在通用文件系統上運行的通用應用程序。HDFS更多的是爲批處理而設計的，而不是用戶的交互使用。重點是數據訪問的高吞吐量，而不是數據訪問的低延遲。POSIX強加了許多針對HDFS的應用程序不需要的硬需求
大數據集
運行在HDFS上的應用程序擁有大型數據集。HDFS中的一個典型文件的大小是gb到tb。因此，HDFS被調優爲支持大文件。它應該提供高聚合數據帶寬，並可擴展到單個集羣中的數百個節點。它應該在一個實例中支持數千萬個文件。
簡單一致性模型
HDFS應用需要文件的write-once-read-many訪問模型。文件一旦被創建，寫和關閉操作出了追加和截斷，無需修改操作。支持將內容附加到文件末尾，但不能在任意點進行更新。這個假設簡化了數據一致性問題，並支持高吞吐量數據訪問。MapReduce應用程序或web爬蟲應用程序非常適合這個模型。
移動計算比移動數據廉價
如果應用程序請求的計算在其操作的數據附近執行，那麼它的效率會高得多。當數據集的大小很大時尤其如此。這將最小化網絡擁塞，並提高系統的總體吞吐量。這裏的假設是，將計算遷移到離數據更近的地方通常比將數據遷移到應用程序運行的地方要好。HDFS爲應用提供接口來移動他們自己以達到離數據所在的位置更近。
跨異構硬件和軟件平臺的可移植性
HDFS被設計成易於從一個平臺移植到另一個平臺。這有助於廣泛採用HDFS作爲一組大型應用程序的首選平臺。
NameNode and DataNodes
HDFS有一個主/從架構。HDFS集羣由一個NameNode(可選secondary NameNode)，NameNode是一個主服務器，它管理文件系統名稱空間並控制客戶機對文件的訪問。此外，還有許多datanode，通常是集羣中的每個物理節點一個datanode，它們管理附加到它們所運行的物理節點上的存儲設備。HDFS對外暴露一個文件系統名稱空間，並允許將用戶數據存儲在文件中。在內部，一個文件被分成一個或多個塊，這些塊存儲在一組DataNode中。NameNode執行namespace operations，如打開、關閉和重命名文件和目錄。它還決定塊到數據塊(blocks)和數據節點(DataNodes)間的映射。DataNodes 負責處理來自文件系統客戶端的讀和寫請求。DataNodes還根據來自NameNode的指令執行塊的創建、刪除和複製。
集羣中單個NameNode的存在極大地簡化了系統的體系結構。NameNode是所有HDFS元數據的仲裁器和存儲庫。系統以這樣的方式設計，用戶數據本身永遠不會流經NameNode。
The File System Namespace
HDFS支持傳統的分層文件組織。用戶或應用程序可以在這些目錄中創建目錄並存儲文件。文件系統名稱空間層次結構與大多數現有文件系統相似;可以創建和刪除文件，將文件從一個目錄移動到另一個目錄，或者重命名文件。HDFS支持用戶配額和訪問權限。HDFS不支持硬鏈接或軟鏈接。然而，HDFS體系結構並不排除實現這些特性。
NameNode維護文件系統名稱空間。對文件系統名稱空間或其屬性的任何更改都由NameNode記錄。應用程序可以指定HDFS應該維護的文件副本的數量。一個文件的拷貝數稱爲該文件的複製因子。此信息由NameNode存儲。
Data Replication
HDFS的設計目的是在跨機器的大型集羣中可靠地存儲非常大的文件。它將每個文件存儲爲一系列塊(block)。複製文件的塊是爲了容錯。每個文件都可以配置塊大小和複製因子。
除了最後一個塊之外，文件中的所有塊大小都相同，而用戶可以在append和hsync中添加了對可變長度塊的支持之後，啓動一個新塊，而不需要將最後一個塊填充到所配置的塊大小。
應用程序可以指定文件的副本數量。複製因子可以在文件創建時指定，稍後可以更改。HDFS中的文件是寫一次的(除了追加和截斷)，並且任何時候只有一個writer。
NameNode做出關於複製塊的所有決策。它定期從集羣中的每個數據節點接收心跳和塊報告。接收到心跳意味着DataNode正常工作。塊報告包含DataNode上的所有塊的列表。
Replica Placement: The First Baby Steps
副本的位置對HDFS的可靠性和性能至關重要。經過優化的副本位置使HDFS區別於大多數其他分佈式文件系統。.....
NameNode通過Hadoop 機架感知中概述的過程確定每個DataNode所屬的機架id。一個簡單但非最優的策略是將副本放在各個唯一的機架上。這可以防止在某個機架整體發生故障時丟失數據，並允許在讀取數據時使用多個機架的帶寬。該策略在集羣中均勻分佈副本，這使得在組件發生故障時很容易平衡負載。但是，這個策略增加了寫的成本，因爲寫需要將塊轉移到多個機架。
爲了最小化全局帶寬消耗和讀取延遲，HDFS嘗試滿足來自最接近讀取器的副本的讀取請求。如果在與讀取器節點相同的機架上存在一個副本，則首選該副本來滿足讀取請求。如果HDFS集羣跨越多個數據中心，則首選駐留在本地數據中心的副本，而不是任何遠程副本。
一般情況下，當複製因子是3時，HDFS的放置策略是：
- 將一個副本放在本機如果寫入者位於一個datanode上，否則就放置在一個隨機的datanode
- 另一個副本放置在一個不同的機架上的datanode
- 最後一個副本放置在和2相同機架的另一個datanode
這個策略減少了機架間的寫流量，這通常可以提高寫性能。整個機架失效的概率要遠小於某個節點失效的概率，因此該策略並不影響對數據可靠性和可用性的保證。但是，它確減少了讀取數據時使用的聚合網絡帶寬，因爲一個塊只放在兩個而不是三個機架中。使用此策略，文件的副本不會均勻地分佈在機架上。三分之一的副本在一個節點上，三分之二的副本在一個機架上，另外三分之一均勻地分佈在剩餘的機架上。該策略在不影響數據可靠性或讀取性能的情況下提高了寫性能。
如果複製因子大於3，那麼第4個以及後續的副本將隨機選擇datanode放置，但是每個節點的副本數量有限制（基本上是(replicas - 1) / racks + 2）
因爲NameNode不允許數據陽極具有相同塊的多個副本，所以創建的最大副本數量是當時的datanode總數。
在向HDFS添加了對Storage Types and Storage Policies的支持之後，除了上面描述的機架感知之外，NameNode還考慮這兩種策略。NameNode首先根據機架感知選擇節點，然後檢查候選節點是否具有與文件關聯的策略所需的存儲空間。如果候選節點沒有存儲類型，則NameNode將查找另一個節點。 If enough nodes to place replicas can not be found in the first path, the NameNode looks for nodes having fallback storage types in the second path.
Replica Selection
總體而言就近讀
爲了最小化全局帶寬消耗和讀取延遲，HDFS嘗試滿足來自最接近讀取器的副本的讀取請求。如果在與讀取器節點相同的機架上存在一個副本，則首選該副本來滿足讀取請求。如果HDFS集羣跨越多個數據中心，則首選駐留在本地數據中心的副本，而不是任何遠程副本。
Safemode
在啓動時，NameNode進入一個稱爲Safemode的特殊狀態。當NameNode處於Safemode狀態時，不會發生數據塊的複製。NameNode接收來自datanode的心跳和塊報告消息。塊報告包含DataNode託管的數據塊列表。每個塊都有指定的最小數量的副本。當NameNode檢查到一個數據塊已經達到它所指定的最小副本數時就認爲該數據塊已經安全複製。在達到一個可配置的“已安全複製的數據塊”的百分比之後(再加上30秒)，NameNode退出Safemode狀態。然後，NameNode檢查仍然小於指定副本數的數據塊列表(如果有的話)，並將這些塊複製到其他datanode。
The Persistence of File System Metadata
HDFS名稱空間由NameNode存儲。NameNode使用名爲EditLog的事務日誌持久地記錄文件系統元數據中發生的每個更改。例如，在HDFS中創建一個新文件會導致NameNode將一條記錄插入到表明這一點的EditLog中。類似地，更改文件的複製因子會將一條新記錄插入EditLog。NameNode使用其本地主機OS文件系統中的一個文件來存儲EditLog。整個文件系統名稱空間(包括塊到文件的映射和文件系統屬性)存儲在一個名爲FsImage的文件中。FsImage也作爲文件存儲在NameNode的本地文件系統中。
NameNode在內存中保存整個文件系統名稱空間和文件塊映射的鏡像。當NameNode啓動時，或者一個檢查點（checkpoint）被一個可配置的閾值觸發時，它從磁盤讀取FsImage和EditLog，將EditLog中的所有事務應用於FsImage的內存鏡像，並將這個新版本刷新到磁盤上的一個新FsImage中。然後，它可以截斷（truncate）舊的EditLog，因爲它的事務已應用於持久FsImage。這個過程稱爲checkpoint。checkpoint的目的是通過獲取文件系統元數據快照並將其保存到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。
The Communication Protocols
所有HDFS通信協議都位於TCP/IP協議之上。客戶端建立鏈接到NameNode上的可配置TCP端口，它使用ClientProtocol與NameNode通信。DataNode使用DataNode Protocol與NameNode通信。遠程過程調用(RPC)抽象封裝了Client Protocol和DataNode Protocol。按照設計，NameNode從不啓動任何rpc。相反，它只響應由datanode或客戶端發出的RPC請求。
Robustness 健壯性
HDFS的主要目標是即使在出現故障時也能可靠地存儲數據。常見的三種故障類型是NameNode故障、DataNode故障和network partitions。
Data Disk Failure, Heartbeats and Re-Replication
每個DataNode定期向NameNode發送一條心跳消息。網絡分區(network partition)可能導致部分DataNodes與NameNode失去連接。NameNode通過Heartbeat message的缺席來檢測這種情況。NameNode將沒有心跳的DataNode標記爲死節點，並且不向它們轉發任何新的IO請求。已註冊到死DataNode的任何數據都不再對HDFS可用。DataNode死亡可能導致某些數據塊的複製因子低於指定值。NameNode不斷跟蹤需要複製哪些塊，並在必要時啓動複製。重新複製的必要性可能由許多原因引起：DataNode可能不可用，副本可能損壞，DataNode上的硬盤可能失敗，或者文件的複製因子可能增加。
將DataNodes標記爲死亡的時限謹慎的設置的比較長（默認超過10分鐘），以避免由於DataNode狀態抖動而引起的複製風暴。用戶可以設置更短的間隔，將datanode標記爲陳舊的節點，並避免在配置爲性能敏感的工作負載時在陳舊數據節點上讀或寫（待深入理解 Users can set shorter interval to mark DataNodes as stale and avoid stale nodes on reading and/or writing by configuration for performance sensitive workloads.）
Cluster Rebalancing
HDFS體系結構與數據rebalancing方案兼容。如果DataNode上的空閒空間低於某個閾值，則方案可能會自動將數據從一個DataNode移動到另一個DataNode。In the event of a sudden high demand for a particular file, a scheme might dynamically create additional replicas and rebalance other data in the cluster. These types of data rebalancing schemes are not yet implemented.
Data Integrity
從DataNode獲取的數據塊可能損壞。這種損壞可能由於存儲設備、網絡故障或有bug的軟件中的錯誤而發生。HDFS客戶端軟件實現對HDFS文件內容的校驗和檢查。當客戶端創建HDFS文件時，它計算該文件的每個塊的校驗和，並將這些校驗和存儲在相同HDFS名稱空間中的一個單獨的隱藏文件中。當客戶機檢索文件內容時，它驗證從每個DataNode接收到的數據是否與存儲在關聯校驗和文件中的校驗和匹配。如果沒有，則客戶端可以選擇從具有該塊副本的另一個DataNode檢索該塊。
文件快和校驗文件
[root@datanode04 ~]# ll -h /data/hadoop/tmp/dfs/data/current/BP-855898234-106.66.38.101-1483934264653/current/finalized//subdir116/subdir82
total 835M
-rw-rw-r-- 1 hadoop hadoop 50M May 3 05:01 blk_1114919483
-rw-rw-r-- 1 hadoop hadoop 393K May 3 05:01 blk_1114919483_41260856.meta
-rw-rw-r-- 1 hadoop hadoop 49M May 3 05:01 blk_1114919485
-rw-rw-r-- 1 hadoop hadoop 392K May 3 05:01 blk_1114919485_41260858.meta
... ...Metadata Disk Failure
FsImage和EditLog是HDFS的中心數據結構。這些文件的損壞可能導致HDFS實例不可用。因此，可以將NameNode配置爲支持維護FsImage和EditLog的多個副本。對FsImage或EditLog的任何更新都會導致同步更新每個FsImage和EditLog。FsImage和EditLog的多個副本的同步更新可能會降低NameNode每秒可以支持的namespace事務的速度。但是，這種損失是可以接受的，因爲即使HDFS應用程序本質上是數據密集型的，但它們不是元數據密集型的。當NameNode重新啓動時，它選擇最新一致的FsImage和EditLog來使用。
提高故障恢復能力的另一個選項是使用多個namenode, shared storage on NFS 或使用distributed edit log (稱爲Journal)啓用高可用性。後者是推薦的方法。
Data Organization
Data Blocks
HDFS被設計成支持非常大的文件。與HDFS兼容的應用程序也是那些處理大數據集的應用程序。這些應用程序只寫他們的數據一次，但他們讀取它一次或多次，並要求這些讀取滿足流速度。HDFS支持文件上的write-once-read-many語義。HDFS使用的典型塊大小爲128mb，因此，HDFS文件被分割成128mb的塊，如果可能，每個塊將駐留在不同的DataNode上。
Replication Pipelining
當客戶機將數據寫入複製因子爲3的HDFS文件時，NameNode使用“複製目標選擇算法”獲取目標DataNodes列表。此列表包含將承載該數據塊塊副本的datanode。然後客戶端寫入第一個DataNode。第一個DataNode開始接收被切分成塊的數據，將每個塊寫入它的本地存儲庫（本地文件系統），並將該部分數據傳輸到列表中的第二個DataNode。然後，第二個DataNode開始接收數據塊的每個部分，將該部分寫到它的存儲庫中，然後將該部分刷新到第三個DataNode。最後，第三個DataNode將數據寫入其本地存儲庫。因此，DataNode可以從管道中的前一個接收數據，同時將數據轉發到管道中的下一個。因此，數據以pipelilne的形式從一個DataNode傳輸到下一個DataNode。
Accessibility
可以通過許多不同的方式從應用程序訪問HDFS。從本質上講，HDFS爲應用程序提供了一個文件系統Java API。還提供了用於此Java API和REST API的C語言包裝器。此外，HTTP瀏覽器還可以用來瀏覽HDFS實例的文件。通過使用NFS網關，HDFS可以作爲客戶機本地文件系統的一部分掛載。
Space Reclamation
File Deletes and Undeletes
，由FS Shell刪除的文件不會立即從HDFS中刪除。相反，HDFS將其移動到一個垃圾目錄(每個用戶在/user/<username>/. trash下都有自己的垃圾目錄)。只要文件保存在垃圾中，就可以快速恢復。最近刪除的文件被移動到當前垃圾目錄(/user/<username>/. trash / current)，在一個可配置的間隔內，HDFS爲當前垃圾目錄中的文件創建檢查點(在/user/<username>/. trash /<date>下)，並在舊檢查點過期時刪除它們。有關垃圾的檢查點，請參閱FS shell的expunge命令。在垃圾中的生命週期結束後，NameNode將從HDFS名稱空間中刪除該文件。刪除文件會釋放與文件關聯的塊。注意，從用戶刪除文件的時間到HDFS中相應的空閒空間增加的時間之間可能存在明顯的時間延遲。
如果開啓回收站特性的話，可以通過如下參數強制刪除
hadoop fs -rm -r -skipTrash delete/test2Decrease Replication Factor
當文件的複製因子降低時，NameNode選擇可以刪除的多餘副本。下一個心跳將此信息傳輸到DataNode。然後，DataNode刪除相應的塊，集羣中出現相應的空閒空間。同樣，在完成setReplication API調用和集羣中出現空閒空間之間可能存在時間延遲。