一、小文件问题概述

做大数据的人，十有八九都被小文件坑过。我入行那会儿，第一次在生产环境跑 Spark 任务，跑了一整夜，第二天一看——跑了 6 个小时，光打开文件就花了 4 个半小时。当时我就懵了。后来一查，HDFS 上堆了上千万个小文件，每个才几十 KB。嗯，这就是典型的小文件问题。

说白了，小文件问题就是：文件数量太多，单个文件太小，导致整个存储和计算系统都在为「打开文件」这件事疲于奔命，真正干活的效率反而极低。

什么是小文件问题

在 HDFS 里，一个文件块默认 128MB。但实际生产中，很多文件远小于这个值。比如日志采集按分钟切分，或者 Spark 作业输出时分区数设得太大，都会产生大量几 KB 到几 MB 的文件。

我一般把「远小于 HDFS 块大小」的文件称为小文件。具体来说：

文件大小范围	是否算小文件	典型场景
< 1 MB	严重小文件	实时采集按秒切分、Map-only 任务输出
1 MB ~ 16 MB	中等小文件	不合理分区、Reduce 数量过多
16 MB ~ 64 MB	轻度小文件	部分 ETL 中间结果
> 64 MB	正常文件	合理设计的批处理输出

小文件产生的根源

小文件不是凭空冒出来的。我梳理了一下，主要有这么几个源头：

• 数据采集端切分过细——比如 Flume 按分钟甚至按秒生成文件，一天下来就是 1440 个文件。我曾经见过一个客户，日志采集按 10 秒切一次，一天产生 8640 个小文件，一个月下来 NameNode 直接 OOM。
• Spark / Flink 分区数设置不合理——很多人写 Spark 时习惯把分区数设成几千甚至上万，每个分区写一个文件。你想想看，如果每个分区只有几百 KB 数据，那不就是小文件吗？
• Hive 动态分区写入——动态分区是个好东西，但用不好就是灾难。我记得有一次，一个 Hive 任务按 user_id 动态分区写入，结果产生了 20 万个分区，每个分区只有 1~2 个文件，每个文件几十 KB。整个集群直接瘫痪。
• 流式作业频繁提交——实时计算任务每几分钟 checkpoint 一次，每次输出一批小文件。日积月累，小文件数量就爆炸了。
• 数据合并 / 压缩策略缺失——很多团队只管写数据，不管合并。数据越堆越多，小文件也越堆越多。

小文件对存储的影响

小文件对存储的影响，最直接的就是 NameNode 内存爆炸。HDFS 的元数据全部存在 NameNode 内存里，每个文件、每个目录、每个块都要占用约 150 字节。你算算看：1000 万个小文件，光元数据就要占 1.5GB 内存。如果文件数到 1 亿，那就是 15GB。

除了内存，还有几个问题：

• 磁盘空间浪费——HDFS 最小存储单位是块，一个 1KB 的文件也要占一个块。虽然实际数据只占 1KB，但块元数据、副本管理、心跳检测的开销一点不少。
• 数据本地性变差——小文件太多，DataNode 上的数据分布碎片化。计算任务很难做到「数据本地计算」，大量数据需要网络传输。
• 备份和恢复效率低——做快照或数据迁移时，小文件越多，操作越慢。我经历过一次集群迁移，300 万个小文件花了整整两天才拷贝完。

小文件对计算的影响

计算层面的影响，比存储更隐蔽，也更致命。我总结了几点：

• Task 启动开销巨大——每个小文件在 MapReduce 或 Spark 里都会对应一个 Task。启动 Task 需要分配容器、拉取依赖、初始化 JVM。如果文件数量是 10 万，那就要启动 10 万个 Task。光启动时间就够你喝一壶的。
• Shuffle 阶段性能瓶颈——小文件太多会导致 Map 输出碎片化，Shuffle 阶段需要合并大量小片段。我在一个项目中遇到过，Shuffle 阶段花了 70% 的时间在合并小文件上。
• 查询响应时间变长——Hive / Presto 查询时，需要列举所有文件。文件越多，列举时间越长。一个简单的 SELECT COUNT(*) 可能因为文件太多而跑几分钟。
• 资源利用率低——每个 Task 处理的数据量太小，CPU 和内存利用率极低。集群看起来忙得要死，实际上大部分资源都花在「调度」和「启动」上了。

小文件问题的知识体系

下面这张图，是我梳理的小文件问题全景。你可以把它当作本章的思维导图：

这张图把本章的核心内容串起来了。你可以看到，小文件问题不是孤立存在的——它从「定义」出发，经过「根源」分析，最终落到「影响」上。后面的章节，我们会逐一拆解每个环节的优化策略。