每天跑完ETL后小文件爆炸，你怎么解决？
先说结论
小文件问题的本质是：HDFS上的文件数量太多，每个文件只有几KB到几MB。影响三个方面：NameNode内存压力、Map Task数爆炸、随机IO多。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
小文件问题是Hive生产环境里最常见的性能杀手。我做了9年大数据，每家公司都遇到过这个问题。查询慢、调度慢、NameNode压力大——全是小文件闹的。今天把原因和解决方案彻底讲清楚。
为什么会产生小文件？
原因一：动态分区插入 每个Reduce Task为每个分区生成一个文件。如果有200个Reduce和30个分区，就可能生成6000个文件。
原因二：数据源本身就是小文件 比如Kafka消费到HDFS，每批数据很少，生成大量小文件。
原因三：多次INSERT INTO 每次INSERT INTO都会生成新文件，不会合并已有文件。
五大解决方案
方案一：写入时控制文件数
-- Hive合并小文件配置
SET hive.merge.mapfiles = true;
SET hive.merge.mapredfiles = true;
SET hive.merge.size.per.task = 256000000; -- 256MB
SET hive.merge.smallfiles.avgsize = 128000000; -- 平均<128MB就合并方案二：INSERT OVERWRITE替代INSERT INTO
INSERT OVERWRITE会重写整个分区，不会累积小文件。生产环境的ETL作业建议统一用OVERWRITE。
方案三：用DISTRIBUTE BY控制输出文件数
-- 强制每个分区只输出1个文件
INSERT OVERWRITE TABLE target_table PARTITION(dt)
SELECT * FROM source_table
DISTRIBUTE BY dt;
-- 或者用Spark SQL的方式
-- df.repartition("dt").write.partitionBy("dt").saveAsTable(...)方案四：定期合并作业
-- 定期执行合并
ALTER TABLE target_table PARTITION(dt='2025-03-14') CONCATENATE;方案五：用Delta Lake/Iceberg的OPTIMIZE
-- Delta Lake
OPTIMIZE target_table WHERE dt = '2025-03-14';实战经验
我在元宇宙社交App做实时数仓时，从Kafka消费到Hive的层产生了大量小文件。一个分区里有1000+个小文件，每个只有几百BKB。查询一个小时的数据就要启动1000+个Map Task，Task调度开销比实际计算还大。
解决方案：增加了一个每小时执行的合并作业，用INSERT OVERWRITE重写上一小时的分区，把小文件合并成一个大文件。查询速度提升了10倍。
总结
小文件治理的核心思路：写入时少产生，产生后合并。生产环境用INSERT OVERWRITE + 合并配置是最基本的操作，用Delta Lake/Iceberg的OPTIMIZE是最省心的方案。
下一篇聊一个面试必问的场景题：两张大表Join特别慢，你怎么优化？这是Hive调优的核心场景。
你们治理小文件用的什么方案？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长