Spark访问HDFS不同块大小文件的机制及Parquet文件优化咨询

开发者阿泽

2026-5-21

解答：Spark读取大Parquet文件任务数过多问题及HDFS文件创建策略

刚好之前处理过类似的场景，你的问题核心出在Spark读取Parquet的任务划分逻辑和文件结构不匹配上，我来一步步拆解并给出优化方案：

一、为什么6000个250MB+的Parquet文件会生成10000个任务？

Spark读取Parquet时，任务数不是简单等于文件数，而是由**Parquet的row group（行组）**和Spark的分区大小参数共同决定的：

Parquet的row group是它的最小并行读取单元，默认未压缩大小是128MB。你用了Snappy压缩（压缩率大概2:1左右），250MB的压缩后文件对应的未压缩数据大概是500MB，再结合Spark默认的spark.sql.files.maxPartitionBytes参数（控制单个任务处理的数据上限，默认128MB），你的每个大文件会被拆成2个左右的任务，6000个文件平均下来就生成了10000个任务。

假设你的HDFS块是128MB，250MB的文件会被HDFS拆成2个块存储。Spark读取时：

会尽量在HDFS块的边界拆分任务，避免跨块读取（跨块要访问多个DataNode，网络开销大）。
同时会参考maxPartitionBytes参数，如果单个块大小超过这个值，还会进一步拆分，但Parquet的row group是不可拆分的，所以不会把一个row group拆成多个任务。
这里要注意：Parquet的压缩是按内部的page（页）来压缩的，属于可拆分压缩，所以Spark能正常对大文件拆分任务；如果是整个文件用Gzip打包（不是Parquet内置压缩），那整个文件只能作为一个任务处理。

这类文件是性能杀手：

默认情况下，每个小文件对应一个任务，哪怕只有几KB。大量小文件会导致任务数暴增，带来巨量的调度开销（比如申请资源、启动JVM实例），拖慢整个作业。
Spark有个spark.sql.files.openCostInBytes参数（默认4MB），用来衡量打开一个文件的成本。如果文件大小小于这个值，Spark会尝试把多个小文件合并到一个任务里，但这个优化的效果有限，最好还是从源头上避免生成小文件。

结合你的场景，给你几个落地的优化方向：

核心思路：让压缩后的Parquet文件大小接近HDFS块大小（比如你的HDFS块是128MB，就把压缩后的文件控制在120-130MB；如果是256MB块，就控制在240-260MB）。
- 写Parquet时，调整parquet.block.size（这是未压缩的row group大小，默认128MB）。假设Snappy压缩率是2:1，那把这个参数设为256MB，压缩后正好是128MB，和HDFS块大小匹配，每个文件对应一个任务。
- 或者用spark.sql.files.maxRecordsPerFile，通过限制每个文件的记录数来控制大小，适合数据记录大小比较均匀的场景。

写数据到HDFS前，先用repartition或coalesce调整分区数，让分区数等于你预期的文件数。比如你要生成6000个文件，就把数据repartition到6000个分区再写，这样每个分区对应一个文件，不会出现一堆零散的小文件。
如果已经有大量小文件，用Spark做合并：读取所有小文件后，repartition到合适的数量再重新写入HDFS。

Snappy是平衡速度和压缩率的首选，适合大部分场景；如果想省存储，试试LZ4（速度和Snappy差不多，压缩率略高）；如果不介意读写速度，Gzip压缩率更高，但会增加CPU开销。
重点：一定要用Parquet内置的压缩（写的时候指定compression="snappy"这类参数），不要先压缩整个文件再存HDFS，否则Spark没法拆分任务。

调整parquet.block.size时，算好压缩率，让压缩后的row group大小刚好等于或略小于HDFS块大小。这样每个row group会存在一个HDFS块里，Spark读取时不用跨块，性能更优。

你现在的问题就是文件大小超过了Spark默认的分区大小，导致每个文件被拆成多个任务，增加了调度开销。通过调整Parquet的行组大小、控制文件生成数量，让文件大小和HDFS块、Spark分区匹配，就能把任务数降到和文件数接近的水平，大幅提升运行效率。

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