0094 HDFS架構、讀寫過程詳解、運維

HDFS的架構？

HDFS採用Master-Slave 架構，分爲4部分：

• HDFS Client：HDFS客戶端，通過與 NameNode和DataNode 交互訪問HDFS中的文件
• NameNode：NameNode是一箇中心服務器，負責管理文件系統的名字空間 (Namespace )及客戶端對文件的訪問
• DataNode：管理它所在節點上的存儲，一般一個節點運行一個DataNode
• Secondary DataNode：
  官網架構圖：
  

---

名稱空間？

維護文件系統樹、文件樹中文件、文件夾元數據

管理這些信息的文件有兩個，分別是Namespace 鏡像文件(fsimage)和操作日誌文件(edit log)，這些信息被Cache在RAM中，當然，這兩個文件也會被持久化存儲在本地硬盤

元數據？

描述數據的數據，又稱爲中繼數據、中介數據。如NameNode中的元數據信息：

“文件名 -> 數據塊‘’映射

“數據塊 -> DataNode列表”映射

文件Block管理？

NameNode記錄着文件中每個塊所在數據節點中的位置（元數據信息）。從NameNode中你可以獲取每個文件的每個塊所在的DataNode，但是NamdNode並不持久化這些信息，因爲【NameNode會在每次啓動系統時動態地重建這些信息】

DataNode？

DataNode負責存儲數據，一個【數據塊】（Block）會在多個DataNode中進行冗餘備份；定時通過heartbeat（心跳檢測）向NameNode發送所存儲的文件塊信息。

DataNode上數據簡單理解：存儲數據Block ID和Block，以及他們的對應關係

Secondary NameNode？

定時對NameNode的數據snapshot進行備份，這樣可儘量降低NameNode崩潰之後數據丟失風險；

具體爲，將NameNode中鏡像文件（fsimage)和操作日誌（edit log）合併再發送給NamedNode，這樣既可完成【減輕NameNode的負擔又能安全地備份，一旦HDFS的Master架構失效，就可以藉助Secondary NameNode進行數據恢復】

由於輔助Namenode總是落後於主Namenode，所以在Namenode宕機時，數據丟失是不可避免的。通常，Secondary Namenode 運行在一個單獨的物理機上，因爲合併操作需要佔用大量的CPU時間以及和Namenode相當的內存。

NameNode的目錄結構？

${dfs.name.dir}/current/VERSION
/edits
/fsimage
/fstime

Secondary NameNode的目錄結構？

${fs.checkpoint.dir}/current/VERSION
/edits
/fsimage
/fstime
/previous.checkpoint/VERSION
/edits
/fsimage
/fstime

Secondary NameNode和NameNode合併？

fsimage）文件是文件系統元數據的持久化檢查點，不會在寫操作後馬上更新，因爲fsimage寫非常慢（這個有比較像datafile）。

由於Edit log不斷增長，在NameNode重啓時，會造成長時間NameNode處於安全模式，不可用狀態，是非常不符合Hadoop的設計初衷。所以要週期性合併Edit log，但是這個工作由NameNode來完成，會佔用大量資源，這樣就出現了Secondary NameNode，它可以進行image檢查點的處理工作。步驟如下：
（1） Secondary NameNode請求NameNode進行edit log的滾動（即創建一個新的edit log），將新的編輯操作記錄到新生成的edit log文件；
（2） 通過http get方式，讀取NameNode上的fsimage和edits文件，到Secondary NameNode上；
（3） 讀取fsimage到內存中，即加載fsimage到內存，然後執行edits中所有操作（類似OracleDG，應用redo log），並生成一個新的fsimage文件，即這個檢查點被創建；
（4） 通過http post方式，將新的fsimage文件傳送到NameNode；
（5） NameNode使用新的fsimage替換原來的fsimage文件，讓（1）創建的edits替代原來的edits文件；並且更新fsimage文件的檢查點時間。
整個處理過程完成。
Secondary NameNode的處理，是將fsimage和edites文件週期的合併，不會造成nameNode重啓時造成長時間不可訪問的情況。

參考

HDFS的底層通信原理？

RPC和動態代理對象Proxy

NN與Secondary NN的寫過程交互？

1)寫入數據時，先向NN詢問是否可以寫入（已存在等情況），NN將元數據寫入EditLog文件中

2. NN通知客戶端可寫入，客戶端寫入結束後，通知NN寫入完畢，NN將editLog的元數據寫入內存

3)當Edit Log寫滿時，進行FSImage與Edit Log合併，在secondary namenode上進行。並通知NN停止寫入Edit Log,此時會創建一個新的Edit Log.new,當合並結束後，將合併後的文件上傳到NN，並刪除之前的Edit Log,將Edit Lod.new改名爲EditLog

注意：在寫入時，只要寫入了一個塊就算寫入成功，第二個塊由第一個塊去寫，依次類推，若副本寫入失敗，通知NN，重新再指定位置寫入副本。

數據節點數據存哪兒？

HDFS文件是以Linux系統上的普通文件進行存儲，在DataNode節點上。

HDFS的寫流程？

1. 客戶端向 NameNode（NN)請求 寫 數據，NN檢查目標文件是否已經存在、父目錄是否存在；
2. NN返回是否可以寫數據，若可以則繼續執行；
3. 客戶端請求上傳的block寫到哪個DataNode（DN)服務器上；
4. NN返回3個DN，分別爲dn1、dn2、dn3；
5. 客戶端請求在dn1上寫數據，dn1收到請求後，調用dn2，，然後dn2調用dn3，建立通信管道（pipeline）；
6. dn1、dn2、dn3 逐級應答客戶端（ack）；
7. 客戶端將block上傳到dn1，以packet爲單位，dn1收到packet存儲完後傳給dn2，並在應答隊列中放入一個應答，dn2依次再傳給dn3。當dn3存儲完，應答dn2，dn2再應答dn1，dn1將應答隊列中的應答刪除，標誌着一次packet數據同步成功；
8. 當一個block傳完，客戶端再次請求NN上傳第二個block的服務器（重複3~8）；

HDFS讀數據過程？

1. 客戶端向NN請求讀數據，NN通過查元數據（記錄數據位置的數據），找到文件快所在DN地址；
2. 挑選一臺DN（就近原則，然後隨機）服務器，請求數據讀取；
3. DN開始向客戶端傳數據，數據從磁盤讀到數據流，以packet爲單位驗證；
4. 客戶端以packet爲單位接受，先在本地緩存，然後寫入目標文件。

Hadoop節點動態新增節點？

HDFS節點線下？

（1）修改/conf/hdfs-site.xml 文件

（2）確定需要下線的機器，dfs.osts.exclude 文件中配置好需要下架的機器，這個是阻

止下架的機器去連接 NameNode。

（3）配置完成之後進行配置的刷新操作./bin/hadoop dfsadmin -refreshNodes,這個操作的作用是在後臺進行 block 塊的移動。

（4）當執行三的命令完成之後，需要下架的機器就可以關閉了，可以查看現在集羣上連接的節點，正在執行 Decommission，會顯示：Decommission Status : Decommission in progress 執行完畢後，會顯示：Decommission Status :Decommissioned

（5）機器下線完畢，將他們從excludes 文件中移除。

hadoop的塊大小，從哪個版本開始是128M

Hadoop1.x都是64M，hadoop2.x開始都是128M。

Linux中的塊大小爲4KB, 爲什麼HDFS中塊大小爲64MB或128MB?

如果採用4kb的塊大小來存放存儲在Hadoop中的數據, 就會需要大量的塊, 大大增加了尋找塊的時間, 降低了讀寫效率.
並且, 一個map或者一個reduce都是以一個塊爲單位處理, 如果塊很小, mapreduce任務數就會很多, 任務之間的切換開銷變大, 效率降低。

併發寫入HDFS文件可行嗎?

不行, 因爲客戶端通過namenode接收到在數據塊上寫入的許可後, 那個塊會鎖定直到寫入操作完成, 所以不能在同一個塊上寫入.

HDFS 中的 block 默認保存幾份?

3

JobTracker和TaskTracker區別？

• hadoop的集羣是基於master/slave模式，namenode和jobtracker屬於master，datanode和tasktracker屬於slave，master只有一個，而slave有多個。

• SecondaryNameNode內存需求和NameNode在一個數量級上，所以通常secondary NameNode（運行在單獨的物理機器上）和 NameNode 運行在不同的機器上。

JobTracker對應於NameNode,TaskTracker對應於DataNode。

• DataNode和NameNode是針對數據存放來而言的。JobTracker和TaskTracker是對於MapReduce執行而言的。

• mapreduce中幾個主要概念，mapreduce 整體上可以分爲這麼幾條執行線索：jobclient，JobTracker與TaskTracker。

• JobClient會在用戶端通過JobClient類將已經配置參數打包成jar文件的應用存儲到hdfs，並把路徑提交到Jobtracker,然後由JobTracker創建每一個Task（即 MapTask 和 ReduceTask）並將它們分發到各個TaskTracker服務中去執行。

• JobTracker是一master服務，軟件啓動之後JobTracker接收Job，負責調度Job的每一個子任務。task運行於TaskTracker上，並監控它們，如果發現有失敗的task就重新運行它。一般情況應該把JobTracker 部署在單獨的機器上。

• TaskTracker是運行在多個節點上的slaver服務。TaskTracker主動與JobTracker通信，接收作業，並負責直接執行每一個任務。TaskTracker 都需要運行在HDFS的DataNode上。

參考