Hadoop MapReduce作業(yè)卡死問題的解決方法

1、 Hadoop MapReduce 作業(yè)長(zhǎng)時(shí)間卡死問題的解決方法 目 錄 TOC o 1-3 h z u HYPERLINK l _Toc66483126 1. 問題描述 PAGEREF _Toc66483126 h 3 HYPERLINK l _Toc66483127 2. 問題分析 PAGEREF _Toc66483127 h 3 HYPERLINK l _Toc66483128 2.1. 數(shù)據(jù)傾斜可能性分析 PAGEREF _Toc66483128 h 3 HYPERLINK l _Toc66483129 2.2. Hadoop集群組件狀態(tài)分析 PAGEREF _Toc66483129

2、h 4 HYPERLINK l _Toc66483130 2.3. 日志分析 PAGEREF _Toc66483130 h 4 HYPERLINK l _Toc66483131 2.4. 作業(yè)運(yùn)行外圍情況分析 PAGEREF _Toc66483131 h 8 HYPERLINK l _Toc66483132 2.5. 分析小結(jié) PAGEREF _Toc66483132 h 9 HYPERLINK l _Toc66483133 3. 問題解決 PAGEREF _Toc66483133 h 91. 問題描述當(dāng)前，我們通過編寫Hadoop MapReduce程序?qū)?lái)自上游的源數(shù)據(jù)文件進(jìn)行貼源預(yù)處理加

3、工。源數(shù)據(jù)文件發(fā)到Hadoop集群后，我們的預(yù)處理程序會(huì)對(duì)源數(shù)據(jù)進(jìn)行編碼轉(zhuǎn)換、數(shù)據(jù)去重、加時(shí)間拉鏈、數(shù)據(jù)清洗、錯(cuò)誤數(shù)據(jù)處理等操作，生成貼源的ODS層數(shù)據(jù)，供上層建模使用。一直以來(lái)系統(tǒng)運(yùn)行穩(wěn)定，未出現(xiàn)過問題。但一段時(shí)間以來(lái)部分源文件的預(yù)處理作業(yè)頻繁出現(xiàn)作業(yè)長(zhǎng)時(shí)間卡死的問題，導(dǎo)致Hadoop集群資源被長(zhǎng)時(shí)間占用，其他作業(yè)因資源不足而無(wú)法正常調(diào)起，影響了預(yù)處理加工的時(shí)效性。對(duì)此我們從各方面進(jìn)行了分析和處理，具體過程如下。2. 問題分析2.1. 數(shù)據(jù)傾斜可能性分析當(dāng)問題出現(xiàn)時(shí)，我們首先考慮到可能是因?yàn)閿?shù)據(jù)傾斜問題導(dǎo)致了作業(yè)長(zhǎng)時(shí)間卡死的現(xiàn)象。于是我們首先檢查YARN控制臺(tái)的作業(yè)信息如圖2-1：圖2-1

4、YARN控制臺(tái)reduce任務(wù)運(yùn)行情況從上圖可以看到有大量的reduce任務(wù)長(zhǎng)時(shí)間運(yùn)行，而非少部分reduce任務(wù)長(zhǎng)時(shí)間運(yùn)行。數(shù)據(jù)傾斜的典型現(xiàn)象是大部分reduce任務(wù)執(zhí)行時(shí)間較短，只有很少的reduce任務(wù)長(zhǎng)時(shí)間運(yùn)行，可以說(shuō)上圖反映的情況與數(shù)據(jù)傾斜并不完全相符，同時(shí)，我們也對(duì)MR程序處理的源數(shù)據(jù)文件進(jìn)行了按Key值分組計(jì)算，發(fā)現(xiàn)并未有數(shù)據(jù)分布不均衡的情況，因此我們排除了因數(shù)據(jù)傾斜導(dǎo)致作業(yè)卡死的可能性。2.2. Hadoop集群組件狀態(tài)分析通過查看Hadoop集群UI頁(yè)面上各組件狀態(tài)以及查看NameNode、DataNode、ResouceManager等系統(tǒng)服務(wù)日志信息，可以確認(rèn)集群及各組件

5、沒有問題，運(yùn)行正常，從而排除因集群本身問題導(dǎo)致作業(yè)卡死。2.3. 日志分析我們發(fā)現(xiàn)這些長(zhǎng)時(shí)間運(yùn)行的作業(yè)都是卡死在reduce階段，有大量reduce任務(wù)卡在27%-30%進(jìn)度不再運(yùn)行，如圖2-1所示。同時(shí)也有部分map任務(wù)和reduce任務(wù)失敗。于是我們查看了該作業(yè)的如下日志信息：1）通過yarn -logs獲取的job日志：2）job對(duì)應(yīng)的容器日志為如圖2-2和圖2-3所示圖2-2 異常作業(yè)容器信息1圖2-3 異常作業(yè)容器信息23）失敗map任務(wù)日志：圖2-4 失敗map任務(wù)日志4）失敗reduce任務(wù)日志：圖2-5 失敗reduce任務(wù)日志5）長(zhǎng)時(shí)間卡死的reduce任務(wù)的syslog日志

6、：6）長(zhǎng)時(shí)間卡死的reduce任務(wù)的syslog.shuffle的日志：7）長(zhǎng)時(shí)間卡死的reduce任務(wù)的進(jìn)程棧根據(jù)上述日志進(jìn)行如下分析：（1）job日志中異常1：communication thread org.apache.hadoop.mapred.Task: Communicationexception。這個(gè)是任務(wù)的一種狀態(tài)報(bào)告機(jī)制，當(dāng)出現(xiàn)異常時(shí)會(huì)有重試機(jī)制（默認(rèn)為3次）。后續(xù)沒有出現(xiàn)異常，則說(shuō)明已恢復(fù)正常，不需要關(guān)注.（2）job日志中異常2：communication threadorg.apache.hadoop.yarn.util.ProcfsBasedProcessTree:

7、 Error reading the streamjava.io.IOException: 沒有那個(gè)進(jìn)程。出現(xiàn)該異常信息后，任務(wù)持續(xù)卡住長(zhǎng)達(dá)11小時(shí)，在任務(wù)界面上依然是running狀態(tài)，原因不明。（3）失敗map任務(wù)和失敗reduce任務(wù)日志顯示任務(wù)超時(shí)，容器被killed，對(duì)應(yīng)的進(jìn)程退出碼為143。從UI日志截圖顯示的任務(wù)超過10分鐘無(wú)響應(yīng)（對(duì)應(yīng)yarn容器配置中mapreduce.task.timeout=10分鐘)而被kill掉。該情況通常發(fā)生在任務(wù)高并發(fā)、IO競(jìng)爭(zhēng)激烈的場(chǎng)景下，考慮優(yōu)化超時(shí)時(shí)間、容器內(nèi)存配置等參數(shù)。但該問題不是導(dǎo)致作業(yè)卡死的原因，如果超長(zhǎng)reduce任務(wù)可以超時(shí)被ki

8、ll也不會(huì)出現(xiàn)本文之前描述的情況。（4）對(duì)于長(zhǎng)時(shí)間卡死的reduce任務(wù)的syslog日志中“IOException: 沒有那個(gè)進(jìn)程”異常，一般是讀取“/proc/meminfo”、“/proc/cpuinfo”等本地文件時(shí)出現(xiàn)，正常情況下任何用戶都可以訪問這些文件，初步診斷為可能是沒有更多的文件描述符來(lái)打開/proc/下對(duì)應(yīng)進(jìn)程文件的信息。通過“ulimit -n”查詢發(fā)現(xiàn)所有的節(jié)點(diǎn)配置所有用戶對(duì)應(yīng)的打開文件數(shù)為100000，在系統(tǒng)繁忙時(shí)可能有些偏少，后續(xù)考慮提升至150000。但這不是導(dǎo)致作業(yè)卡死的原因。（5）通過查看長(zhǎng)時(shí)間卡死的reduce任務(wù)的syslog.shuffle日志，可以發(fā)現(xiàn)

9、對(duì)應(yīng)的shuffle任務(wù)在較短的時(shí)間內(nèi)就處理了大量的map結(jié)果，但是shuffer任務(wù)本身日志中并沒有報(bào)錯(cuò)，呈現(xiàn)任務(wù)卡死現(xiàn)象，原因不明。（6）因上述日志沒有查到任務(wù)長(zhǎng)時(shí)間卡死的線索，我們又查了卡死reduce任務(wù)進(jìn)程的堆棧信息，從堆棧信息中，我們發(fā)現(xiàn)reduce任務(wù)獲取map任務(wù)完成事件的線程狀態(tài)是阻塞，也就是說(shuō)reduce任務(wù)在等待map任務(wù)完成的信號(hào)但一直沒收到，而事實(shí)上該job的所有map任務(wù)都已經(jīng)完成，這導(dǎo)致整個(gè)作業(yè)卡死，在高并發(fā)情況下會(huì)偶現(xiàn)這種情況。之所以reduce沒有觸發(fā)超時(shí)kill機(jī)制是reduce任務(wù)的ping心跳發(fā)送本身并沒有異常，而事件獲取線程也并未退出（若因異常退出，會(huì)

10、直接導(dǎo)致reducetask異常而重跑任務(wù)）。我們進(jìn)一步查了job的如下三個(gè)參數(shù)：ipc.client.ping=erval=60000ipc.client.rpc-timeout.ms=0因設(shè)置了基于TCP的Socket的網(wǎng)絡(luò)超時(shí)時(shí)間，當(dāng)任務(wù)節(jié)點(diǎn)讀取數(shù)據(jù)時(shí)發(fā)生SocketTimeoutException時(shí)，會(huì)自動(dòng)的向服務(wù)器端發(fā)送ping包，來(lái)測(cè)試當(dāng)前客戶端與服務(wù)器端的連接是否正常，對(duì)應(yīng)的參數(shù)為erval（默認(rèn)為60000ms)。ipc.client.rpc-timeout.ms是RPC客戶端等待相應(yīng)的超時(shí)時(shí)間值，當(dāng)參數(shù)的值為0時(shí)，在遠(yuǎn)程

11、方法調(diào)用沒有接受到數(shù)據(jù)的情況下，只要ping服務(wù)正常，就不會(huì)超時(shí)，而只會(huì)按erval時(shí)間間隔不停發(fā)出ping服務(wù)，如果有ipc.client.rpc-timeout.ms0,該時(shí)間內(nèi)未收到遠(yuǎn)程方法返回的數(shù)據(jù)即超時(shí)，隨即停止發(fā)送ping服務(wù)，從而可以有效避免卡死。當(dāng)前集群ping發(fā)送機(jī)制是打開的，每1分鐘定期向服務(wù)器發(fā)送ping服務(wù)，但是超時(shí)時(shí)間設(shè)置為0，即永不超時(shí)，會(huì)一直處于讀取map數(shù)據(jù)的階段，這也就是AM一直認(rèn)為該reduce任務(wù)還活著而沒有按照任務(wù)超時(shí)機(jī)制將其kill。這樣問題的核心原因基本找到了。2.4. 作業(yè)運(yùn)行外圍情況分析在分析日志的同時(shí)，我們也關(guān)注了作業(yè)卡

12、死時(shí)段的其他外圍情況：1）有大量作業(yè)在該時(shí)段被調(diào)起；2）近期集群進(jìn)行了擴(kuò)容，正在進(jìn)行數(shù)據(jù)均衡操作中，節(jié)點(diǎn)間IO競(jìng)爭(zhēng)激烈；3）鑒于hadoop的任務(wù)分配原則（本地?cái)?shù)據(jù)優(yōu)先，計(jì)算在數(shù)據(jù)所在節(jié)點(diǎn)上進(jìn)行的原則），在任務(wù)高峰期，某些節(jié)點(diǎn)IO競(jìng)爭(zhēng)激烈，會(huì)導(dǎo)致任務(wù)超時(shí)現(xiàn)象發(fā)生。2.5. 分析小結(jié)綜上，可以得到如下結(jié)論：1）ipc.client.rpc-timeout.ms=0參數(shù)設(shè)置不合理，無(wú)超時(shí)退出機(jī)制，導(dǎo)致在高并發(fā)、IO競(jìng)爭(zhēng)激烈的場(chǎng)景下，觸發(fā)了任務(wù)長(zhǎng)時(shí)間卡死的問題；2）節(jié)點(diǎn)文件描述符數(shù)偏低，導(dǎo)致任務(wù)執(zhí)行中出現(xiàn)“IOException: 沒有那個(gè)進(jìn)程”異常；3）超時(shí)時(shí)間、容器內(nèi)存配置等參數(shù)不夠優(yōu)化，導(dǎo)致部

13、分任務(wù)超時(shí)失敗退出，影響job執(zhí)行；4）大量作業(yè)并發(fā)和數(shù)據(jù)均衡操作一定程度上加劇了IO的競(jìng)爭(zhēng)程度，間接觸發(fā)了卡死問題的出現(xiàn)。其中1）是產(chǎn)生問題的主要因素。3. 問題解決問題原因找到就好制定處理方案了，我們通過控制作業(yè)并發(fā)、降低數(shù)據(jù)均衡操作帶寬和調(diào)整如下集群參數(shù)來(lái)解決問題：上述操作執(zhí)行后，問題得到解決。經(jīng)過此次問題處理，我們也總結(jié)了一套針對(duì)Hadoop程序長(zhǎng)時(shí)間執(zhí)行問題的解決思路：1、首先檢查是否有數(shù)據(jù)傾斜，因?yàn)榇蟛糠智闆r下是由這個(gè)原因引發(fā)Hadoop程序長(zhǎng)時(shí)間執(zhí)行問題。數(shù)據(jù)傾斜的典型現(xiàn)象是大部分reduce任務(wù)執(zhí)行時(shí)間較短，只有很少的reduce任務(wù)長(zhǎng)時(shí)間運(yùn)行，同時(shí)某個(gè)key對(duì)應(yīng)的數(shù)據(jù)比其他key對(duì)應(yīng)的數(shù)據(jù)多很多，一旦出現(xiàn)上述情況就可判斷是出現(xiàn)數(shù)據(jù)傾斜情況，需要對(duì)key值特別多的數(shù)據(jù)進(jìn)行單獨(dú)處理，比如在key上加隨機(jī)數(shù)把數(shù)據(jù)打散，使得數(shù)據(jù)盡可能的平均shuffle到各reduce節(jié)點(diǎn)上，充分利用各節(jié)點(diǎn)的算力。2、如果未出現(xiàn)數(shù)據(jù)傾斜的情況，那就需要先檢查集群各主要組件的運(yùn)行情況，如HDFS、YARN、Spark、Hive等，確認(rèn)各組件是否正常，有相當(dāng)一部分Hadoop程序長(zhǎng)時(shí)間執(zhí)行問題由組件運(yùn)行問題引起。一般通過查看Hadoop集群UI頁(yè)面上各組件狀態(tài)和查