關於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：快速定位各個節點情況，如每個節點的硬碟使用情況
關注微信公眾號：大資料學習與分享，獲取更對技術乾貨