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.reduces1000但实际数据量只有几个GB。结果每个Reducer只输出几MB甚至几KB的数据文件碎得不成样子。第四个来源是数据源本身就很碎。比如从上游系统同步过来的数据上游按小时或按事件推送落地就是一堆小文件HIVE只是做了个外部表映射文件数量的问题在进入HIVE之前就存在了。2.2 小文件对集群的具体伤害很多人只知道小文件不好但说不清楚到底哪里不好。我列几个实际测量过的数据影响维度具体表现量化参考NameNode内存每个文件对象约占150字节堆内存100万文件 ≈ 150MB堆Map任务数每个小文件至少一个split1万文件 ≈ 1万Map任务任务启动开销每个Map任务JVM启动约0.5-1秒1万任务 ≈ 1.4-2.8小时HDFS读取效率大量小文件的寻址开销远高于大文件随机读放大3-5倍下游任务读小文件分区时并发度虚高资源利用率下降40%以上这些数字不是吓唬人是我在实际集群上观察到的。所以小文件合并不是优化项是必做项。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.formatHIVE的输入格式类。要启用合并需要设置为org.apache.hadoop.hive.ql.io.CombineHiveInputFormat。这三个参数的关系是这样的CombineHiveInputFormat在切分split时会尽量把多个小文件合并到一个split里合并后的split大小不超过maxsize同时尽量不低于minsize。如果单个文件本身就大于maxsize那它自己独占一个split不会被拆分。3.2 具体配置方法与参数计算在HIVE会话中直接设置SET hive.input.formatorg.apache.hadoop.hive.ql.io.CombineHiveInputFormat; SET mapreduce.input.fileinputformat.split.minsize134217728; SET mapreduce.input.fileinputformat.split.maxsize268435456;这里minsize设为128MBmaxsize设为256MB。为什么这么设因为HDFS默认Block大小是128MB一个split最好对应1到2个Block。太小了合并效果不明显太大了单个Map任务处理时间过长一旦失败重试成本高。你也可以在hive-site.xml里全局配置property namehive.input.format/name valueorg.apache.hadoop.hive.ql.io.CombineHiveInputFormat/value /property property namemapreduce.input.fileinputformat.split.minsize/name value134217728/value /property property namemapreduce.input.fileinputformat.split.maxsize/name value268435456/value /property注意hive.input.format的默认值在不同HIVE版本中可能不同。HIVE 0.13之后默认就是CombineHiveInputFormat但有些发行版改回了HiveInputFormat。上线前一定要用SET hive.input.format;确认当前值。3.3 实操中的效果验证配置完之后怎么验证生效了看Map任务数量。举个例子一个分区有2000个小文件每个约5MB总数据量约10GB。合并前2000个Map任务每个文件一个split。 合并后按minsize128MB计算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.mapfilestrue; SET hive.merge.mapredfilesfalse;hive.merge.mapfilestrue表示在Map-only任务结束后启动一个额外的合并任务把输出目录下的小文件合并成更大的文件。合并后的大小由hive.merge.size.per.task控制默认256MB。SET hive.merge.size.per.task268435456;还有一个参数hive.merge.smallfiles.avgsize默认16MB。它的作用是当输出文件的平均大小小于这个值时才触发合并。如果平均大小已经大于16MB了就不合并了。SET hive.merge.smallfiles.avgsize16777216;这三个参数的配合逻辑是任务结束后先算输出目录下所有文件的平均大小如果平均值小于avgsize就启动合并任务合并后的每个文件大小约为size.per.task。4.2 带Reduce任务的输出合并如果SQL有Reduce阶段输出文件数量等于Reducer数量。控制Reducer数量本身就能控制文件数量但有时候Reducer数量不好预估或者业务逻辑要求必须用较多Reducer。这时候可以用SET hive.merge.mapredfilestrue;这个参数表示在MapReduce任务结束后合并输出文件。注意它和hive.merge.mapfiles的区别mapfiles针对Map-only任务mapredfiles针对带Reduce的任务。两个可以同时开启。4.3 控制Reducer数量来间接控制文件数最直接的办法其实是控制Reducer数量。有两种方式第一种是直接指定SET mapreduce.job.reduces10;第二种是让HIVE自动推算SET hive.exec.reducers.bytes.per.reducer268435456; SET hive.exec.reducers.max1009;bytes.per.reducer默认值是256MB不同版本可能不同意思是每个Reducer处理256MB数据。HIVE会根据输入数据总量除以这个值来推算Reducer数量上限由reducers.max控制。举个例子输入数据10GBbytes.per.reducer256MB那Reducer数量 10GB / 256MB ≈ 40个。输出就是40个文件每个约256MB。这个大小比较理想。但要注意如果数据有严重倾斜某些Reducer处理的数据量远大于其他Reducer那输出文件大小会很不均匀。这种情况下需要额外处理倾斜问题比如加随机前缀打散Key。4.4 输出端合并的完整配置模板把上面说的参数整合成一个可以直接抄的配置块-- 开启Map-only输出合并 SET hive.merge.mapfilestrue; -- 开启MapReduce输出合并 SET hive.merge.mapredfilestrue; -- 合并后每个文件的目标大小 SET hive.merge.size.per.task268435456; -- 触发合并的平均文件大小阈值 SET hive.merge.smallfiles.avgsize16777216; -- 控制Reducer数量 SET hive.exec.reducers.bytes.per.reducer268435456; SET hive.exec.reducers.max1009;这套配置在实际生产中用下来比较稳。但有一个坑要注意合并任务本身也要消耗资源。如果输出目录下有几十万个文件合并任务启动后需要先扫描所有文件、计算总大小和平均大小这个扫描过程可能很慢。我遇到过合并一个包含30万文件的目录光扫描就花了十几分钟。所以输出端合并最好配合定期的离线合并任务一起用不要等到文件积累到几十万了才想起来合并。5. 两种合并方式的配合策略与场景选择Map输入端合并和输出端合并不是二选一的关系它们解决的是不同阶段的问题。实际生产中我的建议是两个都开但根据场景调整侧重点。5.1 场景一临时查询和Ad-hoc分析这种场景下你只是偶尔查一下历史数据不关心输出文件数量。重点是让查询跑得快。这时候优先保证Map输入端合并生效SET hive.input.formatorg.apache.hadoop.hive.ql.io.CombineHiveInputFormat; SET mapreduce.input.fileinputformat.split.minsize134217728; SET mapreduce.input.fileinputformat.split.maxsize268435456;输出端合并可以不开因为临时查询的结果通常不落盘或者落在临时目录里用完就删。5.2 场景二ETL例行任务这是最需要关注的场景。每天凌晨跑批输出结果要被下游任务消费。这种场景下两个都要开而且输出端合并是重点-- 输入端 SET hive.input.formatorg.apache.hadoop.hive.ql.io.CombineHiveInputFormat; SET mapreduce.input.fileinputformat.split.minsize134217728; -- 输出端 SET hive.merge.mapfilestrue; SET hive.merge.mapredfilestrue; SET hive.merge.size.per.task268435456; SET hive.merge.smallfiles.avgsize16777216; -- Reducer控制 SET hive.exec.reducers.bytes.per.reducer268435456; SET hive.exec.reducers.max500;实操心得ETL任务里如果目标表是分区表且用了动态分区建议额外设置hive.exec.dynamic.partition.modenonstrict和hive.exec.max.dynamic.partitions5000避免分区数过多导致文件爆炸。5.3 场景三历史数据一次性合并对于已经存在的大量小文件上面的参数都帮不了你因为它们是针对新写入的数据的。历史数据需要用INSERT OVERWRITE重写一遍SET hive.merge.mapfilestrue; SET hive.merge.mapredfilestrue; SET hive.merge.size.per.task268435456; SET hive.merge.smallfiles.avgsize16777216; SET mapreduce.job.reduces50; INSERT OVERWRITE TABLE target_table PARTITION(dt2024-01-01) SELECT * FROM target_table WHERE dt2024-01-01;这个操作会把原分区的数据读出来再写回去写回时触发合并逻辑。注意reduces的数量要根据数据量来定别设太大也别设太小。一般按数据量 / 256MB来估算。5.4 两种方式的对比总结对比维度Map输入端合并Map/Reduce输出端合并作用阶段读取时写入时是否改变物理文件否是减少NameNode压力否是减少Map任务数是间接下次读取时适用场景临时查询、Ad-hocETL、例行任务核心参数split.minsize/maxsizemerge.mapfiles/mapredfiles额外资源开销低中到高合并任务6. 常见问题与排查技巧实录这一块是我踩坑最多的地方很多问题在官方文档里找不到答案都是实际跑任务时一点点试出来的。6.1 合并参数设了但不生效这是最常见的问题。原因通常有三个第一hive.input.format没设对。有些发行版默认不是CombineHiveInputFormat你需要显式设置。用SET hive.input.format;确认。第二文件格式不支持。比如ORC文件有自己的split策略CombineHiveInputFormat可能不生效。这时候需要看ORC相关的参数比如orc.split.strategy。第三参数被上层配置覆盖了。比如你在会话里设了split.minsize128MB但hive-site.xml里有个更小的值且会话设置没生效。用SET mapreduce.input.fileinputformat.split.minsize;确认当前生效值。6.2 合并后文件大小不均匀这个问题通常出现在有数据倾斜的场景。某些Reducer处理的数据量远大于其他Reducer输出文件自然大小不一。解决办法有两个一是加随机前缀打散KeySELECT 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.mapfilestrue; INSERT OVERWRITE TABLE target_table PARTITION(dt) SELECT * FROM tmp_table;6.5 常见问题速查表问题现象可能原因排查方法解决方案合并参数不生效input.format不对SET hive.input.format;显式设为CombineHiveInputFormatMap任务数没减少minsize太小检查split.minsize值调大到128MB输出文件仍很多merge参数未开检查merge.mapfiles/mapredfiles两个都设为true文件大小不均数据倾斜看各Reducer处理量加随机前缀或DISTRIBUTE BY合并任务慢文件数太多统计目录下文件数分批合并或提高并行度动态分区文件爆炸分区数×Reducer数过大看分区数和Reducer数分阶段写入或减少Reducer避坑技巧每次调整合并参数后不要只看任务是否成功一定要用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.size134217728; SET hive.exec.orc.default.block.size268435456;7.2 分区策略的优化合理的分区策略能从源头减少小文件。比如按天分区而不是按小时分区按业务维度分区而不是按事件时间分区。分区粒度太细每个分区的数据量就小文件自然就多。一个经验法则是每个分区的数据量最好在1GB以上。如果某个分区每天只有几十MB数据考虑把分区粒度调粗比如按周或按月分区。7.3 定期合并任务的编排对于持续写入的表建议编排一个定期的合并任务比如每天凌晨在ETL任务跑完之后对前一天的分区做一次合并。这样既能保证文件数可控又不会影响正常写入。合并任务的SQL模板SET hive.merge.mapfilestrue; SET hive.merge.mapredfilestrue; SET hive.merge.size.per.task268435456; SET hive.merge.smallfiles.avgsize16777216; SET mapreduce.job.reduces20; 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快得多适合在脚本里做自动化检查。