本文地址：http://www.cnblogs.com/qiaoyihang/p/6293402.html
(一)Namenode的目錄結構
HDFS進行初次格式化之后將會在$dfs.namenode.name.dir/current目錄下生成一系列文件：
${dfs.namenode.name.dir}/ current VERSION edits_0000000000000000001-0000000000000000007 edits_0000000000000000008-0000000000000000015 edits_0000000000000000016-0000000000000000022 edits_0000000000000000023-0000000000000000029 edits_0000000000000000030-0000000000000000030 edits_0000000000000000031-0000000000000000031 edits_inprogress_0000000000000000032 fsimage_0000000000000000030 fsimage_0000000000000000030.md5 fsimage_0000000000000000031 fsimage_0000000000000000031.md5 seen_txid in_use.lock
VERSION 文件的內容是一些HDFS的ID信息，比較重要的是fsimage、edits和seen_txid
fsimage中存儲的是HDFS的元數據信息，包括文件系統上的文件目錄和相關序列化的信息。
edits文件保存的是HDFS上的更新操作信息。
seen_txid文件保存的是一個數字，就是最后一個edits_的數字
每次Namenode啟動的時候都會將fsimage文件讀入內存，並從00001開始到seen_txid中記錄的數字依次執行每個edits里面的更新操作，保證內存中的元數據信息是最新的、同步的，可以看成Namenode啟動的時候就將fsimage和edits文件進行了合並。
集群啟動之后，每次對HDFS的更新操作都會寫入edits文件。
對於客戶端來說，每次寫操作都會先記錄到edits文件中，之后更新Namenode內存中的元數據信息。
對於一個長期運行中的集群來說，edits文件會一直增大，SecondaryNamenode會在運行的時候定期將edits文件合並到fsimage中，否則一旦集群重新啟動，Namenode合並fsimage和edits使用的時間將會非常久。
SecondaryNamenode會運行一個checkpoint進程來進行合並操作：
1.SecondaryNamenode告知Namenode停止當前edits文件的讀寫，並將操作寫入一個新的edits文件，同時更新seen_txid文件
2.通過HTTP Get請求從Namenode中獲得fsimage和edits文件
3.加載fsimage文件到內存（和Namenode內存一致的原因），並執行edits文件中的每個操作，產生一個新的fsimage
4.通過HTTP Put將新的fsimage文件發送到Namenode中，保存為一個.ckpt文件
5.Namenode重命名.ckpt文件使其生效
默認情況下，SecondaryNamenode每隔一個小時就會進行以上的操作，通過dfs.namenode.checkpoint.period以秒為單位來配置
另外，如果未到達配置的時間而edits文件大小達到dfs.namenode.checkpoint.txns配置的值時也會進行合並操作
每隔dfs.namenode.checkpoint.check.period指定的時間檢查一個edits文件的大小
(二)SecondaryNamenode的目錄結構
SecondaryNamenode的current目錄和Namenode是類似的，但是其還保留着一個previous.checkpoint目錄 數據存儲的目錄由dfs.namenode.checkpoint.dir指定
顧名思義，就是上一個檢查點的目錄，其結構是和current目錄一致的
如此一來當Namenode掛了之后可以從SecondaryNamenode上啟動一個新的Namenode（即使可能不是最新的元數據）
有兩種方式可以實現：
1、第一種方式
(1)將相關的存儲目錄復制到新Namenode指定目錄中
(2)在SecondaryNamenode上使用-importCheckpoint選項來啟動Namenode進程
2、第二種方式
將指定目錄下的元數據加載到內存中從而成為一個新的Namenode
該目錄由dfs.namenode.checkpoint.dir指定（前提是dfs.namenode.name.dir目錄下找不到元數據信息）
(三)Datanode的目錄結構
和Namenode不一樣的是，Datanode的目錄並不需要進行格式化來創建，如下：
{dfs.datanode.data.dir}/
current
BP-1079595417-192.168.2.45-1412613236271
current
VERSION
finalized
subdir0
subdir1
blk_1073741825
blk_1073741825_1001.meta
lazyPersist
rbw
dncp_block_verification.log.curr
dncp_block_verification.log.prev
tmp
VERSION
in_use.lock
blk開頭的文件就是存儲HDFS block的數據塊
VERSION：與Namenode類似
finalized/rbw目錄：於實際存儲HDFS BLOCK的數據，里面包含許多block_xx文件以及相應的.meta文件，.meta文件包含了checksum信息
dncp_block_verification.log：用於追蹤每個block最后修改后的checksum值
in_use.lock：防止一台機器同時啟動多個Datanode進程導致目錄數據不一致
(四)安全模式
安全模式是指Namenode在剛啟動的時候，加載fsimage合並edits文件的過程，一旦加載完畢將會在磁盤中為自己創建一個新的fsimage和空的edits文件，該過程中無法對文件系統進行寫操作
關於安全模式的一些命令：
hadoop dfsadmin -safemode get：查詢是夠處於安全模式
hadoop dfsadmin -safemode wait：執行某命令以前先退出安全模式
hadoop dfsadmin -safemode enter：進入安全模式
hadoop dfsadmin -safemode leave：退出安全模式
(五)管理工具或命令
1、dfsadmin
hadoop dfsadmin既可以查詢HDFS狀態信息，也可以進行HDFS管理操作，用途較廣 該命令參數較多，可以使用-help選項來查看使用幫助
2、fsck
即為Filesystem check，文件系統檢查，可以得到HDFS指定目錄的健康狀態信息 該工具可以找出HDFS上缺失、過多、過少或者損壞的數據塊
fsck將從Namenode中獲得所有信息，而不會去Datanode獲取真實的block數據
hadoop fsck /user/heybiiiiii/part-00007 -files -blocks -racks
以上命令演示了如何通過fsck工具來為一個文件查找其block信息
-files：顯示該文件的文件名、大小、block數量和健康狀態
-blocks：顯示該文件每個block信息，每行一條信息
-racks：顯示每個block所在的Datanode和機架位置信息
3、Datanode的塊掃描器
每個Datanode都運行着一個塊掃描器定期檢測節點上的所有塊
從而在客戶端讀到損壞的數據塊之前及時的檢車和修復
默認情況下每個504個小時（三周）會自動檢查一個，該值可以通過dfs.datanode.scan.period.hours選項來配置
用戶可以通過訪問 http://datanode:50075/blockScanerReport 來查看該Datanode的塊檢測報告
4、balancer
隨着時間的推移，各個Datanode上的數據的分布會越來越不均衡，這樣會降低MapReduce的數據本地性導致性能降低，部分Datanode相對繁忙
balancer能夠將數據從繁忙的Datanode中遷移到較為空閑的Datanode，從而從新分配數據塊，在遷移數據的過程中也會始終堅持HDFS的副本存放策略
balancer一旦啟動，將會不斷地移動數據，直至集群中的數據達到一個平衡的狀態
該狀態通過該節點已用空間和整個集群可用空間之比和集群中已用空間和整個集群可用空間之比來判斷 一個集群中只能運行一個balancer程序，命令如下：
start-balancer.sh
通過-threshold選型來指定一個閾值以判斷集群是否平衡，默認為10%
二、Hadoop集群的日常維護
(一)元數據備份
一旦元數據出現損壞，整個集群將無法工作，所以元數據的備份是非常重要的
可以在系統中分別保存不同時間點的備份（一小時、一天、一周或者一個月）以保護元數據
一個最直接的方法就是使用dfsadmin命令來下載一個Namenode最新的元數據副本：
hdfs dfsadmin -fetchImage fsimage.backup
可以通過一個腳本定時在異地站點存儲元數據信息
(二)數據備份
盡管HDFS的數據容錯性做的很好，但是我們仍然不能夠保證其永遠不會出錯
HDFS上的數據備份可以通過distcp工具來實現集群數據的復制
(三)文件系統檢查
建議定期使用fsck工具對HDFS上的數據塊進行檢查，主動查找丟失或者損壞的數據塊
(四)文件系統均衡
定期運行balancer程序以保證各個Datanode的數據平衡
(五)添加和刪除節點
1、添加節點
過程如下：
(1)將新機器的地址加入以上允許連接的列表中
(2)使用hdfs dfsadmin -refreshNodes/yarn rmadmin -refreshNodes命令重新讀取配置
(3)在slaves文件中添加該節點信息，使得hadoop腳本文件可以讀取到
(4)在新節點配置完之后啟動Datanode和NodeManager進程
(5)可以在We界面查看該節點是否上線
注意：HDFS不會自動將數據遷移到新節點，需要手動啟動balancer進程
2、刪除節點
過程如下：
(1)將新機器的地址加入以上不允許連接的列表中
(2)使用hdfs dfsadmin -refreshNodes/yarn rmadmin -refreshNodes命令重新讀取配置
(3)在Web界面可以看到該節點處於Decommission in progress狀態，節點上的數據將會被遷移到其他節點中
(4)當節點處於Decommissioned狀態時表示數據塊復制完畢，關閉該節點上的進程
(5)從允許連接的列表中移除該節點並重新執行命令刷新配置
(6)在slaves文件中移除該節點
注意，副本數量要小於或者等於正常節點的數量，否則刪除失敗
刪除節點時，該節點長期處於Decommission Status : Decommission in progress狀態，由於數據量太大，導致復制的時間很久，使用新集群測試時瞬間下線該節點
(六)集群升級
在升級集群之前可以現在一個測試集群上進行測試確保升級無誤之后再在生產集群上進行升級
僅當文件系統健康時才能進行升級，所以在升級之前使用fsck工具對文件系統進行檢查 最好保留檢查結果，對比升級前和升級后的信息
升級之前最好清空臨時文件，包括HDFS、MapReduce系統目錄和本地臨時文件
升級步驟如下：
(1)升級之前確保前一升級已經定妥
(2)關閉Yarn和MapReduce進程
(3)關閉HDFS進程並備份元數據目錄
(4)在集群中安裝新版本的Hadoop
(5)使用-upgrade選項來啟動HDFS
(6)等待等級完成
(7)檢查HDFS是否運行正常
(8)啟動Yarn和MapReduce進程
(9)回滾（可選操作）
步驟5中使用的命令如下：
/bin/start-dfs.sh -upgrade
該命令的結果是讓Namenode升級元數據，並將前一版本放在名為previous目錄下，Datanode的操作類似
步驟6中，可以使用dfsadmin工具來查看升級進度：
/bin/hdfs dfsadmin -upgradeProgress status
如果需要對升級進行回滾，則進行步驟9的操作：
首先關閉HDFS進程
使用-rollback選項來啟動舊版本的Hadoop進程：
/bin/start-dfs.sh -rollback
該命令會讓Namenode和Datanode使用升級之前的副本替換當前存儲目錄，文件系統恢復之前的狀態