窗口函数reduce卡在99%是因分区键数据倾斜，如某key占80%，导致单reducer处理几亿行；需用distribute by加盐（如concat(cast(rand(42)*5 as int),'_',key)）打散，配合hive.optimize.skewjoin等参数优化。
窗口函数导致reduce卡在99%怎么办
直接原因是某个分区键（partition by字段）的数据量远超其他分区，比如用户ID为'0'或NULL的记录占全表80%，这些数据全被hash到同一个reducer。这不是语法错误，而是执行阶段的资源分配失衡——你看到的“卡住”，其实是单个reducer在处理几亿行，而其他reducer早已空闲。
用distribute by打散倾斜key的实操要点
不能只靠partition by，必须配合distribute by控制shuffle前的数据分发逻辑。核心思路是：对倾斜key加盐，让相同原始key分散到不同reducer；再在reduce后二次聚合还原。
- 先识别倾斜key：跑
SELECT key, COUNT(*) FROM t GROUP BY key ORDER BY COUNT(*) DESC LIMIT 10，看是否某几个key占比异常高 - 对倾斜key加随机前缀：
CONCAT(CAST(RAND() * 10 AS INT), '_', key)，注意别用RAND()裸调用（每次计算值不同），要用RAND(42)固定种子保证同一行多次调用结果一致 - 用新key做
distribute by，但保留原key用于最终partition by：SELECT key, ROW_NUMBER() OVER (PARTITION BY key ORDER BY ts) AS rn FROM ( SELECT key, ts, -- 加盐后重分布 DISTRIBUTE BY CONCAT(CAST(RAND(42) * 5 AS INT), '_', key) FROM t WHERE key IS NOT NULL ) s - 如果倾斜key有明确业务含义（如
'unknown'、'-'），优先过滤或单独映射成多个虚拟值，比纯随机更可控
ROW_NUMBER()替代方案：为什么rank()和dense_rank()更易倾斜
ROW_NUMBER()本身不加剧倾斜，但它的典型使用场景（如取每个用户的最新记录）往往绑定高基数且分布不均的user_id。真正危险的是rank()和dense_rank()——它们必须等待整个分区数据收齐才能排序赋值，内存压力更大，一旦某分区超大，容易OOM或触发spill到磁盘，拖慢整体进度。
- 能用
ROW_NUMBER()就不用rank()，除非业务明确要求并列排名 - 如果必须用
rank()且已知倾斜，先按user_id采样统计频次：SELECT user_id, COUNT(*) FROM t TABLESAMPLE(BUCKET 1 OUT OF 10 ON user_id)，快速定位TOP倾斜用户 - 对TOP倾斜用户单独走子查询+
LIMIT，和其他用户union all合并，避免全局排序
配置层面必须开的三个开关
光改SQL不够，Hive默认配置会放大窗口函数的倾斜效应。以下三个参数不设，加盐也白搭：
-
set hive.groupby.mapaggr=true;：开启map端预聚合，减少shuffle数据量（对count()类窗口虽无效，但能缓解上游压力） -
set hive.optimize.skewjoin=true;：即使没显式join，某些窗口函数底层会被转成join-like操作，此开关能自动拆分倾斜key -
set hive.exec.reducers.bytes.per.reducer=256000000;：把单reducer处理上限从默认1GB降到256MB，强制增加reducer数量，分散压力（注意别设太小，否则reducer过多反拖慢）
最常被忽略的是hive.optimize.skewjoin——很多人以为它只作用于JOIN，其实Hive 3.x+中窗口函数的PARTITION BY也会受其影响，尤其当统计信息存在且hive.stats.autogather=true时效果更明显。
