一. 问题描述
需求:
4895708a4e03a6ab96b34ae81456e58.png
卡在了reduce，只有一个reduce
MR job卡在了最后一个reduce，任务迟迟未运行成功
image.png
二. 解决方案
2.1 调整reduce个数
一般一个reduce处理的数据是1G，所以首先想能不能增加reduce的个数来调优上述Hive SQL。
-- 可以指定每个redcue处理的数据size，也可以直接指定reduce的个数
set hive.exec.reducers.bytes.per.reducer = 12000000;
经验证，调整了上述参数后，问题依旧没有得到解决。
2.2 SQL改写
上述SQL所代表的业务逻辑是求截止当前每分钟的用户访问数(如出现多次，只算一次)
SQL也是因为 count(distinct)的存在，导致reduce数分配少了，进而出现数据性能问题。
所以首先我们想想能不能把count(distinct)去掉
因为本身是离线数据，此时可以借助临时表，首先把每个用户首次访问的时间记录下来，这样就可以将处理的数据大大减少，最后再通过开窗函数处理即可。
完美解决:
image.png
