ROW_NUMBER() 直接用于高基数倾斜字段会加剧倾斜，需结合加盐实现两阶段打散；NULL值需重映射避免单分区瓶颈；取Top1优先用max_by或first_value等更高效函数。
ROW_NUMBER() 本身不解决倾斜，反而可能引爆它
直接在高基数且分布不均的字段（比如 user_id）上写 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time)，Spark 会把所有同 user_id 的行拉到同一个 task，不做 shuffle，也没有 merge 阶段——结果就是那个 task 卡死、OOM 或者拖慢整个 stage。这不是 bug，是窗口函数的设计使然：它依赖本地排序，不拆分热点 key。
真正能用 ROW_NUMBER() 优化倾斜的，是把它嵌入「两阶段打散」流程里，而不是当单点聚合用。
用加盐 + ROW_NUMBER() 实现两阶段打散
核心思路是把原本集中在单个 key 上的百万级记录，先按盐值打散到多个子组，再用 ROW_NUMBER() 在用户维度做局部序号控制，最后合并取代表值。适用于“每个用户只取最早/最新一条”这类场景。
- 第一阶段：对原始 key 加盐，例如
CONCAT(user_id, '_', FLOOR(RAND() * 20))，盐值范围建议 10–50，太少打散不足，太多增加小 key 的 group by 开销 - 第二阶段：按盐值分组聚合基础指标（如
MIN(event_time),MAX(event_time),COUNT(*)），同时保留user_id - 第三阶段：定义新窗口
Window.partitionBy("user_id").orderBy("salted_key")，用ROW_NUMBER().over(window)给每个用户下的盐值组编号，再过滤row_num = 1得到代表组
注意：盐值必须是确定性表达式（不能用 UUID()），否则第二阶段无法关联；RAND() 在 Spark SQL 中每次调用生成不同值，需提前物化为列。
PARTITION BY 字段为空或 null 时的陷阱
如果 PARTITION BY 字段含大量 NULL 值（比如未登录用户的 user_id），所有 NULL 行会被分到同一个分区，极易触发单点瓶颈。这不是数据质量问题，而是 Spark 的语义行为。
- 显式过滤：在窗口前加
WHERE user_id IS NOT NULL，但会丢弃数据 - 重映射
NULL：用COALESCE(user_id, CONCAT("null_", FLOOR(RAND() * 100)))把空值也打散，确保不会全进一个分区 - 慎用
DEFAULT填充：不要填固定字符串如"unknown"，否则又制造新热点
这个细节在日志类宽表中高频出现，但很容易被忽略——UI 上看 stage 进度卡在 99%，查数据发现全是 NULL 分区在扛压。
替代方案比硬刚 ROW_NUMBER() 更高效
不是所有“取 Top N”需求都适合用 ROW_NUMBER()。当目标只是每个分组取 1 条，agg(struct(*), ...) + max_by() 或 first_value()（带 ignore nulls）往往更轻量，不强制排序，也不依赖 ORDER BY 字段的可比较性。
-
MAX_BY(struct(*), event_time)直接返回 event_time 最大那行的完整结构，无须排序开销 -
FIRST_VALUE(col).ignoreNulls()在窗口帧内跳过 null 后取首值，适合补缺场景 - 若只需计数去重，
APPROX_COUNT_DISTINCT(x) OVER (PARTITION BY y)比COLLECT_SET(x) OVER省内存且支持倾斜容忍
真正难处理的，从来不是语法怎么写，而是你有没有在写 OVER (PARTITION BY ...) 前，先用 df.groupBy(...).count().orderBy("count", ascending=False).show(10) 看一眼分布长尾程度。
