Hadoop TeraGen 性能调优：如何选择最佳的 Map 数量？（附 5GB 实测数据）

一、背景

Hadoop 自带的 teragen 是测试 HDFS 写入性能的常用工具，它会生成指定数量的随机数据。很多初学者会有一个朴素的想法：Map 数量越多，并行度越高，任务跑得越快。

真的是这样吗？本文通过在 3 节点小集群上运行 5GB（5000 万条记录） 的 TeraGen 测试，对比了不同 Map 数量（2, 4, 8, 16, 32, 40）对作业总耗时、GC 开销、推测执行等指标的影响，得出一个反直觉的结论：过犹不及，Map 数量不是越多越好。

二、测试环境

项目	配置
Hadoop 版本	2.7.1
集群规模	3 个 DataNode（masterl, slavel1, slavel2）
每节点磁盘	1 块虚拟磁盘，容量 18 GB（实际可用 HDFS 约 17 GB）
网络	千兆
数据量	5000 万条记录，每条记录 100 字节 → 约 5 GB
副本数	3

三、实验设计

分别设置 mapreduce.job.maps 为 2、4、8、16、32、40，每个配置独立运行并清理输出目录。记录以下指标：

• 总耗时（real 时间）
• GC 时间（GC time elapsed）
• Killed map tasks（推测执行产生的冗余任务）
• Launched map tasks（实际启动的 map 数量）
• CPU 时间
• 平均每个 map 处理的数据量

四、实验结果

4.1 数据汇总表

Map 数量	总耗时 (real)	GC 时间 (ms)	Killed 任务	Launched 任务	CPU 时间 (ms)	每 Map 数据量
2	1m5.757s	7,115	0	2	34,270	2.5 GB
4	1m5.725s	8,600	0	4	39,800	1.25 GB
8	1m5.260s	12,848	0	8	44,090	625 MB
16	1m52.251s	65,240	5	21	58,040	312 MB
32	2m34.369s	173,268	4	36	82,940	156 MB
40	2m50.760s	329,928	3	43	94,070	125 MB

注：Launched map tasks 大于设定值是因为推测执行（Speculative Execution）启动了备份任务。

4.2 耗时趋势图（文字模拟）

耗时(秒)
 170 |                                                         
     |                                                         
 150 |                                                         
     |                                                         
 130 |                                                         
     |                                                         
 110 |                                          * (40)        
     |                                          
  90 |                                 * (32)                
     |                                                         
  70 |                    * (16)                              
     |                                                         
  65 | * (2)  * (4)  * (8)                                    
     +-------------------------------------------------> Map 数量
       2      4      8      16     32     40

五、结果分析

5.1 Map 数量在 2~8 之间时，性能几乎持平

• 2、4、8 个 map 的耗时都在 1 分 5 秒 左右，8 个 map 甚至略快一点点（可视为误差范围）。
• 这说明在集群资源范围内，增加少量 map 不会拖慢任务，但也没有带来明显加速。原因是 5GB 数据用 2 个 map 已经能打满磁盘和网络带宽。

5.2 当 Map 数量达到 16 时，性能急剧下降

• 耗时从 65 秒 翻倍 到 112 秒。
• GC 时间从 12.8 秒 暴涨到 65.2 秒，JVM 频繁创建和销毁对象成为主要瓶颈。
• 出现了 5 个被 kill 的任务（推测执行），浪费了集群资源。

5.3 Map 数量继续增加（32、40），性能进一步恶化

• 耗时增加到 2 分 34 秒、2 分 50 秒。
• GC 时间高达 173 秒、329 秒 —— 超过任务总耗时的一半！
• 调度开销（JVM 启动、分配容器、任务排队）显著增加。

5.4 为什么过多 Map 反而慢？

• 固定开销累积：每个 map 任务都需要启动 JVM、分配内存、与 Application Master 通信，这些开销与数据量无关。当 map 数量过多时，固定开销占据主导。
• GC 压力：大量短生命周期的 map 会产生大量临时对象，触发频繁的 GC，甚至 Full GC。
• 磁盘 I/O 争用：虽然 TeraGen 是顺序写，但多个 map 同时写不同文件时，磁盘磁头需要频繁寻道（对 HDD 尤其严重）。
• 资源排队：小集群并发槽位有限（假设每个节点 8 个 slot，共 24 个）。40 个 map 需要分两批执行，调度本身也耗时。

六、结论与建议

6.1 本次测试的最佳 Map 数量

在 3 节点、HDD、5GB 数据的环境下，最佳 Map 数量为 4~8。默认的 2 个 map 也完全可以接受，完全没有必要调高。

6.2 通用的调优原则（不局限于 TeraGen）

1. 从小到大，试探拐点
   从节点数或默认值开始，逐步增加 map 数量，观察作业耗时和 GC 指标。当耗时不再下降反而上升时，就是最佳点。

2. 硬件决定了最佳并行的上限

   • 磁盘越多、越快，能支撑的并发 map 越多。
   • 网络带宽越高，副本传输越不是瓶颈。
   • CPU 核数越多，JVM 启动和 GC 的影响越小。

3. 不要盲目相信经验公式
   网上常有“每个 map 处理 128MB 数据”的说法，这只是默认分片大小，并不保证性能最优。必须根据实际集群压测。

4. 留意推测执行
   如果出现大量 killed tasks，说明集群负载过高或数据倾斜，应适当减少并发或增加资源。

七、扩展思考：如果数据量是 1TB 会怎样？

• 5GB 时，2 map 和 40 map 的差距只有 2 分钟。
• 当数据量放大到 1TB（200 倍），固定开销也会线性放大。用 40 个 map（每个处理 25GB）可能比用 200 个 map（每个 5GB）快得多，因为减少了 JVM 创建和调度的总次数。
• 实际生产环境中，1TB 数据通常设置 map 数为 500~2000（取决于集群规模），而不是 40 或 80。最佳值需要针对你的硬件重新测试。

八、清理与后续

每次测试后记得删除 HDFS 输出目录，避免占满磁盘：

hdfs dfs -rm -r /output_*

如果你想进一步调优，可以尝试：

• 调整 mapreduce.map.memory.mb 和 mapreduce.map.java.opts
• 开启或关闭推测执行（mapreduce.map.speculative）
• 对比 terasort（包含 Reduce 阶段）的最佳配置

九、总结

性能调优不是简单增加并行度，而是在集群资源、数据量和任务开销之间找到平衡点。本文通过一组可复现的对比测试，展示了过度并行化带来的恶果，并给出了通用的调优方法论。

希望这篇文章能帮助你避免“Map 越多越快”的误区。如果你在自己的集群上做了测试，欢迎在评论区分享你的结果！

---

附：本文所有测试均可以在 3 节点 Hadoop 2.7.1 上重复，脚本和原始日志已留存。如有疑问欢迎交流。