Hive 数据倾斜怎么发现，怎么定位，怎么解决
多数介绍数据倾斜的文章都是以大篇幅的理论为主，并没有给出具体的数据倾斜案例。当工作中遇到了倾斜问题，这些理论很难直接应用，导致我们面对倾斜时还是不知所措。
今天我们不扯大篇理论，直接以例子来实践，排查是否出现了数据倾斜，具体是哪段代码导致的倾斜，怎么解决这段代码的倾斜。
当执行过程中任务卡在 99%，大概率是出现了数据倾斜，但是通常我们的 SQL 很大，需要判断出是哪段代码导致的倾斜，才能利于我们解决倾斜。通过下面这个非常简单的例子来看下如何定位产生数据倾斜的代码。
表结构描述
先来了解下这些表中我们需要用的字段及数据量：
表的字段非常多，此处仅列出我们需要的字段
第一张表：user_info （用户信息表，用户粒度）
| 字段名 | 字段含义 | 字段描述 |
| userkey | 用户 key | 用户标识 |
| idno | 用户的身份证号 | 用户实名认证时获取 |
| phone | 用户的手机号 | 用户注册时的手机号 |
| name | 用户的姓名 | 用户的姓名 |
user_info 表的数据量：1.02 亿，大小：13.9G，所占空间：41.7G（HDFS三副本）
第二张表：user_active （用户活跃表，用户粒度）
| 字段名 | 字段含义 | 字段描述 |
| userkey | 用户 key | 用户没有注册会分配一个 key |
| user_active_at | 用户的最后活跃日期 | 从埋点日志表中获取用户的最后活跃日期 |
user_active 表的数据量：1.1 亿
第三张表：user_intend（用户意向表，此处只取近六个月的数据，用户粒度）
| 字段名 | 字段含义 | 字段描述 |
| phone | 用户的手机号 | 有意向的用户必须是手机号注册的用户 |
| intend_commodity | 用户意向次数最多的商品 | 客户对某件商品意向次数最多 |
| intend_rank | 用户意向等级 | 用户的购买意愿等级，级数越高，意向越大 |
user_intend 表的数据量：800 万
第四张表：user_order（用户订单表，此处只取近六个月的订单数据，用户粒度）
| 字段名 | 字段含义 | 字段描述 |
| idno | 用户的身份证号 | 下订单的用户都是实名认证的 |
| order_num | 用户的订单次数 | 用户近六个月下单次数 |
| order_amount | 用户的订单总金额 | 用户近六个月下单总金额 |
user_order 表的数据量：640 万
1. 需求
需求非常简单，就是将以上四张表关联组成一张大宽表，大宽表中包含用户的基本信息，活跃情况，购买意向及此用户下订单情况。
2. 代码
根据以上需求，我们以 user_info 表为基础表，将其余表关联为一个宽表，代码如下：
select a.userkey, a.idno, a.phone, a.name, b.user_active_at, c.intend_commodity, c.intend_rank, d.order_num, d.order_amount from user_info a left join user_active b on a.userkey = b.userkey left join user_intend c on a.phone = c.phone left join user_order d on a.idno = d.idno;
执行上述语句，在执行到某个 job 时任务卡在 99%：
这时我们就应该考虑出现数据倾斜了。其实还有一种情况可能是数据倾斜，就是任务超时被杀掉，Reduce 处理的数据量巨大，在做 full gc 的时候，stop the world。导致响应超时，超出默认的 600 秒，任务被杀掉。报错信息一般如下：
AttemptID:attempt_1624419433039_1569885_r_000000 Timed outafter 600 secs Container killed by the ApplicationMaster. Container killed onrequest. Exit code is 143 Container exited with a non-zero exit code 143
3. 倾斜问题排查
数据倾斜大多数都是大 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 多倍：
