窗口函数高并发内存暴涨主因是Spark默认用ExternalAppendOnlyUnsafeRowArray缓存窗口数据，需协同调整spark.sql.windowExec.buffer.in.memory.threshold和spill.threshold，并隔离资源池、优化PARTITION BY字段。
窗口函数在高并发下内存暴涨的直接原因
根本不是 SQL 写得“错”，而是 Spark 默认用 ExternalAppendOnlyUnsafeRowArray 在内存里缓存每个窗口的数据——只要一个分区里窗口数据行数超过 spark.sql.windowExec.buffer.in.memory.threshold（默认 4096），就触发落盘；但若并发高、窗口大、分区多，大量缓冲区同时驻留内存，GC 跟不上，OOM 就来了。
调参必须改这两个配置项
只调其中一个等于白干，必须协同调整：
-
spark.sql.windowExec.buffer.in.memory.threshold：设太小（如 512）→ 频繁 spill → 磁盘 IO 暴增；设太大（如 16384）→ 单个窗口吃光 executor 堆内存 -
spark.sql.windowExec.buffer.spill.threshold：它控制 spill 后的 UnsafeExternalSorter 再溢出阈值，默认是Integer.MAX_VALUE，意味着“不主动 spill”。但实际中建议设为 20000～50000，避免排序器在内存里攒太多数据
示例（提交作业时加）：
spark-submit \ --conf spark.sql.windowExec.buffer.in.memory.threshold=8192 \ --conf spark.sql.windowExec.buffer.spill.threshold=30000 \ ...
执行资源池必须绑定窗口密集型任务
单纯调参治标，不隔离任务会互相挤占内存。Spark 3.0+ 支持通过 resourceProfile 或 YARN/ Kubernetes 的队列划分，把窗口计算任务固定到专用资源池：
- YARN 场景：确保窗口作业提交到独立队列（如
window-queue），并配yarn.scheduler.capacity.root.window-queue.maximum-capacity=40 - Spark UI 中检查是否生效：看
Stage Details → Resource Profile ID是否非 default，且对应 executor 分配的 cores/memory 符合预期 - 关键点：窗口任务不能和 shuffle-heavy 任务（如大 join）混跑，否则 spill 文件争抢磁盘带宽，延迟翻倍
真正容易被忽略的点
窗口函数的内存压力往往藏在 PARTITION BY 字段的选择里——如果按高频低基数字段（如 status 只有 3 个值）分区，所有数据挤进极少数 partition，单个 partition 窗口数据量爆炸；换成按 user_id 或 order_id 这类高基数字段，压力才真正摊开。这个比调参影响更大，但日志里完全不报错，只能靠 explain extended 看 partition 数量分布。
