Spark rerun时的缓存行为：修改过滤条件后缓存如何更新？

答案很明确：修改过滤条件后重新运行全部代码，Spark会基于新条件重新计算DataFrame，并用新结果覆盖缓存（如果新代码里依然保留cache操作的话），旧的缓存数据会因为失去引用被Spark的缓存管理器回收，不会被沿用。

Spark能识别需要重新执行而非沿用缓存，核心依赖两个核心机制：

1. DataFrame是逻辑执行计划的引用，而非实际数据 #

当你写出df = spark.read(...).filter(...)这类代码时，变量df存储的不是内存里的实际数据，而是一条逻辑执行链（血统/Lineage）——它记录了从数据源到最终过滤步骤的所有操作指令。cache()方法只是给这条执行链打了个标记：“等实际计算时，把这个链的结果存起来”。

2. 缓存与特定逻辑执行计划绑定，而非变量名 #

• 第一次执行时，你的过滤条件会生成一条特定的逻辑计划，Spark执行后会把对应结果缓存，这个缓存是和这条计划绑定的，不是和变量df绑定。
• 当你修改过滤条件，相当于生成了一条全新的逻辑执行链——哪怕你还用同一个变量名df，这个变量现在指向的是完全不同的执行计划。Spark解析新计划时，发现没有对应的缓存记录，就会重新从数据源读取、执行新过滤，然后把新结果缓存。

3. 旧缓存的回收 #

旧的缓存数据因为没有任何变量再引用它对应的逻辑计划，Spark的缓存管理器会根据内存使用情况，自动将其回收释放空间。

举个直观的代码示例：

# 第一次执行流程
df = spark.read.parquet("s3://tb-level-data")
df = df.filter("age > 30")
df.cache()
df.count()  # 触发计算，缓存age>30的结果

# 修改过滤条件后重新运行全代码
df = spark.read.parquet("s3://tb-level-data")
df = df.filter("age > 40")  # 生成全新的逻辑计划
df.cache()
df.count()  # 触发新计算，缓存age>40的结果，旧缓存被回收

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