Spark 2.3是否改变了小文件的处理机制？

嘿，我来帮你搞明白这个事儿！从Spark 1.5升级到2.3后看到的任务数变化，其实是Spark新版本针对小文件场景做的默认优化，不是什么异常情况哦。

在Spark 1.5时代，确实是每个HDFS块（这里你的每个小文件刚好对应一个块）对应一个RDD分区，每个分区再对应一个执行任务，所以24000个小文件就会生成24000个任务。

但Spark 2.0之后，官方针对小文件过多导致的调度开销问题，默认启用了分区合并逻辑，核心是这两个参数：

• spark.sql.files.maxPartitionBytes：默认值和HDFS块大小一致（128MB），表示单个分区允许的最大字节数
• spark.sql.files.openCostInBytes：默认4MB，用来衡量打开一个文件的“开销”，Spark会把这个开销换算成字节数，和文件实际大小一起计算，决定是否合并多个文件到一个分区

简单来说，Spark会把多个总大小接近maxPartitionBytes的小文件合并到一个分区里，这样就能大幅减少任务数量，避免因为成千上万个小任务挤占调度资源、拖慢整体执行速度。

要是你的业务场景确实需要每个小文件对应一个独立任务，可以通过调整参数实现：

• 把spark.sql.files.maxPartitionBytes设为极小值，比如1，这样每个小文件都会单独成为一个分区：

  // 在代码里设置
  spark.conf.set("spark.sql.files.maxPartitionBytes", "1")
  

  或者提交作业时通过命令行指定：

  spark-submit --conf spark.sql.files.maxPartitionBytes=1 ...
  

• 另外也可以用wholeTextFiles API读取数据，这个API会把每个文件作为一个键值对（文件名→文件内容），每个文件对应一个分区，但要注意这个API的内存开销——每个文件的内容会被完整加载到内存里，要是文件内容过大可能会有OOM风险。

其实Spark 2.x的默认优化是更合理的，过多小任务会给集群调度带来极大压力，反而降低执行效率。如果你的HDFS里长期存在大量小文件，建议从根源解决：

• 定期合并小文件：用HDFS的distcp工具，或者写个简单的Spark作业把小文件合并成大文件
• 写入数据时避免生成小文件：调整spark.sql.shuffle.partitions减少 shuffle 后的分区数，或者在写入前用coalesce/repartition合并分区，避免每个分区生成一个小文件

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