共计 1196 个字符，预计需要花费 3 分钟才能阅读完成。
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/appli…
通过输出记录数，一般的 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：