企业官网建设流程全解析

1. MapReduce核心思想：为什么说是“分而治之”的大规模计算范式

1.1 从一个实际问题出发：处理上亿条日志里的关键词统计

很多人第一次接触MapReduce，都是从“统计单词出现次数”这个经典例子开始的。但真正让我理解MapReduce价值的，是一次实际的日志分析需求：线上服务每天产生大约3亿条访问日志，每条日志里包含用户行为、请求路径、状态码等信息。老板的需求很朴素——把这一天的日志按请求路径聚合，统计每个路径的访问量和平均响应时间。

如果日志量是几十万条，用Shell脚本或者Python单机处理，几秒钟就出结果了。但3亿条，单机处理非常吃力——内存扛不住，磁盘IO也扛不住，跑一个统计任务可能要几个小时，而且中间一旦机器内存爆掉，整个任务就白跑了。这时候就面临一个选择：要么花钱买更大的服务器，要么换一种能横向扩展的计算框架。买更大服务器这件事有明显的“天花板”，不仅是成本问题，单台机器的CPU核数、内存插槽、磁盘通道都是有限制的。这也是MapReduce这类分布式计算框架存在的根本原因：与其让一台机器累死，不如让一百台机器各干一点活。

MapReduce的本质，就是把这个“各干一点活”的过程规范化、框架化。它不像你用Python手写多线程、手动分片、手动合并结果那样“自由”，但它提供了一套严谨的约定：你只需要写两个函数——map和reduce——剩下的分布式调度、数据分发、故障重试、结果聚合，全部由框架帮你完成。

1.2 MapReduce的“分”与“合”：Map阶段和Reduce阶段

“MapReduce”这个名字本身就揭示了它的全部秘密。Map（映射）负责“分”，Reduce（归约）负责“合”。

先说Map阶段。输入数据被框架自动切分成若干个分片（split），每个分片由一个Map任务处理。这里注意一个细节：分片的大小是可以配置的，默认情况下和HDFS的块大小对齐（通常是128MB或256MB）。每个Map任务读入分片中的数据，逐条调用你写的map()函数，把输入记录转换成中间输出的Key-Value对。

举例来说，如果你要统计单词频率，一条输入“hello world hello”会被map()函数拆成三个键值对：(hello, 1)、(world, 1)、(hello, 1)。如果输入是日志，map()函数可以解析出请求路径，输出(path, 1)这样的键值对，或者输出(path, response_time)以便后续算平均值。

再说Reduce阶段。Map阶段产出的中间结果不会直接写回HDFS，而是先经过一个极其重要的“洗牌”过程（Shuffle），将相同Key的键值对自动合并到一起，形成一个(Key, [value1, value2, ...])的列表，再交给Reduce任务处理。reduce()函数拿到这个列表后，做最终的聚合计算。还是拿单词统计举例，Reduce端拿到(hello, [1,1,1])，把所有1加起来就是hello的出现次数。

这个模型的设计巧妙之处在于，Map和Reduce之间是松耦合的。Map任务的输出只要符合Key-Value格式，Reduce任务就能按Key聚合，至于中间数据如何传输、如何排序、如何分组，框架层面已经做了标准实现。你不需要关心“哪台机器跑了哪个Map任务”“中间数据存到哪里”，这些全部是透明的。

1.3 适合什么场景，不适合什么场景

在深入学习MapReduce之前，先搞清楚边界，否则容易用错方向。

MapReduce的强项是离线批处理。数据量巨大（TB级甚至PB级）、计算逻辑相对简单、对延迟要求不高（分钟级到小时级）、需要跑完一个完整的计算任务（比如全量数据统计、全量数据清洗、全量索引构建），这些场景是MapReduce的主场。

MapReduce不适合的场景也很明确：实时计算不行——它的设计目标是高吞吐而非低延迟，一个任务从启动到结束，光任务调度和Shuffle就要花不少时间；复杂的多阶段迭代计算不行——比如机器学习里的梯度下降算法要反复迭代同一份数据，MapReduce每个阶段都要把中间结果落盘，迭代十几轮的话磁盘IO开销会让人崩溃；大量Tuple级随机读写也不行——它不适合像传统关系型数据库那样做单条记录的更新、删除和点查。

所以，如果你现在的场景是“每天凌晨跑一次大规模报表统计”“每月把上亿条交易数据做一次全量校验”，MapReduce依然是一个非常可靠、可维护性很强的选择——虽然现在很多新项目会选Spark或Flink，但MapReduce所建立的“Map-Shuffle-Reduce”思维模型，是你理解后面所有分布式计算框架的基础。把这一步吃透，后面学Spark、Flink会轻松一半。

2. 深入拆解Map阶段与Reduce阶段的职责边界

2.1 Map阶段：输入分片、RecordReader与map()函数

Map阶段远不是“写一个map方法”这么简单，它内部有一套执行流程。

首先，框架会把输入数据切成输入分片（InputSplit）。分片是一个逻辑概念，它不物理存储数据，只是指定了要处理的数据范围和对应的元数据信息。分片大小默认与HDFS块对齐，这意味着如果你HDFS块大小是128MB，那么一个1GB的文件会被切成大约8个分片，由8个Map任务并行处理。

接下来，每个Map任务内部有一个RecordReader组件，负责按行读取分片中的数据并解析成Key-Value对。默认情况下，TextInputFormat的RecordReader会把每行的行首偏移量作为Key，整行文本作为Value。也就是说，虽然你看到的map()函数参数是(Object key, Text value)，但这个key实际上就是行号偏移量，业务上用不到它。

然后map()函数逐条处理这些键值对，处理完通过context.write()输出新的Key-Value对。这个输出会被写入一个环形缓冲区，缓冲区默认大小100MB，当写入量达到阈值比例（默认80%）时，后台线程开始将数据溢写（spill）到本地磁盘。溢写之前会先做分区和排序——这一步我后面会详细讲，因为这是理解Shuffle的关键。

还有一点值得留意：map()函数的输入和输出Key-Value类型必须实现Writable接口，这是Hadoop自定义的序列化接口。为什么不用Java自带的Serializable？因为Java序列化太重了，会把类名、继承结构等大量元信息也序列化进去，而Hadoop的Writable只序列化字段内容，体积小、速度快。你在写MapReduce程序时，文本用Text、整数用IntWritable、长整数用LongWritable，字符串数组就用Text数组的包装，这些类型直接对应了Java里的String、Integer、Long。

2.2 Reduce阶段：数据分组、reduce()函数与多Reduce任务

Reduce阶段接收的是Map端输出的中间数据。但这里有个容易误解的点：所有相同Key的键值对都会交给同一个Reduce任务处理，无论这些键值对来自哪个Map任务。这也就是Shuffle的核心作用——它完成了一次“全局分组”。

每个Reduce任务内部会有分组（Grouping）的步骤：把Key相同的记录归为一组。你写的reduce()函数参数是(Text key, Iterable<IntWritable> values)，这个Iterable就是一个分组迭代器，每次迭代取出的value都属于同一个Key。注意一个细节：这个Iterable里的values只能迭代一次，如果你需要多次访问这些值（比如既要算总数又要算平均值，需要遍历两遍），就得先把values复制到List里，否则第二遍迭代会得到空集合。

Reduce任务的数量由你显式设置，默认情况下是1。这意味着所有Key都会涌向同一个Reduce任务，也就是单点处理——数据量大的时候性能极差。通常建议把Reduce数量设置成和集群可用CPU核数相关，比如job.setNumReduceTasks(8)或更大一点。但也不是越大越好，Reduce数量太多会导致每个Reduce处理的数据量过少，启动和调度的开销占比反而上升，任务完成后输出的小文件也会变多。

2.3 中间结果的Key-Value设计原则

写MapReduce程序时，map()输出什么Key、什么Value，看似自由发挥，实际上有很强的约束和技巧。

核心原则是：Key必须是“语义上的分组维度”。因为框架会按Key分组，所以你想按什么维度聚合，就把什么作为Key。比如按请求路径统计流量，Key就是路径字符串；按用户ID统计消费总额，Key就是用户ID。如果把业务维度放在Value里，而Key设置得很粗糙，Reduce端还是要自己在values里做二次分组，失去了框架分组的优势。

Value的设计相对自由，但有一个常见场景要注意——Reduce端需要不止一个字段时。比如统计每个路径的访问量和平均响应时间，map()输出Key为路径，Value如果只是一个IntWritable的响应时间值，那Reduce端只能算出总花费时间或总次数，算不出平均值（因为平均值需要同时知道次数和时间总和）。这时候有两种做法：

第一种：写一个自定义Writable类型，包含count和time两个字段，map()输出这个复合对象，Reduce端分别累加，最后除法得到平均响应时间。

第二种：用Text类型，把count和time拼成一个字符串，比如"1:128"，Reduce端再拆分解析。这种方法简单粗暴但可读性差，如果字段里本身含分隔符就麻烦。

我建议用自定义Writable，虽然代码量多一点，但类型安全、扩展性好，后续加字段不用改String解析逻辑。后面第4节我会给完整的代码。

3. Shuffle机制：MapReduce最容易被忽视的“隐形枢纽”

3.1 Shuffle全流程：从Map端输出到Reduce端输入

我见过很多人写MapReduce程序调优时，总在纠结map和reduce函数本身写得“对不对”，结果发现瓶颈根本不在业务代码，而在Shuffle——它是整个MapReduce框架中最复杂、最容易出性能问题的环节。

Shuffle横跨Map和Reduce两端，具体流程是这样的：

Map端：map()函数调用context.write()后，输出数据先进入环形缓冲区。这个缓冲区默认100MB，当数据量达到缓冲区大小的80%（也就是80MB）时，后台线程开始溢写。溢写时先把数据按Partitioner分区（就是把Key映射到哪个Reduce任务），每个分区内部再按Key排序。如果配置了Combiner，还会在排序后做一次局部合并，减少溢写数据量。溢写会产生多个spill文件，Map任务全部结束后，这些spill文件会被合并成一个最终的输出文件（这个过程叫Merge）。

Reduce端：Reduce任务启动后，会从Map端拉取属于自己分区的数据。注意，Reduce任务不知道数据在哪，它需要向ApplicationMaster询问每个Map任务的输出位置，然后并行地下载属于本分区的数据。下载的数据先放在内存，内存不够就落盘。全部拉完后，再进行一次最终的合并排序，把相同Key的记录聚在一起，然后才轮到reduce()函数执行。

这个流程里每一步都涉及磁盘IO和网络传输，所以Shuffle的数据量直接决定了作业的运行时间。优化Shuffle的核心思路，就是尽可能减少中间数据的体积——这就要用到分区控制、Combiner和压缩了。

3.2 分区、排序、分组：对应关系一眼理清

不少初学者会把分区（Partition）、排序（Sort）、分组（Grouping）混为一谈，其实它们解决的是不同层面的问题。

分区解决的是“这个Key交给哪个Reduce任务”。默认的分区器是HashPartitioner，它计算(key.hashCode() & Integer.MAX_VALUE) % numReduceTasks，通过哈希取模把Key均匀分布到各个Reduce。这样可以保证相同Key的键值对必然进入同一个Reduce，因为同一Key的哈希值相同。如果你想让某些有业务关联的Key进入同一个Reduce（比如所有订单量大的用户ID进同一个Reduce做特殊处理），可以自定义Partitioner，重写getPartition()方法。

排序解决的是“同一个分区里的Key按什么顺序排列”。默认按Key的字典序升序。有些Reduce计算依赖有序数据，比如数值统计需要从小到大累加、去重需要跳过连续相同值，这时候排序就有用了。你可以在map阶段就做部分排序，Reduce阶段再全局归并，最终保证每个分组内部的Key是有序的。

分组解决的是“对Reduce函数来说，哪些Key算一组”。默认情况下，两个Key完全相等才分成一组。但有时你想让“语义上相关但不相等”的Key分到同一组——比如Key是句子，你想让同一句子不同大小写形式归入一组；或者月份字段是"2024-01"和"2024-1"，你想合并。这时候可以自定义GroupingComparator，重写比较逻辑，让不完全相等的Key在Reduce端被视为同一组。

一句话总结：分区控制流向，排序保证顺序，分组决定视图。三者独立又协作，是MapReduce里最考验功力的部分。

3.3 Combiner的正确使用方式

Combiner是很多人容易用错的一个优化配置。它的作用是：在Map端先做一次局部合并，减少Shuffle传输和Reduce端的数据量。比如WordCount，200个Map任务每个都输出(hello, 1)，那你传输到Reduce端的数据就有200份。但如果每个Map任务在本地先做一次reduce操作，把(hello, 1)合并成(hello, 67)，中间数据就只剩一份。

但要注意，Combiner不是想怎么用就怎么用。Combiner的输入和输出必须是同一个类型，而且它的操作必须是幂等可重复的。最典型的问题是“求平均值”——如果map()输出(path, 128)，Combiner把两个值合并成(path, 256)，这没有问题，因为求和是可结合的；但如果Combiner算的是平均值，两个127合并成一个128，那两个127和一个128这三个值的平均应该怎么算？只拿到128这个结果的人是算不出来的。所以求平均值不能直接拿Combiner当Reduce用。

我常用的方式是：如果Reduce做的是求和、求Count、求最大值、求最小值这类满足交换律和结合律的操作，Combiner可以直接复用Reducer类。如果是平均值、中位数这类复杂操作，要么在Combiner里输出(总和, 次数)这种二元组并在Reducer里相除，要么干脆不用Combiner，避免引入错误结果。

4. WordCount实战：第一个MapReduce程序的完整实现

4.1 环境准备：用什么版本、怎么快速搭一套本地开发环境

写MapReduce程序，不一定要先搭一个完整的Hadoop集群——对于学习和调试，本地模式（Local Mode）就够了。我的建议是：先在本地把逻辑跑通，再上集群跑全量数据，这样排查问题的时间成本会低很多。

具体环境上，我目前用的是Hadoop 3.x系列（比如3.3.x），JDK 8以上，Maven做依赖管理。在Maven项目里的pom.xml中引入：

<dependency> <groupId>org.apache.hadoop</groupId> <artifactId>hadoop-client</artifactId> <version>3.3.6</version> </dependency>

如果你不习惯用Maven，也可以直接把Hadoop安装包里的所有jar包（在share/hadoop/common、share/hadoop/mapreduce、share/hadoop/hdfs等目录）都加到classpath里。但说实话，用Maven管理会清爽很多，换版本、传递依赖都省心。

本地模式下不需要启动任何守护进程。Hadoop的LocalJobRunner会自动模拟单机、单进程的环境，直接跑在JVM里，适合快速验证代码逻辑。同时它也支持访问本地的HDFS——如果不显式指定HDFS地址，默认会使用本地文件系统的临时目录file:///tmp/hadoop-${user}。所以你在本地跑通之后，代码直接打成jar包扔到集群上，运行时通过-fs hdfs://namenode:8020这样的参数切换文件系统。

4.2 Mapper实现：从一行文本到键值对

经典的WordCount，map()函数要做的事非常直观：每读入一行文本，按空格和标点把它切分成单词，每个单词输出(单词, 1)。

完整代码如下：

import org.apache.hadoop.io.IntWritable; import org.apache.hadoop.io.LongWritable; import org.apache.hadoop.io.Text; import org.apache.hadoop.mapreduce.Mapper; import java.io.IOException; public class WordCountMapper extends Mapper<LongWritable, Text, Text, IntWritable> { private static final IntWritable ONE = new IntWritable(1); private Text word = new Text(); @Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { // value 是一行文本，key 是该行在文件中的字节偏移量 String line = value.toString(); // 简单分词：按非字母数字字符切分 String[] words = line.split("[\\s\\p{Punct}]+"); for (String w : words) { if (w.isEmpty()) { continue; } word.set(w); context.write(word, ONE); } } }

这里我用了正则[\s\p{Punct}]+来切分，可以一次性处理空格、制表符和标点。这个是比较Python风格的写法，Java里也支持。如果你要处理的是日志文件，map()里就得写针对日志格式的解析逻辑了，比如按空格split后取第几个字段作为Key。

4.3 Reducer实现：聚合统计并输出

Reducer这边做的事情更简单：把迭代器里的所有value加起来，写出去。

import org.apache.hadoop.io.IntWritable; import org.apache.hadoop.io.Text; import org.apache.hadoop.mapreduce.Reducer; import java.io.IOException; public class WordCountReducer extends Reducer<Text, IntWritable, Text, IntWritable> { private IntWritable result = new IntWritable(); @Override protected void reduce(Text key, Iterable<IntWritable> values, Context context) throws IOException, InterruptedException { int sum = 0; for (IntWritable val : values) { sum += val.get(); } result.set(sum); context.write(key, result); } }

如果还想按出现次数降序排序输出，默认的Reduce输出是按Key字典序升序排列的。如果你要全局排序，需要再加一个控制排序的环节。这里先不展开，后面讲进阶技巧时会提到。

4.4 Driver主类：Job的组装与配置

有了Mapper和Reducer，还需要一个Driver类来组装整个Job并提交运行。

import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.fs.Path; import org.apache.hadoop.io.IntWritable; import org.apache.hadoop.io.Text; import org.apache.hadoop.mapreduce.Job; import org.apache.hadoop.mapreduce.lib.input.FileInputFormat; import org.apache.hadoop.mapreduce.lib.output.FileOutputFormat; public class WordCountDriver { public static void main(String[] args) throws Exception { if (args.length != 2) { System.err.println("Usage: WordCountDriver <input path> <output path>"); System.exit(-1); } Configuration conf = new Configuration(); Job job = Job.getInstance(conf, "Word Count"); job.setJarByClass(WordCountDriver.class); job.setMapperClass(WordCountMapper.class); job.setCombinerClass(WordCountReducer.class); // 复用Reducer做Combiner job.setReducerClass(WordCountReducer.class); job.setOutputKeyClass(Text.class); job.setOutputValueClass(IntWritable.class); FileInputFormat.addInputPath(job, new Path(args[0])); FileOutputFormat.setOutputPath(job, new Path(args[1])); System.exit(job.waitForCompletion(true) ? 0 : 1); } }

这里有几个细节：

• job.setJarByClass(WordCountDriver.class)是必须的，它告诉Hadoop去哪里找包含所有依赖类的jar包。如果你在终端里用hadoop jar xxx.jar提交，框架会使用你指定的jar包，这个设置依然会做校验。

• 我在这里设置了job.setCombinerClass(WordCountReducer.class)，因为WordCount的Reduce逻辑是求和，满足可结合性，Combiner直接复用Reducer类合法且高效。

• FileInputFormat默认会递归读取指定目录下的所有文件（如果你配置了递归），输出路径必须不存在，否则Hadoop会直接报错——这是为了避免误覆盖历史结果。

打包时用Maven的shade插件把依赖打成一个fat jar。实际运行命令如下：

hadoop jar wordcount-1.0.jar WordCountDriver /input /output

4.5 运行与结果验证

本地模式运行时，如果你用IDE直接跑Driver类，需要在IDE里配置程序参数（input path和output path），比如：

# 在项目根目录下准备输入文件 echo -e "hello world\nhello hadoop\nmapreduce is powerful" > input.txt # 运行（本地模式） hadoop jar target/wordcount-1.0.jar WordCountDriver input.txt output_dir

跑完之后查看结果：

hadoop fs -cat output_dir/part-r-00000

如果你是在本地文件系统跑，结果文件也在本地，直接cat output_dir/part-r-00000即可。正常情况下你会看到每个单词一行统计结果，按单词字典序排好。

如果结果里每个单词出现了两行或者统计值不对，大概率是Combiner配置出了问题，或者map()输出Value类型和Reducer的期望不一致——这是新手最容易翻车的两个点。

5. MapReduce编程进阶：让作业跑得更稳更快的经验

5.1 合理设置并行度：Map数量和Reduce数量怎么定

很多初学者以为Map任务越多并行度越高，其实Map任务数是有限制的，而且并非越多越好。

Map任务数由输入文件的大小和分片大小决定。默认情况下，一个128MB的分片对应一个Map任务。如果你的输入是100GB，理论上会有大约800个Map任务。如果都是几KB的小文件，每个小文件也可能产生一个Map任务，这就会出现“一个Map任务处理几KB数据、启动开销远大于计算开销”的极端情况。

所以合理规划输入数据的存储结构很重要。把大量小文件合并成SequenceFile或Parquet这类大文件，是降低Map任务数、提升整体效率的最有效手段之一。另外，在Driver类里可以通过FileInputFormat.setMaxInputSplitSize()调大分片大小来减少Map数，但要注意分片过大时单Map任务处理时间也会变长，需要根据实际数据分布权衡。

Reduce数量的设置更讲究。一个通用经验公式是：

Reduce数 = 每个Reduce期望处理的数据量 / 集群可用CPU核数

比如总共要处理100GB的中间数据，集群有200个可用vcore，每个Reduce处理1GB数据比较合适，那么设50个Reduce是比较合理的。Reduce太少会导致单个Reduce负载过重、任务长时间跑不完；Reduce太多会导致调度开销大、每个Reduce拿到的数据碎不成片、输出小文件过多。

5.2 数据倾斜：你的作业为什么有的Reduce跑了很久，有的却早早干完

数据倾斜是MapReduce作业运行时间不可控的“头号元凶”。

症状很明显：同一个作业里，某个Reduce任务运行时间是其他Reduce的几倍甚至几十倍，或者某个Reduce任务进度条一直卡在100%附近不动。

根本原因，在于Key的分布极度不均匀。比如统计用户日活时，超级大V用户的行为日志特别多，映射到同一个Reduce上，其他普通用户的Reduce任务几分钟就结束了，大V所在的那个Reduce要跑几个小时。

针对倾斜的常规处理手段有几种：

• 给倾斜的Key加前缀或随机后缀，让它“分身”到多个Reduce。比如大V用户ID后面加_0、_1、_2，这样它的数据被分散到3个Reduce上，最后再单独跑一个二次聚合把结果合并。

• 如果倾斜只集中在少数几个Key，可以用采样预先识别出倾斜Key，在map()阶段就单独标记处理，不让它走默认分区。

• 用Combiner尽量做局部合并，也能显著缓解倾斜程度。

实际操作中，我一般会先看一眼任务日志，定位到那个迟迟不结束的Reduce，然后打印它处理的Key分布，确认是倾斜后，再针对性加随机后缀做二次聚合。

5.3 小文件问题：MapReduce最容易被低估的性能杀手

Hadoop的HDFS本身是为大文件设计的，块默认128MB，但实际业务里经常出现大量几KB、几十KB的小文件，比如日志按小时切分后每个小时的文件非常碎，或者上游接口每5分钟吐一个临时文件。

小文件带来的连锁反应很严重：Map任务数量剧增、NameNode内存压力飙升（每个文件都要在NameNode里维护元数据）、磁盘寻道开销大、调度和启动任务的资源消耗盖过了实际计算。

我的经验是：在做MapReduce批处理之前，先做一层文件合并。可以用Hadoop自带的工具，也可以在上游做数据汇聚时把粒度从“分钟级”调整为“小时级”或“天级”。Hadoop 3.x还引入了Storage Policy和Erasure Coding，能缓解一部分小文件带来的副本存储开销，但治本的方法还是提前控制文件粒度。

5.4 中间数据压缩：用CPU换网络和磁盘IO

Shuffle过程的传输量如果降不下来，还有一个性价比极高的优化手段——中间结果压缩。

在Driver类里加上配置：

conf.set("mapreduce.map.output.compress", "true"); conf.set("mapreduce.map.output.compress.codec", "org.apache.hadoop.io.compress.SnappyCodec");

Snappy压缩算法速度非常快，压缩率在中低水平，但CPU开销很小，对绝大多数场景都是正收益。开启后Map端溢写的spill文件和Reduce端拉取的数据都会变小，网络传输压力明显降低。

如果输入文件本身是压缩格式，比如Gzip、Bzip2、Snappy，Hadoop会自动识别并解压。但要注意Gzip不支持分片（splittable），一个Gzip文件只能由一个Map任务处理，大文件配Gzip会让你眼睁睁看着并行度变成1。所以如果输入文件较大且需要高并行度，建议存储时用Snappy或者LZO，这两种格式支持分片。

6. 常见问题与排查技巧实录

6.1 任务反复失败：从日志里怎么最快定位问题

MapReduce作业失败时，第一件事是看日志——但日志在哪、看哪个日志，是有讲究的。

如果你提交的是hadoop jar命令，任务运行完控制台会打印每个Task的日志链接，格式类似于http://nodemanager:8042/logs/userlogs/application_xxx/container_xxx/。你可以打开对应container的标准输出、标准错误和系统日志。如果任务失败，通常syslog里含有业务代码抛出的异常堆栈，这是排查的第一手信息。

最常见的几类错误：

• ClassNotFoundException：说明你打包的jar里没有包含依赖的类，检查是不是忘了用shade插件打进依赖。

• FileAlreadyExistsException：输出目录已经存在。Hadoop不会自动覆盖，需要先删除旧目录。

• GC overhead limit exceeded或OutOfMemoryError：内存设置不合理，检查Map和Reduce的堆内存配置。

• Killed by AM：说明Container被资源管理器主动杀掉，通常是内存超限或Yarn队列资源配额不够。

我个人的排查顺序是：先看ApplicationMaster页面上的“失败任务列表”，然后点进失败的Task里看syslog，再对应异常类型去处理。不建议一上来就翻几十个Task的日志，浪费时间。

6.2 内存溢出和GC频繁：参数怎么调

Map任务默认的堆内存上限一般是1GB左右，如果你的一个Map任务要处理的行数特别多、value特别长，很容易触发OOM。

可以通过参数调整：

hadoop jar myjob.jar \ -Dmapreduce.map.memory.mb=2048 \ -Dmapreduce.reduce.memory.mb=4096 \ ...

mapreduce.map.memory.mb控制的是Yarn分配给Map Container的内存上限，建议同时调整对应JVM堆大小：mapreduce.map.java.opts，比如设为-Xmx1536m。注意Container内存要大于JVM堆内存，因为还有内存开销（JVM自身、代码缓存、直接内存等）。

如果你发现GC非常频繁，但还没有OOM，可以先开启map端的中间输出压缩（前面提过的Snappy），减少内存和磁盘间的数据流动，另一个角度是把环形缓冲区的默认阈值调小，减少一次溢写携带的数据量。

6.3 结果不符合预期：数据去哪儿了

写完了MapReduce，跑完了，结果却对不上，这种问题在开发阶段很常见。

首先检查一下你的map()输出Key和预期是否一致。有时候你以为自己切分好了单词，结果分词正则里有特殊字符没处理干净，导致hello.和hello被当成两个不同的Key。用上面WordCount的示例，分词正则漏掉句号是很常见的事。

其次检查Reduce端是否用到了Iterable的重复遍历。前面提过，Iterable里的values只能遍历一次。如果你先循环一遍算总和、再循环一遍算平均值，第二次循环会得到空集合，最终结果自然是不对的。解决办法是把values复制到List里，再做多轮计算。

最后注意：如果你的Job设置了多个Reduce任务，输出文件名是多份，比如part-r-00000、part-r-00001。你聚合所有part文件才是完整结果，少了哪一份都可能导致统计值不对。

6.4 如何调试MapReduce程序：本地跑、单元测试、小数据量验证

我强烈建议开发时遵循“先小后大”的原则：先在本地用几MB的样例数据跑通，再上集群用几十GB的数据做验证，最后才跑全量。

本地调试时，最直接的方式是在IDE里直接运行Driver类。它能实时看到日志和异常堆栈，打断点调试也很方便。唯一问题是本地模式默认单进程，运行效率不高，但调试逻辑足够了。

如果你需要更细粒度的单元测试，可以用Hadoop自带的测试框架（如MRUnit），对Mapper和Reducer分别写测试用例。这样可以在不启动任何Hadoop环境的情况下，快速验证map和reduce的输入输出逻辑。项目里引入：

<dependency> <groupId>org.apache.hadoop</groupId> <artifactId>hadoop-minicluster</artifactId> <version>3.3.6</version> <scope>test</scope> </dependency>

MiniCluster是Hadoop提供的单机模拟集群，会启动一个完整的HDFS和YARN环境，非常适合做集成测试。

最后再分享一个小技巧：如果你排查问题一直无头绪，给map()和reduce()函数里临时加上业务日志，比如把每个Key的value打印前十条，用System.err.println输出到syslog里。跑完任务直接去container日志里看。这个方法虽然朴素，但很多诡异的“数据对不上”问题就是这样被定位出来的——尤其是当你不确定上游数据到底长什么样时，打印原始输入往往比看中间代码更有效。