Spark Persist方法行为异常：全量调用却仅单个DataFrame持久化生效

核心机制说明 #

• Spark 中调用persist后，仅为DataFrame的计算链路打缓存标记，必须等待行动算子（如show()、count()）触发完整计算后，才会把分区计算结果块写入内存或本地磁盘的BlockManager存储，不会在调用persist的瞬间生成和源表解耦的永久快照。
• 无参数调用persist()时，默认使用MEMORY_AND_DISK存储级别。BlockManager的可用缓存空间由Executor可用内存、本地磁盘预留空间共同决定，无法无限制存储缓存块。
• 当缓存块因为任何原因丢失时，Spark不会抛出错误，会沿着原始计算血缘重新发起作业；重算阶段会读取元数据、数据源的最新状态，不会保留缓存生成时刻的源表快照。
• 缓存块丢失的常见触发场景：
  • LRU驱逐策略：缓存总大小超过BlockManager承载阈值时，自动淘汰最近最少访问的存储块
  • 本地磁盘临时空间不足，已落盘的缓存块被Spark存储层或操作系统主动清理
  • 主动调用unpersist()、Executor节点宕机导致缓存块丢失

本案例中各DataFrame的表现差异逻辑 #

结合代码中的SQL逻辑，三个DataFrame的体量存在显著差异，这是行为不一致的核心原因：

• new_data：筛选src_data中id不在test表的记录，这类增量同步场景下，对应数据体量通常仅占全量的极低比例，缓存块面积极小，不容易在有限的缓存空间中被LRU策略驱逐。
• changed_data：关联src_data与test表的差异数据，体量通常为全量数据的10%-30%，缓存块占比中等。
• unchanged_data：读取test表全量数据后筛选非变更部分，体量基本和原test表相当，是三个DataFrame中体积最大的。
  按照代码中的执行顺序，完整异常链路为：

1. 三个DataFrame先后通过show()触发计算，所有计算结果块尝试写入BlockManager缓存
2. 三个DataFrame的总缓存大小超过Executor的缓存承载阈值，LRU策略自动驱逐占空间最大的unchanged_data、以及体量次之的changed_data的存储块，仅留下体积极小的new_data缓存块没有被淘汰
3. 执行truncate table test清空Hive表后，再次调用三个DataFrame的show()：
   • 访问new_data时，直接命中留存的缓存块，返回truncate前的计算结果，表现和预期一致
   • 访问changed_data时，因对应缓存块被驱逐，只能沿血缘链路重新计算；重算时发现底层关联的Hive test表已经被清空，最终返回空结果，表现为持久化未生效
   • 访问unchanged_data时，同样因为缓存块被驱逐，重算时直接从已清空的test表读取数据，自然返回空结果

优化建议 #

• 对需要长期复用的大体积DataFrame，显式指定高可靠的存储级别，比如persist(StorageLevel.MEMORY_AND_DISK_SER)，通过序列化压缩降低缓存块体积，减少被LRU驱逐的概率
• 关键大体积缓存，在触发行动算子计算后主动调用count()发起全量缓存落盘，确认缓存大小在BlockManager的承载范围内
• 若需要和源表状态完全解耦的固定快照，不要依赖内存/本地磁盘缓存，直接将结果写入Hive表或分布式持久化存储，避免后续源表变更、缓存驱逐导致的结果偏差

内容的提问来源于stack exchange，提问作者SuperAadi