OVER(PARTITION BY)易OOM因单个分区数据全加载至同一Task内存；可通过DISTRIBUTE BY+SORT BY拆分、MAPJOIN预过滤、采样、TopN剪枝及hive.groupby.skewindata=true防倾斜优化。
为什么OVER(PARTITION BY)容易OOM
因为每个PARTITION BY子句会把对应分区的所有行数据拉到同一个Task（通常是Reduce Task）内存中做窗口计算。如果某个分区数据量极大（比如某天的订单量占全表70%），这个Task就会因内存不足而失败，报java.lang.OutOfMemoryError: Java heap space或GC overhead limit exceeded。
用DISTRIBUTE BY + SORT BY替代全局PARTITION BY
当业务允许“分区内有序、不强求全局序”时，可用DISTRIBUTE BY + SORT BY拆分压力，避免单个Reducer扛全量分区数据：
-
DISTRIBUTE BY按分区字段哈希分发，确保同一分区键的数据落到同一Reducer（但不保证顺序） -
SORT BY在每个Reducer内局部排序，配合OVER(ORDER BY ...)就能完成窗口函数计算 - 比
ORDER BY轻量得多，不会触发全局排序和单点瓶颈
示例：统计每日用户访问序号，不依赖跨天全局序
SELECT user_id, dt, url, ROW_NUMBER() OVER (PARTITION BY dt, user_id ORDER BY ts) AS visit_seq FROM raw_log DISTRIBUTE BY dt, user_id SORT BY dt, user_id, ts;
加MAPJOIN预过滤或采样再开窗
对大表先做轻量级预处理，大幅缩小开窗输入规模：
- 用
/*+ MAPJOIN(small_dim) */提前关联维度表，过滤掉无效主键（如已注销用户） - 对超大事实表用
TABLESAMPLE(BUCKET x OUT OF y ON rand())抽样验证逻辑，避免调试时全量跑 - 若只需TopN结果，先
GROUP BY + ORDER BY + LIMIT聚合出候选集，再对小结果集开窗
例如：只统计每类商品销量Top10用户的累计购买额
WITH top10_users AS ( SELECT item_type, user_id FROM dwd_sales GROUP BY item_type, user_id ORDER BY SUM(amount) DESC LIMIT 1000 -- 控制后续开窗数据量 ) SELECT s.*, SUM(amount) OVER (PARTITION BY item_type, user_id ORDER BY dt) AS cum_amount FROM dwd_sales s JOIN /*+ MAPJOIN(top10_users) */ top10_users t ON s.item_type = t.item_type AND s.user_id = t.user_id;
设置hive.groupby.skewindata=true防倾斜
虽然这是为GROUP BY设计的参数，但它对OVER(PARTITION BY)同样生效——当检测到某分区数据远超均值时，Hive会自动启用两阶段聚合策略：第一阶段加随机前缀打散热点分区，第二阶段合并结果。必须配合以下设置才有效：
set hive.groupby.skewindata=true;-
set hive.map.aggr=true;（开启Map端预聚合） -
set hive.groupby.mapaggr.checkinterval=100000;（控制检查频率）
注意：该机制仅缓解倾斜，不能替代合理分区键设计。如果PARTITION BY字段本身存在严重数据倾斜（如99%记录user_id='unknown'），优先清洗或改用WHERE user_id != 'unknown'过滤。
真正卡住性能的往往不是语法写法，而是没意识到PARTITION BY字段的分布质量。上线前务必用SELECT col, COUNT(*) FROM tbl GROUP BY col ORDER BY COUNT(*) DESC LIMIT 5查下热点值——比调任何参数都管用。
