根本原因是Hive将整个分区数据加载至单个Task内存计算窗口函数，导致OOM或性能骤降；应改用DISTRIBUTE BY+SORT BY拆分数据分发与局部排序，避免全局ORDER BY引发单点瓶颈。
为什么 OVER 子句在超大数据集上容易 OOM 或慢得离谱
根本原因不是语法写错了，而是 Hive 默认把整个分区数据拉到单个 reducer（或 task）内存里做窗口计算。比如 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts)，如果某个 user_id 有上千万行，这个 partition 就会卡死一个 task，触发 GC、溢出到磁盘，甚至直接 java.lang.OutOfMemoryError: Java heap space。
必须加 DISTRIBUTE BY + SORT BY 替代 ORDER BY 的场景
Hive 的 OVER 子句中若只写 ORDER BY，它会强制全局排序，等价于走一个大 reduce；而生产中真正需要的往往只是“每个 reducer 内部有序 + 分布均匀”。这时应显式拆开：
-
DISTRIBUTE BY控制数据分发（决定哪些 key 进同一个 reducer），要选高基数列（如user_id），避免倾斜 -
SORT BY只保证单个 reducer 内部有序，不保证全局序，但窗口函数在单 reducer 内已够用 - 绝对不要写
ORDER BY在OVER里，除非你确认 partition key 的最大桶大小可控（比如dt分区且每天数据量稳定
示例写法：
SELECT user_id, ts, ROW_NUMBER() OVER (DISTRIBUTE BY user_id SORT BY ts) AS rn FROM logs WHERE dt = '2024-06-01'
用 MAX/COUNT 等聚合窗口时，优先改写为 GROUP BY + JOIN
像 COUNT(*) OVER (PARTITION BY user_id) 这类无序聚合，本质就是分组计数，Hive 执行引擎无法下推优化，硬扛窗口框架反而更重。直接拆解更稳：
- 先用
GROUP BY算出每个user_id的计数（map-side aggregate 能大幅减量） - 再和原表
JOIN（建议用MAP JOIN，加/*+ MAPJOIN(user_cnt) */hint） - 避免任何
OVER中带COUNT/SUM/MAX且无ORDER BY的写法——这是 Hive 窗口最常被滥用的坑
错误示范：COUNT(1) OVER (PARTITION BY user_id)；正确思路：
SELECT l.*, c.cnt FROM logs l JOIN (SELECT user_id, COUNT(1) AS cnt FROM logs GROUP BY user_id) c ON l.user_id = c.user_id
设置关键参数防止小文件和内存崩塌
即使逻辑改对了，没调参照样翻车。以下三个参数必须检查：
-
hive.optimize.sort.dynamic.partition=true：开启后，DISTRIBUTE BY会自动适配动态分区数量，防止单 reducer 过载 -
hive.map.aggr=true和hive.groupby.mapaggr.checkinterval=100000：在 map 端预聚合，对COUNT/SUM类窗口前的中间数据量影响极大 -
hive.exec.reducers.bytes.per.reducer建议设为256000000（256MB），比默认 1GB 更保守，让 reducer 数量多些、单个轻些，尤其适合窗口计算这种内存敏感型任务
这些参数不写进 SQL 里，得在作业提交前用 SET 配好，漏掉任何一个，都可能让前面所有优化白做。
