必须指定PARTITION BY，否则Spark将全表数据拉入单Task导致Shuffle爆表；高基数均匀列（如user_id）适合作为分区键，避免低基数列引发数据倾斜；ORDER BY仅保留业务强依赖字段，减少排序开销；显式声明ROWS BETWEEN避免默认全分区扫描；NULL分区键需提前过滤或加盐处理。
窗口函数没加 PARTITION BY 就执行？Shuffle 量直接爆表
不写 PARTITION BY，Spark 会把整张表数据拉到一个 Task 里排序计算，10 亿行就 shuffle 10 亿行。这不是慢，是根本跑不动——Shuffle Spill 频发、Executor OOM、任务卡在 Stage 0。
必须明确：窗口函数的计算单元是「分区」，不是全表。没指定分区键，就等于告诉 Spark：“所有数据归你管”。
- 高基数列（如
user_id）适合做分区键，但要确认分布是否均匀；若存在大量 NULL 或少数超大user_id，反而引发倾斜 - 避免用低基数列（如
status只有 3 个值）分区，会导致极少数 Task 承担绝大部分数据 - 组合分区更稳：
PARTITION BY user_id, date_trunc('day', event_time)比单列user_id更能摊薄单日热点用户压力
ORDER BY 字段越多，排序开销越大，别堆无关字段
窗口里的 ORDER BY 不是“为了好看”，而是触发全分区排序的开关。每多一个字段，排序复杂度就上升一级——尤其当字段类型是字符串或嵌套结构时。
比如业务只要按时间排访问序，却写了 ORDER BY event_time, page_url, device_type，Spark 就得对每个 user_id 分区内所有页面 URL 做字典序比对，IO 和 CPU 成倍涨。
- 只保留业务强依赖的排序字段，删掉
page_url这类高 Cardinality 且非必需字段 - 对字符串字段排序前先检查是否已索引或是否可转为整型编码（如
device_type映射为1/2/3） - 如果只是取最新一条，用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time DESC) = 1，比LAST_VALUE+ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING更轻量
别让默认窗口范围（UNBOUNDED PRECEDING）拖垮移动计算
没写 ROWS BETWEEN，Spark 默认窗口是“从分区第一行到当前行”。算移动平均、累计求和时没问题，但算“最近 3 条行为”还这么写，就是拿全量数据陪跑。
例如：SUM(amount) OVER (PARTITION BY user_id ORDER BY event_time) 会为每一行重扫该用户全部历史记录；而 SUM(amount) OVER (PARTITION BY user_id ORDER BY event_time ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) 只读 3 行。
- 明确业务窗口语义：是“截止当前”还是“固定滑动”？前者用默认范围，后者必须显式写
ROWS BETWEEN -
RANGE BETWEEN在时间字段上易出错（相同时间戳会被合并），优先用ROWS BETWEEN - 注意
CURRENT ROW是包含当前行的，别漏写导致结果少一行
分区键本身含 NULL？先清理或填充，否则自动聚到一个 Task
Spark 对 PARTITION BY 中的 NULL 值不做哈希散列，而是统一路由到同一个 Executor。哪怕只有 0.1% 的 user_id IS NULL，这部分数据也会在单个 Task 上堆积，成为事实上的倾斜点。
现象是：Stage 中某个 Task 的 Shuffle Read Size 是其他 Task 的几十倍，UI 上一眼可见“长尾”。
- 提前过滤：
WHERE user_id IS NOT NULL放在窗口计算前，而不是 after - 业务允许时用
COALESCE(user_id, concat('null_', rand()))加盐，避免 NULL 聚堆 - 若 NULL 有业务含义（如匿名用户），单独抽出来走另一条逻辑路径，别硬塞进主窗口流
真正难的不是写出语法正确的窗口函数，而是想清楚：这一行输出，到底需要拉进来多少行数据参与计算。每一个 PARTITION BY、每一个 ORDER BY、每一个未声明的 ROWS 范围，都在悄悄决定 Shuffle 的规模。
