窗口函数OOM主因是分区逻辑不合理而非数据量，应避免低基数字段分区，改用加盐或组合分区，并同步调整buffer.in.memory.threshold（8192）和spill.threshold（30000），配合资源隔离与explain验证。

窗口函数OOM的真正源头不是数据量，而是分区逻辑

Spark SQL里窗口函数触发OOM，90%的情况跟输入数据总量关系不大，而是PARTITION BY字段选得不合理。比如按status（只有3个取值）分区，所有数据挤进3个partition，每个partition里窗口要缓存几千甚至上万行——ExternalAppendOnlyUnsafeRowArray直接吃光executor堆内存。

真正有效的缓解方式是把大分区打散：

• 加盐：用concat(col("user_id"), lit("_"), (rand() * 10).cast("int"))生成高基数伪键，强制分散
• 组合分区：把时间维度带进来，比如partitionBy("user_id", "date_trunc('day', ts)")，天然限流且业务语义清晰
• 绝对避免只按低基数字段（如country、category）分区，哪怕SQL看起来“更简洁”

必须协同调整的两个核心参数

spark.sql.windowExec.buffer.in.memory.threshold和spark.sql.windowExec.buffer.spill.threshold必须一起调，只改一个等于白干。

• spark.sql.windowExec.buffer.in.memory.threshold设为8192：比默认4096略高，避免过早spill拖慢IO；但绝不设到16384以上，否则单窗口吃掉几GB内存
• spark.sql.windowExec.buffer.spill.threshold设为30000：防止UnsafeExternalSorter在内存里攒太多数据，又不至于频繁落盘
• 提交作业时显式带上：spark-submit --conf spark.sql.windowExec.buffer.in.memory.threshold=8192 --conf spark.sql.windowExec.buffer.spill.threshold=30000

资源隔离比调参更重要

窗口密集型任务不能和shuffle-heavy任务（比如大join或repartition）混跑。YARN场景下必须绑定独立队列：

• 确保作业提交到window-queue这类专用队列，配yarn.scheduler.capacity.root.window-queue.maximum-capacity=40
• Spark UI中检查Stage Details → Resource Profile ID是否非default，且分配的cores/memory符合预期
• 混跑会导致spill文件争抢磁盘带宽，延迟翻倍，且OOM日志里完全不提示冲突来源

最容易被忽略的验证动作

调完参数、改完SQL，不看explain extended就上线，等于没做优化。重点盯两处：

• Physical Plan里WindowExec节点下的Partitioning信息，确认实际partition数量是否从个位数变成上千
• Spark UI中对应Stage的“Number of Tasks”和“Input Rows per Task”分布是否均匀，有无单task处理行数超均值5倍以上
• 这些信息不会报错，但决定了你的窗口函数到底是在并行计算，还是在单点硬扛