在PySpark的DataFrame操作中，我们经常会先对列进行重命名，再在后续的过滤条件中引用列名。不少用户发现，即使列已经被重命名，原来的列名仍然可以在WHERE子句中使用，这背后的核心原因是PySpark的惰性计算机制和查询计划解析逻辑。
问题现象复现
我们先通过一个简单的示例来复现这个问题。首先创建一个测试DataFrame，然后对其中的列进行重命名，再尝试用原列名进行过滤：
from pyspark.sql import SparkSession
from pyspark.sql.functions import col
# 初始化SparkSession
spark = SparkSession.builder.appName("test").getOrCreate()
# 创建测试数据
data = [(1, "张三", 20), (2, "李四", 25), (3, "王五", 30)]
df = spark.createDataFrame(data, ["id", "name", "age"])
# 重命名age列为user_age
df_renamed = df.withColumnRenamed("age", "user_age")
# 尝试用原列名age进行过滤
result = df_renamed.where(col("age") > 22)
result.show()
运行上述代码后，你会发现程序没有报错，而且返回了正确的结果，也就是李四和王五对应的两条数据。按常理来说，age列已经被重命名为user_age，原列名应该已经不存在了，为什么还能正常查询呢？
核心原因：查询计划的逻辑优化
PySpark采用惰性计算模式，所有的DataFrame转换操作都不会立即执行，而是先生成对应的逻辑查询计划，直到遇到行动操作（如show、count等）时才会触发实际计算。在查询计划生成和优化的过程中，PySpark会做以下几件事：
- 记录所有的列引用关系，不会在重命名操作后立即删除原列名的引用入口
- 对查询计划进行规则优化，自动匹配列名的不同别名
- 在最终生成物理执行计划时，才会将列引用映射到实际的底层数据列
也就是说，withColumnRenamed操作只是给列添加了一个新的别名，并没有立即删除原列名的逻辑映射。当WHERE子句引用原列名时，PySpark的查询优化器会自动识别到该列名对应的实际列就是重命名后的user_age，因此不会报错，而是正常执行过滤逻辑。
验证查询计划
我们可以通过explain方法查看DataFrame的查询计划，来验证上述逻辑：
# 查看过滤操作的查询计划 result.explain(True)
在输出的详细查询计划中，你会看到逻辑计划里仍然保留了原列名age的引用，但是在优化后的逻辑计划和物理计划中，age会被自动替换为user_age，这就是为什么原列名可以正常生效的原因。
注意事项与最佳实践
虽然PySpark支持这种引用方式，但是在实际开发中并不推荐这么做，原因如下：
- 代码的可读性会变差，其他开发者看到原列名引用时，可能会误以为列没有被重命名
- 如果后续对DataFrame做了更多的列操作，可能会导致列名解析出现歧义，引发错误
- 不同版本的PySpark可能对这种别名解析的逻辑有细微差异，存在兼容性风险
因此最佳实践是在列重命名后，统一使用新的列名进行后续的查询操作：
# 正确的过滤方式，使用重命名后的列名
result_correct = df_renamed.where(col("user_age") > 22)
result_correct.show()
总结
PySpark中WHERE子句可以引用重命名后不存在的列，本质是惰性计算下的查询计划优化机制导致的，优化器会自动将原列名映射到重命名后的实际列。虽然这种写法可以正常运行，但是为了保证代码的可读性和稳定性，建议在列重命名后，统一使用新的列名进行后续操作。