怎么排查是哪里出现了数据倾斜

Hive 数据倾斜怎么发现，怎么定位，怎么解决

多数介绍数据倾斜的文章都是以大篇幅的理论为主，并没有给出具体的数据倾斜案例。当工作中遇到了倾斜问题，这些理论很难直接应用，导致我们面对倾斜时还是不知所措。

今天我们不扯大篇理论，直接以例子来实践，排查是否出现了数据倾斜，具体是哪段代码导致的倾斜，怎么解决这段代码的倾斜。

当执行过程中任务卡在 99%，大概率是出现了数据倾斜，但是通常我们的 SQL 很大，需要判断出是哪段代码导致的倾斜，才能利于我们解决倾斜。

倾斜问题排查

数据倾斜大多数都是大 key 问题导致的。

如何判断是大 key 导致的问题，可以通过下面方法：

1.通过时间判断

如果某个 reduce 的时间比其他 reduce 时间长的多，如下图，大部分 task 在 1 分钟之内完成，只有 r_000000 这个 task 执行 20 多分钟了还没完成。

注意：要排除两种情况：

如果每个 reduce 执行时间差不多，都特别长，不一定是数据倾斜导致的，可能是 reduce 设置过少导致的。

有时候，某个 task 执行的节点可能有问题，导致任务跑的特别慢。这个时候，mapreduce 的推测执行，会重启一个任务。如果新的任务在很短时间内能完成，大数据培训通常则是由于 task 执行节点问题导致的个别 task 慢。但是如果推测执行后的 task 执行任务也特别慢，那更说明该 task 可能会有倾斜问题。

2.通过任务 Counter 判断

Counter 会记录整个 job 以及每个 task 的统计信息。counter 的 url 一般类似：

http://bd001:8088/proxy/application_1624419433039_1569885/mapreduce/singletaskcounter/task_1624419433039_1569885_r_000000/org.apache.hadoop.mapreduce.FileSystemCounter

通过输入记录数，普通的 task counter 如下，输入的记录数是 13 亿多:

而 task=000000 的 counter 如下，其输入记录数是 230 多亿。是其他任务的 100 多倍：

4.定位 SQL 代码 1.确定任务卡住的 stage 通过 jobname 确定 stage：一般 Hive 默认的 jobname 名称会带上 stage 阶段，如下通过 jobname 看到任务卡住的为 Stage-4：

如果 jobname 是自定义的，那可能没法通过 jobname 判断 stage。需要借助于任务日志：

找到执行特别慢的那个 task，然后 Ctrl+F 搜索 “CommonJoinOperator: JOIN struct” 。Hive 在 join 的时候，会把 join 的 key 打印到日志中。如下：

上图中的关键信息是：struct<_col0:string, _col1:string, _col3:string>

这时候，需要参考该 SQL 的执行计划。通过参考执行计划，可以断定该阶段为 Stage-4 阶段：

2.确定 SQL 执行代码

确定了执行阶段，即 stage。通过执行计划，则可以判断出是执行哪段代码时出现了倾斜。还是从此图，这个 stage 中进行连接操作的表别名是 d：

就可以推测出是在执行下面红框中代码时出现了数据倾斜，因为这行的表的别名是 d：