企业官网建设流程全解析

1. 为什么HIVE小文件问题值得单独拎出来讲

干过离线数仓的人基本都踩过这个坑：一个分区底下躺着几万个小文件，每个文件几KB到几MB不等，hdfs dfs -ls一屏刷不完，跑个count(*)要等半天，下游任务读这个分区的时候直接起几百个Map任务，每个任务处理的数据量还不够JVM启动的开销。这不是理论问题，是每天凌晨跑批时真实发生的生产事故。

HIVE小文件的本质是元数据膨胀 + 任务调度开销放大。NameNode的内存是有限的，每个文件、每个Block、每个目录在NameNode里都要占一份元数据，默认一个对象大约150字节。你算一下，100万个小文件就是150MB左右的堆内存，这还只是一个分区。如果整张表有几千个分区，NameNode的堆压力会非常明显。更直接的影响在计算侧：HIVE在提交MapReduce任务时，每个小文件（或几个小文件合并后仍小于mapreduce.input.fileinputformat.split.minsize）会单独切一个split，一个split对应一个Map任务。1万个几KB的小文件，就是1万个Map任务，每个任务启动+销毁的JVM开销按1秒算，光调度就浪费了近3个小时。

所以小文件合并这件事，核心目标就两个：减少文件数量和控制文件大小在合理区间。合理区间是多少？业界比较通用的经验值是每个文件128MB到256MB，跟HDFS的Block大小对齐。太小了合并没意义，太大了单个任务处理时间长、失败重试代价高。

这篇文章围绕两个合并入口展开：Map输入端合并和Map/Reduce输出端合并。前者是在读取阶段把小文件合并成更少的split，后者是在写入阶段控制输出文件的数量和大小。两条路解决的是不同阶段的问题，实际生产中往往需要配合使用。下面我会把每个参数的来龙去脉、配置方法、踩坑经验都拆开讲清楚。

2. 先搞清楚HIVE小文件是怎么产生的

在动手合并之前，得先弄明白小文件从哪来。不找到源头，合并完了明天又冒出来一批，等于白干。

2.1 数据写入阶段的常见诱因

最常见的来源是动态分区插入。你写一条INSERT INTO TABLE ... PARTITION(dt, hour)的SQL，底层跑的是MapReduce或Tez任务，每个Reducer默认输出一个文件。如果动态分区产生了500个分区，每个Reducer负责写多个分区的数据，那最终就是500 × Reducer数量个文件。假设你起了100个Reducer，那就是5万个文件。这个数字一点都不夸张，我见过一个任务跑完直接生成12万个文件的。

第二个来源是频繁的微批写入。有些团队用HIVE做准实时场景，每5分钟或15分钟往同一个分区里灌一次数据，每次灌入都产生一批新文件。一天下来，一个分区里累积几百上千个文件是常态。

第三个来源是Reducer数量设置不合理。很多人为了加快任务速度，把Reducer数量调得很大，比如mapreduce.job.reduces=1000，但实际数据量只有几个GB。结果每个Reducer只输出几MB甚至几KB的数据，文件碎得不成样子。

第四个来源是数据源本身就很碎。比如从上游系统同步过来的数据，上游按小时或按事件推送，落地就是一堆小文件，HIVE只是做了个外部表映射，文件数量的问题在进入HIVE之前就存在了。

2.2 小文件对集群的具体伤害

很多人只知道小文件不好，但说不清楚到底哪里不好。我列几个实际测量过的数据：

这些数字不是吓唬人，是我在实际集群上观察到的。所以小文件合并不是"优化项"，是"必做项"。

3. Map输入端合并：让小文件在读取时就被"吃掉"

Map输入端合并的思路很直接：你文件多没关系，我在读取的时候把多个小文件塞给同一个Map任务处理，这样Map任务的数量就降下来了。注意，这种方式不改变HDFS上的物理文件，只是在计算层面减少split数量。文件还是那么多，NameNode的压力没减，但计算效率能提上去。

3.1 三个核心参数的关系

Map输入端合并依赖三个参数的配合：

• mapreduce.input.fileinputformat.split.minsize：单个split的最小大小。默认值通常是1（不同发行版可能有差异），意味着每个文件至少一个split。
• mapreduce.input.fileinputformat.split.maxsize：单个split的最大大小。默认值很大（通常是Long.MAX_VALUE），一般不主动限制。
• hive.input.format：HIVE的输入格式类。要启用合并，需要设置为org.apache.hadoop.hive.ql.io.CombineHiveInputFormat。

这三个参数的关系是这样的：CombineHiveInputFormat在切分split时，会尽量把多个小文件合并到一个split里，合并后的split大小不超过maxsize，同时尽量不低于minsize。如果单个文件本身就大于maxsize，那它自己独占一个split，不会被拆分。

3.2 具体配置方法与参数计算

在HIVE会话中直接设置：

SET hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; SET mapreduce.input.fileinputformat.split.minsize=134217728; SET mapreduce.input.fileinputformat.split.maxsize=268435456;

这里minsize设为128MB，maxsize设为256MB。为什么这么设？因为HDFS默认Block大小是128MB，一个split最好对应1到2个Block。太小了合并效果不明显，太大了单个Map任务处理时间过长，一旦失败重试成本高。

你也可以在hive-site.xml里全局配置：

<property> <name>hive.input.format</name> <value>org.apache.hadoop.hive.ql.io.CombineHiveInputFormat</value> </property> <property> <name>mapreduce.input.fileinputformat.split.minsize</name> <value>134217728</value> </property> <property> <name>mapreduce.input.fileinputformat.split.maxsize</name> <value>268435456</value> </property>

注意：hive.input.format的默认值在不同HIVE版本中可能不同。HIVE 0.13之后默认就是CombineHiveInputFormat，但有些发行版改回了HiveInputFormat。上线前一定要用SET hive.input.format;确认当前值。

3.3 实操中的效果验证

配置完之后怎么验证生效了？看Map任务数量。举个例子，一个分区有2000个小文件，每个约5MB，总数据量约10GB。

合并前：2000个Map任务（每个文件一个split）。 合并后：按minsize=128MB计算，10GB / 128MB ≈ 80个Map任务。

从2000降到80，任务启动开销直接省了95%以上。实际跑下来，一个原本需要25分钟的查询，合并后大约6分钟就跑完了。

验证方法很简单，在SQL前面加EXPLAIN看执行计划里的Map Operator数量，或者直接看YARN界面上实际启动的Map任务数。

3.4 Map输入端合并的局限性

这种方式有个明显的短板：它不减少HDFS上的文件数量。NameNode的元数据压力一点没减，只是计算时不再一个文件一个任务了。如果你的核心痛点是NameNode内存吃紧，那光靠Map输入端合并解决不了问题，必须配合输出端合并。

另外，CombineHiveInputFormat对某些特殊格式的文件支持有限。比如ORC文件，它有自己的split策略，CombineHiveInputFormat的效果可能不如预期。这种情况下需要结合ORC自身的参数来调。

4. Map/Reduce输出端合并：从源头控制文件数量

输出端合并才是真正"治本"的手段。它的核心思想是在Map或Reduce任务写出数据时，控制最终落地的文件数量和大小。HIVE提供了几个参数来做这件事，分别作用于Map-only任务和带Reduce的任务。

4.1 Map-only任务的输出合并

有些SQL不需要Reduce阶段，比如简单的SELECT * FROM table WHERE ...或者INSERT INTO ... SELECT ...不带聚合、排序、Join的场景。这时候输出文件的数量等于Map任务的数量。如果Map任务很多，输出文件就很多。

控制参数是：

SET hive.merge.mapfiles=true; SET hive.merge.mapredfiles=false;

hive.merge.mapfiles=true表示在Map-only任务结束后，启动一个额外的合并任务，把输出目录下的小文件合并成更大的文件。合并后的大小由hive.merge.size.per.task控制，默认256MB。

SET hive.merge.size.per.task=268435456;

还有一个参数hive.merge.smallfiles.avgsize，默认16MB。它的作用是：当输出文件的平均大小小于这个值时，才触发合并。如果平均大小已经大于16MB了，就不合并了。

SET hive.merge.smallfiles.avgsize=16777216;

这三个参数的配合逻辑是：任务结束后，先算输出目录下所有文件的平均大小，如果平均值小于avgsize，就启动合并任务，合并后的每个文件大小约为size.per.task。

4.2 带Reduce任务的输出合并

如果SQL有Reduce阶段，输出文件数量等于Reducer数量。控制Reducer数量本身就能控制文件数量，但有时候Reducer数量不好预估，或者业务逻辑要求必须用较多Reducer。这时候可以用：

SET hive.merge.mapredfiles=true;

这个参数表示在MapReduce任务结束后合并输出文件。注意它和hive.merge.mapfiles的区别：mapfiles针对Map-only任务，mapredfiles针对带Reduce的任务。两个可以同时开启。

4.3 控制Reducer数量来间接控制文件数

最直接的办法其实是控制Reducer数量。有两种方式：

第一种是直接指定：

SET mapreduce.job.reduces=10;

第二种是让HIVE自动推算：

SET hive.exec.reducers.bytes.per.reducer=268435456; SET hive.exec.reducers.max=1009;

bytes.per.reducer默认值是256MB（不同版本可能不同），意思是每个Reducer处理256MB数据。HIVE会根据输入数据总量除以这个值来推算Reducer数量，上限由reducers.max控制。

举个例子：输入数据10GB，bytes.per.reducer=256MB，那Reducer数量 = 10GB / 256MB ≈ 40个。输出就是40个文件，每个约256MB。这个大小比较理想。

但要注意，如果数据有严重倾斜，某些Reducer处理的数据量远大于其他Reducer，那输出文件大小会很不均匀。这种情况下需要额外处理倾斜问题，比如加随机前缀打散Key。

4.4 输出端合并的完整配置模板

把上面说的参数整合成一个可以直接抄的配置块：

-- 开启Map-only输出合并 SET hive.merge.mapfiles=true; -- 开启MapReduce输出合并 SET hive.merge.mapredfiles=true; -- 合并后每个文件的目标大小 SET hive.merge.size.per.task=268435456; -- 触发合并的平均文件大小阈值 SET hive.merge.smallfiles.avgsize=16777216; -- 控制Reducer数量 SET hive.exec.reducers.bytes.per.reducer=268435456; SET hive.exec.reducers.max=1009;

这套配置在实际生产中用下来比较稳。但有一个坑要注意：合并任务本身也要消耗资源。如果输出目录下有几十万个文件，合并任务启动后需要先扫描所有文件、计算总大小和平均大小，这个扫描过程可能很慢。我遇到过合并一个包含30万文件的目录，光扫描就花了十几分钟。所以输出端合并最好配合定期的离线合并任务一起用，不要等到文件积累到几十万了才想起来合并。

5. 两种合并方式的配合策略与场景选择

Map输入端合并和输出端合并不是二选一的关系，它们解决的是不同阶段的问题。实际生产中，我的建议是两个都开，但根据场景调整侧重点。

5.1 场景一：临时查询和Ad-hoc分析

这种场景下，你只是偶尔查一下历史数据，不关心输出文件数量。重点是让查询跑得快。这时候优先保证Map输入端合并生效：

SET hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; SET mapreduce.input.fileinputformat.split.minsize=134217728; SET mapreduce.input.fileinputformat.split.maxsize=268435456;

输出端合并可以不开，因为临时查询的结果通常不落盘，或者落在临时目录里用完就删。

5.2 场景二：ETL例行任务

这是最需要关注的场景。每天凌晨跑批，输出结果要被下游任务消费。这种场景下两个都要开，而且输出端合并是重点：

-- 输入端 SET hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; SET mapreduce.input.fileinputformat.split.minsize=134217728; -- 输出端 SET hive.merge.mapfiles=true; SET hive.merge.mapredfiles=true; SET hive.merge.size.per.task=268435456; SET hive.merge.smallfiles.avgsize=16777216; -- Reducer控制 SET hive.exec.reducers.bytes.per.reducer=268435456; SET hive.exec.reducers.max=500;

实操心得：ETL任务里，如果目标表是分区表且用了动态分区，建议额外设置hive.exec.dynamic.partition.mode=nonstrict和hive.exec.max.dynamic.partitions=5000，避免分区数过多导致文件爆炸。

5.3 场景三：历史数据一次性合并

对于已经存在的大量小文件，上面的参数都帮不了你，因为它们是针对新写入的数据的。历史数据需要用INSERT OVERWRITE重写一遍：

SET hive.merge.mapfiles=true; SET hive.merge.mapredfiles=true; SET hive.merge.size.per.task=268435456; SET hive.merge.smallfiles.avgsize=16777216; SET mapreduce.job.reduces=50; INSERT OVERWRITE TABLE target_table PARTITION(dt='2024-01-01') SELECT * FROM target_table WHERE dt='2024-01-01';

这个操作会把原分区的数据读出来再写回去，写回时触发合并逻辑。注意reduces的数量要根据数据量来定，别设太大也别设太小。一般按数据量 / 256MB来估算。

5.4 两种方式的对比总结

6. 常见问题与排查技巧实录

这一块是我踩坑最多的地方，很多问题在官方文档里找不到答案，都是实际跑任务时一点点试出来的。

6.1 合并参数设了但不生效

这是最常见的问题。原因通常有三个：

第一，hive.input.format没设对。有些发行版默认不是CombineHiveInputFormat，你需要显式设置。用SET hive.input.format;确认。

第二，文件格式不支持。比如ORC文件有自己的split策略，CombineHiveInputFormat可能不生效。这时候需要看ORC相关的参数，比如orc.split.strategy。

第三，参数被上层配置覆盖了。比如你在会话里设了split.minsize=128MB，但hive-site.xml里有个更小的值，且会话设置没生效。用SET mapreduce.input.fileinputformat.split.minsize;确认当前生效值。

6.2 合并后文件大小不均匀

这个问题通常出现在有数据倾斜的场景。某些Reducer处理的数据量远大于其他Reducer，输出文件自然大小不一。解决办法有两个：

一是加随机前缀打散Key：

SELECT concat(key, '_', cast(rand()*10 as int)) as new_key, value FROM source_table;

二是用DISTRIBUTE BY控制数据分布：

INSERT OVERWRITE TABLE target_table SELECT * FROM source_table DISTRIBUTE BY rand();

6.3 合并任务本身跑得很慢

合并任务慢通常是因为文件数量太多。我遇到过合并30万文件的目录，扫描阶段就花了15分钟。这种情况建议分批合并，比如按子分区逐个合并，而不是一次性合并整个表。

另外，合并任务的并行度也影响速度。可以通过mapreduce.job.reduces控制合并任务的Reducer数量，适当调大能加快合并速度，但别太大，否则又产生一堆小文件。

6.4 动态分区写入时文件数爆炸

动态分区是文件数爆炸的重灾区。除了前面说的控制Reducer数量，还有一个技巧是分阶段写入：先把数据写入一个临时表（不分区的），然后再从临时表插入到目标分区表。这样临时表阶段可以充分合并，插入分区表时文件数就可控了。

-- 第一步：写入临时表 INSERT OVERWRITE TABLE tmp_table SELECT * FROM source_table; -- 第二步：从临时表写入分区表 SET hive.merge.mapfiles=true; INSERT OVERWRITE TABLE target_table PARTITION(dt) SELECT * FROM tmp_table;

6.5 常见问题速查表

避坑技巧：每次调整合并参数后，不要只看任务是否成功，一定要用hdfs dfs -count或hdfs dfs -ls确认输出目录的实际文件数和文件大小。我见过任务成功但文件数没变的案例，原因是合并任务被跳过了（平均大小已大于阈值）。

7. 进阶技巧：结合表格式和存储格式做优化

前面讲的都是HIVE层面的参数调优。如果你的环境支持更高级的表格式，还有一些额外的优化空间。

7.1 ORC格式的合并策略

ORC文件本身是列式存储，对小文件的容忍度比TextFile高一些，但文件太多仍然有问题。ORC有一个orc.merge相关的优化，可以在写入时自动合并小文件。另外，ORC的stripe大小也影响读取效率，一般建议stripe大小在64MB到256MB之间。

SET hive.exec.orc.default.stripe.size=134217728; SET hive.exec.orc.default.block.size=268435456;

7.2 分区策略的优化

合理的分区策略能从源头减少小文件。比如按天分区而不是按小时分区，按业务维度分区而不是按事件时间分区。分区粒度太细，每个分区的数据量就小，文件自然就多。

一个经验法则是：每个分区的数据量最好在1GB以上。如果某个分区每天只有几十MB数据，考虑把分区粒度调粗，比如按周或按月分区。

7.3 定期合并任务的编排

对于持续写入的表，建议编排一个定期的合并任务，比如每天凌晨在ETL任务跑完之后，对前一天的分区做一次合并。这样既能保证文件数可控，又不会影响正常写入。

合并任务的SQL模板：

SET hive.merge.mapfiles=true; SET hive.merge.mapredfiles=true; SET hive.merge.size.per.task=268435456; SET hive.merge.smallfiles.avgsize=16777216; SET mapreduce.job.reduces=20; INSERT OVERWRITE TABLE target_table PARTITION(dt='${yesterday}') SELECT * FROM target_table WHERE dt='${yesterday}';

这个任务可以做成定时调度，每天跑一次。注意${yesterday}是调度系统的变量，实际使用时替换成具体日期。

8. 我在实际生产中的几点体会

小文件合并这件事，参数配置只是表面，核心是对数据写入模式的理解。你得知道数据是怎么进来的、每天产生多少文件、哪些分区是重灾区，才能有针对性地调参。

我刚开始做的时候，只知道把参数往大了设，结果合并任务本身消耗了大量资源，反而拖慢了整体跑批时间。后来才明白，合并的粒度要跟数据量匹配。小数据量用大合并参数，等于杀鸡用牛刀。

还有一个体会是：不要等到文件积累到几十万了才想起来合并。最好在ETL任务里就把合并参数带上，让每次写入都自动控制文件数量。这样文件数始终在一个可控范围内，不需要额外跑合并任务。

最后分享一个小技巧：如果你不确定某个分区的文件数是否正常，可以用hdfs dfs -count -v /path/to/partition快速查看文件数和总大小，然后算一下平均文件大小。如果平均小于64MB，就说明该合并了。这个命令比ls快得多，适合在脚本里做自动化检查。