Hadoop TeraGen 调优：并行度与压缩的博弈——5GB 数据实测分析

引言

在上一篇文章中，我们探讨了 Map 数量对 Hadoop TeraGen 性能的影响，发现 2~8 个 Map 是最佳区间，过多 Map 反而因调度和 GC 开销导致性能下降。那么，开启数据压缩（如 Snappy）能否进一步提速？ 有人说“压缩减少 I/O，一定更快”，也有人说“压缩消耗 CPU，小数据量得不偿失”。本文通过一组对比实验，用数据回答这个问题，并解释一个有趣的现象：“开启压缩后，任务会先卡一下，然后就顺畅了”。

测试环境

项目	配置
Hadoop 版本	2.7.1
集群规模	3 个 DataNode（虚拟机，单盘 HDD）
数据量	5000 万条记录（约 5GB）
副本数	3
压缩方式	Snappy（org.apache.hadoop.io.compress.SnappyCodec）

测试了 2、4、8、16、32、40 共 6 种 Map 数量，分别对比不压缩和启用 Map 输出压缩两种情况下的总耗时（real 时间）。

实验结果总览

Map 数	无压缩 (real)	有压缩 (real)	差异	有无压缩 GC 时间 (ms)	有无压缩 CPU 时间 (ms)
2	1m5.757s	1m2.518s	✅ 快 3.2s	7,115 → 3,131	34,270 → 32,050
4	1m5.725s	1m6.591s	❌ 慢 0.9s	8,600 → 7,764	39,800 → 38,800
8	1m5.260s	1m16.265s	❌ 慢 11s	12,848 → 24,393	44,090 → 50,210
16	1m52.251s	1m46.242s	✅ 快 6s	65,240 → 156,117? (异常)	58,040 → 65,630
32	2m34.369s	2m36.195s	持平	173,268 → 156,156	82,940 → 85,010
40	2m50.760s	2m26.217s	✅ 快 24.5s	329,928 → 232,484	94,070 → 96,060

注：16 Map 有压缩时 GC 时间飙升，可能与推测执行或 JVM 行为有关，但耗时仍略优于无压缩，暂不深究。

现象分析：“先卡一下，然后顺畅”

用户在执行压缩测试时观察到一个直观感受：任务启动后，前几秒似乎卡住了（进度 0% 持续较久），但一旦开始跑，进度条就跳动得很快。

为什么“卡一下”？

• 每个 Map 任务初始化时，需要加载 Snappy 本地库、创建压缩器、分配内部缓冲区。这个过程大约需要 0.5~1 秒（取决于 CPU 和库版本）。对于小数据量（如 5GB），单个 Map 处理的数据量可能只有几百 MB，1 秒的初始化开销占比就很大。尤其当 Map 数量多时（比如 40 个 Map），累积的初始化时间就会很明显。

为什么“然后顺畅”？

• 压缩器就绪后，实际写入 HDFS 的数据量减少。TeraGen 生成的随机文本压缩比约为 1.5~2.0（Snappy 下），即 1GB 原始数据实际写 500~667MB。这减少了磁盘 I/O 和网络传输的压力，每个 Map 的执行速度变快，所以进度条刷新更频繁，给人“顺畅”的感觉。

数据解读：压缩到底有没有用？

1. 最佳 Map 数（2~8）时，压缩基本无收益

• 2 Map：压缩略快 3 秒（从 65.7s 到 62.5s），提升约 5%。
• 4 Map：压缩略慢 0.9 秒，可视为持平。
• 8 Map：压缩慢 11 秒（1m5s → 1m16s），明显更差。

原因：当集群 I/O 尚未饱和（2~8 Map 已经能跑满带宽）时，压缩节省的 I/O 时间不足以抵消 CPU 开销和初始化开销。尤其 8 Map 时，每个 Map 处理约 625MB 数据，压缩器初始化的 1 秒占 Map 执行时间（约 8 秒）的 12%，加上压缩本身消耗 CPU，总体变慢。

2. 过多 Map（16~40）时，压缩能部分挽回性能

• 16 Map：有压缩比无压缩快 6 秒。
• 40 Map：有压缩比无压缩快 24.5 秒（2m50s → 2m26s）。

原因：当 Map 数量过多时，无压缩情况下磁盘 I/O 争用、GC 压力、推测执行已经让性能崩溃。开启压缩后，每个 Map 写出的数据量减少，缓解了磁盘压力，同时减少了 GC 次数（虽然你看到 16 Map 的 GC 时间异常增加，但总体上耗时下降）。压缩虽然不能彻底解决过度并行化的问题，但可以减轻其恶果。

结论与建议

1. 小数据量下，不推荐默认开启压缩
   对于 5GB 级别的 TeraGen，最优配置是 不压缩 + 4~8 个 Map，耗时稳定在 1m5s 左右。开启压缩可能让事情变糟（如 8 Map 时慢了 17%）。

2. 如果一定要用压缩，应配合适当的 Map 数
   从测试看，2 Map + 压缩 的耗时 62.5 秒，比 8 Map 不压缩的 65.2 秒还略好。如果你喜欢压缩带来的“顺畅感”，可以选择 2~4 个 Map 并开启压缩。

3. 大规模数据（TB 级）时，压缩通常是赢家
   当数据量大到 I/O 成为绝对瓶颈（例如跨机架传输、慢速磁盘），压缩节省的时间远超 CPU 开销。此时推荐使用 Snappy 或 LZO，并适当增加 Map 数来平衡并行度。

4. 关于“先卡一下”的说明
   这是压缩库初始化的正常现象，不是故障。对于长任务（几百 GB 以上），这点初始化时间可以忽略。

写在最后

性能调优没有银弹。Map 数量、压缩、内存参数、集群硬件……每个因素相互影响。我们通过一组严谨的对比实验，揭示了在小集群、小数据量下压缩的真实效果。希望这篇文章能帮助你避免盲目开启压缩，并理解“卡一下”背后的原理。

如果你有自己的测试结果或不同观点，欢迎在评论区交流。

本文所有测试均可在 3 节点 Hadoop 2.7.1 上复现。原始日志和数据已存档，需要可留言索取。

相关阅读：Hadoop TeraGen 性能调优：如何选择最佳的 Map 数量？