窗口函数不解决数据倾斜反而可能加剧，因其在PARTITION BY字段上无shuffle导致单task处理热点key；需通过加盐分组、两阶段聚合等方法拆解倾斜。
窗口函数本身不解决数据倾斜，反而可能加剧它
很多人以为用 ROW_NUMBER() 或 COUNT() OVER 就能绕过 GROUP BY 的倾斜问题，实际恰恰相反：窗口函数会在每个分区内部排序或累积计算，如果某个 PARTITION BY 值（比如某用户 ID）出现几百万次，整个任务就会卡死在那个分区上。
真正起作用的不是窗口函数本身，而是你如何用它“拆解”原本集中在单个 key 上的聚合逻辑。
- 窗口函数必须搭配
PARTITION BY字段使用，而该字段就是潜在的倾斜源 - 如果
PARTITION BY是高基维（如user_id），但分布极不均匀，MAX() OVER (PARTITION BY user_id)会把所有同 user_id 的行拉到一个 task，无法并行 - 相比
GROUP BY，窗口函数少了 shuffle 后的 merge 阶段，意味着中间结果更重、更难容错
用两阶段聚合 + 窗口函数替代单层分组
核心思路是：先把大 key 拆成子组打散，再用窗口函数做局部序号/累计，最后全局合并。适用于需要排名、累计求和、前后行对比等场景。
比如统计每个用户的点击流中，首次点击到下单的时间差——不能直接 MIN(event_time) OVER (PARTITION BY user_id, order_id)，因为 order_id 可能为空，导致全落到 null 分区。
- 第一阶段：对
user_id加盐，比如CONCAT(user_id, '_', FLOOR(RAND() * 10))，然后按新字段分组聚合基础指标（如最早点击时间、是否下单） - 第二阶段：用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY salted_group)给每个用户下的盐值组编号，再取编号 = 1 的记录作为代表 - 注意：盐值数量要足够（通常 10–100），但也不能太多，否则小 key 的 group by 开销反超
COUNT(DISTINCT) 场景下，APPROX_COUNT_DISTINCT 比窗口函数更实用
想用 COUNT(DISTINCT x) OVER (PARTITION BY y)？别试了。这个写法在 Spark SQL 和 Hive 中要么报错，要么触发全量广播，极易 OOM。
真实生产里，90% 的“需要窗口内去重计数”需求，其实可以退化为近似计算，或者改用 COLLECT_SET + SIZE 控制内存上限。
-
APPROX_COUNT_DISTINCT(x, 0.01)支持窗口，误差率可控，性能比精确去重高 5–10 倍 - 如果必须精确，改用
COLLECT_SET(x) OVER (PARTITION BY y ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)，但需确保集合大小有界（比如限定x是枚举值） - 避免在
PARTITION BY字段上存在长尾分布时用COLLECT_SET，一个分区收集几百万个元素会直接拖垮 executor
检查执行计划里有没有 Exchange 被窗口函数绕过
Spark UI 中看到某个 stage 没有 Exchange 节点，但耗时奇高，大概率是窗口函数没走 shuffle，全压在一个 task 上了。这是最隐蔽也最容易被忽略的倾斜信号。
- 用
EXPLAIN FORMATTED查看物理计划，确认Window算子前是否有Exchange - 如果没有，说明 partition 字段未触发重分区，此时加
DISTRIBUTE BY强制 shuffle（如DISTRIBUTE BY user_id, RAND()） - Hive 用户注意：
hive.optimize.skewjoin对窗口函数无效，别指望它自动拆分大 key
实际跑通的关键，往往不在函数怎么写，而在你有没有看到那个没出现在代码里的 Exchange 节点。
