關於HDFS應知應會的N個問題 | 技術點

1. Namenode的安全模式 ？

安全模式是Namenode的一種狀態（Namenode主要有active/standby/safemode三種模式）。

 

2. 哪些狀況下，Namenode會進入安全模式 ？

a. Namenode發現集羣中的block丟失率達到必定比例時（默認0.01%），Namenode就會進入安全模式，在安全模式下，客戶端不能對任何數據進行操做，只能查看元數據信息

b. 在hdfs集羣正常冷啓動時，Namenode也會在safemode狀態下維持至關長的一段時間，此時你不須要去理會，等待它自動退出安全模式便可

 

3. 爲何，在HDFS集羣冷啓動時，Namenode會在安全模式下維持至關長的一段時間 ？

Namenode的內存元數據中，包含文件路徑、副本數、blockid，及每個block所在Datanode的信息，而fsimage中，不包含block所在的Datanode信息。那麼，當Namenode冷啓動時，此時內存中的元數據只能從fsimage中加載而來，從而就沒有block所在的Datanode信息 ——> 就會致使Namenode認爲全部的block都已經丟失 ——> 進入安全模式 ——> 所在的Datanode信息啓動後，會按期向Namenode彙報自身所持有的block信息 ——> 隨着Datanode陸續啓動，從而陸續彙報block信息，Namenode就會將內存元數據中的block所在Datanode信息補全更新 ——> 找到了全部block的位置，從而自動退出安全模式

 

4. 如何退出安全模式 ？

1）找到問題所在，進行修復（好比修復宕機的所在Datanode信息補全更新）

2）能夠手動強行退出安全模式：hdfs namenode --safemode leave 【不推薦，畢竟沒有真正解決問題】

 

5. Namenode服務器的磁盤故障致使namenode宕機，如何挽救集羣及數據 ？

1）HA機制：高可用hadoop2.0
2）配置hdfs-site.xml指定而後重啓Namenode運行時數據存放多個磁盤位置
3）而後重啓Namenode和SecondaryNamenode的工做目錄存儲結構徹底相同，固然後重啓Namenode故障退出須要從新恢復時，能夠從SecondaryNamenode的工做目錄存儲結構徹底相同，當的工做目錄中的namesecondary文件夾及其中文件拷貝到而後重啓Namenode所在節點工做目錄中(但只能恢復大部分數據SecondaryNamenode最後一次合併以後的更新操做的元數據將會丟失)，將namesecondary重命名爲name而後重啓Namenode

 

6. Namenode是否能夠有多個？Namenode跟集羣數據存儲能力有關係嗎？

1）非HA的模式下Namenode只能有一個，HA模式下能夠有兩個（一主active一備standby），HDFS聯邦機制能夠有多個Namenode

2）關係不大，存儲數據由Datanode完成。可是藥儘可能避免存儲大量小文件，由於會耗費Namenode內存

 

7. fsimage是否存放了block所在服務器信息 ？

1）在edits中保存着每一個文件的操做詳細信息

2）在fsimage中保存着文件的名字、id、分塊、大小等信息，可是不保存Datanode 的IP

3）在hdfs啓動時處於安全模式，Datanode 向Namenode彙報本身的IP和持有的block信息

安全模式結束，文件塊和Datanode 的IP關聯上

驗證過程： 1) 啓動Namenode，離開safemode，cat某個文件，看log，沒有顯示文件關聯的Datanode 2) 啓動Datanode，cat文件，內容顯示 3) 中止Datanode ，cat文件，看log，看不到文件，但顯示了文件塊關聯的Datanode

 

8. Datanode動態上下線？

在實際生產環境中，在hdfs-site.xml文件中還會配置以下兩個參數：

dfs.hosts：白名單；dfs.hosts.exclude：黑名單

<property> <name>dfs.hosts</name> #完整的文件路徑：列出了容許連入NameNode的datanode清單（IP或者機器名） <value>$HADOOP_HOME/conf/hdfs_include</value> </property> <property> <name>dfs.hosts.exclude</name> #文件完整路徑：列出了禁止連入NameNode的datanode清單（IP或者機器名） <value>$HADOOP_HOME/conf/hdfs_exclude</value> </property>

1) 上線datanode

a) 保證上線的datanode的ip配置在白名單而且不出如今黑名單中

b) 配置成功上線的datanode後，經過命令hadoop-daemon.sh datanode start啓動

c) 刷新節點狀態：/bin/hadoop dfsadmin -refreshNodes(這個命令能夠動態刷新dfs.hosts和dfs.hosts.exclude配置，無需重啓NameNode)

d) 手動進行數據均衡：start-balance.sh

 

2) 下線datanode

a) 保證下線的datanode的ip配置在黑名單而且不出如今白名單中

b) 關閉下線的節點

c) 刷新節點狀態：/bin/hadoop dfsadmin -refreshNodes

d) 機器下線完畢後，將它們從hdfs_exclude文件中移除

 

9. 關於Datanode的幾個問題 ？

1）Datanode在什麼狀況下不會備份？

在強制關閉或者非正常斷電時不會備份

2）3個Datanode中有一個Datanode出現錯誤會怎樣？

這個Datanode的數據會在其餘的Datanode上從新作備份

 

10. HDFS HA機制下的腦裂現象以及避免方法 ？
當standby Namenode的ZKFailoverController收到active Namenode端故障通知時，不會當即將本身的狀態切換爲active，由於此時active Namenode可能處於「假死」狀態，若是即刻切換爲active狀態，有可能形成腦裂現象。
爲了防止腦裂，建議寫個腳本確保發出故障通知的active Namenode必定被kill掉，具體能夠按照如下幾個步驟完成kill操做：
1.執行殺掉active Namenode的shell腳本，等待ssh kill返回命令
2.若是響應成功，就把原standby Namenode的狀態切換爲active；若是響應失敗或者超時（能夠配置一個超時時間）
3.只要shell腳本的調用返回值爲true，則切換本身端的Namenode狀態爲active

筆者強調：Namenode主備切換、健康狀態監控等須要經過ZKFailoverController等組件實現，但最終會藉助於zookeeper集羣

 

11. HDFS爲何不適合存儲小文件 ？

通常一個block對應的元數據大小爲150byte左右，大量小文件會使內存中的元數據變大致使佔用大量Namenode內存、尋址時間長

 

 

12. 大量小文件的處理方式？

1）打成HAR files
命令：hadoop archive -archiveName xxx.har -p /src /dest
查看內容：hadoop fs -lsr har:///dest/xxx.har

該命令底層其實是運行了一個MapReduce任務來將小文件打包成HAR。可是經過HAR來讀取一個文件並不會比直接從HDFS中讀取文件高效，由於對每個HAR文件的訪問都須要進行index文件和文件自己數據的讀取。而且雖然HAR文件能夠被用來做爲MapReduce任務的input，可是並不能將HAR文件中打包的文件看成一個HDFS文件處理

2）編寫MR程序，將小文件序列化到一個Sequence File中

將小文件以文件名做爲key，以文件內容做爲value，編寫一個程序將它們序列化到HDFS上的一個Sequence File中，而後來處理這個Sequence File。相對打成HAR文件，具備兩個優點：
（1）Sequence File是可拆分的，所以MapReduce能夠將它們分紅塊並獨立地對每一個塊進行操做
（2）它們同時支持壓縮，不像HAR。在大多數狀況下，塊壓縮是最好的選擇，由於它將壓縮幾個記錄爲一個塊，而不是一個記錄壓縮一個塊

筆者強調hdfs小文件問題要結合具體的處理引擎以及業務狀況等，好比離線處理下、流式處理下小文件問題如何解決，以後筆者會開單篇詳述

13. 查看HDFS集羣工做狀態命令 ？

hdfs dfsadmin -report：快速定位各個節點狀況，如每一個節點的硬盤使用狀況

---

關注微信公衆號：大數據學習與分享，獲取更對技術乾貨