【總結】一不小心的Map端數據傾斜

MapReduce任務的數據傾斜一般指的是Reduce端數據傾斜，Map端怎么還會出現數據傾斜呢。~~

Mapper任務如下圖所示，其中一個map任務耗時特別長

跑了一個ETL程序，兩個Map分別讀取兩類數據，一個是lzo格式，另外一個是txt格式。

map任務通常是一個數據塊一個map，為什么其中一個map計算會如此耗時呢，分別查看兩個數據文件的分塊情況

輸入1有50個分塊

輸入2有11個分塊

查看任務一共才有52個map。map格式應該是50+11=61個才對。

有如下結論

MultipleInputs兩個輸入，有一個在數據輸入的時候沒有Split成功，考慮到其中一個輸入是lzo，極有可能是該文件沒有index索引造成。

于是檢查lzo文件所在目錄中，檢查是否存在lzo.index文件。

存在lzo.index文件，還能造成讀取數據沒有進行分塊處理，于是檢查代碼發現，在處理lzo文件的時候采用了TextInputFormat（代碼標紅位置處已修改為LzoTextInputFormat）。

所以沒有按照lzo.index進行文件分塊。一個lzo文件都在一個map里面進行計算處理。導致處理數據map個數不對，并且其中一個map處理耗時長。

if (commonPath != null && commonPath.length() != 0) {

MultipleInputs.addInputPath(job, new Path(commonPath.toString()), TextInputFormat.class, MidHotelMapper.class);

} else {

logger.error("輸入路徑為空:-->{}", conf.get(CommonConstant.COMMON_TASK_INPUT));

System.exit(-1);

}

if (ctripPath != null && ctripPath.length() != 0) {

MultipleInputs.addInputPath(job, new Path(ctripPath.toString()), LzoTextInputFormat.class, MidCtripHotelMapper.class);

} else {

logger.error("輸入路徑為空:-->{}", conf.get(Constant.CTRIP_TASK_INPUT));

System.exit(-1);

}

修改之前這ETL任務平均耗時在16分鐘左右。

修改之后，耗時只用2分鐘。

竟然用TextInputFormat跑了兩年的ETL。終于。。。有空查了一下修改過來