徐卓菲做大数据的人，大概率都经历过这种状况：集群明明有几十个节点，跑个批量任务却慢得让人怀疑人生；听说 Hadoop 性能优化能救，结果照着网上的"调优大典"把参数改了一遍，任务不但没变快，反而开始 OOM、容器被 kill、shuffle 卡成瓶颈。大数据领域的 Hadoop 性能优化，最怕的就是不知道瓶颈在哪就盲目抄参数。Hadoop 的默认配置是为"能跑起来"设计的，不是为"跑得快"设计的，而且每个集群的硬件、数据规模、作业特征都不一样，网上那套参数很难直接复制。
这篇文章就是来分享我这些年实际调优 Hadoop 的经验。我会从瓶颈定位、HDFS 存储调优、YARN 和 MapReduce 资源配置、操作系统与基础设施、以及最终的压测验证五个方向展开，尽量把每个配置背后的逻辑讲清楚，而不是丢一堆参数让你照抄。适合正在维护 Hadoop 集群的运维、开发，也适合那些刚把集群搭起来、准备做性能摸底的朋友。
1. 先定位瓶颈：你的Hadoop到底慢在哪一边
1.1 从作业链路找问题：读、算、写、shuffle，哪一段最刺眼
Hadoop 上的一个批量作业，看起来是"丢个任务进去等结果"，实际上内部是一条很长的链路：从 HDFS 读输入文件，按输入分片生成 map 任务，map 处理完毕做 shuffle，把中间数据交给 reduce，reduce 结果再写回 HDFS。每一条链路都可能成为性能瓶颈，而且瓶颈不是固定的。你如果不知道这个作业是慢在 HDFS 读取、map 计算、shuffle 传输还是 reducer 倾斜，就贸然调参，完全就是盲人摸象。
我的习惯是先打开 YARN ResourceManager 的 Web UI，看作业整体时间分配。界面上会显示 Map 阶段和 Reduce 阶段的执行时间，如果 Map 阶段本身耗时很长，点进单个 task 看读取字节数、处理记录数和反序列化时间；如果 Reduce 阶段特别长，则要关注是不是有个别 reducer 积压了大量数据，或者 shuffle 阶段一直在等数据。这里有个很典型的误区：很多人一看到作业慢，就去改 yarn.nodemanager.resource.memory-mb，但其实瓶颈可能在 HDFS 的小文件数量上，可能是 reducer 数据倾斜，也可能是某个 DataNode 磁盘坏道拖慢整个任务。改内存参数治不了这些病。
另外一个不要忽略的信息源是 Counter。Hadoop 的 MapReduce Counter 里有 GC time、Spilled Records、Physical memory、Virtual memory、HDFS_BYTES_READ 这些指标，通过 Web UI 的「Counters」页面就能看到。如果 Spilled Records 数量远远大于实际输出记录数，说明 map 端输出因为内存不足在反复写磁盘，shuffle 阶段发生了大量溢写，这是一个非常强烈的需要调 io.sort.mb 或 mapreduce.map.java.opts 的信号。先通过这些数据分析，再动手改参数，才不会把集群越调越乱。
1.2 从系统层面找问题：CPU、磁盘、网络，用量化指标代替"凭感觉"
除了 Hadoop 自带的监控页面，操作系统层面的指标同样关键。我在排查问题时经常用 dstat 看整体负载，用 iostat -x 1 看每块磁盘的利用率、await、svctm，用 iftop 看节点间的流量流向。每一个指标背后都有对应的问题模式：
%util长期超过 90%，且await很高，大概率是磁盘 IO 饱和。如果数据目录恰好和系统日志放在同一块机械盘上，性能会被拖得很严重。- 网络流量在 reduce 阶段突然飙升，甚至跨机架流量暴增，shuffle 是主要嫌疑，需要看是否因为数据本地性差，或者中间数据没有压缩。
- CPU 使用率很分散，每个核都不高，但任务就是跑不动，往往是调度开销、锁竞争、大量小任务在排队。
使用系统指标时，还可以配合 pidstat -p 看 Hadoop 守护进程本身的消耗。NameNode 如果 CPU 长期偏高，多半是处理 block report 或文件系统操作太频繁；DataNode 如果 GC 停顿大，会影响整个 HDFS 的读写带宽。记住一点：先给集群做一次"体检"，把瓶颈锁定到一个层面，再去翻对应的优化参数，这才是能稳定复现的调优方式。我遇到不少团队，折腾了一周参数，最后发现是某台节点网络网线松动，reducer 一直在等那个慢节点拖尾。这个问题你用再好的 mapreduce.reduce.shuffle.parallelcopies 也救不回来。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. HDFS层的存储与读取优化：数据放得对不对，决定了后面跑得顺不顺
2.1 Block Size：别把128MB当成永远正确的真理
HDFS 默认的 block size 是 128MB，这是很多发行版的新手默认项。但是，block size 改不改、改成多少，完全取决于作业模型和文件大小分布。
先搞懂一件事：MapReduce 的输入分片大小通常是 Math.max(minSize, Math.min(maxSize, blockSize))，默认配置下，一个 block 对应一个输入分片，也就是一个 map 任务。如果 block size 是 128MB，一个 1GB 的文件会切成 8 个 block，默认产生 8 个 map 任务；把 block size 调到 256MB，同样大小的文件就只有 4 个 map 任务。调大 block 的收益是减少 map 任务数，降低 task 调度、JVM 启动、任务初始化带来的开销，同时减少 NameNode 中 block 元数据数量，对 HDFS 内存友好。
我见过一些场景，集群数据量不算大，但每个文件就几十 MB，却有成千上万个文件，这种情况下不管 block size 是多少都救不了，因为小文件本身不占用整块空间，反而白白消耗 block 元数据。反过来，如果是单文件几十 GB 的 TeraSort 或离线加工任务，我会考虑把 block size 调到 256MB 甚至 512MB，配合减少 map task 数量，会发现调度开销下降明显。特别是在使用 Hive/Tez 跑大批量聚合时，超大数量的 map task 很容易把 ResourceManager 的调度线程拖垮，这时候调大分片是一个立竿见影的手段。
需要注意，block size 也不是越大越好。单个 mapper 处理一个超大 block 时，读取管道受限于单客户端读取速度和热点块影响，如果集群节点多、核数多，而 block 太大导致任务数太少，计算资源反而会被闲置。调优不是换一个"万能值"，而是让数据分片规模和你集群的并行度匹配。先通过压测找到当前并发下的合理 map 任务数，再倒推 split size，这样最稳妥。
2.2 小文件治理：不解决小文件，调多少参数都找不回来
小文件问题在 Hadoop 集群里可以说是"百病之源"。每个文件、目录、block 在 NameNode 内存中都有固定代价的元数据对象，单个小文件至少会占用几十字节到几百字节的 NameNode heap。文件数量一旦到了几百万，NameNode GC 会越来越慢，整个集群的元数据服务响应都会恶化。你会发现明明磁盘空间还很多，但写入新文件却变慢了，这就是内存层面的压力，不是磁盘问题。
更影响业务的是，MR 读取小文件时每个文件至少产生一个 input split，一个 map task 可能只处理几 KB 数据，却要承担完整的 task 生命周期和 JVM 启动开销。很多跑批慢到无法接受，本质就是上游产生了大量不可分割的小文件。
治理小文件有几种常见手段，使用场景不同：
- 数据摄入阶段控制：对于 Flume、Kafka 落地 HDFS 的场景，把文件滚动时间调大一点，比如按 30 分钟或 128MB 滚动生成，而不是每秒钟写一个小文件。
- 使用 Hive
concatenate：对已经被小文件污染的 Hive 表，可以执行ALTER TABLE xxx CONCATENATE，让 ORC/Parquet 文件合并，这个操作在 Hive 上是较为安全的。 - 写 MR 时使用
CombineFileInputFormat：它能把多个小文件合并为一个 split，减少 map task 数量。这不需要改动物理文件，见效快，适合临时作业。 - 定期合并任务：离线跑批之外再跑一个轻量合并任务，把目录下小于某阈值的小文件合并到大文件中。
不要等到 NameNode 内存告急才想起来治理小文件。每次做性能优化之前，先看 HDFS 文件总数和 block 总数，如果文件数超过集群节点能承受的范围，第一步永远是先清理小文件，而不是去调 YARN 的容器内存。
2.3 副本、本地读与机架感知：让 DataNode 少当"搬运工"
HDFS 默认副本数是 3，很多人以为减少副本能省磁盘、提升性能，其实没那么简单。副本数的增加确实会带来额外写入流量和磁盘占用，但读取性能并不一定因此提升，因为 Hadoop 调度任务时最理想的是数据本地化读取，也就是 map 任务直接跑在存有该 block 的 DataNode 上。副本越多，数据本地化的命中概率越高，任务从"本地读"降级成"机架内网络读"或"跨机架网络读"的概率就越低。从稳定性的角度，3 副本依然是大多数生产集群的最优折中；如果为了省一半磁盘删到 2 副本，一个节点损坏可能让部分 block 进入低副本状态，还得等后台复制，反而影响读写。
真正能立刻提升读取性能的，是开启 HDFS Short Circuit Read，也就是"短路读"。所谓短路，是指本地 MapReduce 任务读取 DataNode 上的数据时，直接绕过 DataNode 服务端和 TCP 协议，通过 Unix Domain Socket 从磁盘文件上读块，省掉网络栈和系统调用开销。对于高并发读取、大量小文件，或者每台机器上经常跑本地任务的场景，这个优化非常显著。配置方式是把 dfs.client.read.shortcircuit=true、dfs.domain.socket.path=/var/lib/hadoop-hdfs/dn_socket，并保证目录权限正确。很多发行版默认没开，集群已经跑了很多小任务的话，开了之后会有意外惊喜。
机架感知也是很多人忽略的性能优化点。配置了机架感知的副本放置策略，HDFS 会把副本分散到至少两个机架，有利于容错；而从任务调度角度，NameNode 知道网络拓扑后，能够更准确地判断数据本地性，YARN 在调度 Container 时也会优先选择同一机架内的节点。如果集群跨多个机房或机架，却没有配置机架感知，跨机架流量会变得不可控，shuffle 阶段整体吃掉大量网络带宽。配置机架感知本身并不复杂，写好 topology.py 或 topology.sh，在 core-site.xml 里设置 net.topology.node.switch.mapping.impl，重启 NameNode 就能生效。
2.4 压缩与数据格式：存储减了，吞吐反而升了
压缩是一个看似简单但坑很多的优化点。在 Hadoop 场景里，压缩要解决的不只是磁盘占用，更是网络 IO 和磁盘 IO 的压力。明确一点：压缩算法对 CPU 有额外消耗，但对现代集群而言，瓶颈通常在网络和磁盘，CPU 往往还有富余，所以开启压缩通常是划算的。
选压缩算法时，最常犯的错是不考虑是否可分割。Gzip 压缩率高，但单个 Gzip 文件不可分割，一个 1GB 的 Gzip 文件无论多大都只能由一个 map 任务顺序读取，并行度直接砍半。如果要处理不可分割的大文件，可以考虑 LZO，它支持对压缩流做切分，但需要安装额外的 native 库；现在更常见的方案是使用 Snappy，Snappy 速度快、开销低，在 HDFS 上用 Snappy 存储文本时，虽然原生不是按 block 切分，但如果你配合 Parquet/ORC 这类列式格式，文件内部的 stripe/row group 天然可分割，就不会出现一个大压缩文件只能单 map 读的尴尬。
我在实际集群里推荐的做法是：
- 中间 shuffle 数据开启压缩：
mapreduce.map.output.compress=true，codec 选org.apache.hadoop.io.compress.SnappyCodec。map 输出先压缩再进入 shuffle，减少网络传输量，尤其在 reducer 数量多、数据倾斜不明显的时候，效果很直观。 - 最终落地数据使用列式存储：比如 Hive 表用 Parquet/ORC + Snappy。列式格式在扫描大表时能跳过无关列，减少 IO，并且配合谓词下推，效果远好于纯文本。
- 对于不可压缩的数据（图片、压缩过的视频等），别盲目开启压缩，反而浪费 CPU。
2.5 HDFS扩容与数据均衡：小心后台任务偷走你的带宽
集群扩容后，新节点默认没有任何数据，HDFS Balancer 会开始从旧节点复制数据到新节点。如果你不限制 Balancer 的带宽，它会占满整个集群的网络，正在跑的业务任务都会被拖慢。日常维护中遇到扩容后作业变慢，第一反应应该是去看有没有 Balancer 在后台运行。
控制方法很简单，设置 HDFS Balancer 带宽：
bash复制hdfs dfsadmin -setBalancerBandwidth 20971520
这条命令会把 Balancer 的最大带宽限制在 20MB/s。需要跑平衡时，尽量安排在业务低峰期，并且不要一次性把带宽调得太大。如果集群里同时有大量新数据写入，还可以配合 dfs.datanode.max.transfer.threads 控制 DataNode 的数据传输线程数，避免一个 DataNode 的线程资源被后台复制任务占满。扩容本身是为了提升性能，但要注意平衡过程对在线业务的冲击，否则扩容完业务反而变慢了，那就非常冤枉。
3. YARN和MapReduce的资源配置：从"一核有难九核围观"说起
3.1 谁都要面对的内存换算：Container、Heap 与物理内存
YARN 是一个资源调度框架，它把每台节点的 CPU、内存抽象成资源池，通过 Container 分配给具体的 map/reduce 任务。很多人看到 yarn.nodemanager.resource.memory-mb、mapreduce.map.memory.mb、mapreduce.map.java.opts 一堆参数就头疼，其实关键就一句话：Container 规定了进程允许使用的物理内存上限，而 java.opts 里的 -Xmx 只是堆内存的大小，两者之间必须留出足够的差值。
举个例子，一台 64GB 内存的 DataNode/NodeManager 节点，操作系统本身要占用几个 GB，DataNode 进程要几百 MB，NameNode 如果部署在同一节点上也需要内存，还要给 HDFS 页面缓存留一点空间。假设我们能给 YARN 的资源是 48GB，也就是 yarn.nodemanager.resource.memory-mb=49152。如果把每个 map Container 的内存 mapreduce.map.memory.mb 设置为 4GB，那么堆参数 mapreduce.map.java.opts 就不能也设 -Xmx4g，因为 JVM 除了堆还要使用 metaspace、线程栈、native 内存、DirectByteBuffer。堆设得和 Container 一样满，很容易在物理内存达到阈值后就被 NodeManager 判定超限杀掉。我通常会把 -Xmx 设为 Container 内存的 70%~80%，比如 Container 为 4GB，-Xmx3g 左右，留出的空间给 JVM overhead 和框架所需的 native 内存。
对应的配置文件片段如下：
xml复制<property>
<name>yarn.nodemanager.resource.memory-mb</name>
<value>49152</value>
</property>
<property>
<name>yarn.scheduler.maximum-allocation-mb</name>
<value>8192</value>
</property>
MapReduce 任务参数（mapred-site.xml）：
xml复制<property>
<name>mapreduce.map.memory.mb</name>
<value>4096</value>
</property>
<property>
<name>mapreduce.map.java.opts</name>
<value>-Xmx3072m -XX:+UseG1GC</value>
</property>
<property>
<name>mapreduce.reduce.memory.mb</name>
<value>8192</value>
</property>
<property>
<name>mapreduce.reduce.java.opts</name>
<value>-Xmx6144m -XX:+UseG1GC</value>
</property>
很多 JVM 老参数如 -XX:+UseConcMarkSweepGC 在新版 JDK 中已经不支持了，直接用 G1GC，然后观察 GC 日志，如果 Old GC 频繁且时间长，再考虑调整 Container 内存或任务并行度。这里要特别提醒：YARN 的总资源不是越大越好。如果 yarn.nodemanager.resource.memory-mb 设置超过了实际可用内存，系统的 swap 就会被触发，Hadoop 进程一旦发生 swap，性能会断崖式下降。让节点保留一定内存给文件系统缓存，对数据处理是有益的，HDFS 的读请求很多会命中页缓存，所以不要为了一时的高并发把节点榨干。
3.2 并行度到底设多少：map/reduce任务数不是越多越好
不少人的直觉是：集群有几百个核，那就把 map/reduce 任务数调到最大，让每个核都跑满。实际上任务数过多会导致两个问题：一是每个 task 的调度、JVM 启动、内存分配需要时间，如果一个 map 任务只跑几十秒而调度开销占了三分之一，整体效率非常差；二是任务数过多会让中间结果数量膨胀，shuffle 阶段的连接数也会变多，reduce 拉取数据的压力呈指数上升。
map 任务数不由 mapreduce.job.maps 直接设置，而是由输入分片数量和文件分布决定的。如果想控制 map 任务数量，需要控制 split 大小。增大 mapreduce.input.fileinputformat.split.maxsize 并不会让分片变大，我见过不少刚接触的人在这里搞反。想减少 map 数量，通常要么增大 HDFS block size，要么调整 mapreduce.input.fileinputformat.split.minsize 下限；反过来想增加并行度，就减小 split.maxsize，让单个文件被拆成更多 split。这个公式一定要弄清楚，不然会出现"参数改了没反应"的情况。
reduce 任务数倒是可以通过 mapreduce.job.reduces 直接指定。Reducer 数量我见过很多拍脑袋设置。一个粗暴的经验法则是 reducer 总并发不超过集群可用 Container 数的 1.5 倍到 2 倍，并且要避免单个 reducer 的输出产生过多小文件。如果 reducer 数太少，每个 reducer 处理的数据量过大，shuffle 阶段的单任务耗时很长；如果 reducer 数太多，shuffle copy 会产生大量并发连接，网络和 reducer 侧的内存都扛不住。可以先用默认的自动推断（-1）跑一次，再根据日志里的 reduce shuffle 耗时和数据总量微调。记住，调 reduce 数不是为了好看，是为了让每个 reducer 在合理时间内处理完数据，同时尽量让数据分布均匀。
3.3 Shuffle优化：Combiner、压缩、缓冲区缺一不可
MapReduce 任务性能的很大一部分隐藏在 shuffle 里。Map 端先处理数据，然后会把结果写到本地磁盘，再通知 reduce 去拉取。这个过程中有三次写磁盘、两次网络传输，任何一次都能成为瓶颈。
map 端最有效的优化是在写盘之前做一次本地合并，也就是 Combiner。Combiner 可以看作一个"局部 reduce"，它在 map 端执行一组 reduce 函数，对相同 key 的值先做一轮合并，大幅度减少写盘和网络传输的数据量。最常见的错误是没有检查 Combiner 函数是否满足交换律和结合律。比如求平均值，如果你在 Combiner 里也直接求平均值，那最终结果一定是错的。正确做法是先在 Combiner 里累计总和与计数，到真正 reduce 里再做除法。如果 Combiner 加错了，任务倒是快了，数据结果错了，那比慢更危险。
map 端缓冲区同样值得调整。mapreduce.task.io.sort.mb 控制 map 输出排序缓冲的大小，默认只有 100MB。如果 map 输出特别大，可以适当调大到 200MB 或 300MB，减少溢写（spill）次数。前面第 1 节提到过，当 Counter 里 Spilled Records 非常大时，就是要调大缓冲区或调整 Combiner 的信号。还要开启 mapreduce.map.output.compress=true 并用 Snappy，这会压缩写入本地磁盘的中间数据，减少磁盘 IO 和网络传输。压缩带来的 CPU 开销在多数场景下可以忽略不计，但磁盘和网络的收益却很明确。
reduce 端也有一组参数，比如 mapreduce.reduce.shuffle.parallelcopies 控制一次并发从多个 map task 拉取数据的线程数，默认是 5。如果节点数量多、map 数据量大，可以适当调高到 10 或 15，但也要注意过高的并发会对网络和 reducer 内存造成冲击。另一个有用的参数是 reduce 端最小完成比例：mapreduce.job.reduce.slowstart.completedmaps。默认是 0.05，也就是说 reduce 任务会过早启动，在 map 只完成 5% 时就开始等数据，白白占着 reduce 槽位。对于 map 阶段本来就很长的作业，可以改成 0.8 甚至 0.9，让 80% 的 map 完成后再启动 reduce，能避免 reduce 空等浪费资源。
3.4 数据倾斜与动态分区：把长尾任务削平
Hadoop 上最常见的性能故障不是整体慢，而是同一批任务里 99 个 reducer 都跑完了，有一个 reducer 还在慢慢处理。这种情况十有八九是数据倾斜：热点 key 的数据量远大于其他 key，导致默认的 hash 分区把所有同 key 数据分配到了同一个 reducer。
处理数据倾斜不要一上来就上复杂方案。先确认倾斜发生在哪个层面：如果倾斜的 key 有业务意义，比如某个热门城市的日志量特别大，可以做两阶段聚合。第一阶段给 key 加一个随机前缀，让热点 key 的数据分散到不同 map/reduce 中完成局部聚合；第二阶段去掉前缀，再对结果做一次全局聚合。这样虽然多了一轮任务，但每个 reducer 的负载会均匀很多。
如果倾斜是由于 key 本身分布不均匀，比如排序类的 TeraSort 场景，可以考虑自定义 Partitioner，通过抽样估算 key 的分布边界，把范围切得更均匀一些。不要只用默认的 hash，因为 hash 均匀分布只对取值空间均匀的 key 有效。能利用好 Combiner 和 Salting（加盐）技巧，是 Hadoop 性能调优里很加分的能力。
如果数据写的是 Hive 分区表，还要注意动态分区的数量。hive.exec.max.dynamic.partitions 如果设置过大，会产生几百上千个分区文件，每次任务写几十个小文件到 HDFS，很快就把小文件问题重新引回来。动态分区数量要和文件合并策略配合，不然一次优化刚完成，下个作业又把集群拖垮了。
4. 容易被忽略的磁盘、网络和操作系统底子：集群没精神，参数全是白扯
4.1 磁盘规划：最容易被忽略的慢盘陷阱
Hadoop 处理的是海量数据，数据最终都要落到磁盘上。如果底层的磁盘能力不行，再多的内存参数也是白搭。我判断一个集群的物理资源是否合理，最先看的就是数据节点的磁盘组合方式。
先说一个常见的误区：dfs.datanode.data.dir 可以配置多个目录，有人就在同一块物理盘上分了两个分区，把两个目录都填进去，以为这样就有两份磁盘 IO 能力。其实无论分多少个分区，底层还是同一块物理盘的磁头，并没有带来真正的并行能力。正确的做法是一块物理盘对应一个数据目录，配置多个目录时应选择不同的物理磁盘。使用机械盘时，数据盘最好用 RAID 0 或 JBOD 模式，不要为 Hadoop 数据盘做 RAID 5 或 RAID 10，因为 HDFS 本身已经通过副本机制做了冗余，底层再做校验会白白损失写盘性能。
同样是 DataNode，本地目录也很关键。yarn.nodemanager.local-dirs 存放的是 map task 的中间结果和 shuffle 数据。这个路径虽然临时，但读写频率非常高。如果条件允许，把 YARN 的本地目录放到 SSD 上，与 HDFS 数据盘分开，shuffle 性能会明显改善。我见过一个集群，DataNode 的数据盘和 YARN 的本地目录都在同一块机械盘上，跑大作业时磁盘 %util 直接到 100%，业务性能惨不忍睹。
磁盘文件系统挂载参数也要注意。数据盘建议以 noatime 方式挂载，避免写文件时额外更新访问时间戳；IO 调度器可以改成 deadline 或 none。对机械盘来说，deadline 能在高并发下保证读写有合理延迟；对 SSD 来说，用 none 或 noop 减少调度开销。修改调度器的示例命令：
bash复制echo deadline > /sys/block/sda/queue/scheduler
这是一次性设置，重启会失效，如果要在服务器上固化配置，建议写到 udev 规则或系统文档里。
4.2 网络与机架：shuffle吃宽带，别让跨机架流量拖死
Hadoop 里 DataNode 之间要复制副本，map 与 reduce 之间要 shuffle 数据。对典型的 shuffle-heavy 作业，网络很早就可能成为瓶颈，但大家最容易忽略的却也是网络。
先确认你的集群是不是万兆网络。HDFS 单节点顺序读写很容易突破千兆网卡上限，如果是 1Gbps 的网络，跑大型 MapReduce 时网络一定是瓶颈。另外不要以为集群在同一个机房就万事大吉，跨机架之间的汇聚带宽往往比机架内低很多。如果机架感知没有配好，NameNode 和 ResourceManager 就不知道网络拓扑，副本放置和任务调度可能大量跨越机架，让核心交换机变成瓶颈。
开启机架感知之后，还需要从 YARN 调度层配合。一般模式是先等任务分配到数据本地节点，如果没有可用容器，才考虑同机架节点，最后才分配跨机架节点。但如果你设置了 yarn.scheduler.capacity.root.default.node-locality-delay（Capacity Scheduler）或类似参数，它可以控制调度器等待本地节点的时间。这个值不宜太大，否则 map 任务会一直等待而浪费整体时间；也不宜为 0，否则很多任务立刻被分配到非本地节点，数据本地率会很低。通常可以从节点数的一半开始试验，观察 Web UI 上的 Data Local 比例。
shuffle 超时也是网络不稳定的常见问题。mapreduce.reduce.shuffle.read.timeout 默认是 180000 毫秒，当节点负载高或网络抖动时，reduce 拉取 map 输出可能暂时阻塞，超过这个时间任务会被判定失败。如果集群偶发超时但整体网络不差，可以适当调大这个超时时间，比如 300000，避免无谓的任务重试。当然，调大超时是治标，根本还是要检查网络抖动来源和磁盘 IO 为什么慢。
4.3 操作系统层面：越基础越容易藏问题
很多 Hadoop 性能问题最终都会在操作系统层面原形毕露，但这一层也最容易被忽略。
首先是文件句柄数。DataNode、NodeManager 这类进程在跑高并发任务时会打开大量文件，系统默认的 ulimit -n 可能是 1024 或 4096，根本不够用。我遇到过一个诡异的问题：任务跑一段时间后，DataNode 开始报 "Too many open files"，整个集群的读写吞吐大幅下降，重启之后又恢复正常。排查到最后就是文件句柄数上限太低。需要在 /etc/security/limits.conf 中把 hadoop 用户的 nofile 设到 65535 以上，并确保持久化生效。
其次是内存分配策略。Hadoop 是内存大户，尤其 JVM 堆外内存和操作系统 page cache 会相互竞争。建议把 vm.swappiness 调小，比如设为 10 甚至 1，让系统尽量避免把 Hadoop 进程换到 swap。另外，透明大页（THP）在 Hadoop 场景下经常导致延迟波动，因为它会在内存分配时引入不可预期的停顿。核心的 Hadoop 组件节点可以关闭透明大页：
bash复制echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
还有一个细节：Hadoop native 库。Snappy、ZStandard 这些压缩库如果没加载 native 版本，会退化为 JDK 内置实现或直接不支持，压缩和解压性能差距可能在一个数量级。启动时日志里会有 "Unable to load native-hadoop library" 的警告，但很多人没在意。确认 $HADOOP_HOME/lib/native 里有对应库文件，并且 LD_LIBRARY_PATH 或 java.library.path 配置正确，这是低成本高收益的检查项。
最后，NameNode 自身的 JVM heap 也值得专项调优。小文件一多，NameNode 的堆内存就会吃紧，GC 时间变长，整个元数据服务变慢。如果开启了 HA，JournalNode 所在磁盘也不能太慢，因为写 edit log 的延迟会拖慢 NameNode 响应。这些看着和"业务性能优化"不直接相关，但恰恰是很多集群在某个量级之后突然变慢的元凶。
5. 用一套压测流程验证优化效果：别再说"改完感觉快了"
5.1 标准压测工具怎么用，才能拿到有效数据
任何参数改动，如果只靠"感觉快了"来验证，很难说服自己，更别说说服团队。我做性能调优时，习惯用 Hadoop 自带的基准测试工具做前后对比，其中两个最常用：TestDFSIO 和 TeraSort。
TestDFSIO 专门压 HDFS 的读写吞吐。命令大概是：
bash复制hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-*-tests.jar \
TestDFSIO -write -nrFiles 64 -fileSize 1000
它会生成 64 个文件、每个 1GB，共 64GB 的数据来测试写入吞吐，然后再用 -read 参数测试读取吞吐。跑完会输出吞吐率（MB/s）和平均 IO 速率。这个测试适合在做完 HDFS 相关调整后验证，比如确认开启了短路读、调整了 block size、优化了磁盘目录之后，吞吐是否真的有提升。测试结束后要记得用 -clean 清理产生的数据，避免压测数据占用集群空间。
TeraSort 是更接近真实业务全链路的测试，因为它同时压到了 HDFS、MapReduce shuffle、网络、排序算法。流程是先用 teragen 生成数据，再用 terasort 排序，最后用 teravalidate 验证：
bash复制hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar \
teragen -Dmapreduce.job.maps=200 1000000000 /bench/terasort/input
hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar \
terasort /bench/terasort/input /bench/terasort/output
hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar \
teravalidate -Dmapreduce.job.maps=200 /bench/terasort/output /bench/terasort/validate
这里 1000000000 是 10 亿条记录，差不多百 GB 级，可以用更小的量级先测。跑 TeraSort 时我会同时记录 Web UI 里的 map 耗时、reduce 耗时、shuffle 耗时以及每阶段的 GC 时间。每次压测跑三遍，取中间值，因为 JVM 热度和系统缓存会对结果产生影响，只跑一次很难代表真实水平。
5.2 一个真实案例：我调了一轮参数，作业反而慢了3倍
有一次做数仓 ETL 提速，原任务大约 2 小时跑完，Log 显示大量 reducer 空转。我当时的判断是 reducer 数不足，导致每个 reducer 数据量太大。于是把 mapreduce.job.reduces 从 100 调到了 400，想通过增加并行度来减少单 reducer 压力。结果是任务跑了整整 5 个多小时，比原来更慢。打开 Counter 一看，400 个 reducer 产生了 400 份输出文件，其中大部分都很小；shuffle 阶段从 100 个 map 端拉数据变成了 400 个 reducer 并行拉取，连接数暴增，网络和磁盘同时被打满，部分 reducer 因为频繁 GC 开始拖慢整体进度。
后来我把 reducer 数调回 100，但开启了 map 端中间压缩，并把 mapreduce.job.reduce.slowstart.completedmaps 从默认值 0.05 调到了 0.8。结果是 map 阶段已经完成了大半，reduce 才启动去拉数据，不在那边空等占资源；加上中间数据压缩让 shuffle 网络流量降了 40%，最终作业跑到 1 小时 20 分钟。这个案例让我彻底认可了两个原则：一次只改一个变量，并且每次都要跑压测验证。如果当时我把 reducer 数量和压缩同时改，最后很难定位到底是谁起了作用。
还有一个经常出问题的参数是 mapreduce.input.fileinputformat.split.maxsize。有人为了让 map 任务并行度更高，把这个值调得很小，比如 16MB，结果一个 100GB 的文件被拆成了几千个 split，每个 map 只处理 16MB，还没有算 JVM 启动时间就已经结束了。这种情况下，调度的开销远大于计算本身，任务反而慢得离谱。并行度不是越大越好，而是在资源允许范围内找到最优值。判断的方法很简单：看 map 任务的平均执行时间，如果大多数任务在 1 分钟以内，说明任务被切得太碎了。
5.3 建立优化前后基线，不然你的调优永远无法复制
团队协作时更怕的是"这个人改完跑了，下个季度再来一遍"。我强烈建议针对自己的集群和主要作业建立一张基线记录表，每次优化只改一个变量，然后把所有条件记录清楚：
| 作业 | 数据量 | 关键参数（改前） | 关键参数（改后） | 耗时改前 | 耗时改后 | map任务数 | reduce任务数 | GC时间 |
|---|---|---|---|---|---|---|---|---|
| ETL A | 1.2TB | reduces=100 | reduces=180 | 2h05m | 1h30m | 830 | 180 | - |
记录的时候，最好把当时集群的并发任务数、测试时间和是否清空了 page cache 也写进去。同样一个作业，白天业务高峰跑和深夜跑，耗时一定不同。如果没法做到完全控制变量，至少要在同一时间段、同一负载水平下做 A/B 对比。没有基线的调优，最后都会退化成玄学。
我个人始终保留一个习惯：任何生产参数变更之前，先把修改项统一备份到一个变更记录里，并标注这次修改想解决的指标是什么。如果一个参数改完没有效果，立即回滚而不是叠加另一个参数。Hadoop 性能调优更像一门实验科学，瓶颈定位、参数假设、压测验证、记录复盘，这几步少了哪一步都不行。经过这一轮从 HDFS 到 YARN、再到操作系统和压测的整理，希望你在下一次面对"集群很慢"的时候，能先问一句：瓶颈到底在哪，再动手改参数。