情景再現：
在修復hadoop叢集某一個datanode無法啟動的問題時，搜到有一個答案說要刪除hdfs-site.xml中dfs.data.dir屬性所配置的目錄，再重新單獨啟動該datanode即可；
問題就出在這個誤刪除上，當時是在namenode的hadoop/hdfs/目錄下，然後就執行了一個可怕的命令
rm -rf data
rm -rf name #儲存namenode永久性後設資料目錄當時還不知道刪除這個的可怕，以為只是誤刪除了普通資料而已，然後再轉到datanode下再次執行刪除，再啟動datanode後就正常了，jps檢視各項服務均已正常啟動
然後晚上在執行一個job時，報錯了，說目錄不存在，到此我才意識到是我之前到誤刪導致到這個錯誤，當時把datanode節點除錯成功後也沒試試執行一個job驗證hadoop環境到正確性。
然後我就手動建了一個日誌說找不到到目錄，重啟後報錯namenode is not formatted，就是說需要格式化namenode才行，到這裡就傻眼了，格式化容易，可叢集上幾個t的資料可能就沒了，這很闊怕。
解決歷程：
首先重啟叢集，發現除了namenode外其他均成功啟動，這個時候使用
hdfs dfs -ls / 這樣的命令去檢視hdfs檔案系統，是無法檢視的，應該是報錯被拒絕。
我們去檢視
http://192.168.1.148:50070/dfshealth.html#tab-datanode
這個目錄，發現是無法訪問了，然後再去檢視每個資料節點的使用量，使用命令
df -lh發現幾個節點的使用量都不是為0，就是說叢集的資料並沒有被刪除，還有恢復的可能，然後看到了幾篇hadoop資料恢復的文章
1，hadoop主節點（NameNode）備份策略以及恢復方法
2，hadoop叢集崩潰恢復記錄
3，模擬namenode當機：資料塊損壞，該如何修復
還有一篇介紹資料儲存的文章
4，hadoop HDFS儲存原理
以下是正確的解決方案，耗時一天一夜，首先在本地偽分散式環境測試成功，然後移到叢集環境中成功解決：
1、存在一個正常的hadoop環境，hdfs上存在多個檔案及資料夾
2、刪除name目錄
3、stop-all.sh
4、執行namenode格式化操作
hadoop namenode -format5、複製namesecondary/current下的VERSION資料夾裡的三個id（clusterID，namespaceID，blockpoolID）到name/current的VERSION檔案相應的值裡
6、複製namesecondary/current資料夾下fsimage開頭的映象檔案到name到相應目錄下
7、start-all.sh
PS：這裡要注意一點，namesecondary裡和data裡的clusterID值一樣；name目錄指的是hdfs-site.xml中dfs.name.dir代表的目錄，這裡是tmp/hdfs/name，同理data目錄；因為沒有配置secondary目錄，所以採用的是預設的配置，所以namesecondary指的是tmp/dfs/namesecondary