4. HDFS小文件合并策略：三种主流方案深度对比

小文件合并，说白了就是把一堆零碎的小文件拼成大文件。HDFS天生适合大文件，一个128MB或256MB的块，你塞一堆几KB的小文件进去，NameNode内存先扛不住。

我这些年见过不少团队，一上来就问“哪种合并方案最好？”其实没有银弹。HDFS Concat、HDFS Append、DistCp，各有各的适用场景。今天我把这三个方案掰开揉碎了讲，你听完就知道该怎么选。

4.1 HDFS Concat合并：最快但限制最多

HDFS Concat是HDFS原生提供的一个API，能把多个文件的内容直接拼接成一个文件。它不走网络传输，只在NameNode层面做元数据修改，速度极快。

我记得第一次用Concat时，心里还挺美——几万个文件几秒钟就合并完了。但后来踩了个坑：Concat要求所有源文件必须在同一个目录下，而且文件块必须连续。什么意思？就是你得保证这些文件在HDFS上的块分布是相邻的，否则会报错。

用法很简单，Java API调用：

// HDFS Concat合并示例
Configuration conf = new Configuration();
FileSystem fs = FileSystem.get(conf);
Path[] srcPaths = new Path[] {
    new Path("/data/part-00000"),
    new Path("/data/part-00001"),
    new Path("/data/part-00002")
};
Path targetPath = new Path("/data/merged-file");
fs.concat(targetPath, srcPaths);

注意：目标文件必须存在，且不能为空。我习惯先创建一个空的目标文件，再执行concat。

4.2 HDFS Append合并：灵活但性能有代价

HDFS Append允许你往一个已存在的文件末尾追加数据。这个功能在HDFS 2.x之后才稳定，早期版本有bug，我吃过亏。

Append的思路很简单：打开一个文件，把其他文件的内容逐块读出来，然后追加到目标文件末尾。它不要求文件块连续，也不要求同目录，灵活性比Concat高。

但代价是什么？性能。Append需要走网络IO，数据要从DataNode读到客户端，再写到目标DataNode。如果文件数量大，这个过程会很慢。

// HDFS Append合并示例
Configuration conf = new Configuration();
FileSystem fs = FileSystem.get(conf);
Path targetPath = new Path("/data/merged-file");
FSDataOutputStream out = fs.append(targetPath);

for (Path srcPath : srcPaths) {
    FSDataInputStream in = fs.open(srcPath);
    byte[] buffer = new byte[1024 * 1024]; // 1MB缓冲区
    int bytesRead;
    while ((bytesRead = in.read(buffer)) != -1) {
        out.write(buffer, 0, bytesRead);
    }
    in.close();
}
out.close();

我个人建议：如果文件数量超过1000个，别用Append。否则你会看到任务跑半天还没结束，而且中间一旦失败，恢复起来很麻烦。

4.3 DistCp合并方案：分布式合并的王者

DistCp是HDFS自带的分布式拷贝工具，通常用来做跨集群数据迁移。但很多人不知道，它也能用来合并小文件。

DistCp合并的思路是：把多个小文件通过MapReduce任务拷贝到一个目标目录，在拷贝过程中，通过设置合并参数，把小文件合并成大文件。

你想想看，DistCp本质上是分布式作业，可以并行处理大量文件。对于百万级别的小文件，DistCp是唯一可行的方案。

# DistCp合并小文件示例
hadoop distcp \
  -Dmapreduce.job.reduces=10 \
  -Ddfs.blocksize=268435456 \
  -update \
  -delete \
  -numListstatusThreads 20 \
  /data/small-files/ \
  /data/merged-files/

这里的关键参数是-Dmapreduce.job.reduces，它决定了最终生成多少个合并后的大文件。我一般根据数据总量来算，每个大文件控制在128MB到256MB之间。

4.4 三种方案对比表

我把这三个方案的核心差异整理成了一张表，方便你快速决策：

对比维度	HDFS Concat	HDFS Append	DistCp
合并速度	极快（秒级）	慢（取决于文件大小）	中等（取决于集群资源）
文件块要求	必须连续	无要求	无要求
目录限制	必须在同一目录	无限制	无限制
网络IO	无（元数据操作）	有（客户端中转）	有（DataNode直连）
适用文件量	千级以内	百级以内	百万级
断点续传	不支持	不支持	支持
跨集群	不支持	不支持	支持

4.5 核心逻辑流程图

下面这张图展示了三种方案的核心流程差异，我画的时候特意把关键决策点标出来了：

4.6 我的实战建议

说了这么多，到底怎么选？我根据实际项目经验，给你几条硬建议：

• 同批次、同目录、文件量不大：无脑选Concat。我处理Spark Streaming的微批次输出时，就用Concat，几秒钟搞定几万个文件。
• 实时流式写入：用Append。比如Flume写入HDFS时，Append是唯一能保持文件持续增长的方式。但记得控制文件大小，别让单个文件无限增长。
• 跨集群或大规模合并：DistCp是唯一选择。我曾经用DistCp合并过500万个小文件，跑了3个小时，但至少跑完了，没挂。
• 混合策略：我习惯的做法是，先用Concat把同批次文件合并成中等文件（比如10MB左右），再用DistCp把这些中等文件合并成大文件（128MB以上）。这样既快又稳。