本篇博客將持續更新一些遇到過的Hadoop大數據集羣的問題，及相關的解決方案
1. DataNode服務經常僵死
描述
集羣一共設置了8個DataNode，經常不知道什麼原因會導致其中3 4 個一直處於僵死狀態，重啓可以恢復單身過一段時間又會有同樣的問題。如果長時間不管，甚至還會namenode服務掛掉。
分析
通過查看/data/var/log/hadoop/hdfs/目錄下面DataNode的log日誌可以看到:
java. io. IOException: Premature EOF from inputstream
文件操作超租期，實際上就是data stream操作過程中文件被刪掉了。通常是因爲Mapred多個task操作同一個文件，一個task完成後刪掉文件導致。這個錯誤跟dfs.datanode.max.transfer.threads參數到達上限有關。這個是datanode同時處理請求的任務上限，指定用於在DataNode間傳輸block數據的最大線程數，老版本的對應參數爲dfs.datanode.max.xcievers
若集羣中需要運行HBASE則需要設置更多，網上建議設置爲16k。
解決
將dfs.datanode.max.transfer.threads 原本爲1024調大至10240之後灰度重啓DataNode所有節點，隔一定時間後查看服務正常。
2. DataNode因數據盤損壞重啓失敗
描述
DataNode單點離線，且一直嘗試重啓DataNode失敗
分析
查看該節點DataNode日誌，可以看到
Invalid dfs.datanode.data.dir /data4/hadoop/hdfs/data :
java.io.FileNotFoundException: File file:/data4/hadoop/hdfs/data does not exist
初步判斷是有個數據盤壞了，讀取不到相應數據，導致每次重啓都會失敗。
解決
因爲需要保障線上服務，需要立刻啓動DataNode服務。
hdfs有一個配置dfs.datanode.failed.volumes.tolerated可以指定datanode可以容忍多少個失敗的目錄，默認是0，表示只要失敗一個datanode就無法啓動。
將該配置修改爲1之後再灰度重啓DataNode服務，成功。
後續操作則爲更換壞盤：
嘗試新建文件報錯如下
touch 111
touch: cannot touch `111': Read-only file system
硬盤的健康狀況
smartctl -H /dev/sdd
result後邊的結果：PASSED，這表示硬盤健康狀態良好
如果這裏顯示Failure，那麼最好立刻給服務器更換硬盤
可以肯定是這塊sdd硬盤出現問題，可以將此節點服務器，從hadoop羣集中排除，
umount這塊硬盤，之後更換個新的，重新格式化mount，再將服務器重新加入到hadoop羣集中即可。
網上有些朋友說進行linux修復模式，fsck下硬盤，但是爲了避免再出現問題，還是直接換個新的。
3. 優化Hadoop Balancer平衡的速度
Hadoop的HDFS集羣在使用一段時間後，各個DataNode節點的磁盤使用率肯定會出現不平衡的情況，也就是數據量層面的數據傾斜。
我們都知道當HDFS出現數據不平衡的時候，就會造成MapReduce或Spark等應用程序無法很好的利用本地計算的優勢，而且Datanode節點之間也沒有更好的網絡帶寬利用率，某些Datanode節點的磁盤無法使用等等問題。
可以參考 https://blog.51cto.com/xiaoxiaozhou/2139249
Ref
- https://community.cloudera.com/t5/Support-Questions/Is-there-any-recommendation-for-dfs-datanode-max-transfer/td-p/120288
- https://blog.csdn.net/levy_cui/article/details/51143058
