Hive 小文件治理与合并策略实操指南

小文件问题的根子不在"文件太小"，而在生成机制：写入频率高、每次写入产出文件多，文件数就会指数级失控。治理要分三层打：源头控制写入、任务级参数合并、存量定时回刷。三层不是三选一，而是按成本从低到高、按见效从快到慢叠加使用。本文按"先治源头、再治任务、最后治存量"的顺序给出可落地的方案。

先定位：小文件是怎么产生的

Hive 表的小文件主要来自四类写入模式：

• 高频小批量写入：实时或准实时任务每隔几分钟 insert 一次，每次只写几 MB，一天下来几百上千个文件；
• 动态分区写入：insert overwrite 或 insert into 动态分区时，每个分区由多个 Reduce/Task 输出，分区多、Task 多，文件数约等于分区数乘以输出 Task 数；
• 并行度与数据量不匹配：Spark 的 shuffle 分区数、MapReduce 的 Reduce 数远大于实际数据量，每个 Task 写出一个几乎空壳的小文件；
• 分桶与数据量不匹配：分了 1024 个桶，实际数据只有几个 GB，每个桶文件远小于 HDFS 块大小。

定位方法很简单：用 dfs -count 看目录的文件数与总大小，算出平均文件大小；再把写入任务按时间轴对齐，找出持续产出小文件的任务。平均文件大小低于 64MB（HDFS 默认块大小）就要警惕，低于 10MB 基本可以断定在持续制造问题。

举个典型例子：一张订单明细表每天有 100 个动态分区，每个分区由 50 个 Task 写出，一天就产生 5000 个文件，一个月 15 万个；如果单分区数据只有 2GB，平均每个文件只有 40MB，明显小于块大小。这就是"分区数 × 输出 Task 数"失控的典型画像，dfs -count -h 一眼就能看出文件数与总大小的严重失衡。

第一层：源头写入控制

源头控制成本最低、效果最持久，核心是四件事：

1. 分区粒度要合理。分区是 Hive 表的物理切分单元，分区太多本身就是一种"小目录"问题。按分钟、小时分区适合流式场景，但要评估查询裁剪收益能否覆盖元数据开销；离线表默认到天或月即可，别为了"灵活"把分区切到很细。
2. 分桶数按数据量设计。分桶的目标是让每个桶文件接近目标大小（如 128MB-256MB），不是"越多越均匀"。数据量增长后再评估是否调整桶数，而不是一开始拍一个很大的数。
3. 控制写入频率、攒批写。高频小批量写入尽量合并：Flink/Spark 任务提高批大小或 checkpoint 间隔，离线任务从"每小时全量 overwrite"改成"一天一次 overwrite + 增量 merge"。
4. 写入时控制输出文件数。Spark 写 Hive 表前先 repartition 或 coalesce 到合理分区数；MapReduce 场景控制 Reduce 数，让"输出文件数 × 平均大小"对齐目标块大小。

源头控制不是一次改完，而是写入任务上线时就带上"目标文件大小"的验收标准：单文件低于阈值（如 64MB）的任务不允许直接上线。

第二层：任务级参数合并

Hive 提供了一组运行时合并参数，让任务在结束时自动把输出的小文件合并。最常用的是：

-- Map-only 任务（如只有 map 阶段的 insert select）
SET hive.merge.mapfiles=true;
-- MapReduce 任务
SET hive.merge.mapredfiles=true;
-- 触发合并的阈值：输出文件平均大小小于该值时合并
SET hive.merge.smallfiles.avgsize=134217728; -- 128MB
-- 合并后每个文件的目标大小
SET hive.merge.size.per.task=268435456;      -- 256MB

Tez/Spark 引擎有对应的开关：hive.merge.tezfiles、hive.merge.sparkfiles。ORC 表还可以开启 stripe 级合并 hive.merge.orcfile.stripe.level，只做逻辑合并、不重写数据，开销更小。完整参数说明可参考 Hive 官方配置文档。

适用边界要讲清楚：

• 参数合并是"任务结束时"的动作，适合离线批处理任务，任务多、单任务小文件多的场景收益明显；
• 对高频小批量写入收效有限：每次写入都要多跑一遍合并，相当于用额外计算换文件数，写入频率越高越不划算；
• 正在被持续写入的表不适合频繁合并，合并与写入并发会造成资源争抢甚至数据可见性问题，需要与写入侧协调窗口；
• 参数合并治不了存量小文件——它只影响"本次任务之后"产生的文件。

第三层：定时回刷合并存量

存量小文件只能用"回刷重写"解决：把分区数据读出来，按目标大小重新写出。Spark 动态分区回刷是主流做法：

// 按分区回刷：读取指定分区，重写到目标文件大小
val df = spark.read.table("ods.event_log")
  .where("dt >= '2026-07-01' and dt <= '2026-07-31'")

df.repartition(/* 目标文件数 ≈ 数据量 / 目标文件大小 */)
  .write
  .mode("overwrite")
  .format("parquet") // 与原表存储格式保持一致
  .insertInto("ods.event_log")

关键点：

• repartition 粒度：目标文件数 = 分区数据量 ÷ 目标文件大小，别用固定并行度，否则大分区还是小文件；
• 动态分区回刷：insert overwrite ... select ... distribute by 分区列 可以只重写指定分区，避免全表回刷；
• 执行窗口：回刷会覆盖数据，必须避开写入高峰和下游读取窗口，先回刷冷分区再处理热分区；
• 失败回退：回刷前保留原快照（或至少先在一个分区做演练），确认文件数和数据量符合预期再铺开。

回刷时目标文件数先算再设：比如某分区 10GB 数据、目标单文件 256MB，目标文件数约 40 个，用 repartition(40) 或按分区列 distribute by 控制输出，避免直接沿用 Spark 默认的 shuffle 分区数，导致回刷后依旧是小文件。

三层怎么选：适用边界对照

• 源头控制：治本，适合所有新任务，是长期策略，但改写入逻辑需要排期；
• 参数合并：见效最快、改动最小，适合存量批处理任务批量开启，是短期止血；
• 定时回刷：兜底，专门处理已经烂掉的存量表，周期执行（如每周）防止回潮。

实践中的顺序是：先给存量表排一轮回刷把文件数降下来，同时给批处理任务开参数合并止血，再推动写入侧源头改造。三层叠完，用监控盯住"平均文件大小"和"文件数环比"两个指标，防止回潮。

失败模式与排障要点

• 开了参数合并反而变慢：合并是额外一轮重写，小任务多时开销占比高；调高 hive.merge.smallfiles.avgsize 触发阈值，只合并真正的小文件，别让大文件也跟着重写；
• 回刷覆盖踩到下游：回刷用 overwrite 替换分区文件，正在读旧文件的查询可能读到中间态；先在小分区演练，并和下游约定窗口；
• 回刷破坏分桶结构：回刷后文件数与分桶数不一致，会影响后续 join 的 bucket 优化；回刷后核对实际文件数与表的分桶定义；
• 合并与写入并发：合并任务和写入任务同时写同一分区会互相覆盖或产生重复；用调度锁或时间窗错开；
• 只看文件数不看字节数：有些目录文件多但总量很小，合并收益低；按"平均文件大小"排序，先治文件数与数据量失衡最严重的对象。

这类从写入控制到回刷合并的治理流程，如果落在统一的平台底座上会省掉大量手工操作。袋鼠云大数据基础平台 EasyMR 基于开源 Hadoop 自研增强，在一站式平台内统一承载 Hive、Spark、Flink 等引擎的部署与调度，配合 EasyManager 的自动化运维与监控告警，可以把回刷任务、合并参数和文件数巡检沉淀成平台化的常规运维动作。