记一次神奇的 MapReduce OOM

背景

使用 HiBench 对 CDH 集群中各个组件进行基准测试（HiBench的使用这里不过多赘述）。由于最初 conf/hibench.conf 文件中配置的 hibench.scale.profile (影响数据规模的参数) 为 huge， hibench.default.map.parallelism & hibench.default.shuffle.parallelism (影响并行度的参数) 为 30。最终导致在 sql.aggregation 测试项中，总共只有 1.7 G 的数据被分割为了 30 个文件。

hdfs@t1:~/HiBench-master/report/aggregation/hadoop$ hdfs dfs -du -h /HiBench/Aggregation/Input/uservisits
0       0        /HiBench/Aggregation/Input/uservisits/_SUCCESS
59.4 M  178.1 M  /HiBench/Aggregation/Input/uservisits/part-00000
59.4 M  178.3 M  /HiBench/Aggregation/Input/uservisits/part-00001
...
59.4 M  178.3 M  /HiBench/Aggregation/Input/uservisits/part-00028
59.6 M  178.9 M  /HiBench/Aggregation/Input/uservisits/part-00029

这时，测试 SQL 的执行效率并不高，但这不是重点。重点是脑洞大开的我想着这些小文件连 128 M 都不到，如果两两合并可以让文件数减少为原来的一半，以此降低 NameNode 所需存储的元数据信息。

而且，Hive 处理数据时，默认情况下如果单个文件小于 128 M，即使只有10 M，也会分配一个 map 任务单独处理该文件。这就导致 map 任务太多，每个 map 处理的数据量太小。（map 数量过多过少都不好，平衡这个数量真的很玄学，实践或许才是检验真理的唯一标准）

$ cat uservisits_aggre.hive 
USE DEFAULT;
set hive.input.format=org.apache.hadoop.hive.ql.io.HiveInputFormat;
set mapreduce.job.maps=15; # 软性指定 15 后， map 数量依旧为 30
set mapreduce.job.reduces=3;
set hive.stats.autogather=false;

DROP TABLE IF EXISTS uservisits;
CREATE EXTERNAL TABLE uservisits (sourceIP STRING,destURL STRING,visitDate STRING,adRevenue DOUBLE,userAgent STRING,countryCode STRING,languageCode STRING,searchWord STRING,duration INT ) ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.OpenCSVSerde' STORED AS  SEQUENCEFILE LOCATION 'hdfs://t1.dev.dxy.cn:8020/HiBench/Aggregation/Input/uservisits';
DROP TABLE IF EXISTS uservisits_aggre;
CREATE EXTERNAL TABLE uservisits_aggre ( sourceIP STRING, sumAdRevenue