Spark 2.0.2与2.2.0+中persist()差异及新版本兼容方案咨询

这确实是Spark缓存机制在版本迭代中的一个行为变更：在2.0.2里，父DataFrame和其衍生的子DataFrame的缓存是完全独立的——你unpersist父DF时，子DF的缓存不会受影响；但从2.2.x版本开始，Spark优化了缓存的依赖管理逻辑，父子DF因为共享lineage中的缓存节点，所以unpersist父DF会连带取消所有依赖它的子DF的缓存。

针对你的需求，这里有几个可以复现2.0.2行为的替代方案，性能表现应该会比checkpoint好很多：

1. 用无副作用的转换打破父子DF的缓存依赖链 #

你可以在子DF的persist()之前，添加一个不会改变数据的轻量转换（比如select("*")或者coalesce（若分区数不变）），让子DF生成一个独立的LogicalPlan节点，这样它的缓存条目就不会和父DF绑定了。示例代码如下：

val parent: DataFrame = ... 
parent.persist() 
parent.count 
// 通过select("*")生成新节点，切断缓存依赖
val child: DataFrame = parent.filter(...).select("*") 
child.persist() 
child.count 
parent.unpersist()
// 此时child的缓存依然保留

这个方法的性能几乎和原逻辑一致，因为select("*")只是在逻辑计划上做了简单包装，不会产生额外计算开销。

2. 用Catalog的表缓存独立管理父子DF #

把父DF和子DF分别注册为临时视图，然后通过spark.catalog的缓存API来管理缓存。这种方式下，缓存是基于表名的独立条目，不会受lineage依赖的影响：

val parent: DataFrame = ... 
// 注册父DF为临时表并缓存
parent.createOrReplaceTempView("parent_temp")
spark.catalog.cacheTable("parent_temp")
parent.count 

val child: DataFrame = parent.filter(...)
// 注册子DF为临时表并缓存
child.createOrReplaceTempView("child_temp")
spark.catalog.cacheTable("child_temp")
child.count 

// 仅取消父表的缓存
spark.catalog.uncacheTable("parent_temp")
// child_temp的缓存依然有效

这种方式适合需要更精细化管理缓存的场景，缓存的生命周期完全由你通过表名控制。

为什么checkpoint性能不佳？ #

你提到checkpoint性能不好，这是因为checkpoint的核心是把数据持久化到磁盘（默认是分布式存储），同时截断lineage——这会带来额外的IO开销，而我们上面的方案都是基于Spark的内存/磁盘缓存体系（和原persist逻辑一致），性能损耗极小。

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