Databricks中PySpark limit()在display与toPandas下的性能差异问题

核心差异：display vs toPandas() 的执行逻辑 #

1. Databricks display 的定制化优化 #

display是Databricks专为交互式场景做了特殊优化的命令，并非原生Spark逻辑：

• 它会自动利用Delta表的**数据跳过（Data Skipping）**和列统计信息（比如直方图、分区/Z-Order信息），直接定位存储xyz='abc'的少量数据文件。
• 内部实现了提前截断逻辑：扫描数据时一旦收集到10条符合条件的记录，就立刻停止扫描，不会遍历全表，因此耗时极短。

2. toPandas() 的原生Spark执行限制 #

toPandas()触发的是标准Spark Job，性能骤降的关键在于执行计划的优化缺失：

• 如果xyz列没有统计信息（未执行过ANALYZE TABLE），也没有做分区/Z-Order排序，Spark优化器无法判断xyz='abc'的数据分布，只能生成全量扫描的执行计划——哪怕加了limit(10)，Spark也会先扫描所有可能包含目标数据的文件，筛选出全部符合条件的记录后再取前10条，而非扫描到10条就停止。
• 大量不必要的文件扫描会触发成百上千个任务，这就是任务数暴增、耗时超20分钟的核心原因。

3. 移除filter后性能一致的原因 #

去掉filter后，两种方式都只需要读取表的前10条记录，直接扫描表的起始数据文件即可完成，不存在数据筛选的额外开销，因此性能表现一致。

优化方案 #

• 生成列统计信息：执行ANALYZE TABLE catalog.schema.my_table_a COMPUTE STATISTICS FOR COLUMNS xyz;，让Spark优化器能精准识别数据分布，生成高效的执行计划。
• Z-Order排序优化：运行OPTIMIZE catalog.schema.my_table_a ZORDER BY xyz;，将相同xyz值的数据集中存储，大幅减少扫描的文件范围。

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