直接用 order by + limit 做 top n 在 hive 中易出错，因 order by 触发全局排序致 oom，且 limit 不支持分组逻辑；应使用 row_number() 配合 partition by 实现分组内排序取前 n。
为什么直接用 ORDER BY + LIMIT 做 Top N 在 Hive 里容易出错
因为 Hive 的 ORDER BY 会触发全局排序，所有数据被拉到一个 reducer 上，数据量稍大就 OOM 或卡死；而 LIMIT 又不保证跨分区逻辑——比如你想查每个部门工资最高的 3 个人，ORDER BY salary DESC LIMIT 3 只会返回全表前 3 条，根本不是按部门分组的 Top 3。
用 ROW_NUMBER() 配合 PARTITION BY 实现真正分组 Top N
这是最常用也最稳妥的方式：先按业务维度（如 dept_id）分组，再在组内按目标字段（如 salary）排序编号，最后过滤编号 ≤ N 的行。
关键点：
-
ROW_NUMBER()必须搭配OVER (PARTITION BY ... ORDER BY ...)，缺一不可 - 排序字段要明确写
DESC，否则默认升序，取的是“最低”的 N 条 - 不能在同一个查询中对窗口函数结果直接
WHERE rn ，必须嵌套一层子查询或 CTE
SELECT dept_id, emp_name, salary
FROM (
SELECT dept_id, emp_name, salary,
ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn
FROM employees
) t
WHERE rn
<h3>RANK() 和 DENSE_RANK() 的区别在哪？什么时候该换用它们</h3>
<p>当存在并列值（比如两人同为最高薪）且你希望保留名额时，<code>ROW_NUMBER()</code> 会强行挤掉后续名次，而 <code>RANK()</code> 会跳号，<code>DENSE_RANK()</code> 则连续编号。</p>
<p>举例：某部门四人工资为 [10k, 9k, 9k, 8k]，取 Top 3：</p>
-
ROW_NUMBER()→ 返回 3 行（10k, 9k, 9k），但两个 9k 分别是第 2 和第 3 名 -
RANK()→ 返回 3 行（10k, 9k, 9k），两个 9k 都是第 2 名，第 4 名直接跳到第 4 名 -
DENSE_RANK()→ 返回 4 行（10k, 9k, 9k, 8k），因为两个 9k 占第 2 名后，8k 是第 3 名，没跳号
所以如果你要“取分数前 3 名的所有人”，且允许并列，就该用 RANK()；如果要求严格限制最多返回 3 行，才用 ROW_NUMBER()。
Hive 版本和执行引擎对窗口函数的影响
Hive 0.13+ 才完整支持标准窗口函数语法，旧版本（如 0.11）可能报 FAILED: ParseException line x:xx missing EOF at 'OVER'；另外 Tez 引擎比 MapReduce 更高效地处理窗口函数，尤其在大表分组场景下，建议确认 hive.execution.engine=tez 已启用。
还有个隐形坑：ORDER BY 子句里不能引用别名（如写 ORDER BY sal DESC 而不是原始列名 salary），否则 Hive 会报 Invalid column reference，这个错误信息不直观，容易卡住。
复杂点在于：窗口函数本身不触发 shuffle，但 PARTITION BY 字段若基数极高（比如用户 ID），会导致大量小分区，reducer 启动开销反而上升；这时得权衡是否改用 DISTRIBUTE BY + SORT BY 预处理，再配合 row_number() 局部计算。
