深刻理解HDFS工作原理
概述
HDFS（Hadoop Distributed File System ）Hadoop分散式檔案系統的簡稱。HDFS被設計成適合執行在通用硬體(commodity hardware)上的分散式檔案系統。DFS是一個高度容錯性的系統，適合部署在廉價的機器上。HDFS能提供高吞吐量的資料訪問，非常適合大規模資料集上的應用。HDFS放寬了一部分POSIX約束，來實現流式讀取檔案系統資料的目的。HDFS在最開始是作為Apache Nutch搜尋引擎專案的基礎架構而開發的。HDFS是Apache Hadoop Core專案的一部分。
本篇首先對HDFS的重要特性和使用場景做一個簡要說明，之後對HDFS的資料讀寫、元資料管理以及NameNode、SecondaryNamenode的工作機制進行深入分析。
HDFS工作原理簡介
HDFS的重要特性
HDFS是一個檔案系統，用於儲存和管理檔案，通過統一的名稱空間（類似於本地檔案系統的目錄樹）。HDFS是分散式的系統，伺服器叢集中各個節點都有自己的角色和職責。理解HDFS，需要注意以下幾個概念：
- HDFS中的檔案在物理上是分塊儲存（block），塊的大小可以通過配置引數(
dfs.blocksize)來規定，預設大小在hadoop2.x版本中是128M，之前的版本中是64M。 - HDFS檔案系統會給客戶端提供一個統一的抽象目錄樹，客戶端通過路徑來訪問檔案，形如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data
- 目錄結構及檔案分塊位置資訊(元資料)的管理由namenode節點承擔，namenode是HDFS叢集主節點，負責維護整個hdfs檔案系統的目錄樹，以及每一個路徑（檔案）所對應的資料塊資訊（blockid及所在的datanode伺服器）
- 檔案的各個block的儲存管理由datanode節點承擔，datanode是HDFS叢集從節點，每一個block都可以在多個datanode上儲存多個副本（副本數量也可以通過引數設定dfs.replication，預設是3）
- Datanode會定期向Namenode彙報自身所儲存的檔案block資訊，而namenode則會負責保持檔案的副本數量，HDFS的內部工作機制對客戶端保持透明，客戶端請求訪問HDFS都是通過向namenode申請來進行。
- HDFS是設計成適應一次寫入，多次讀出的場景，且不支援檔案的修改。需要頻繁的RPC互動，寫入效能不好。
HDFS寫資料分析
客戶端要向HDFS寫資料，首先要跟namenode通訊以確認可以寫檔案並獲得接收檔案block的datanode，然後客戶端按順序將檔案逐個block傳遞給相應datanode，並由接收到block的datanode負責向其他datanode複製block的副本。
對於HDFS寫資料的流程大概可以用以下的流程圖表示：
7. 客戶端向namenode傳送上傳檔案請求，namenode對要上傳目錄和檔案進行檢查，判斷是否可以上傳，並向客戶端返回檢查結果。
8. 客戶端得到上傳檔案的允許後讀取客戶端配置，如果沒有指定配置則會讀取預設配置（例如副本數和塊大小預設為3和128M，副本是由客戶端決定的）。向namenode請求上傳一個數據塊。
9. namenode會根據客戶端的配置來查詢datanode資訊，如果使用預設配置，那麼最終結果會返回同一個機架的兩個datanode和另一個機架的datanode。這稱為“機架感知”策略。
10. 客戶端在開始傳輸資料塊之前會把資料快取在本地，當快取大小超過了一個數據塊的大小，客戶端就會從namenode獲取要上傳的datanode列表。之後會在客戶端和第一個datanode建立連線開始流式的傳輸資料，這個datanode會一小部分一小部分（4K）的接收資料然後寫入本地倉庫，同時會把這些資料傳輸到第二個datanode，第二個datanode也同樣一小部分一小部分的接收資料並寫入本地倉庫，同時傳輸給第三個datanode，依次類推。這樣逐級呼叫和返回之後，待這個資料塊傳輸完成客戶端後告訴namenode資料塊傳輸完成，這時候namenode才會更新元資料資訊記錄操作日誌。
11. 第一個資料塊傳輸完成後會使用同樣的方式傳輸下面的資料塊直到整個檔案上傳完成。
細節：
a.請求和應答是使用RPC的方式，客戶端通過ClientProtocol與namenode通訊，namenode和datanode之間使用DatanodeProtocol互動。在設計上，namenode不會主動發起RPC，而是響應來自客戶端或 datanode 的RPC請求。客戶端和datanode之間是使用socket進行資料傳輸，和namenode之間的互動採用nio封裝的RPC。
b.HDFS有自己的序列化協議。
c.在資料塊傳輸成功後但客戶端沒有告訴namenode之前如果namenode宕機那麼這個資料塊就會丟失。
d.在流式複製時，逐級傳輸和響應採用響應佇列來等待傳輸結果。佇列響應完成後返回給客戶端。
c.在流式複製時如果有一臺或兩臺（不是全部）沒有複製成功，不影響最後結果，只不過datanode會定期向namenode彙報自身資訊。如果發現異常namenode會指揮datanode刪除殘餘資料和完善副本。如果副本數量少於某個最小值就會進入安全模式。
HDFS讀資料分析
客戶端將要讀取的檔案路徑傳送給namenode，namenode獲取檔案的元資訊（主要是block的存放位置資訊）返回給客戶端，客戶端根據返回的資訊找到相應datanode逐個獲取檔案的block並在客戶端本地進行資料追加合併從而獲得整個檔案。
HDFS讀資料步驟大概可以用以下的流程圖表示：
12. 客戶端向namenode發起RPC呼叫，請求讀取檔案資料。
13. namenode檢查檔案是否存在，如果存在則獲取檔案的元資訊（blockid以及對應的datanode列表）。
14. 客戶端收到元資訊後選取一個網路距離最近的datanode，依次請求讀取每個資料塊。客戶端首先要校檢檔案是否損壞，如果損壞，客戶端會選取另外的datanode請求。
15. datanode與客戶端簡歷socket連線，傳輸對應的資料塊，客戶端收到資料快取到本地，之後寫入檔案。
依次傳輸剩下的資料塊，直到整個檔案合併完成。
注：檔案合併的問題從某個Datanode獲取的資料塊有可能是損壞的，損壞可能是由Datanode的儲存裝置錯誤、網路錯誤或者軟體bug造成的。HDFS客戶端軟體實現了對HDFS檔案內容的校驗和(checksum)檢查。當客戶端建立一個新的HDFS檔案，會計算這個檔案每個資料塊的校驗和，並將校驗和作為一個單獨的隱藏檔案儲存在同一個HDFS名字空間下。當客戶端獲取檔案內容後，它會檢驗從Datanode獲取的資料跟相應的校驗和檔案中的校驗和是否匹配，如果不匹配，客戶端可以選擇從其他Datanode獲取該資料塊的副本。
HDFS刪除資料分析
HDFS刪除資料比較流程相對簡單，只列出詳細步驟:
16. 客戶端向namenode發起RPC呼叫，請求刪除檔案。namenode檢查合法性。
17. namenode查詢檔案相關元資訊，向儲存檔案資料塊的datanode發出刪除請求。
18. datanode刪除相關資料塊。返回結果。
19. namenode返回結果給客戶端。
注：當用戶或應用程式刪除某個檔案時，這個檔案並沒有立刻從HDFS中刪除。實際上，HDFS會將這個檔案重新命名轉移到/trash目錄。只要檔案還在/trash目錄中，該檔案就可以被迅速地恢復。檔案在/trash中儲存的時間是可配置的，當超過這個時間時，Namenode就會將該檔案從名字空間中刪除。刪除檔案會使得該檔案相關的資料塊被釋放。注意，從使用者刪除檔案到HDFS空閒空間的增加之間會有一定時間的延遲。只要被刪除的檔案還在/trash目錄中，使用者就可以恢復這個檔案。如果使用者想恢復被刪除的檔案，他/她可以瀏覽/trash目錄找回該檔案。/trash目錄僅僅儲存被刪除檔案的最後副本。/trash目錄與其他的目錄沒有什麼區別，除了一點：在該目錄上HDFS會應用一個特殊策略來自動刪除檔案。目前的預設策略是刪除/trash中保留時間超過6小時的檔案。將來，這個策略可以通過一個被良好定義的介面配置。
當一個檔案的副本系數被減小後，Namenode會選擇過剩的副本刪除。下次心跳檢測時會將該資訊傳遞給Datanode。Datanode遂即移除相應的資料塊，叢集中的空閒空間加大。同樣，在呼叫setReplication API結束和叢集中空閒空間增加間會有一定的延遲。
NameNode元資料管理原理分析
首先明確namenode的職責：響應客戶端請求、管理元資料。
namenode對元資料有三種儲存方式：記憶體元資料(NameSystem)、磁碟元資料映象檔案、資料操作日誌檔案（可通過日誌運算出元資料）
細節：HDFS不適合儲存小檔案的原因，每個檔案都會產生元資訊，當小檔案多了之後元資訊也就多了，對namenode會造成壓力。
三種儲存機制的解釋
記憶體元資料就是當前namenode正在使用的元資料，是儲存在記憶體中的。磁碟元資料映象檔案是記憶體元資料的映象，儲存在namenode工作目錄中，它是一個準元資料，作用是在namenode宕機時能夠快速較準確的恢復元資料。稱為fsimage。資料操作日誌檔案是用來記錄元資料操作的，在每次改動元資料時都會追加日誌記錄，如果有完整的日誌就可以還原完整的元資料。主要作用是用來完善fsimage，減少fsimage和記憶體元資料的差距。稱為editslog。
checkpoint機制分析
因為namenode本身的任務就非常重要，為了不再給namenode壓力，日誌合併到fsimage就引入了另一個角色secondarynamenode。secondarynamenode負責定期把editslog合併到fsimage，“定期”是namenode向secondarynamenode傳送RPC請求的，是按時間或者日誌記錄條數為“間隔”的，這樣即不會浪費合併操作又不會造成fsimage和記憶體元資料有很大的差距。因為元資料的改變頻率是不固定的。
每隔一段時間，會由secondary namenode將namenode上積累的所有edits和一個最新的fsimage下載到本地，並載入到記憶體進行merge（這個過程稱為checkpoint）。
checkpoint步驟：
1. namenode向secondarynamenode傳送RPC請求，請求合併editslog到fsimage。
2. secondarynamenode收到請求後從namenode上讀取（通過http服務）editslog（多個，滾動日誌檔案）和fsimage檔案。
3. secondarynamenode會根據拿到的editslog合併到fsimage。形成最新的fsimage檔案。（中間有很多步驟，把檔案載入到記憶體，還原成元資料結構，合併，再生成檔案，新生成的檔名為fsimage.checkpoint）。
4. secondarynamenode通過http服務把fsimage.checkpoint檔案上傳到namenode，並且通過RPC呼叫把檔案改名為fsimage。
namenode和secondary namenode的工作目錄儲存結構完全相同，所以，當namenode故障退出需要重新恢復時，可以從secondary namenode的工作目錄中將fsimage拷貝到namenode的工作目錄，以恢復namenode的元資料。
關於checkpoint操作的配置：
dfs.namenode.checkpoint.check.period=60 #檢查觸發條件是否滿足的頻率，60秒
dfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary
#以上兩個引數做checkpoint操作時，secondary namenode的本地工作目錄
dfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir}
dfs.namenode.checkpoint.max-retries=3 #最大重試次數
dfs.namenode.checkpoint.period=3600 #兩次checkpoint之間的時間間隔3600秒
dfs.namenode.checkpoint.txns=1000000 #兩次checkpoint之間最大的操作記錄editslog和fsimage檔案儲存在$dfs.namenode.name.dir/current目錄下，這個目錄可以在hdfs-site.xml中配置的。目錄結果如下：
包括edits日誌檔案（滾動的多個檔案），有一個是edits_inprogress_*是當前正在寫的日誌。fsimage檔案以及md5校檢檔案。seen_txid是記錄當前滾動序號，代表seen_txid之前的日誌都已經合併完成。
$dfs.namenode.name.dir/current/seen_txid非常重要，是存放transactionId的檔案，format之後是0，它代表的是namenode裡面的edits_*檔案的尾數，namenode重啟的時候，會按照seen_txid的數字恢復。所以當你的hdfs發生異常重啟的時候，一定要比對seen_txid內的數字是不是你edits最後的尾數，不然會發生重啟namenode時metaData的資料有缺少，導致誤刪Datanode上多餘Block的資訊。其他概念
安全模式：Namenode啟動後會進入一個稱為安全模式的特殊狀態。處於安全模式的Namenode是不會進行資料塊的複製的。Namenode從所有的 Datanode接收心跳訊號和塊狀態報告。塊狀態報告包括了某個Datanode所有的資料塊列表。每個資料塊都有一個指定的最小副本數。當Namenode檢測確認某個資料塊的副本數目達到這個最小值，那麼該資料塊就會被認為是副本安全(safely replicated)的；在一定百分比（這個引數可配置）的資料塊被Namenode檢測確認是安全之後（加上一個額外的30秒等待時間），Namenode將退出安全模式狀態。接下來它會確定還有哪些資料塊的副本沒有達到指定數目，並將這些資料塊複製到其他Datanode上。