Spark读取S3分区Parquet数据性能差异及原理咨询

结论：这段代码不会先加载全部数据，但耗时久的原因和Spark的分区发现逻辑、懒执行特性有关，具体拆解如下：

1. Spark的懒执行逻辑 #

Spark是懒执行框架，spark.read().parquet("s3a://my_bucket/backup/backup/")这行代码只是创建了一个逻辑上的数据集抽象，不会立刻读取任何数据。真正的IO操作和计算，要等到dataset.show()这个Action触发时才会执行。

2. 耗时久的核心原因 #

(1) 全部分区元数据扫描开销 #

你的数据是按year/month/day/hour分层分区的，当读取根路径时，Spark需要遍历S3上所有的分区目录（比如所有year、month对应的子文件夹），逐个扫描分区的元数据信息。如果存储桶里有大量历史分区，这个扫描过程会非常耗时。

而第一个代码直接指定到hour=0的具体目录，Spark不需要扫描其他分区，直接读取目标目录下的文件，所以速度快。

(2) 分区裁剪的前提是元数据扫描完成 #

虽然你后续用SQL加了过滤条件，Spark会做分区裁剪（只读取符合条件的分区数据），但这个裁剪是在Spark完成所有分区的元数据扫描之后才会生效。也就是说，前面的分区扫描开销已经产生了，这才是拖慢整体速度的关键。

3. 优化方案 #

• 优先指定具体分区路径：保留第一种写法的优势，直接定位到目标分区目录，彻底避免全部分区的元数据扫描。
• 显式指定分区信息（按需）：如果必须用SQL过滤分区，可以在读取时指定basePath帮助Spark识别分区列，缩小扫描范围，示例代码：

  Dataset<Row> dataset = spark.read()
      .option("basePath", "s3a://my_bucket/backup/backup/")
      .parquet("s3a://my_bucket/backup/backup/year=*")
      .filter("year=2023 and month=12 and day=20 and hour=0");
  

• 检查分区列识别情况：如果用SQL查询时发现分区裁剪没生效，可以执行spark.sql("DESCRIBE my_data")查看分区列是否被正确识别，若未识别，需调整读取方式让Spark感知分区结构。

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