本文共 1600 字，大约阅读时间需要 5 分钟。

如果某个key下记录数远超其他key，在join或group的时候可能会导致某个reduce任务特别慢。可能会导致下面2个问题： 1）某个reduce task，卡在99.9%半天不动 2）任务超时被杀掉

如何判断是大Key导致的问题

通过时间判断

如果某个reduce的时间比其他reduce时间长的多。才可以查看Web UI，大部分task在4分钟之内完成，只有r_000021这个task在30分钟内还没完成。 另外注意，这里面需要排除一种特殊情况。有时候，某个task执行的节点可能有问题，导致任务跑的特别慢。这个时候，MapReduce的推测执行，会重启一个任务。如果新的任务在很短时间内能完成，通常则是由于task执行节点问题导致的个别task慢。如果推测执行后的task执行任务也特别慢，那更能说明该task可能会有倾斜问题。

通过任务Counter判断

Counter会记录整个job以及每个task的统计信息。counter的url一般类似： http://rm:9099/proxy/application_1498075186313_242232/mapreduce/taskcounters/task_1498075186313_242232_r_000017

1）通过输入记录数

普通的task counter如下： 而task=000021的counter如下，其输入记录数是2亿4000万，是其他任务的10几倍。 2）通过输出字符数 普通的task counter如下： 而task=000021的counter如下，是其他任务的几十倍：

如何找到大Key及对应SQL执行代码

【找到对应大Key】

一般情况下，Hive在做join的时候，会打印join的日志。我们通过日志查找大Key。 1）找到任务特别慢的那个task，打开对应日志，url类似于： http://rm:8042/node/containerlogs/container_e115_1498075186313_242232_01_000416/hdp-ads-audit/syslog/?start=0

2）搜索日志中出现的“rows for joinkey”，如下图：

3） 找到时间跨度最大的那条记录，如下图： 比如[54bc0748b1c0fb46135d117b6d26885e]，处理的时间从2017-08-03 11:31:30 一直到2017-08-03 11:46:35，耗时15分钟，任务依然没有结束。 另外，从日志中也可能看到，54bc0748b1c0fb46135d117b6d26885e已经处理了236528000条数据，实际情况该key在imei_open_app中确实有2亿3659万条数据。

【确定任务卡住的stage】

1）通过jobname确定stage 一般通过Hive的默认jobname会带上名称会带上stage阶段，如下为Stage-1。 2）如果jobname是自定义的，那可能没法通过jobname判断stage。需要借助于任务日志。找到执行特别慢的那个task，搜索 “CommonJoinOperator: JOIN struct” 。Hive在做join的时候，会把join的Key打印到日志中。如下： 上图中的关键信息是struct<_col1:string,_col6:string> 这时候，需要参考该SQL的执行计划。通过参考执行计划，可以断定该阶段为stage1阶段。 这时候，需要参考该SQL的执行计划。通过参考执行计划，可以断定该阶段为stage1阶段。

【确定SQL执行代码】

确定了执行阶段，即stage。通过执行计划，则可以判断出是执行哪段代码时出现了倾斜。还是从上图，可以推测出是在执行下面红框中代码时出现了数据倾斜。

转载地址：http://yfhli.baihongyu.com/