多PARTITION BY易拖慢执行计划是因为会触发多次Shuffle并增加Stage；应确保后一个分区字段是前一个的超集且同层书写以复用分区，或用CTE显式分阶段控制。
为什么多 PARTITION BY 容易拖慢执行计划
多个 PARTITION BY（比如嵌套窗口函数中连续用两次）会强制 Hive 拆出额外 Stage，尤其是当它们的分区字段不一致、或与排序字段不重合时。每个独立的 PARTITION BY 都可能触发一次 Shuffle —— 数据要重新按新键哈希分发、排序、再聚合。实际作业里常看到 Stage-1 → Stage-2 → Stage-3 连续 shuffle，中间结果全落盘，I/O 和网络开销翻倍。
如何合并或复用已有分区逻辑
核心思路是：让后一个窗口复用前一个窗口已分好组的数据，避免二次 shuffle。这要求两个条件同时满足：
- 后一个
PARTITION BY字段必须是前一个的**超集**（例如先PARTITION BY dt, region，后PARTITION BY dt可复用；反过来不行） - 两个窗口的
ORDER BY字段需兼容（如都按ts升序，或后一个不排序） - 不能跨 Stage 引用——所有窗口必须写在同一层 SELECT，不能包在子查询里
反例：SELECT ..., ROW_NUMBER() OVER (PARTITION BY dt ORDER BY ts) rn FROM (SELECT ..., SUM(x) OVER (PARTITION BY region) s FROM t) t1 —— 子查询打断了物理数据分布，Hive 无法复用分区。
用 CTE 或临时表显式控制 Stage 边界
当业务逻辑确实需要不同粒度的分区（比如先按用户算累计值，再按天归总），硬塞进一个窗口反而让优化器放弃合并。这时更稳妥的做法是主动拆解，并用 CTE 明确阶段边界：
WITH user_daily AS (
SELECT user_id, dt, SUM(amount) daily_amt
FROM sales
GROUP BY user_id, dt
),
user_cum AS (
SELECT *,
SUM(daily_amt) OVER (PARTITION BY user_id ORDER BY dt) cum_amt
FROM user_daily
)
SELECT *,
AVG(cum_amt) OVER (PARTITION BY dt) avg_cum_by_day
FROM user_cum;
这样写虽然多一个 Stage，但每个 Stage 内部的 PARTITION BY 是单一且可控的；比强行揉在一起导致三重 shuffle 更可靠。注意：CTE 不是视图，Hive 会物化中间结果（除非开启 hive.optimize.cte.materialize=false，但慎用）。
检查执行计划确认是否真的合并了
运行 EXPLAIN FORMATTED 后重点看两处：
- Stage 列表是否比预期少（比如本该 3 个 Stage，实际只有 2 个）
- 每个 Stage 的 Operator 中是否出现多个
WindowFunction节点共存于同一个 Map 或 Reduce Task（说明复用了分区上下文） - 有无
Shuffle类型为EXPRESSION的边——这是谓词下推或分区复用的信号；若全是HASH，大概率没复用成功
真正难调的不是语法写法，而是数据分布本身：如果 PARTITION BY 字段存在严重倾斜（比如 90% 的记录 dt='20260930'），即使合并了 Stage，单个 Reducer 仍会卡死。这时候得先处理倾斜，再谈多分区优化。
