OVER窗口函数本身不导致数据倾斜，但PARTITION BY字段分布不均（如大量null或固定值）会引发单task负载过高；ORDER BY配合未限定范围加剧排序开销；rank类函数在排序键重复时加重内存压力；根本解法是优化分区键质量或重分区。
OVER 窗口函数本身不直接导致数据倾斜，但当窗口定义依赖的分区键（PARTITION BY）存在严重数据分布不均时，就会触发倾斜。本质是：Spark 必须把所有属于同一 PARTITION BY 值的行拉到同一个 task 中排序、累积或计算，若某个分区键值（比如 user_id = 0 或 region = 'unknown'）占了全量数据的 30% 以上，那个 task 就会卡死。
PARTITION BY 字段存在大量重复值
- 常见错误现象：任务卡在 99%，UI 显示某几个 task 的 Shuffle Read Size 是其他 task 的百倍，Executor 内存持续上涨甚至 OOM。
- 典型场景：
- 日志表中
app_version为空或固定为'1.0.0'，导致 85% 的记录落到同一个 partition - 用户表里
country_code大量为null或'CN'，而其他值分散 - 活动埋点中
event_type默认填充为'default'，实际占比超 40%
- 日志表中
- 解决思路不是禁用
OVER，而是先干预分区键的数据质量：- 用
df.filter("partition_col IS NOT NULL AND partition_col != ''")过滤无效值（如果业务允许） - 对高频 key 单独打标，比如
when(col("user_id") === 0, concat(lit("salt_"), rand())).otherwise(col("user_id"))，再PARTITION BY新列 - 如果必须保留 null，可改用
COALESCE(partition_col, concat(lit("null_"), monotonically_increasing_id()))分散 null
- 用
ORDER BY + ROWS BETWEEN 触发全量排序且无法裁剪
- 当窗口定义含
ORDER BY且范围是未限定的（如UNBOUNDED PRECEDING），Spark 会强制对每个 partition 内所有行做全局排序。 - 若该 partition 数据量极大（比如千万级），单 task 排序开销剧增，GC 频繁，CPU 占满。
- 更隐蔽的问题：即使你写了
ROWS BETWEEN 10 PRECEDING AND CURRENT ROW，只要PARTITION BY键本身倾斜，这个“局部窗口”仍得在超大数据块里滚动计算 —— 并不能缓解底层数据分配不均。 - 实操建议：
- 确认是否真需要
ORDER BY：若仅需累加，用SUM(col) OVER (PARTITION BY a ORDER BY b ROWS UNBOUNDED PRECEDING)可被优化；但若只是ROW_NUMBER() OVER (PARTITION BY a ORDER BY b)，且 b 无区分度，排序毫无意义 - 避免在倾斜键上叠加高成本函数：比如
PARTITION BY hash(user_id) % 100不解决根本问题，反而增加计算负担 - 必要时拆解：先用
repartition(200, "partition_col")强制重分区，再执行窗口逻辑（注意这会引入一次 shuffle，但比原生倾斜更可控）
- 确认是否真需要
使用 rank() / dense_rank() 时遇到重复排序键
-
rank()和dense_rank()在遇到大量相同ORDER BY值时，必须对这些“并列行”做额外协调（比如统一分配相同 rank），Spark 会把所有并列行保留在内存中等待后续判断。 - 如果
ORDER BY timestamp精度只到秒，且某秒内有 50 万条日志，这一秒的所有记录就会被锁在一个 task 里排队处理。 - 应对方式不是换函数，而是降低排序键冲突概率：
- 提升时间精度：
cast(unix_millis(event_time) as bigint)替代to_date(event_time) - 混入唯一因子：
ORDER BY event_time, id（确保id在该时间点内唯一） - 若业务允许近似结果，改用
approx_count_distinct或采样后计算，绕过精确排名
- 提升时间精度：
真正难处理的，是那些既不能过滤、又无法加盐、还必须保证语义正确的倾斜场景 —— 比如实时风控中必须按 ip_address 统计最近 1 小时请求次数，而某个 CDN 节点 IP 每分钟产生 200 万请求。这时候 OVER 不是问题源头，业务数据本身的集中性才是。
