溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本文主要是作者自己的學習過程，主要是對原文的翻譯及理解，某些地方根據自己的理解，在表述上稍做些改動，以便更易于理解。
官方原文
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作為一組大型應用程序的首選平臺。
HDFS有一個主/從架構。HDFS集群由一個NameNode(可選secondary NameNode)，NameNode是一個主服務器，它管理文件系統名稱空間并控制客戶機對文件的訪問。此外，還有許多datanode，通常是集群中的每個物理節點一個datanode，它們管理附加到它們所運行的物理節點上的存儲設備。HDFS對外暴露一個文件系統名稱空間，并允許將用戶數據存儲在文件中。在內部，一個文件被分成一個或多個塊，這些塊存儲在一組DataNode中。NameNode執行namespace operations，如打開、關閉和重命名文件和目錄。它還決定塊到數據塊(blocks)和數據節點(DataNodes)間的映射。DataNodes 負責處理來自文件系統客戶端的讀和寫請求。DataNodes還根據來自NameNode的指令執行塊的創建、刪除和復制。
集群中單個NameNode的存在極大地簡化了系統的體系結構。NameNode是所有HDFS元數據的仲裁器和存儲庫。系統以這樣的方式設計，用戶數據本身永遠不會流經NameNode。
HDFS支持傳統的分層文件組織。用戶或應用程序可以在這些目錄中創建目錄并存儲文件。文件系統名稱空間層次結構與大多數現有文件系統相似;可以創建和刪除文件，將文件從一個目錄移動到另一個目錄，或者重命名文件。HDFS支持用戶配額和訪問權限。HDFS不支持硬鏈接或軟鏈接。然而，HDFS體系結構并不排除實現這些特性。
NameNode維護文件系統名稱空間。對文件系統名稱空間或其屬性的任何更改都由NameNode記錄。應用程序可以指定HDFS應該維護的文件副本的數量。一個文件的拷貝數稱為該文件的復制因子。此信息由NameNode存儲。
HDFS的設計目的是在跨機器的大型集群中可靠地存儲非常大的文件。它將每個文件存儲為一系列塊(block)。復制文件的塊是為了容錯。每個文件都可以配置塊大小和復制因子。
除了最后一個塊之外，文件中的所有塊大小都相同，而用戶可以在append和hsync中添加了對可變長度塊的支持之后，啟動一個新塊，而不需要將最后一個塊填充到所配置的塊大小。
應用程序可以指定文件的副本數量。復制因子可以在文件創建時指定，稍后可以更改。HDFS中的文件是寫一次的(除了追加和截斷)，并且任何時候只有一個writer。
NameNode做出關于復制塊的所有決策。它定期從集群中的每個數據節點接收心跳和塊報告。接收到心跳意味著DataNode正常工作。塊報告包含DataNode上的所有塊的列表。
副本的位置對HDFS的可靠性和性能至關重要。經過優化的副本位置使HDFS區別于大多數其他分布式文件系統。.....
NameNode通過Hadoop 機架感知中概述的過程確定每個DataNode所屬的機架id。一個簡單但非最優的策略是將副本放在各個唯一的機架上。這可以防止在某個機架整體發生故障時丟失數據，并允許在讀取數據時使用多個機架的帶寬。該策略在集群中均勻分布副本，這使得在組件發生故障時很容易平衡負載。但是，這個策略增加了寫的成本，因為寫需要將塊轉移到多個機架。
為了最小化全局帶寬消耗和讀取延遲，HDFS嘗試滿足來自最接近讀取器的副本的讀取請求。如果在與讀取器節點相同的機架上存在一個副本，則首選該副本來滿足讀取請求。如果HDFS集群跨越多個數據中心，則首選駐留在本地數據中心的副本，而不是任何遠程副本。
一般情況下，當復制因子是3時，HDFS的放置策略是：
這個策略減少了機架間的寫流量，這通常可以提高寫性能。整個機架失效的概率要遠小于某個節點失效的概率，因此該策略并不影響對數據可靠性和可用性的保證。但是，它確減少了讀取數據時使用的聚合網絡帶寬，因為一個塊只放在兩個而不是三個機架中。使用此策略，文件的副本不會均勻地分布在機架上。三分之一的副本在一個節點上，三分之二的副本在一個機架上，另外三分之一均勻地分布在剩余的機架上。該策略在不影響數據可靠性或讀取性能的情況下提高了寫性能。
如果復制因子大于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.
總體而言就近讀
為了最小化全局帶寬消耗和讀取延遲，HDFS嘗試滿足來自最接近讀取器的副本的讀取請求。如果在與讀取器節點相同的機架上存在一個副本，則首選該副本來滿足讀取請求。如果HDFS集群跨越多個數據中心，則首選駐留在本地數據中心的副本，而不是任何遠程副本。
在啟動時，NameNode進入一個稱為Safemode的特殊狀態。當NameNode處于Safemode狀態時，不會發生數據塊的復制。NameNode接收來自datanode的心跳和塊報告消息。塊報告包含DataNode托管的數據塊列表。每個塊都有指定的最小數量的副本。當NameNode檢查到一個數據塊已經達到它所指定的最小副本數時就認為該數據塊已經安全復制。在達到一個可配置的“已安全復制的數據塊”的百分比之后(再加上30秒)，NameNode退出Safemode狀態。然后，NameNode檢查仍然小于指定副本數的數據塊列表(如果有的話)，并將這些塊復制到其他datanode。
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。
所有HDFS通信協議都位于TCP/IP協議之上。客戶端建立鏈接到NameNode上的可配置TCP端口，它使用ClientProtocol與NameNode通信。DataNode使用DataNode Protocol與NameNode通信。遠程過程調用(RPC)抽象封裝了Client Protocol和DataNode Protocol。按照設計，NameNode從不啟動任何rpc。相反，它只響應由datanode或客戶端發出的RPC請求。
HDFS的主要目標是即使在出現故障時也能可靠地存儲數據。常見的三種故障類型是NameNode故障、DataNode故障和network partitions。
每個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.）
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.
從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
... ...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)啟用高可用性。后者是推薦的方法。
HDFS被設計成支持非常大的文件。與HDFS兼容的應用程序也是那些處理大數據集的應用程序。這些應用程序只寫他們的數據一次，但他們讀取它一次或多次，并要求這些讀取滿足流速度。HDFS支持文件上的write-once-read-many語義。HDFS使用的典型塊大小為128mb，因此，HDFS文件被分割成128mb的塊，如果可能，每個塊將駐留在不同的DataNode上。
當客戶機將數據寫入復制因子為3的HDFS文件時，NameNode使用“復制目標選擇算法”獲取目標DataNodes列表。此列表包含將承載該數據塊塊副本的datanode。然后客戶端寫入第一個DataNode。第一個DataNode開始接收被切分成塊的數據，將每個塊寫入它的本地存儲庫（本地文件系統），并將該部分數據傳輸到列表中的第二個DataNode。然后，第二個DataNode開始接收數據塊的每個部分，將該部分寫到它的存儲庫中，然后將該部分刷新到第三個DataNode。最后，第三個DataNode將數據寫入其本地存儲庫。因此，DataNode可以從管道中的前一個接收數據，同時將數據轉發到管道中的下一個。因此，數據以pipelilne的形式從一個DataNode傳輸到下一個DataNode。
可以通過許多不同的方式從應用程序訪問HDFS。從本質上講，HDFS為應用程序提供了一個文件系統Java API。還提供了用于此Java API和REST API的C語言包裝器。此外，HTTP瀏覽器還可以用來瀏覽HDFS實例的文件。通過使用NFS網關，HDFS可以作為客戶機本地文件系統的一部分掛載。
，由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/test2當文件的復制因子降低時，NameNode選擇可以刪除的多余副本。下一個心跳將此信息傳輸到DataNode。然后，DataNode刪除相應的塊，集群中出現相應的空閑空間。同樣，在完成setReplication API調用和集群中出現空閑空間之間可能存在時間延遲。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
