判断原理:
当一个分区下的文件数量>100且平均文件大小<20M时一般认定为小文件过多。
小文件过多时,下游任务拉取上游数据花费时间会增多,任务执行过程耗时变长,可能导致下游作业数据生产延迟或失败。
优化方法:
1、当执行的作业没有shuffle阶段,只有map task,没有reduce task时,希望每个map task能够处理更大的数据量,可以设置:
set spark.hadoopRDD.targetBytesInPartition=67108864;(默认为33554432);
2、当存在shuffle阶段,即存在reduce task时,希望最后输出的文件数比较少,即每个reduce task写的单个文件更大时,可以设置如下参数:
set spark.sql.adaptive.shuffle.targetPostShuffleInputSize=134217728;(默认67108864,64M)。
3、当写出动态分区时,按照动态分区进行distribute by,如果目标表有三个动态分区dp1,dp2.dp3,就distribute by dp1,dp2,dp3,将数据均匀分布到不同的分区中。这样做的目的是确保每个分区内的数据量尽可能均匀,从而避免某些分区过大或过小的问题。
4、当一个分区的数据量比较大时,使用distribute by产生的文件就会非常大,且作业执行就会比较慢,此时可以通过distribute by某列将数据打散
例如(以分散到10个分区为例):
(1)用一个整数的id对10取模
distribute by id % 10
(2)用任意一个类型字段的hash,然后对10取模
distribute by abs(hash(col) % 10)
(3)避免某个字段倾斜,多考虑几个字段,降低倾斜的概率
distribute by abs(hash(col1, col2, …) % 10)
5.如果以上几步还是解决不了小文件问题,那么添加小文件合并参数
set spark.sql.mergeSmallFileSize=67108864
注意: 合并文件的操作会额外增加stage执行, 可能会增加执行时间.