窗口函数导致reduce卡99%的根本原因是数据倾斜，需通过partition by加随机盐、改用distribute by+sort by、避免冗余order by、合理设置windowing_buffer_size及验证多reducer并行执行来解决。
窗口函数导致Reduce阶段卡在99%怎么办
根本原因是默认的 hive.groupby.skewindata=false 且窗口函数未指定 DISTRIBUTE BY，导致数据倾斜——所有分区键相同的数据被发往同一个Reducer。比如用 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts) 时，若某 user_id 占比超 70%，该 Reducer 就会拖慢整个作业。
- 强制打散倾斜键：在
PARTITION BY后加随机盐，例如PARTITION BY user_id, CAST(RAND() * 10 AS INT)，再外层过滤掉盐值为 0 的冗余行（需业务允许容忍少量重复逻辑） - 改用
DISTRIBUTE BY user_id+SORT BY user_id, ts预排序，再在 Reduce 端用自定义 UDAF 或分段处理（适合高并发小窗口场景） - 确认是否真需要全局排序：能用
RANK()或DENSE_RANK()就别硬上ROW_NUMBER()，前者在 Hive 3.1+ 支持更优的并行化策略
Hive 3.x 中 windowing_buffer_size 设置多少才不 OOM
windowing_buffer_size 控制每个 Mapper/Reducer 缓存窗口数据的内存上限（单位：行数），默认是 100000。设太小会导致频繁 spill 到磁盘；设太大则容易触发 java.lang.OutOfMemoryError: Java heap space，尤其当窗口涉及多列聚合（如 AVG(col1) OVER (PARTITION BY a ORDER BY b ROWS BETWEEN 10 PRECEDING AND CURRENT ROW)）。
- 先用
EXPLAIN EXTENDED查看执行计划中WindowingTableFunction节点的估算输入行数，把windowing_buffer_size设为该值的 1.2–1.5 倍 - 避免在大宽表上直接开窗口：先用
SELECT ... FROM t WHERE ...子查询过滤出必要字段和分区，再套窗口逻辑 - HiveServer2 中通过
SET hive.windowing.buffer.size=200000;设置，注意该参数在 Tez 引擎下无效，需改用tez.grouping.split-count
ORDER BY 在窗口子句里为什么让性能暴跌
窗口函数里的 ORDER BY 会强制全量排序，而 Hive 默认使用 MapReduce 时，排序必须走 Reduce 阶段——即使你只想要前 3 行，也会把整个分区数据 shuffle 过去。对比 ORDER BY 和 SORT BY：SORT BY 是每个 Reducer 内部排序，不保证全局有序，但能跳过 shuffle。
- 若业务只要「每个分区内的 TopN」，用
ROW_NUMBER() OVER (PARTITION BY x SORT BY y DESC)替代ORDER BY，配合DISTRIBUTE BY x实现 map-side 局部 top-k - 慎用
RANGE BETWEEN：它依赖精确值比较，Hive 会加载整个窗口范围的数据进内存；ROWS BETWEEN只按行号截断，更轻量 - Hive 4.0+ 支持
WINDOW命名复用，避免重复写PARTITION BY + ORDER BY，减少解析与调度开销
如何验证窗口函数是否真的并行执行了
不能只看任务数量，得看实际数据是否被分散到多个 Reducer 处理。最直接的方式是检查 Counter 中 REDUCE_INPUT_GROUPS 是否均匀分布，或查日志里各 Reduce task 的 input records 差异是否超过 3 倍。
- 在 SQL 前加
SET hive.exec.counters.pull.interval=1000;，跑完后用hadoop job -status <jobid></jobid>查各 Reduce 的输入记录数 - 用
EXPLAIN FORMATTED看物理计划：若出现WindowingTableFunction下挂多个Map Operator Tree，说明已分片；若只有单个 Reduce 节点承接全部窗口逻辑，就是串行瓶颈 - 对非确定性窗口（如含
UDF或COLLECT_LIST），Hive 可能自动退化为单 Reducer，此时需显式加DISTRIBUTE BY rand()强制分发
窗口函数调优的核心不是堆参数，而是看清数据分布、窗口语义和引擎限制三者的咬合点。最容易被忽略的是：同一 SQL 中混用多个窗口函数时，Hive 默认不会复用已计算的分区结果——哪怕 PARTITION BY 完全一致，也会各自 shuffle 一遍。
