为什么在Spark SQL中对大表使用DENSE_RANK()容易OOM？-SQL-PHP中文网

DENSE_RANK()在大表上比ROW_NUMBER()更易OOM，因其典型使用场景需全量排序+高基数分区，触发UnsafeExternalSorter为每个分区单独缓存并排序数据，内存占用达“分区数×每分区行数”量级；而ROW_NUMBER()常配合LIMIT提前过滤，且Tungsten支持流式序号分配。

为什么在spark sql中对大表使用dense_rank()容易oom？

为什么DENSE_RANK()在大表上比ROW_NUMBER()更容易OOM

DENSE_RANK()本身不比ROW_NUMBER()多占内存，但它的典型使用模式会显著放大窗口执行器的内存压力。关键在于：DENSE_RANK()几乎总是和ORDER BY + PARTITION BY一起用，而ORDER BY触发排序缓冲区（UnsafeExternalSorter），PARTITION BY又让Spark为每个分区单独维护一个排序缓冲区——这两个操作叠加后，内存占用呈“分区数 × 排序行数”级增长。

相比之下，ROW_NUMBER()虽然也依赖排序，但业务上常用于去重或取Top N，往往配合LIMIT或WHERE提前过滤；而DENSE_RANK()常出现在全量排名、分位统计等场景，数据根本没被裁剪。

DENSE_RANK()必须等整个窗口数据全部读入、完成排序后才能输出首行结果；ROW_NUMBER()在Tungsten优化下可流式分配序号（只要知道当前排序位置）
如果PARTITION BY字段基数低（比如只有5个部门），所有数据挤进5个分区，每个分区要缓存几百万行再排序 → 单个executor内存瞬间打满
Spark默认不把DENSE_RANK()识别为“可下推聚合”，无法像SUM()那样边读边算，只能全量缓存

spark.sql.windowExec.buffer.in.memory.threshold设太小反而更卡

这个参数控制窗口排序前在内存里缓存多少行才开始落盘。设成512看似“省内存”，实则让每个分区频繁spill到磁盘，产生大量小文件和随机IO，CPU和磁盘都忙于搬运，整体任务延迟飙升，还可能因磁盘写满失败。

真正有效的阈值取决于你的分区大小分布。例如，若95%的分区数据量在1万～3万行之间，设spark.sql.windowExec.buffer.in.memory.threshold=16384能覆盖大部分分区免spill，同时避免单个分区吃光executor堆内存。

必须同步调spark.sql.windowExec.buffer.spill.threshold，否则排序器在spill后仍攒大量数据在内存，照样OOM
建议值范围：in.memory.threshold设为预期最大分区行数的0.7～0.9倍；spill.threshold设为该值的2～3倍
验证方式：看Spark UI中Stage的Shuffle Write Size是否突增——突增说明spill太频繁

PARTITION BY字段选错，调参完全白搭

日志里从不报错，但EXPLAIN EXTENDED会暴露真相：如果PARTITION BY status（只有3个值），你会发现物理执行计划里只有3个task处理窗口计算，每个task扛着几千万行——这就是OOM根源。换成PARTITION BY user_id（亿级基数），压力立刻摊到上千个task上。

别只看业务语义是否合理，先跑SELECT COUNT(*) FROM t GROUP BY partition_col ORDER BY 1 DESC LIMIT 5查分布
如果top 3分区占总数据量超60%，这个字段基本不能直接用作PARTITION BY
临时补救：加盐（salting）——比如PARTITION BY status, (hash(user_id) % 10)，把大分区人工打散

为什么加LIMIT也不管用

因为DENSE_RANK()是窗口函数，不是普通SELECT字段。外层LIMIT 10在窗口计算完成之后才生效，Spark必须先把所有行的DENSE_RANK()全算出来，再截断——它不会像ORDER BY id LIMIT 10那样下推排序和截断逻辑。

想真正减少计算量，得把LIMIT塞进子查询：SELECT * FROM (SELECT ..., DENSE_RANK() OVER (...) AS rnk FROM big_table WHERE ... LIMIT 10000) t WHERE rnk
或者改用NTILE(100) OVER (...)替代，它能按分位粗筛，再对目标分位细排
MySQL/PostgreSQL里视图套DENSE_RANK()再LIMIT，大概率触发物化（DERIVED），比Spark还狠——全量生成中间结果再截断

实际中最容易被忽略的点，是以为OOM来自“函数太重”，于是去换数据库或降版本；其实90%的情况，只要把PARTITION BY字段从低基数换成高基数，再配合合理的in.memory.threshold，问题就消失了——连代码都不用动。