PySpark执行df.count()正常但df.show(5)报Java堆内存溢出问题

两种操作的计算逻辑、内存开销模型完全不同，show(5)仅需要返回5条数据，不代表整个计算流程的内存开销比count()小：

• count()的执行逻辑极轻量：每个executor仅需统计当前分片内的记录条数，不需要加载、解析、传输行数据的完整字段内容，Spark优化器还会自动做列裁剪、谓词下推，跳过所有非必要的列读取、shuffle传输步骤，整个过程只在各个分片做数字计数，最后把所有分片的计数值做全局累加即可，单分片内存开销极低，只要计数逻辑能跑通就不会触发OOM。
• show(5)的执行逻辑远没有直觉里那么轻，常见内存溢出原因有三类：
  1. limit算子的实现机制带来的Driver拉取开销：在多数Spark版本中，show(N)会先让每个executor分片都取N条完整行数据，把这些数据全部传输到Driver端，再由Driver从所有分片返回的分片数*N条数据里筛选出前N条做展示。假设你的作业有2000个executor分片，show(5)时总共会有10000条完整行数据拉到Driver的JVM堆里，如果你单条数据包含MB级别的大字段（长文本、二进制、深度嵌套的JSON/数组结构），10000条数据的总大小很容易直接打满Driver堆内存。
  2. 列裁剪失效带来的shuffle开销：如果你的转换链路包含宽依赖（groupBy、join、开窗函数、distinct等），count()触发计算时优化器可以把不需要的列全部裁剪掉，shuffle阶段只需要传输计算行数必需的极小数据量；但show()需要返回完整行的所有字段，shuffle阶段必须拉取、缓存、排序全量字段数据，如果存在数据倾斜，单个分片拉取的shuffle数据量超过executor堆内存上限，哪怕最终只需要返回5条数据，也会在shuffle读、排序阶段直接触发OOM。
  3. 反序列化带来的额外开销：count()不需要解析行的具体内容，很多场景下直接读取序列化后的二进制数据就能完成计数；但show()需要把二进制数据反序列化成可读的行对象，如果单条记录结构复杂、嵌套层级深，反序列化后的内存占用可能是原始序列化数据的3-10倍，直接撑爆executor或者Driver的堆内存。

• 先定位OOM的进程：如果日志显示被kill的是Driver进程，说明是分片拉取的limit数据量过大，可以先执行df.select(你需要校验的小字段列表).show(5)，跳过不需要展示的大字段，同时适当调大spark.driver.memory参数即可。
• 如果被kill的是Executor进程，先检查转换链路是否存在数据倾斜，同时调大spark.executor.memory、spark.executor.memoryOverhead参数，调整shuffle溢写配置避免全量数据卡在内存中。
• 调试阶段不要直接对未做裁剪的宽依赖结果DF做show，尽量先筛选必要字段、缩小数据范围后再触发行动操作，避免无意义的内存开销。

内容的提问来源于stack exchange，提问作者Tom J Muthirenthi