Hive命名空间配额告急：INSERT INTO操作引发文件数过多问题求助

你猜的完全没错——原分区表的大量小文件就是导致INSERT操作生成过多文件、耗尽HDFS命名空间配额的核心原因。从你给出的hdfs fs -count结果来看，剩余命名空间配额只剩19.8K，确实已经非常紧张了。下面给你几个实用的方案来减少INSERT操作生成的文件数，同时附上相关配置说明：

一、调整Spark核心配置，直接控制输出文件数量 #

这些配置可以从根源上减少Shuffle和输出阶段的文件数：

• 调整Shuffle分区数：spark.sql.shuffle.partitions默认值是200，对于你的场景来说可能过大。你可以根据目标数据量调小这个值，比如设置为spark.sql.shuffle.partitions=16（和集群CPU核数匹配是个不错的选择）。因为你的INSERT操作包含GROUP BY，会触发Shuffle，更少的分区数意味着最终生成的文件数更少。
• 限制单文件最大记录数：设置spark.sql.files.maxRecordsPerFile=1000000（可根据你的单条记录大小调整），强制每个输出文件至少包含100万条记录，避免生成大量极小文件。
• 优化小文件合并判断阈值：spark.sql.files.openCostInBytes默认是4MB，代表Spark认为打开一个文件的开销等价于读取4MB数据。如果你的原表小文件很多，可以调大这个值（比如spark.sql.files.openCostInBytes=67108864即64MB），让Spark更倾向于合并小文件进行处理。

二、读取原表时先合并小文件 #

在处理原表数据前先合并分区，能减少后续Shuffle和输出的压力：

• 使用COALESCE减少分区：在查询中直接对原表数据进行分区合并，因为COALESCE不会触发Shuffle，性能比REPARTITION更高。示例SQL如下：

  INSERT INTO TABLE <new-table> 
  SELECT col_1, col_2, col_3 
  FROM (
      SELECT col_1, col_2, col_3 
      FROM <old-partitioned-table> 
      WHERE YEAR='2017' AND MONTH='03'
  ) t
  COALESCE(10)
  GROUP BY col_1, col_2;
  

• 开启Spark自动合并小文件读取：确保spark.sql.hive.convertMetastoreParquet=true（默认已开启），这个配置让Spark读取Parquet格式的Hive表时自动合并小文件，提升读取效率同时减少后续处理的分区数。

三、借助Hive的小文件合并机制（针对Hive管理表） #

如果你的<new-table>是Hive管理表，可以在执行INSERT前开启Hive的输出合并参数，让Hive在任务完成后自动合并小文件：

SET hive.merge.mapfiles=true; -- 开启Map任务输出合并
SET hive.merge.mapredfiles=true; -- 开启Reduce任务输出合并
SET hive.merge.size.per.task=256000000; -- 每个合并后的目标文件大小（示例为256MB）
SET hive.merge.smallfiles.avgsize=16000000; -- 当输出文件平均大小小于16MB时触发合并

执行完这些设置后再运行你的INSERT语句，Hive会自动帮你合并小文件。

四、考虑对新表进行分区写入（可选） #

如果你的业务查询场景允许，可以将<new-table>按col_1或其他维度分区，这样每个分区内的文件数会大幅减少，同时还能提升后续查询的性能。示例SQL如下：

INSERT INTO TABLE <new-table> PARTITION (col_1)
SELECT col_2, col_3, col_1 
FROM <old-partitioned-table> 
WHERE YEAR='2017' AND MONTH='03' 
GROUP BY col_1, col_2, col_3;

调整完上述配置或方案后，你可以再次执行hdfs fs -count -q -h -v <user-path>来查看剩余命名空间配额的变化，确认文件数量是否有所减少。

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