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。終於。。。有空查了一下修改過來