HDFS的一些重要知識點

hdfs將檔案存放在哪裡？
datanode 使用者的檔案存放在datanode上，放在配置的目錄dfs.datanode.data.dir下
namenode 管理元資料（檔案路徑、副本數、檔案的blockid，位置等資訊）

##1.讀寫流程

一、讀流程

1、客戶端向namenode請求讀取檔案（指定一個路徑）

2、namenode查詢元資料資訊，看檔案是否存在，看檔案的block資訊，並返回給客戶端

3、客戶端拿到block資訊後，從第一個block開始，找到一臺最近的datanode

4、客戶端跟這臺DataNode發出讀取資料請求，建立檔案傳輸通道，開始接受資料到客戶端本地

5、接收完一個block後，再重複以上過程找到另一個DataNode接收下一個block

二、寫流程

1、客戶端向namenode請求上傳檔案（指定一個路徑）

2、namenode查詢元資料資訊，看路徑是否存在

3、客戶端就請求上傳第一個block，指定副本數量、blocksize等引數

4、namenode收到請求後、找到若干臺（副本數量）DataNode資訊返回給客戶端

5、客戶端跟第一個datanode發出請求建立資料傳輸通道，第一個datanode會繼續向第2個datanade發出通道建立請求，直到pipeline建立成功

6、pipeline成功後，客戶端就開始向第1個datanode傳輸第一個block的資料，第1個就向第2個，第2個就向第3個傳輸資料

7、待第一個block上傳成功後，繼續向namenode請求上傳第二個block塊

namenode和secondary namenode的工作目錄儲存結構完全相同，所以，當namenode故障退出需要重新恢復時，可以從secondary namenode的工作目錄中將fsimage拷貝到namenode的工作目錄，以恢復namenode的元資料

可以通過hdfs的一個工具來檢視edits中的資訊:
–>bin/hdfs oev -i edits -o edits.xml

2.namenode工作機制

主架構，負責管理元資料（檔案，名稱，副本，儲存位置）只有一個節點

（1）Namenode始終在記憶體中儲存metedata，用於處理“讀請求”

（2）到有“寫請求”到來時，namenode會首先寫editlog到磁碟，即向edits檔案中寫日誌，成功返回後，才會修改記憶體，並且向客戶端返回

（3）Hadoop會維護一個fsimage檔案，也就是namenode中metedata的映象，但是fsimage不會隨時與namenode記憶體中的metedata保持一致，而是每隔一段時間通過合併edits檔案來更新內容。Secondary namenode就是用來合併fsimage和edits檔案來更新NameNode的metedata的。

2.2namenode怎樣感知block位置資訊：

fsimage元資料裡面並沒有block所在的位置資訊，只有檔案的blockid資訊。
但是在叢集執行時，整個叢集中的所有datanode會定期向namenode彙報自身所持有的block資訊。
namenode收到這些資訊後，就會向記憶體中的元資料結構中維護block資訊。
同時namenode也就知道了那些block缺少副本，那些block多餘副本，就能採取相應的措施，補全缺少的，刪除冗餘的。

##2.3 元資料管理

NameNode對資料的管理採用了三種儲存形式：
記憶體元資料（NameSystem)
磁碟元資料映象檔案
資料操作日誌檔案（可通過日誌運算出元資料）

##2.3.1 元資料儲存機制

1、記憶體中有一份完整的元資料（記憶體 meta data）

2、磁碟有一個“準完整”的元資料映象（fsimage）檔案（在NameNode的工作目錄中）

3、用於銜接記憶體metadata和持久化元資料映象fsimage之間的操作日誌（edits檔案）注意：當客戶端對hdfs中的檔案進行新增或修改操作，操作記錄首先被記入edits日誌檔案中，當客戶端操作成功後，相應的元資料會更新到記憶體metadata中

2.4.namenode職責

1、負責客戶端請求的響應
2、元資料的管理（查詢，修改）

##2.5.namenode啟動流程

• NameNode啟動的時候首先將fsimage（映象）載入記憶體，並執行（replay）編輯日誌editlog的的各項操作

• 一旦在記憶體中建立檔案系統元資料對映，則建立一個新的fsimage檔案（這個過程不需SecondaryNameNode） 和一個空的editlog

• 在安全模式下，各個datanode會向namenode傳送塊列表的最新情況

• 此刻namenode執行在安全模式。即NameNode的檔案系統對於客戶端來說是隻讀的。(顯示目錄，顯示檔案內容等。寫、刪除、重新命名都會失敗)

• NameNode開始監聽RPC和HTTP請求

  解釋RPC:RPC（Remote Procedure Call Protocol）——遠端過程通過協議，它是一種通過網路從遠端計算機程式上請求服務，而不需要了解底層網路技術的協議

• 系統中資料塊的位置並不是由namenode維護的，而是以塊列表形式儲存在datanode中

• 在系統的正常操作期間，namenode會在記憶體中保留所有塊資訊的對映資訊

(1) 載入映象檔案，還原了checkpoint時間節點前的元資料（包含目錄結構，檔案大小，塊的大小，塊的id等等資訊），不包含塊的儲存位置
(2) 載入edits檔案，還原了checkpoint時間節點到叢集停止的元資料，不包含塊的儲存位置。（至此namenode還原的元資料唯一缺失的就是塊的儲存位置）
(3) blockreport階段，datanode啟動，向namendoe彙報自己所管理的塊及塊的id，namenode根據塊的ID還原塊的儲存位置
(4) 在blockreport結束後，叢集會判斷，datanode的啟動數量（可設定，預設為0），丟失的塊的佔比（可設定，預設0.999f）是否滿足退出安裝模式的條件，如果滿足，30秒後退出安全模式。在安全模式下namenode會刪除多餘的塊
（副本數為3，結果實際儲存4個。ps:這種情況發生在datanode宕機，叢集把宕機的datanode管理的塊進行了複製，
而宕機的datanode又重新啟動了）還會複製低於副本數的塊

##3.secondary namenode的工作機制，日誌合併步驟

輔助節點，用於合併兩類檔案

SecondaryNameNode它的職責是合併NameNode的edit logs到fsimage檔案中

首先，SecondaryNameNode定時到NameNode去獲取edit logs，並更新到fsimage上。一旦它有了新的fsimage檔案，SecondaryNameNode將其拷貝回NameNode中。NameNode在下次重啟時會使用這個新的fsimage檔案，從而減少重啟的時間。

Secondary NameNode的整個目的是在HDFS中提供一個檢查點。它只是NameNode的一個助手節點。這也是它在社群內被認為是檢查點節點的原因。

（1）secondary通知namenode切換edits檔案

（2）secondary從namenode獲得fsimage和edits(通過http)

（3）secondary將fsimage載入記憶體，然後開始合併edits

（4）secondary將新的fsimage發回給namenode

（5）namenode用新的fsimage替換舊的fsimage

##4.datanode工作機制

從架構，儲存真實資料的節點，存在多個

儲存管理使用者的檔案塊資料定期向namenode彙報自身所持有的block資訊（通過心跳資訊上報彙報的目的是，namenode如果長時間接收不到一個datanode的心跳後，說明該datanode宕機了，該datanode的資料塊就被namenode拿不到了，需要從其他機上拿該datanode的資料塊副本。)

（1）提供真實檔案資料的儲存服務。 （2）檔案塊（block）：最基本的儲存單位。對於檔案內容而言，一個檔案的長度大小是size，那麼從檔案的０偏移開始，按照固定的大小，順序對檔案進行劃分並編號，劃分好的每一個塊稱一個Block。HDFS預設Block大小是128MB，以一個256MB檔案，共有256/128=2個Block. dfs.block.size （3）不同於普通檔案系統的是，HDFS中，如果一個檔案小於一個數據塊的大小，並不佔用整個資料塊儲存空間 （4）Replication。多複本。預設是三個。hdfs-site.xml的dfs.replication屬性

##4.1Datanode工作職責：

1、儲存管理使用者的檔案塊資料
2、定期向namenode彙報自身所持有的block資訊（通過心跳資訊上報）

4.2Datanode掉線判斷時限引數

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秒。

##4.3 元資料checkpoint

每隔一段時間，會secondary NameNode 將NameNode上積累的所有edits和一個最新的fsimage下載到本地，並載入到記憶體進行merge，這個過程稱作 checkpoint

hdfs元資料是怎麼儲存的？

1、記憶體中有一份完整的元資料
2、磁碟有一個“準完整”的元資料映象
3、當客戶端對hdfs中的檔案進行新增或者修改操作，響應的記錄首先被記入edits這種log日誌中，當客戶端操作成功後，相應的元資料會更新到記憶體中
4、每隔一段時間，會由secondary namenode將namenode上積累的所有edits和一個最新的fsimage下載到本地，並載入到記憶體進行merge（這個過程稱為checkpoint）

checkpoint操作的觸發條件配置引數：(hdfs-site.xml)

​ dfs.namenode.checkpoint.check.period=60 #檢查觸發條件是否滿足的頻率，60秒
dfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary #secondary namenode的本地工作目錄
dfs.namenode.checkpoint.max-retries=3 #最大重試次數
dfs.namenode.checkpoint.period=3600 #兩次checkpoint之間的時間間隔3600秒
dfs.namenode.checkpoint.txns=1000000 #兩次checkpoint之間最大的操作記錄

5 HA

HA的運作機制
（1）hadoop-ha叢集運作機制介紹
所謂HA，即高可用（7*24小時不中斷服務）
實現高可用最關鍵的是消除單點故障
hadoop-ha嚴格來說應該分成各個元件的HA機制

同時出現兩個active狀態namenode的術語叫：

腦裂 brain split

防止腦裂有兩種方式

1 、ssh傳送kill指令

2、 呼叫使用者自定義指令碼程式

（2）HDFS的HA機制
通過雙namenode消除單點故障
雙namenode協調工作的要點：
A、元資料管理方式需要改變：
記憶體中各自儲存一份元資料
Edits日誌只能有一份，只有Active狀態的namenode節點可以做寫操作
兩個namenode都可以讀取edits
共享的edits放在一個共享儲存中管理（qjournal和NFS兩個主流實現）
B、需要一個狀態管理功能模組
實現了一個zkfailover，常駐在每一個namenode所在的節點
每一個zkfailover負責監控自己所在的namenode節點，利用zk進行狀態標識
當需要進行狀態切換時，由zkfailover來負責切換
切換時需要防止brain split現象的發生