ROW_NUMBER()在Hive中易因key热点导致OOM或卡死，因其按PARTITION BY字段shuffle且不支持动态reducer内存调整；需用pmod(hash(user_id),N)打散分组并两阶段排序解决。
为什么 ROW_NUMBER() 在 Hive 里容易因 key 热点导致 OOM 或卡死
窗口函数如 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts) 在 Hive 中默认按 PARTITION BY 字段做 shuffle，如果某个 user_id 占比极高（比如 10% 以上），对应 reducer 就会收到远超平均的数据量。Hive 的 MapReduce 或 Tez 引擎不支持动态调整 reducer 内存，结果就是该 task 内存溢出、重试失败，或拖慢整个作业。
这不是语法问题，是执行计划层面的物理分布缺陷——Hive 不像 Flink 或 Spark SQL 那样自动做局部聚合+两阶段排序。
- 典型错误现象：
java.lang.OutOfMemoryError: Java heap space出现在 reducer 日志里；或 task 运行时间远超其他同批 task（比如 2h vs 2min） - 确认方式：查
EXPLAIN EXTENDED输出，看Windowing阶段的Partition By是否直接命中高基数低分布度字段 - 不能靠调大
hive.tez.container.size治本——只是把 OOM 推迟，且浪费集群资源
用随机前缀打散 PARTITION BY 的具体写法
核心思路：把原来单一的 user_id 拆成 (user_id, rand_prefix) 两级分组，让热点 key 的数据分散到多个 reducer；再在 reduce 后补一层全局排序/去重逻辑。
注意不是简单加 RAND()，而是用确定性哈希确保同一 user_id 的所有记录被分配到固定几个 bucket，避免后续无法合并。
- 第一阶段：加随机前缀打散
SELECT
user_id,
ts,
-- 打散为 10 个子分组（可根据数据倾斜程度调大，如 50/100）
pmod(hash(user_id), 10) AS prefix,
ROW_NUMBER() OVER (
PARTITION BY user_id, pmod(hash(user_id), 10)
ORDER BY ts
) AS rn_local
FROM events
- 第二阶段：按
user_id重新聚合，取每个user_id下最小的rn_local作为全局序号（适用于取 topN 场景）；或用SUM(rn_local)累加模拟全局序（需保证排序键唯一）
若需严格全局序（如分页），必须补全排序逻辑：
SELECT user_id, ts,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts, prefix, rn_local) AS rn_global
FROM (
SELECT user_id, ts, pmod(hash(user_id), 10) AS prefix,
ROW_NUMBER() OVER (
PARTITION BY user_id, pmod(hash(user_id), 10)
ORDER BY ts
) AS rn_local
FROM events
) t
pmod(hash(x), N) 比 rand() 更可靠的原因
RAND() 每行生成新值，会导致同一 user_id 的多条记录被分到不同 reducer，后续无法正确排序或去重；而 hash(user_id) 是确定性函数，pmod(..., N) 能稳定将每个 user_id 映射到 [0, N-1] 中某一个 bucket，既打散又可追溯。
-
hash()在 Hive 中对 string/int 均有效，返回 long；pmod(a,b)是正余数函数（比%更安全，避免负数） - N 取值建议：先用
SELECT user_id, COUNT(*) c FROM events GROUP BY user_id ORDER BY c DESC LIMIT 10看头部热点占比，若最大 key 占比 20%，N ≥ 5；若占 5%，N=2 即可 - 别用
CAST(RAND()*10 AS INT)—— 它破坏一致性，第二遍跑结果可能不一致，且无法 debug
打散后性能与结果正确性的权衡点
加前缀本质是用额外 shuffle 和计算换稳定性，但代价明确：
- Shuffle 数据量翻 N 倍（每条记录复制 N 份？不，是每条记录只进一个 bucket，但总 bucket 数变多 → reducer 总数上升，单个 reducer 数据下降）
- 两层窗口嵌套增加 CPU 开销，尤其当
ORDER BY字段非索引列时，排序成本上升 - 结果仍正确：因为
prefix是user_id的函数，最终ROW_NUMBER()的PARTITION BY user_id逻辑没变，只是中间分治了 - 真正容易漏的是：没检查原始数据中
user_id是否含 NULL ——hash(NULL)返回 0，所有 NULL 会挤进同一个 bucket，需提前WHERE user_id IS NOT NULL或给 NULL 单独打标
最常被跳过的一步：上线前没用倾斜样本验证 prefix 分布。跑一次 SELECT prefix, COUNT(*) FROM (...) GROUP BY prefix，确认各 bucket 计数方差小于 3 倍，否则说明 hash 不够散或 N 太小。
