做大數(shù)據(jù)&&算法 其實最重要的三件事 西采，就是 管理數(shù)據(jù) 和集群運維 模型訓練罐呼，一旦 遠離這三個主題鞠柄，大數(shù)據(jù)都無法發(fā)揮它應用的作用。
廢話不多說嫉柴，這幾天主要是采坑了厌杜。我認為現(xiàn)在碰到的最要命的就是 碰到 集群 掉鏈子 無法使用，導致 其他 同事無法運行 任務计螺。
這幾天夯尽，碰到了兩次 hadoop mapreduce 卡死的現(xiàn)象 ，主要就是停留在 job 那里 無法進行登馒，或者map 0 reduce 0.第一次 碰到時沒有找到原因匙握，用網(wǎng)上最粗暴的方法 重啟了hadoop集群，暫時解決了問題陈轿。
今天又碰到了同樣的問題圈纺，因為 logstash一直在往hdfs上寫數(shù)據(jù)，一旦重啟集群可能會丟失數(shù)據(jù)济欢，所以 一直非常謹慎，不敢 行事小渊。希望找到最主要的原因法褥。通過在網(wǎng)上查找，其實大部分是三種
1.原先配置有嚴重錯誤問題酬屉，因為之前我的集群 運行良好半等，現(xiàn)在 卡死，可能是 最近 集群狀態(tài)除了問題可以排除這一條呐萨，還有就是程序本身有問題杀饵，因為同一個程序運行小數(shù)據(jù)量的正常出了結果，大數(shù)據(jù)量就job卡死掉了谬擦，說明程序本身沒有問題
2.剩下的兩天就是 磁盤不足了和內存 不足了
先說磁盤不足 切距，其實這個是半真半假的事情，我們三個 DataNode節(jié)點的 各有 12T 的數(shù)據(jù)存放 磁盤惨远，12塊1024G的磁盤構成谜悟，但是 系統(tǒng)盤 只有區(qū)區(qū) 60G话肖，
內存不足 ，也是一個半真半假的事情葡幸，每個節(jié)點 12G 內存最筒，三個節(jié)點36G，每個節(jié)點 cpu 六核蔚叨。
為了確定問題的根源床蜘，只能先看 hadoop的logs 日志，Master 和 DataNode的logs 都看了蔑水，但是都沒有找到具體的原因邢锯，有點沮喪，后來 就去分析 job 執(zhí)行 的網(wǎng)頁狀態(tài)肤粱，job狀態(tài)也沒有發(fā)現(xiàn)太多問題弹囚，因為 job卡死，很多job 就直接被 hadoop job -kill job_id 掉了
后來就看 集群狀態(tài)圖领曼，發(fā)現(xiàn)一些貓膩鸥鹉。 CPU total 變成0 了，memery也是 0庶骄，接著再看毁渗，發(fā)現(xiàn) node unhealthy 出現(xiàn)了 3，
點開一看单刁，三個數(shù)據(jù)節(jié)點都是unhealthy的灸异。
那么 這個unhealthy 是一個更明晰的問題特征，
接著就跟著往深里 找原因羔飞，出現(xiàn) unhealthy 兩種原因肺樟，1. 節(jié)點通信故障 ，因為hdfs 一直在寫數(shù)據(jù) 很正常逻淌，可以排除
2么伯。磁盤 真的 不足了，但是我的節(jié)點12個磁盤都是在沒有超過80%呀卡儒，只有系統(tǒng)盤超過了90%田柔，難道 hadoop 連系統(tǒng)盤都算是檢查的盤，好吧骨望，可能是硬爆，之后就按網(wǎng)上的以解決磁盤不足導致job卡死。
主要是 hadoop 默認檢查 磁盤狀況擎鸠，一旦超過默認的90%就會 導致 數(shù)據(jù)節(jié)點拒絕執(zhí)行mapreduce缀磕，通過在yarn-site.xml 設置 更大的閾值，延遲 節(jié)點拒絕mapreduce的情況。通過在其中添加
<property> <name>yarn.nodemanager.disk-health-checker.min-healthy-disks</name> <value>0.0</value> </property> <property> <name>yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage</name> <value>100.0</value> </property>
集群也沒有重啟虐骑，Master和數(shù)據(jù)節(jié)點 四個機器都修改了准验，然后就生效。所以說 有些配置可以不重啟集群實現(xiàn)的廷没。
如果要重啟糊饱，網(wǎng)上給出 只用重啟 NodeManager 和Resourcemannager
`
3.1 重啟nodemanager：
/usr/local/goldmine/hadoop/default/sbin/yarn-daemon.sh stop nodemanager
/usr/local/goldmine/hadoop/default/sbin/yarn-daemon.sh start nodemanager
3.2 重啟resourcemanager，(否則會導致修改的節(jié)點狀態(tài)錯亂)
/usr/local/goldmine/hadoop/default/sbin/yarn-daemon.sh stop resourcemanager
/usr/local/goldmine/hadoop/default/sbin/yarn-daemon.sh start resourcemanager
3.3 刷新http://hadoop/cluster/nodes/unhealthy頁面： 可以看到不健康的nodemanager已經(jīng)消失在列表了。3.4 命令顯示yarn各節(jié)點狀態(tài)：
yarn node -list -all
`
也定位到了原來是系統(tǒng)磁盤惹得鬼，下次在建hadoop集群俊柔，系統(tǒng)磁盤也一定要足夠大，不然會嚴重影響集群的穩(wěn)定夭坪。
之后執(zhí)行job 完美執(zhí)行了，再看系統(tǒng)盤也恢復到40%一下过椎，剛才主要是系統(tǒng)盤有一些【臨時文件】導致的室梅。
之后發(fā)現(xiàn) job 又卡死了，但是這次是卡死在 map12 reduce0中疚宇，好詭異亡鼠，之前 發(fā)生了一件事情，map60% 后敷待，竟然回滾了到了map 0,接著卡死间涵。再次查看系統(tǒng)盤，又 飆到了97% 99% 96%榜揖，因為系統(tǒng)盤無法 擴容勾哩，這可咋整。
那我們就要想想 為什么 系統(tǒng)盤會突然猛增大量的臨時文件 擠占磁盤空間举哟，為什么 為什么Ｋ祭汀！７列伞Ｇ迸选！册赛！钠导，想了半天我終于知道了震嫉，這和hadoop的mapreduce 原理有關森瘪，如果是spark就不會出現(xiàn)這種情況，更多的是內存不足票堵，hadoop 的mapreduce 在map的中間結果會保留在磁盤上扼睬，而spark的中間結果會放在內存里，所以更快更吃內存。
正是因為hadoop的中間結果保存在了磁盤上窗宇，導致猛增大量臨時文件措伐。好，現(xiàn)在問題的根源找到了军俊，就是mapreduce 的中間文件太大影響了 磁盤空間 導致節(jié)點拒絕服務侥加，內存 和CPU 拒絕提供 都為 0， 導致 沒有資源粪躬，job 卡死担败。也說明了，為啥 小數(shù)據(jù)量程序正常镰官，大數(shù)據(jù)量了反而 job卡死提前，正是因為 數(shù)據(jù)量越大 中間結果就更多，擠占磁盤就更多泳唠。
但是我們 執(zhí)行mapreduce就是要產生中間文件的狈网，這個是源碼規(guī)定 適合hadoop運行保障的，不可以修改笨腥，那么 既然中間臨時文件必須產生拓哺，主要就是把中間文件放在哪里，可以保障 擠占磁盤的百分比更小扇雕，當然是更大的磁盤了拓售，我們的最小磁盤是系統(tǒng)盤，所以最容易增長百分比镶奉，job卡死础淤，所以我們要用最大的盤 保留 中間結果，我們最大的盤是1024G哨苛，就用這個就可以了鸽凶，然后就是設置 mapreduce中間結果路徑，在配置文件里建峭，到這里玻侥，問題就等于從根源上解決了。
hadoop 2.8.1 需要在 mapred-site.xml 設置 map.local.dir 和
map.tmp.dir 屬性對應的 磁盤目錄
