PySpark：SQL查询内过滤与filter函数过滤的性能差异及原因

首先要指出你代码里的关键笔误：第二个代码的filter条件错误地将column1写成了column2——第一个SQL是过滤column1 LIKE 'D%'，而第二个代码是过滤column2 LIKE 'D%'，这会导致两个查询返回的数据量完全不同，这几乎肯定是你感知到速度差异的直接原因。

正常情况下两种写法的性能等价性 #

如果修正笔误，让两个查询的过滤逻辑完全一致，理论上两者的执行速度应该没有差别。原因在于Spark的Catalyst优化器会对所有DataFrame/SQL操作进行逻辑优化：

• 当你在SQL中使用WHERE子句时，Spark会自动将过滤条件下推到数据源（比如Hive、JDBC等），数据源会先完成过滤，只返回符合条件的数据，减少数据传输和后续处理的开销。
• 当你在PySpark中调用filter时，只要这个操作是在触发动作（比如toPandas()）之前执行的，Catalyst会把filter操作合并到逻辑执行计划中，同样将过滤条件下推到数据源层面，最终生成的物理执行计划和SQL写法完全一致。

若修正后仍有差异的可能原因 #

如果修正笔误后还是存在性能差异，可能是以下因素导致：

• 数据源兼容性：部分小众数据源或JDBC驱动对SQL语法的下推支持更完善，但对DataFrame操作的下推支持存在瑕疵，导致过滤无法在数据源端完成，需要Spark拉取全表后再过滤。
• 数据类型不匹配：比如column2如果是日期类型，SQL中直接用字符串比较（'2019-01-01'）和DataFrame中用F.col比较的处理逻辑可能不同，建议使用日期专用函数（如F.to_date）来统一处理，避免隐式类型转换带来的性能损耗。

关于PySpark的意义 #

SQL只是PySpark提供的一种查询接口，PySpark的核心价值远不止于替代SQL：

• 灵活的编程能力：可以结合Python生态的各种工具（比如自定义UDF、机器学习库、可视化工具），完成纯SQL无法实现的复杂数据处理和分析逻辑。
• 统一的处理模型：支持批处理、流式处理、机器学习等多种场景，用一套API就能完成全链路的数据工作，而SQL在流式处理、迭代计算等场景下能力有限。
• 可扩展性：可以轻松应对大规模数据的分布式处理，同时支持自定义优化和扩展，这是纯SQL查询难以做到的。

内容的提问来源于stack exchange，提问作者Perkūns