1. 从一个真实的数据处理困境说起几年前我接手过一个日志分析的需求原始数据是大约 40GB 的文本文件每行一条记录需要做的是按业务字段分组统计、排序、取 Top N然后输出成报表。当时第一反应是用 Python 写个脚本读文件、用字典累加、最后排序输出。逻辑上完全没问题但实际跑起来就傻眼了——单机内存根本扛不住全量字典改成边读边写临时文件之后磁盘 IO 又成了瓶颈跑完一轮要将近两个小时而且中间一旦出错就得从头再来。这个场景其实就是 MapReduce 最经典的应用土壤数据量大到单机处理吃力但计算逻辑本身可以拆分成互相独立的子任务。后来我把这套逻辑迁移到了 Hadoop 的 MapReduce 框架上用一台主节点加三台从节点的伪分布式集群跑同样的数据量耗时压到了二十分钟出头而且中途某个节点挂掉任务能自动重试不用我盯着。这篇内容就是围绕这个实践案例展开的。我会把 MapReduce 的核心设计思路、关键参数、完整实操流程、以及我踩过的那些坑尽量掰开揉碎讲清楚。不管你是刚接触分布式计算的学生还是需要把离线批处理任务落到生产环境的工程师应该都能从里面找到能直接抄作业的部分。核心关键词就三个Hadoop、MapReduce、分布式计算全文围绕它们展开不跑偏。2. MapReduce 到底解决了什么问题2.1 单机计算的三个天花板在讲 MapReduce 之前得先搞清楚它到底在跟什么较劲。单机处理大规模数据绕不开三个硬约束。第一个是内存天花板。像分组统计这种操作最直观的做法是维护一个哈希表key 是分组字段value 是累加值。数据量小的时候没问题但数据量一上来哈希表膨胀JVM 堆内存直接爆掉或者频繁 Full GC 把 CPU 拖垮。你可能说可以调大堆内存但单机内存终归有上限40GB 数据对应的中间状态可能远超物理内存。第二个是磁盘 IO 天花板。内存放不下就得落盘落盘就有读写放大。单块机械硬盘的顺序读写大概在 100-200MB/s随机读写更惨。如果计算逻辑需要反复扫描数据IO 就会成为绝对瓶颈CPU 反而闲着。第三个是单点故障天花板。单机跑长任务最怕的就是跑到 90% 的时候进程崩了或者机器重启之前所有计算成果全部归零。没有检查点机制的话只能从头再来时间成本极高。MapReduce 的设计哲学本质上就是针对这三个天花板给出的工程答案用数据分片解决内存问题用本地化计算减少 IO用任务重试和推测执行解决单点故障。2.2 分而治之MapReduce 的核心抽象MapReduce 把整个计算过程抽象成两个阶段Map 阶段和 Reduce 阶段。这个抽象看起来简单但它的精妙之处在于把做什么和怎么做彻底分离了。你只需要写两个函数Map 函数负责把一条输入记录转换成若干键值对Reduce 函数负责把相同 key 的 value 集合聚合成结果。至于数据怎么切分、任务怎么调度、中间结果怎么传输、失败怎么重试全部由框架接管。这就好比你去餐厅点菜你只管说要吃什么至于厨房怎么备料、几个厨师分工、火候怎么控制那是厨房的事。用生活化的类比假设你要统计一个图书馆里所有书的字数总和。单机做法是你一个人一本一本翻翻完累加。MapReduce 做法是把图书馆分成若干个区域每个区域派一个人去统计自己区域的字数Map然后所有人把结果汇总到一个总账本上相加Reduce。区域之间互不干扰某个人请假了换个人接着统计就行。这个类比里有个关键点Map 任务之间是独立的Reduce 任务之间也是独立的只有 Map 到 Reduce 之间存在数据依赖。这个依赖就是通过 Shuffle 阶段来完成的也是整个框架里最复杂、最容易出问题的地方。2.3 为什么是 Hadoop 而不是别的市面上做分布式计算的框架不少Spark、Flink 在迭代计算和流处理上确实比 MapReduce 快很多。但 MapReduce 至今仍然是很多离线批处理场景的默认选择原因有几个。一是成熟稳定。MapReduce 从 2006 年左右就开始在大型集群上跑经过十几年生产环境打磨各种边界情况都处理过了。它的容错机制、资源调度、数据本地化策略都是经过验证的。二是磁盘友好。Spark 基于内存计算迭代快但对内存要求高。MapReduce 每个阶段都落盘虽然慢但胜在稳定数据量再大也不容易 OOM。对于那种跑一次要几个小时、但结果很重要的离线任务稳定性比速度更重要。三是生态绑定。Hadoop 生态里的 HDFS、YARN、Hive、HBase 都跟 MapReduce 深度集成。很多数仓任务用 Hive SQL 写底层自动翻译成 MapReduce 作业。你不需要直接写 MapReduce 代码但理解它的原理对调优和排查问题至关重要。提示如果你的任务是迭代式的机器学习训练或者要求秒级延迟的流处理MapReduce 不是好选择。但如果是 T1 的离线报表、日志清洗、大规模 ETLMapReduce 依然是稳妥的方案。3. 案例拆解一个日志分组统计任务的完整设计3.1 需求定义与数据特征我拿前面提到的日志分析场景来具体展开。原始数据是应用日志每行格式大致如下2024-01-15 10:23:45 | app-001 | user-8823 | page-view | 120 2024-01-15 10:23:46 | app-002 | user-1120 | click | 45 2024-01-15 10:23:47 | app-001 | user-8823 | purchase | 299字段依次是时间戳、应用 ID、用户 ID、行为类型、耗时毫秒。需求是按应用 ID 分组统计每个应用的总请求数和平均耗时并按总请求数降序输出。数据特征很关键总量约 40GB文件数约 200 个单文件平均 200MB。这个规模用单机处理吃力但拆成 MapReduce 任务后每个 Map 任务处理一个或几个文件内存压力就分散了。3.2 Map 与 Reduce 的职责划分设计 MapReduce 任务第一步永远是确定 key 是什么。因为 key 决定了数据怎么分组、怎么进入同一个 Reduce。这个需求里分组字段是应用 ID所以 Map 输出的 key 就是应用 ID。value 需要携带两个信息这条记录的请求计数固定为 1和耗时值。所以 Map 输出形如app-001, (1, 120)。Reduce 阶段收到某个应用 ID 对应的所有(1, 耗时)对做两件事累加计数得到总请求数累加耗时除以计数得到平均耗时。输出形如app-001, 总请求数15230, 平均耗时87.3。这里有个设计决策值得说明为什么不在 Map 阶段就做局部聚合。因为 Map 任务处理的是单个文件同一个应用 ID 在同一个文件里可能出现多次如果在 Map 端先做一次局部累加输出给 Reduce 的数据量会大幅减少。这就是所谓的 Combiner后面会详细讲。3.3 数据流全景整个作业的数据流大致是这样的输入分片HDFS 上的 200 个文件被切成若干个 InputSplit每个 Split 对应一个 Map 任务。Map 阶段每个 Map 任务读取自己的 Split逐行解析输出appId, (1, cost)。Combiner 阶段可选在 Map 输出端做局部聚合减少网络传输。Shuffle 阶段框架按 key 的哈希值把 Map 输出分区相同 key 的数据汇聚到同一个 Reduce 任务。Reduce 阶段对每个 key 的 value 列表做聚合计算输出结果。输出阶段结果写入 HDFS每个 Reduce 任务产生一个结果文件。这个流程里Shuffle 是最耗时的环节因为它涉及大量的网络传输和磁盘读写。理解 Shuffle 的机制是调优的关键。4. 核心组件与关键参数详解4.1 InputFormat 与数据分片策略InputFormat 决定了数据怎么读、怎么切分。默认的TextInputFormat按行读取适合文本日志。它有个重要特性按文件切分但会保证不把一行拆到两个 Split 里。具体做法是切分点如果落在行中间会往后找到第一个换行符把这一行完整留给下一个 Split。这个特性带来一个实际问题如果某个文件特别大而它的行又特别长可能导致 Split 大小不均匀。我遇到过一种情况日志里有超长的 JSON 行单行几 MB结果某个 Map 任务处理的数据量远超预期成了长尾任务。解决办法是调整mapreduce.input.fileinputformat.split.maxsize限制单个 Split 的最大字节数。另一个参数是mapreduce.input.fileinputformat.split.minsize控制最小 Split 大小。默认情况下Split 大小等于 HDFS 块大小通常 128MB。如果文件数很多但每个都很小会产生大量 Map 任务每个任务启动开销占比过高。这时候可以把 minsize 调大让一个 Map 任务处理多个小文件。4.2 Partitioner决定数据去哪个 ReducePartitioner 负责把 Map 输出的 key 分配到不同的 Reduce 任务。默认的HashPartitioner用key.hashCode() % numReduceTasks来计算分区。这个默认策略在大多数场景下够用但有个坑如果 key 分布不均匀会导致数据倾斜。比如某个应用 ID 的日志量是其他应用的几十倍那么它对应的 Reduce 任务就会成为瓶颈其他 Reduce 早早跑完就等它一个。解决数据倾斜有几种思路。一是自定义 Partitioner把热点 key 打散到多个 Reduce然后在后续阶段再合并。二是加随机前缀让同一个 key 的不同记录进入不同 Reduce做两阶段聚合。三是直接调大 Reduce 数量虽然不能根本解决倾斜但能缓解单点压力。4.3 CombinerMap 端的局部聚合Combiner 本质上是一个运行在 Map 端的迷你 Reduce。它的作用是在数据进入 Shuffle 之前先做一次局部聚合减少网络传输量。还是用日志统计的例子。假设某个 Map 任务处理了 10 万条app-001的记录如果不做 Combiner这 10 万个app-001, (1, cost)都要通过网络传给 Reduce。如果加了 CombinerMap 端先累加成app-001, (100000, 总耗时)网络传输量直接降到一条。但 Combiner 有个前提它的计算逻辑必须满足交换律和结合律。求和、求最大值、计数都满足但求平均值不满足。因为平均值不能简单地对局部平均值再求平均必须保留分子分母。所以我在代码里 Combiner 输出的是(count, sum)而不是(count, avg)最终在 Reduce 里才做除法。注意Combiner 不保证一定被执行框架可能调用零次、一次或多次。所以 Reduce 端的逻辑必须能正确处理未经 Combiner 的原始数据不能依赖 Combiner 一定生效。4.4 关键参数速查表下面这张表是我在实际调优中经常调整的参数列出来方便对照。参数名默认值作用调优建议mapreduce.input.fileinputformat.split.maxsizeLong.MAX_VALUE单个 Split 最大字节数有超长行时调小避免长尾mapreduce.input.fileinputformat.split.minsize1单个 Split 最小字节数小文件多时调大减少 Map 数mapreduce.job.reduces1Reduce 任务数量根据数据量和集群规模调整mapreduce.map.memory.mb1024单个 Map 容器内存逻辑复杂时调大mapreduce.reduce.memory.mb1024单个 Reduce 容器内存聚合数据大时调大mapreduce.task.io.sort.mb100Map 端排序缓冲区大小数据量大时调大减少溢写mapreduce.reduce.shuffle.parallelcopies5Reduce 拉取 Map 输出的并行度网络好时调大这些参数没有万能值需要根据实际数据特征和集群资源来试。我的经验是先跑一轮看 Counter 里的指标比如溢写次数、Shuffle 数据量、各阶段耗时再针对性调整。5. 完整实操从环境准备到作业提交5.1 环境准备与集群规划我用的是一套伪分布式环境做验证生产环境是 1 主 3 从。伪分布式的好处是能完整跑通流程又不需要多台机器。核心组件是 HDFS 和 YARNMapReduce 作业跑在 YARN 上。环境准备的关键步骤安装 JDK配置JAVA_HOME。Hadoop 对 JDK 版本有要求建议用 JDK 8 或 11版本太新可能有兼容问题。配置core-site.xml指定 HDFS 的地址。配置hdfs-site.xml设置副本数。伪分布式下副本数设为 1生产环境通常 3。配置yarn-site.xml指定 ResourceManager 地址和 NodeManager 资源。配置mapred-site.xml指定 MapReduce 运行在 YARN 上。格式化 HDFS启动 HDFS 和 YARN。这里有个容易忽略的点mapred-site.xml里的mapreduce.framework.name必须设为yarn否则作业会跑在本地模式你以为是分布式其实还是单机。5.2 代码实现Mapper 与 Reducer下面是我实际用的代码骨架用 Java 写的。虽然现在很多人用 Python 或 Scala但 Java 版本最能体现 MapReduce 的原生机制。Mapper 类public class LogMapper extends MapperLongWritable, Text, Text, CountSumWritable { private Text appId new Text(); private CountSumWritable outValue new CountSumWritable(); Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { String line value.toString(); String[] fields line.split(\\|); if (fields.length 5) { return; // 脏数据跳过 } String app fields[1].trim(); long cost Long.parseLong(fields[4].trim()); appId.set(app); outValue.set(1, cost); context.write(appId, outValue); } }这里我自定义了一个CountSumWritable包含 count 和 sum 两个字段实现 Writable 接口。为什么不直接用LongWritable传耗时、然后在 Reduce 里计数因为那样 Reduce 收到的 value 列表里只有耗时计数需要额外遍历一次。用自定义 Writable 把计数和耗时打包一次遍历就能同时累加两个值。Reducer 类public class LogReducer extends ReducerText, CountSumWritable, Text, Text { Override protected void reduce(Text key, IterableCountSumWritable values, Context context) throws IOException, InterruptedException { long totalCount 0; long totalCost 0; for (CountSumWritable v : values) { totalCount v.getCount(); totalCost v.getSum(); } double avg totalCount 0 ? 0 : (double) totalCost / totalCount; String result String.format(requests%d, avgCost%.2f, totalCount, avg); context.write(key, new Text(result)); } }Combiner 类跟 Reducer 逻辑几乎一样只是输出类型要跟 Map 输出一致不能直接输出最终字符串。所以 Combiner 输出的是CountSumWritable而不是Text。5.3 驱动类与作业提交驱动类负责组装作业配置public class LogJobDriver { public static void main(String[] args) throws Exception { Configuration conf new Configuration(); Job job Job.getInstance(conf, log-stat); job.setJarByClass(LogJobDriver.class); job.setMapperClass(LogMapper.class); job.setCombinerClass(LogCombiner.class); job.setReducerClass(LogReducer.class); job.setMapOutputKeyClass(Text.class); job.setMapOutputValueClass(CountSumWritable.class); job.setOutputKeyClass(Text.class); job.setOutputValueClass(Text.class); job.setNumReduceTasks(4); FileInputFormat.addInputPath(job, new Path(args[0])); FileOutputFormat.setOutputPath(job, new Path(args[1])); System.exit(job.waitForCompletion(true) ? 0 : 1); } }几个关键点说明。setCombinerClass指定 Combiner注意它的输出类型必须跟 Map 输出类型一致。setNumReduceTasks(4)设置 Reduce 数量这个值需要根据数据量来定。我一般按每个 Reduce 处理 1-2GB 数据来估算40GB 数据配 4 个 Reduce 差不多。提交作业的命令hadoop jar log-stat.jar com.example.LogJobDriver \ /input/logs/2024-01-15 \ /output/log-stat-2024-01-15输出目录必须不存在否则作业会报错。这是 Hadoop 的一个保护机制防止误覆盖已有结果。5.4 结果验证与性能观察作业跑完后用hdfs dfs -cat查看输出。每个 Reduce 任务产生一个part-r-00000之类的文件。我一般会抽样几条验证逻辑正确性再跟单机小数据集的结果做对比。性能观察主要看几个指标Map 任务的平均耗时、Reduce 任务的平均耗时、Shuffle 的数据量、溢写次数。这些在 JobHistory 页面或者 Counter 里都能看到。如果发现某个 Reduce 明显比其他慢基本就是数据倾斜需要针对性处理。6. 常见问题与排查技巧实录6.1 数据倾斜最头疼的问题数据倾斜的表现是大部分 Reduce 任务几分钟就跑完了但有一两个 Reduce 卡在那里几十分钟甚至更久。根本原因是某个 key 对应的数据量远超其他 key。排查方法看 Counter 里各个 Reduce 的输入记录数如果差异悬殊就是倾斜。我遇到过一次某个应用 ID 的日志量占了总量的 60%那个 Reduce 处理了 24GB 数据其他三个加起来才 16GB。解决思路有几种。最简单的是加随机前缀在 Map 输出 key 的时候给热点 key 拼一个随机数后缀比如app-001_0到app-001_9这样数据就分散到 10 个 Reduce 了。然后在下一个作业里去掉后缀再聚合。代价是要跑两轮作业。另一种是自定义 Partitioner把热点 key 单独识别出来分配到多个 Reduce。但这种方法需要提前知道哪些是热点 key不够通用。还有一种思路是调大 Reduce 数量让每个 Reduce 处理的数据量都变小虽然倾斜依然存在但单点压力没那么大。这个方法治标不治本但胜在简单。6.2 内存溢出Map 和 Reduce 端的 OOMOOM 通常发生在两个地方。一是 Map 端的排序缓冲区如果mapreduce.task.io.sort.mb设得太小溢写频繁但一般不会 OOM。真正容易 OOM 的是 Reduce 端因为 Reduce 需要把某个 key 的所有 value 加载到内存里遍历。如果某个 key 的 value 列表特别大Reduce 内存扛不住就会 OOM。解决办法是调大mapreduce.reduce.memory.mb或者用二次排序、分组合并等技巧减少单次加载的数据量。我踩过的一个坑是Reduce 里把 value 列表转成了 ArrayList 再遍历结果内存翻倍。后来改成直接遍历 Iterable不额外存储内存占用降了一半。Iterable 是流式读取的不要轻易转成集合。6.3 任务卡在 Shuffle 阶段Shuffle 阶段卡住常见原因是网络带宽不足或者 Reduce 拉取并行度太低。可以调大mapreduce.reduce.shuffle.parallelcopies默认是 5网络好的话可以调到 10 甚至 20。另一个原因是 Map 输出太大网络传输成了瓶颈。这时候 Combiner 就派上用场了。我做过对比加上 Combiner 之后Shuffle 数据量从 12GB 降到了 800MB作业总耗时减少了 40%。还有一种情况是磁盘 IO 瓶颈。Map 端的溢写和 Reduce 端的合并都涉及大量磁盘读写。如果用的是机械硬盘可以考虑把中间目录配到 SSD 上通过mapreduce.cluster.local.dir指定多个磁盘目录让 IO 并行起来。6.4 常见问题速查表问题现象可能原因排查方法解决思路个别 Reduce 特别慢数据倾斜看各 Reduce 输入记录数加随机前缀、自定义 PartitionerReduce OOM单 key value 过多看 Reduce 内存日志调大内存、避免转集合Shuffle 卡住网络或磁盘瓶颈看 Shuffle 阶段耗时加 Combiner、调并行度Map 任务数过多小文件太多看 Map 任务总数调大 minsize、合并小文件作业跑在本地模式配置未生效看作业追踪 URL检查 mapred-site.xml输出目录已存在重复提交看报错信息删除或换输出路径6.5 几个容易被忽略的实操心得第一个心得Map 输出 key 尽量用 Text 而不是自定义对象。Text 的 hashCode 实现经过优化分布比较均匀。自定义对象的 hashCode 如果写不好容易导致分区不均。第二个心得Reduce 数量不要设成 1。默认值是 1很多人忘了改结果所有数据汇聚到一个 Reduce完全丧失了分布式并行的优势。但也不要设太多每个 Reduce 任务都有启动开销数量太多反而慢。经验值是每个 Reduce 处理 1-2GB 数据。第三个心得善用 Counter 做调试。在 Map 或 Reduce 里用context.getCounter(group, name).increment(1)埋点作业跑完后在 Counter 里能看到统计值。这比打日志方便而且不影响性能。第四个心得本地模式先验证逻辑。在提交到集群之前用本地模式跑一个小数据集确认 Map 和 Reduce 逻辑正确。本地模式不需要 HDFS 和 YARN直接在 IDE 里就能跑调试效率高很多。配置方法是在Configuration里设mapreduce.framework.name为local输入输出用本地文件路径。7. 性能调优的几个实战方向7.1 数据本地化让计算靠近数据Hadoop 的核心优化之一就是数据本地化尽量把 Map 任务调度到数据所在的节点上避免跨网络读取。如果做不到同节点退而求其次同机架。查看数据本地化率的方法是看 Counter 里的Data-local map tasks、Rack-local map tasks和Off-switch map tasks。理想情况下Data-local 应该占绝大多数。如果 Off-switch 很多说明调度有问题可能是集群资源紧张或者数据分布不均。提升本地化率的办法一是保证 HDFS 块大小和 Split 大小匹配二是避免在作业运行时大量写入新数据导致块分布变化三是合理设置集群资源别让节点过载。7.2 压缩减少 IO 和网络传输MapReduce 的中间数据和最终输出都可以压缩。压缩能显著减少磁盘 IO 和网络传输代价是额外的 CPU 开销。在 CPU 不是瓶颈的场景下压缩几乎总是划算的。Map 输出压缩用mapreduce.map.output.compress开启编码器选SnappyCodec它在压缩率和速度之间平衡得比较好。最终输出压缩用FileOutputFormat.setCompressOutput设置如果下游还要继续处理选 Splittable 的压缩格式比如BZip2Codec否则下游无法并行读取。我实测过开启 Map 输出压缩后Shuffle 数据量减少 60% 以上作业总耗时降低约 25%。这个收益在数据量大时尤其明显。7.3 JVM 重用减少启动开销每个 Map 或 Reduce 任务默认会启动一个新的 JVM任务结束后 JVM 销毁。如果任务本身很短JVM 启动和销毁的开销占比就会很高。通过mapreduce.job.jvm.numtasks可以设置一个 JVM 跑多少个任务默认是 1。调大这个值比如设成 10就能让 JVM 复用减少启动开销。但要注意JVM 重用会累积内存碎片如果任务本身内存占用大可能导致后续任务 OOM。所以这个值要结合任务特征来定短任务可以设大长任务建议保持默认。7.4 推测执行应对慢节点集群里难免有节点性能差或者负载高导致个别任务跑得特别慢。推测执行机制会检测这种慢任务在另一个节点上启动一个相同的备份任务谁先完成就用谁的结果。开启推测执行的参数是mapreduce.map.speculative和mapreduce.reduce.speculative默认都是 true。但在某些场景下要关掉比如任务有副作用写外部数据库重复执行会导致数据重复或者集群资源紧张备份任务会挤占正常任务的资源。我遇到过一次推测执行帮倒忙的情况Reduce 任务本身要写 HBase推测执行导致同一条数据被写了两次。后来把mapreduce.reduce.speculative设为 false 才解决。所以这个机制不是无脑开要看任务性质。8. 从 MapReduce 到更现代的框架MapReduce 的编程模型虽然简单但写一个完整的作业需要 Mapper、Reducer、Driver 三个类还要处理序列化、分区、排序等细节开发效率确实不高。后来 Hive 出现了用 SQL 描述逻辑底层自动生成 MapReduce 作业大大降低了门槛。再后来 Spark 用 RDD 和 DataFrame 抽象把中间结果放在内存里迭代计算快了一个数量级。但我想说的是理解 MapReduce 依然是理解分布式计算的基石。Spark 的 Shuffle 机制、Flink 的算子链、甚至很多流处理框架的窗口聚合底层思想都能追溯到 MapReduce 的 Map-Shuffle-Reduce 三段式。你把 MapReduce 吃透了再看其他框架会发现很多概念是相通的。而且在实际生产环境里MapReduce 并没有被完全取代。很多老系统的离线任务还在跑 MapReduce维护和调优的需求一直存在。Hive 的底层执行引擎虽然可以切到 Tez 或 Spark但默认还是 MapReduce。所以这项技能不过时只是应用场景更聚焦在离线批处理上了。9. 我个人在实际操作中的几点体会跑了几十个 MapReduce 作业之后我最大的体会是调优的本质是找到瓶颈而不是盲目调参数。很多人一上来就把内存调大、Reduce 数量调多结果可能适得其反。正确的做法是先跑一轮看 Counter 和日志定位到到底是 CPU 瓶颈、内存瓶颈、IO 瓶颈还是网络瓶颈再针对性调整。第二个体会是数据特征决定一切。同样一个作业数据分布均匀和不均匀调优策略完全不同。所以在设计阶段就要对数据有足够的了解key 的分布、记录的平均大小、脏数据的比例这些信息直接影响你的参数选择。第三个体会是小步验证快速迭代。不要一次性写完所有逻辑就提交到集群跑全量数据。先用小数据集在本地模式验证逻辑再用部分数据在集群上验证性能最后才跑全量。这样每次出问题都能快速定位不至于浪费几个小时等一个注定失败的作业。最后分享一个实用小技巧如果你不确定 Reduce 数量设多少合适可以先设一个较大的值比如 10跑完后看每个 Reduce 的输出大小。如果大部分 Reduce 输出都很小说明 Reduce 数量偏多可以适当减少如果个别 Reduce 输出特别大说明有倾斜需要先处理倾斜再调数量。这个试错过程跑一两次就能找到比较合适的值。