spark.read与spark.sql执行成本差异原因探究

你的猜测部分正确，核心原因在于Spark处理分区数据时两种读取方式的底层逻辑差异：

• spark.sql的高效性来源：如果你的数据是注册为Hive表或通过元数据管理的分区表，spark.sql会直接读取元数据中的分区信息，精准定位到dt=20221225这个分区路径，不需要扫描整个父目录s3://a/b/c/target的内容，直接读取目标小文件，所以速度快、成本低。

• spark.read的慢因解析：当你直接用spark.read读取s3://a/b/c/target时，Spark默认会触发**自动分区发现（Partition Discovery）**机制：

  1. 它会递归扫描目标路径下的所有子目录和文件，识别key=value格式的分区目录（比如这里的dt=20221225）。这个过程在S3上会产生大量的ListObjects请求——S3的列表操作本身有延迟，尤其是目录下分区数量多的时候，扫描阶段的开销会非常明显。
  2. 不过你提到的“读取所有文件”并不准确：分区发现阶段只会读取文件和目录的元数据（路径、大小等），不会读取文件的实际内容，但仅列表操作的开销就足以让小数据量的读取变慢，远高于直接读取单个分区的成本。

验证方式 #

你可以通过以下方式确认这个逻辑：

• 查看Spark日志：spark.read执行时会出现类似Listing leaf files and directories for path s3://a/b/c/target的日志条目，而spark.sql不会有这个扫描阶段的日志；
• 查看S3访问日志：spark.read会产生大量针对s3://a/b/c/target及其子目录的List请求，而spark.sql只有针对s3://a/b/c/target/dt=20221225的请求。

优化建议 #

如果想让spark.read达到接近spark.sql的效率，可以尝试：

• 指定basePath参数：明确分区根目录，让Spark直接识别指定路径的分区，比如：

  spark.read.option("basePath", "s3://a/b/c/target")
    .parquet("s3://a/b/c/target/dt=20221225")
  

• 关闭自动分区发现：如果已经明确分区结构，设置recursiveFileLookup=false，手动指定分区列；
• 将路径注册为临时表后用spark.sql查询，复用元数据的分区优化。

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