一、HDFS的工作機制
工作機制的學習主要是為加深對分布式系統的理解，以及增強遇到各種問題時的分析解決能 力，形成一定的集群運維能力
PS：很多不是真正理解 hadoop 工作原理的人會常常覺得 HDFS 可用於網盤類應用，但實際 並非如此。要想將技術准確用在恰當的地方，必須對技術有深刻的理解
概述
1、 HDFS 集群分為兩大角色： NameNode、 DataNode (Secondary Namenode)
2、 NameNode 負責管理整個文件系統的元數據，並且負責響應客戶端的請求
3、 DataNode 負責管理用戶的文件數據塊，並且通過心跳機制匯報給 namenode
4、 文件會按照固定的大小（ blocksize）切成若干塊后分布式存儲在若干台 datanode 上
5、 每一個文件塊可以有多個副本，並存放在不同的 datanode 上
6、 Datanode 會定期向 Namenode 匯報自身所保存的文件 block 信息，而 namenode 則會負 責保持文件的副本數量
7、 HDFS 的內部工作機制對客戶端保持透明，客戶端請求訪問 HDFS 都是通過向 namenode 申請來進行
二、HDFS寫數據流程
概述：客戶端要向 HDFS 寫數據，首先要跟 namenode 通信以確認可以寫文件並獲得接收文件 block 的 datanode，然后，客戶端按順序將文件逐個 block 傳遞給相應 datanode，並由接收到 block 的 datanode 負責向其他 datanode 復制 block 的副本 
詳細步驟文字說明：
1、使用 HDFS 提供的客戶端 Client，向遠程的 Namenode 發起 RPC 請求
2、 Namenode 會檢查要創建的文件是否已經存在，創建者是否有權限進行操作，成功則會 為文件創建一個記錄，否則會讓客戶端拋出異常；
3、當客戶端開始寫入文件的時候，客戶端會將文件切分成多個 packets，並在內部以數據隊 列“ data queue（數據隊列）”的形式管理這些 packets，並向 Namenode 申請 blocks，獲 取用來存儲 replicas 的合適的 datanode 列表，列表的大小根據 Namenode 中 replication
的設定而定；
4、開始以 pipeline（管道）的形式將 packet 寫入所有的 replicas 中。客戶端把 packet 以流的 方式寫入第一個 datanode，該 datanode 把該 packet 存儲之后，再將其傳遞給在此 pipeline 中的下一個 datanode，直到最后一個 datanode，這種寫數據的方式呈流水線的形式。
5、最后一個 datanode 成功存儲之后會返回一個 ack packet（確認隊列），在 pipeline 里傳遞 至客戶端，在客戶端的開發庫內部維護着"ack queue"，成功收到 datanode 返回的 ack packet 后會從"ack queue"移除相應的 packet。
6、如果傳輸過程中，有某個 datanode 出現了故障，那么當前的 pipeline 會被關閉，出現故 障的 datanode 會從當前的 pipeline 中移除，剩余的 block 會繼續剩下的 datanode 中繼續 以 pipeline 的形式傳輸，同時 Namenode 會分配一個新的 datanode，保持 replicas 設定的
數量。
7、客戶端完成數據的寫入后，會對數據流調用 close()方法，關閉數據流；
8、只要寫入了 dfs． replication． min(最小)的復本數（默認為 1），寫操作就會成功，並且這 個塊可以在集群中異步復制，直到達到其目標復本數（ dfs． replication 的默認值為 3）， 因為 namenode 已經知道文件由哪些塊組成，所以它在返回成功前只需要等待數據塊進
行最小量的復制。
自己手寫版：
1、client發寫數據請求
2、namenode 響應請求，然后做一系列校驗，如果能上傳該數據，則返回該文件的所有切塊應該被存在哪些datanode上的datanodes列表
blk-001:hadoop02 hadoop03
blk-002:hadoop03 hadoop04
3、client拿到datanode列表之后，開始傳數據
4、首先傳第一塊blk-001,datanode列表就是hadoop02，hadoop03，client就把blk-001傳到hadoop02，hadoop03上
5、....用傳第一個數據塊同樣的方式傳其他的數據
6、當所有數據塊都傳完之后，client會給namenode 返回一個狀態信息，表示數據已全部寫入成功，或者是失敗信息。
7、Namenode 接受到client返回的狀態信息來判斷當次寫入數據的請求是否成功，如果成功，就需要更新元數據信息。
三、HDFS讀數據流程
概述：客戶端將要讀取的文件路徑發送給 namenode， namenode 獲取文件的元信息（主要是 block的存放位置信息）返回給客戶端，客戶端根據返回的信息找到相應 datanode 逐個獲取文件的 block 並在客戶端本地進行數據追加合並從而獲得整個文件
詳細步驟圖：
詳細文字說明
1、使用 HDFS 提供的客戶端 Client，向遠程的 Namenode 發起 RPC 請求；
2、 Namenode 會視情況返回文件的全部 block 列表，對於每個 block， Namenode 都會返回有該 block 拷貝的 DataNode 地址；
3、客戶端 Client 會選取離客戶端最近的 DataNode 來讀取 block；如果客戶端本身就是 DataNode，那么將從本地直接獲取數據；
4、讀取完當前 block 的數據后，關閉當前的 DataNode 鏈接，並為讀取下一個 block 尋找最 佳的 DataNode；
5、當讀完列表 block 后，且文件讀取還沒有結束，客戶端會繼續向 Namenode 獲取下一批 的 block 列表；
6、讀取完一個 block 都會進行 checksum 驗證，如果讀取 datanode 時出現錯誤，客戶端會 通知 Namenode，然后再從下一個擁有該 block 拷貝的 datanode 繼續讀。
四、NameNode 的工作機制
1、namenode 職責
負責客戶端請求的響應（讀寫文件、刪除文件、重命名等等）
元數據的管理（查詢，修改）
2、namenode元數據管理
WAL（ Write ahead Log）: 每做一次操作之前，都會被記下來到這個日志中，然后再做操作，如果成功了，日志會對這次操作做一個成功或者失敗的標記，下次執行時，直接從WAL中拿出來執行 （WAL主要記錄 增刪改）
NameNode 對數據的管理采用了三種存儲形式：
(1) 內存元數據 metadata（全部存在內存中） （完整的元數據全部存在內存中，斷電就沒了）
(2)磁盤元數據鏡像文件 fsimage(全部存在磁盤)
(3)數據操作日志文件（可通過日志運算出元數據） edits（全部存在磁盤中）
edits:（edits-inprogress + 所有類似edits-001-004這種格式的edits）
metadata = 最新的fsimage + edits-inprogress
metadata = 所有的edits之和
(所有類似edits-001-004這種格式的edits 已經合並到fsimage)
3、NameNode 元數據存儲機制
A、內存中有一份完整的元數據(內存 metadata)
B、磁盤有一個“准完整”的元數據鏡像（ fsimage）文件(在 namenode 的工作目錄中)
C、用於銜接內存 metadata 和持久化元數據鏡像 fsimage 之間的操作日志（ edits 文件）
PS：當客戶端對 hdfs 中的文件進行新增或者修改操作，操作記錄首先被記入 edits 日志 文件中，當客戶端操作成功后，相應的元數據會更新到內存 metadata 中 （這就是WAL）
4、元數據的CheckPoint
每隔一段時間，會由 secondary namenode 將 namenode 上積累的所有 edits 和一個最新的 fsimage 下載到本地，並加載到內存進行 merge（這個過程稱為 checkpoint）
CheckPoint 詳細過程圖解：
5、CheckPoint觸發配置
6、CheckPoint的附帶作用
Namenode 和 SecondaryNamenode 的工作目錄存儲結構完全相同，所以，當 Namenode 故障 退出需要重新恢復時，可以從 SecondaryNamenode的工作目錄中將 fsimage拷貝到 Namenode 的工作目錄，以恢復 namenode 的元數據
五、DataNode工作機制
1、 Datanode 工作職責：
存儲管理用戶的文件塊數據
定期向 namenode 匯報自身所持有的 block 信息（通過心跳信息上報）
（ PS： 這點很重要，因為，當集群中發生某些 block 副本失效時，集群如何恢復 block 初始 副本數量的問題）
<property>
<name>dfs.blockreport.intervalMsec</name>
<value>3600000</value>
<description>Determines block reporting interval in milliseconds.</description>
</property
2、 Datanode 掉線判斷時限參數
datanode 進程死亡或者網絡故障造成 datanode 無法與 namenode 通信， namenode 不會立即 把該節點判定為死亡，要經過一段時間，這段時間暫稱作超時時長。 HDFS 默認的超時時長
為 10 分鍾+30 秒。如果定義超時時間為 timeout，則超時時長的計算公式為：
timeout = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval。
而默認的 heartbeat.recheck.interval 大小為 5 分鍾， dfs.heartbeat.interval 默認為 3 秒。 需 要 注 意 的 是 hdfs-site.xml 配 置 文 件 中 的 heartbeat.recheck.interval 的 單位 為 毫 秒 ，dfs.heartbeat.interval 的單位為秒。
所以，舉個例子，如果 heartbeat.recheck.interval 設置為 5000（毫秒）， dfs.heartbeat.interval 設置為 3（秒，默認），則總的超時時間為 40 秒。
3、觀察驗證Datanode功能
上傳一個文件，觀察文件的 block 具體的物理存放情況：
在每一台 datanode 機器上的這個目錄中能找到文件的切塊：
/home/hadoop/app/hadoop-2.5.2/tmp/dfs/data/current/BP-193442119-192.168.2.120-1432457
733977/current/finalized
六、SecondaryNamenode 工作機制
就是 CheckPoint 的工作機制 請看元數據的 CheckPoint