hadoop設計思路和目標

本文主要是做者本身的學習過程，主要是對原文的翻譯及理解，某些地方根據本身的理解，在表述上稍作些改動，以便更易於理解。
官方原文

---

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的放置策略是：

1. 將一個副本放在本機若是寫入者位於一個datanode上，不然就放置在一個隨機的datanode
2. 另外一個副本放置在一個不一樣的機架上的datanode
3. 最後一個副本放置在和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/test2

Decrease Replication Factor

當文件的複製因子下降時，NameNode選擇能夠刪除的多餘副本。下一個心跳將此信息傳輸到DataNode。而後，DataNode刪除相應的塊，集羣中出現相應的空閒空間。一樣，在完成setReplication API調用和集羣中出現空閒空間之間可能存在時間延遲。