ADLS中Parquet子文件数为何与Spark DataFrame分区数不符？

PySpark读取Parquet文件时，分区数并不与子文件数量严格一一对应，你遇到的172个snappy.parquet文件对应89个分区的情况，主要由以下几个核心逻辑导致：

• 小文件自动合并优化：Spark默认会对小文件进行合并。如果你的172个文件中存在大量**远小于spark.sql.files.maxPartitionBytes默认值（通常128MB）**的小文件，Spark会自动将多个小文件合并到同一个分区，以此减少分区数量、降低任务调度开销。前两个文件夹的10个子文件大小刚好接近或达到单分区阈值，所以分区数与文件数一致。

• 存储块与文件的拆分/合并：ADLS以块为单位存储文件（默认块大小100MB）。如果某个Parquet文件大小跨多个存储块，Spark可能会将其拆分为多个分区；反之，多个小文件的总大小若未超过分区阈值，就会被合并为一个分区。你的场景中，部分大文件被拆分、大量小文件被合并，最终总分区数变为89。

• 分区数的动态计算逻辑：Spark读取Parquet时，会先扫描所有文件的总大小，结合spark.sql.files.maxPartitionBytes（单分区最大字节数）和spark.sql.files.openCostInBytes（衡量打开文件的开销，默认4MB）计算最优分区数。核心逻辑是平衡数据量和文件打开开销——如果文件过小，合并分区更划算；如果文件过大，拆分分区更高效。你这个案例就是这种动态调整后的结果。

验证方法 #

你可以通过以下方式确认上述推测：

1. 统计172个snappy.parquet文件的大小分布，查看小文件数量
2. 查看当前Spark配置值：spark.sql.files.maxPartitionBytes、spark.sql.files.openCostInBytes
3. 读取时强制指定分区数（如spark.read.parquet("path").repartition(172)），可得到与文件数一致的分区，但不建议在小文件场景下这么做，会降低执行性能

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