hive卡在最后一个reduce过不去_数据倾斜

sql语句

insert overwrite table jk_ld_xyxj_1214_25002 partition (stat_month='202110')
select a.msisdn, a.25002_area_type, a.longitude, a.latitude from
(select msisdn,25002_area_type,longitude,latitude,row_number() over (partition by msisdn order by longitude asc) rank from jk_ld_xyxj_1206_25002 where stat_month=202110) a 
where a.rank=1;

在hive中跑了两天，重复跑，总是卡在最后一个reduce上。
网上开始搜索原因。看到的比较多的原因

数据倾斜

hive数据倾斜原因和解决方法
在做Shuffle阶段的优化过程中，遇到了数据倾斜的问题，造成了对一些情况下优化效果不明显。主要是因为在Job完成后的所得到的Counters是整个Job的总和，优化是基于这些Counters得出的平均值，而由于数据倾斜的原因造成map处理数据量的差异过大，使得这些平均值能代表的价值降低。Hive的执行是分阶段的，map处理数据量的差异取决于上一个stage的reduce输出，所以如何将数据均匀的分配到各个reduce中，就是解决数据倾斜的根本所在。规避错误来更好的运行比解决错误更高效。

所以估计是数据倾斜问题。。那个reduce上堆了很多数据在跑。
我看了看我的sql，没有找到能发生数据倾斜的原因。
方式1：调整参数

虽然我没有从sql中看到能出现数据倾斜的原因，但是也按照网上的方式调整参数

hive.map.aggr = true

Map 端部分聚合，相当于Combiner

hive.groupby.skewindata=true

有数据倾斜的时候进行负载均衡，当选项设定为 true，生成的查询计划会有两个 MR Job。第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。
结果，失败。

方式2：调整reduce数量
失败

set mapred.reduce.tasks = 1000;

方式3：调整reduce的内存
失败

mapreduce.reduce.memory.mb=5120   //设置reduce container的内存大小
mapreduce.reduce.java.opts=-Xms2000m -Xmx4600m; //设置reduce任务的JVM参数

Reduce内存不足的解决方案

---

我忽然看到一个人说，key值为空的数量太多导致数据倾斜。于是我开始查询key值为null的情况有多少条。（其实上面链接就已经提到了，但是我忽略掉了，啊啊啊，这些空值都由一个reduce处理，灰常慢）

select count(*) from jk_ld_xyxj_1206_25002 where msisdn is null;

看，有两亿多条数据都是空值，他们经过group by后都有一个reduce处理，所以无论你调参数，还是调整reduce数量和内存都不管用，毕竟有两亿多条的数据啊！
后续我处理把电话为null的情况过滤掉。很快就跑出来了。

insert overwrite table jk_ld_xyxj_1214_25002 partition (stat_month='202110')
select a.msisdn, a.25002_area_type, a.longitude, a.latitude from
(select msisdn,25002_area_type,longitude,latitude,row_number() over (partition by msisdn order by longitude asc) rank from jk_ld_xyxj_1206_25002 where stat_month=202110
and msisdn is not null) a 
where a.rank=1;