MapReduce单词计数实战：从原理到调优的完整指南

1. 从一个“Hello World”说起：为什么单词计数是MapReduce的必修课

但凡接触过大数据技术栈的人，几乎都绕不开一个入门案例——单词计数。这个案例的地位，大致相当于编程语言里的“Hello World”，或者电子工程里的“点亮一颗LED”。它足够简单，简单到逻辑用一句话就能说清楚：给一堆文本，统计每个单词出现了多少次。但它又足够典型，典型到几乎涵盖了MapReduce编程模型的全部核心要素——切分、映射、洗牌、归约、输出。

我见过不少初学者，觉得单词计数太小儿科，扫一眼代码就跳过去了，结果到了真正写业务逻辑的时候，连一个简单的分组聚合都写不利索。问题出在哪里？就出在没有把这个“简单案例”吃透。单词计数表面上是在数单词，实际上是在训练一种分布式思维：如何把一个大任务拆成互不依赖的小任务并行执行，再把结果合并起来。这种思维，才是MapReduce真正的价值所在。

这篇文章面向的是刚接触大数据基础、正在学习MapReduce编程的读者，也适合那些以前跑过单词计数但没深究过底层机制的人。我会从设计思路、核心原理、代码实操、调优技巧、问题排查几个维度，把这个案例彻底拆开讲一遍。你不需要有分布式系统的背景，只要会基本的Java或者Python，就能跟着走完整个流程。读完之后，你不仅能独立跑通单词计数，还能理解每一步为什么要这么设计，遇到类似的分组统计需求时能举一反三。

2. 拆解单词计数的整体设计思路

2.1 为什么偏偏选单词计数作为入门案例

很多人会问，大数据处理场景那么多，为什么教材和课程都拿单词计数开刀？这不是随便选的。单词计数这个场景，天然具备几个非常适合教学的特征。

第一，输入数据可以无限大。一篇文章、一本书、甚至整个互联网的网页文本，都可以作为输入。数据量越大，分布式计算的优势越明显。如果用单机程序去数几十亿个单词，内存和时间都扛不住，而MapReduce可以轻松应对。

第二，计算逻辑可以完美并行。统计单词出现次数这件事，有一个非常好的性质：不同单词之间的计数互不影响。统计“apple”出现了几次，完全不需要知道“banana”出现了几次。这意味着可以把文本切成任意多块，每块独立统计，最后把相同单词的计数加起来就行。这种“可分解、可合并”的特性，正是MapReduce模型最擅长处理的。

第三，覆盖了完整的处理链路。单词计数虽然逻辑简单，但从数据输入、分片、映射、分区、排序、归约到最终输出，整个MapReduce的流程一个环节都不少。学完这个案例，你就掌握了MapReduce的完整骨架，后面再学更复杂的join、去重、排序等操作，只是在骨架上填肉而已。

第四，结果易于验证。你写一个单机程序数一遍，再跑一遍MapReduce，对比结果就知道对不对。这种可验证性对初学者非常重要，能快速建立信心。

所以，单词计数不是“随便选的一个简单例子”，而是经过精心设计的教学载体。它的简单是刻意为之的，目的是让你把注意力集中在编程模型本身，而不是业务逻辑的复杂性上。

2.2 MapReduce的核心思想：分而治之

MapReduce这个名字本身就说明了它的两个核心阶段：Map（映射）和Reduce（归约）。这两个词来源于函数式编程，但在大数据的语境下，它们有了更具体的含义。

Map阶段做的事情是“转换”。它接收原始数据，把每一条记录转换成若干个键值对（key-value pair）。在单词计数里，Map接收一行文本，把它拆成一个个单词，然后每遇到一个单词，就输出一个<单词, 1>的键值对。这个“1”表示“这个单词出现了1次”。

Reduce阶段做的事情是“聚合”。它接收Map阶段输出的键值对，把相同key的value合并在一起。在单词计数里，Reduce收到<apple, [1,1,1,1]>这样的输入，把所有的1加起来，输出<apple, 4>，表示“apple这个单词总共出现了4次”。

但这里有一个关键问题：Map阶段是分布在不同机器上并行执行的，Reduce阶段也是分布在不同机器上并行执行的。那么，Map输出的<apple, 1>怎么保证都送到处理apple的那个Reduce任务上去？这就涉及到一个中间环节——Shuffle（洗牌）。

Shuffle是MapReduce中最复杂、最精妙的部分。它负责把Map输出的键值对按照key进行分区、排序、合并，然后分发给对应的Reduce任务。你可以把它想象成一个大型的物流分拣中心：各个Map任务把包裹（键值对）送过来，分拣中心按照目的地（key的哈希值）把包裹分到不同的传送带上，每条传送带对应一个Reduce任务。同一个key的所有包裹一定会被送到同一条传送带上，这样Reduce才能做正确的聚合。

理解了Map、Shuffle、Reduce这三个阶段，你就理解了MapReduce的全部。单词计数的代码之所以短，是因为大部分复杂工作——分布式调度、数据传输、容错处理——都由框架帮你做了。你只需要写两个函数：一个map函数，一个reduce函数。

2.3 从单机版到分布式版的思维跃迁

如果你以前用Python写过单词计数，代码大概是这样：

from collections import Counter text = open("input.txt").read() words = text.split() counts = Counter(words) for word, count in counts.items(): print(word, count)

这段代码逻辑上完全正确，但它只能处理能放进内存的文本。如果文件有100GB，你的机器只有16GB内存，这段代码直接就跑不起来。

MapReduce版本的单词计数，本质上就是把上面这段代码拆开，让不同的机器分别处理不同的数据块。具体来说：

• 把大文件切成N个分片（split），每个分片交给一个Map任务处理。
• 每个Map任务对自己分片里的文本做split和计数，输出<单词, 1>。
• 框架把所有Map的输出按单词分组，相同单词的计数列表送到同一个Reduce任务。
• Reduce任务把计数列表求和，输出最终结果。

这个过程中，没有任何一台机器需要把整个文件读进内存。每台机器只处理自己那一小块数据，内存压力被分散了。这就是分布式的威力。

但要注意，这种拆分不是没有代价的。Map和Reduce之间需要通过网络传输数据，Shuffle阶段的网络开销和磁盘I/O往往是整个作业的性能瓶颈。所以，写MapReduce程序时，一个重要的优化原则就是：尽量减少Shuffle阶段传输的数据量。在单词计数的例子里，你可以在Map端先做一次本地合并（Combiner），把<apple, 1>、<apple, 1>、<apple, 1>合并成<apple, 3>再发送出去，这样网络传输量能减少好几倍。Combiner本质上是一个“迷你Reduce”，它的逻辑通常和Reduce完全一样，只是运行在Map端。

3. 核心细节解析：Map、Shuffle、Reduce到底在干什么

3.1 Map阶段的输入输出与数据分片机制

Map阶段的输入是原始数据的分片。这里要区分两个概念：分片（Split）和块（Block）。在HDFS中，文件被切成固定大小的块（默认128MB），每个块有多个副本存储在不同节点上。而MapReduce的分片是逻辑上的概念，一个分片通常对应一个块，但也可以跨块。分片的大小决定了Map任务的数量：如果有10个分片，就会启动10个Map任务并行处理。

为什么要按块来分片？核心原因是数据本地性（Data Locality）。如果分片和块在同一台机器上，Map任务就可以直接读取本地磁盘上的数据，不需要通过网络传输。这能大幅减少网络开销。框架在调度Map任务时，会尽量把任务分配到数据所在的节点上。如果做不到（比如该节点负载太高），才会退而求其次，从其他节点远程读取。

Map函数的输入是<key, value>形式的。在默认的TextInputFormat下，key是行偏移量（该行在文件中的字节位置），value是这一行的文本内容。很多初学者会疑惑：为什么key是偏移量而不是行号？因为偏移量在分片读取时更容易计算，而且能保证唯一性。行号需要额外维护计数器，在并行读取时会有同步开销。

Map函数的输出是若干个<key, value>对。在单词计数里，key是单词，value是整数1。这里有一个细节：Map输出的key和value的类型必须和Reduce输入的key和value类型一致。在Hadoop中，这通过Job的配置来指定。如果类型不匹配，作业会在运行时抛出类型转换异常。

还有一个容易被忽略的点：Map输出的数据并不是直接写到磁盘的，而是先写入一个环形内存缓冲区。默认大小是100MB，当缓冲区使用到80%时，会触发溢写（Spill），把数据排序后写到磁盘。这个排序非常关键，它保证了每个Map任务输出的数据在本地是按key有序的。有序的数据在后续的合并和Reduce读取时效率更高。

3.2 Shuffle：整个作业中最容易被忽视的性能杀手

Shuffle是连接Map和Reduce的桥梁，也是MapReduce中最复杂、最耗时的阶段。很多作业跑得慢，问题都出在Shuffle上。

Shuffle的过程可以细分为Map端的Shuffle和Reduce端的Shuffle。

Map端的Shuffle主要包括：分区（Partition）、排序（Sort）、合并（Combine）、溢写（Spill）、归并（Merge）。分区决定了每个键值对会被送到哪个Reduce任务。默认使用HashPartitioner，计算公式是(key.hashCode() & Integer.MAX_VALUE) % numReduceTasks。这个公式保证了相同的key一定会被分到同一个Reduce任务。排序是按key进行的，因为Map输出在溢写到磁盘前会先按key排序，这样Reduce读取时可以利用归并排序高效合并。合并就是前面提到的Combiner，它是一个可选的优化步骤，能在Map端减少输出数据量。溢写是当内存缓冲区满时把数据写到磁盘。归并是把多个溢写文件合并成一个大的有序文件。

Reduce端的Shuffle主要包括：拉取（Fetch）、归并（Merge）、排序（Sort）。Reduce任务会通过HTTP从各个Map任务所在的节点拉取属于自己的分区数据。拉取过来的数据也是有序的，但来自不同Map任务，所以需要做一次归并排序，把多个有序流合并成一个有序流。最后，相同key的value会被分到一组，形成<key, [value1, value2, ...]>的形式，交给Reduce函数处理。

Shuffle的性能瓶颈主要在两个地方：网络带宽和磁盘I/O。Map端溢写和Reduce端拉取都涉及大量的磁盘读写和网络传输。优化Shuffle的常见手段包括：增大内存缓冲区减少溢写次数、使用Combiner减少传输量、调整Reduce拉取时的并行度、启用压缩减少网络传输的数据量。

注意：Combiner虽然能大幅减少Shuffle数据量，但它有一个前提——Reduce函数的逻辑必须满足交换律和结合律。单词计数的求和满足这两个性质，所以可以安全使用Combiner。但如果你做的是求平均值，就不能直接用Combiner，因为平均值不满足结合律（avg(avg(a,b), c) != avg(a,b,c)）。

3.3 Reduce阶段的聚合逻辑与输出格式

Reduce阶段接收的是<key, Iterable >形式的输入。注意这里的value是一个迭代器，而不是一个列表。这意味着Reduce函数可以逐个遍历value，而不需要一次性把所有value加载到内存中。这对于value数量很大的场景非常重要，能避免内存溢出。

在单词计数里，Reduce函数遍历迭代器，把所有的1累加起来，得到该单词的总次数，然后输出<单词, 总次数>。

Reduce的输出格式由OutputFormat决定。默认是TextOutputFormat，输出为“key\tvalue”的文本格式，每行一条记录。你也可以自定义OutputFormat，比如输出成JSON、CSV或者写入数据库。在实际项目中，根据下游系统的需求选择合适的输出格式很重要。

Reduce任务的数量是可以配置的。默认是1个，这意味着所有Map输出都会汇聚到一个Reduce任务上，成为性能瓶颈。通常建议把Reduce数量设置为集群可用Reduce槽位的0.9倍左右，这样既能充分利用资源，又留有一些余量应对任务失败重试。但Reduce数量也不是越多越好，每个Reduce任务都有启动和初始化开销，数量太多会导致大量小文件，增加NameNode的负担。

还有一个细节：Reduce任务的输出文件数量等于Reduce任务的数量。如果你设置了10个Reduce任务，最终会得到10个输出文件（part-r-00000到part-r-00009）。这些文件是按key范围划分的，但并不是全局有序的。如果你需要全局有序的输出，要么只用一个Reduce任务，要么在后续步骤中再做一次排序。

4. 完整实操：从零跑通一个单词计数作业

4.1 环境准备与项目搭建

在开始写代码之前，需要先确认环境。这里以Hadoop 3.x为例，假设你已经有一个可用的Hadoop集群或者单机伪分布式环境。如果你还没有搭建环境，可以先在一台机器上配置伪分布式模式，足够跑通单词计数。

需要的组件包括：JDK 8或以上、Hadoop 3.x、Maven（用于管理依赖）。如果你用Python写MapReduce，还需要Hadoop Streaming相关的配置，但本文以Java为例，因为Java是MapReduce的原生语言，能更清楚地展示底层细节。

创建一个Maven项目，在pom.xml中添加Hadoop客户端依赖：

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

打包时使用maven-shade-plugin或者maven-assembly-plugin生成包含所有依赖的fat jar，否则提交到集群时会找不到类。

提示：Hadoop依赖的版本要和集群版本一致，否则可能出现序列化不兼容的问题。如果不确定集群版本，可以用hadoop version命令查看。

4.2 Mapper类的编写与关键参数说明

Mapper类的核心是map方法。在Hadoop中，你需要继承Mapper类并重写map方法。泛型参数有四个：输入key类型、输入value类型、输出key类型、输出value类型。

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; import java.util.StringTokenizer; public class WordCountMapper extends Mapper<LongWritable, Text, Text, IntWritable> { private final static IntWritable one = new IntWritable(1); private Text word = new Text(); @Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { String line = value.toString(); StringTokenizer tokenizer = new StringTokenizer(line); while (tokenizer.hasMoreTokens()) { word.set(tokenizer.nextToken()); context.write(word, one); } } }

这里有几个关键点值得展开说。

为什么用Text而不是String？Hadoop的序列化机制要求key和value必须是Writable类型。Text是Hadoop对String的封装，实现了WritableComparable接口，可以在网络上传输和比较大小。直接用String会报错。

为什么用IntWritable而不是int？同理，int不是Writable类型。IntWritable是int的封装，只占4字节，比Integer的序列化开销小得多。Hadoop还提供了LongWritable、FloatWritable、DoubleWritable等常用类型。

为什么把one和word定义为成员变量？这是为了避免在每次调用map方法时都创建新对象。Map方法会被调用成千上万次，如果每次都new一个IntWritable和Text，会产生大量临时对象，增加GC压力。复用对象是MapReduce编程的一个常见优化技巧。但要注意，context.write会把对象序列化后写出，所以复用是安全的，不会出现引用覆盖的问题。

StringTokenizer和split有什么区别？StringTokenizer是Java早期提供的分词工具，性能比String.split()好，因为它不依赖正则表达式。对于简单的按空格分词场景，StringTokenizer更合适。但如果分隔符复杂，还是得用split或者自定义解析逻辑。

4.3 Reducer类的编写与迭代器使用技巧

Reducer类同样继承Reducer，重写reduce方法。输入是<key, Iterable >，输出是<key, 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); } }

这段代码看起来简单，但有一个隐藏的坑：Iterable 的迭代器只能遍历一次。如果你在reduce方法里遍历了两次values，第二次会得到空结果。这是因为Hadoop为了节省内存，对value迭代器做了复用优化。每次迭代返回的是同一个IntWritable对象，只是改变了内部的值。如果你需要保存value，必须做深拷贝。

另一个注意点是：sum用int类型可能溢出。如果某个单词出现次数超过21亿（int的最大值），就会溢出。虽然实际场景中很少遇到，但严谨的做法是用long。对应的输出类型也要改成LongWritable。

4.4 Driver类的配置与作业提交

Driver类是作业的入口，负责配置各种参数并提交作业。

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 { Configuration conf = new Configuration(); Job job = Job.getInstance(conf, "word count"); job.setJarByClass(WordCountDriver.class); job.setMapperClass(WordCountMapper.class); job.setCombinerClass(WordCountReducer.class); 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); } }

几个关键配置的解释：

setJarByClass告诉Hadoop用哪个类来定位jar包。集群需要把jar包分发到各个节点，这个配置帮助Hadoop找到包含Mapper和Reducer的jar。

setCombinerClass设置了Combiner类。这里直接复用Reducer类，因为单词计数的Reduce逻辑满足交换律和结合律。Combiner能在Map端做预聚合，减少Shuffle数据量。实测下来，对于单词计数这种场景，加上Combiner后Shuffle数据量能减少到原来的几分之一甚至几十分之一，作业速度明显提升。

setOutputKeyClass和setOutputValueClass指定了最终输出的类型。注意，如果Mapper的输出类型和Reducer的输出类型不一致，还需要单独设置setMapOutputKeyClass和setMapOutputValueClass。在单词计数里，Mapper输出<Text, IntWritable>，Reducer也输出<Text, IntWritable>，所以只需要设置一组。

FileInputFormat.addInputPath可以多次调用，添加多个输入路径。输出路径必须不存在，否则作业会报错。这是Hadoop的一个保护机制，防止意外覆盖已有数据。

4.5 编译、打包与集群提交的完整命令

代码写完后，用Maven打包：

mvn clean package

生成的jar包在target目录下。然后准备输入数据，上传到HDFS：

hdfs dfs -mkdir -p /user/test/wordcount/input hdfs dfs -put localfile.txt /user/test/wordcount/input/

提交作业：

hadoop jar wordcount.jar com.example.WordCountDriver \ /user/test/wordcount/input \ /user/test/wordcount/output

作业运行过程中，控制台会打印Map和Reduce的进度。运行完成后，查看结果：

hdfs dfs -cat /user/test/wordcount/output/part-r-00000 | head -20

输出格式是“单词\t次数”，按单词的字典序排列。

注意：如果输出目录已存在，作业会直接失败。调试时反复提交作业的话，每次都要先删除输出目录，或者用脚本自动处理。我一般会在Driver里加一段判断，如果输出路径存在就自动删除，但生产环境不建议这么做，容易误删数据。

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

5.1 作业提交失败：从报错信息定位问题根源

MapReduce作业提交失败的原因五花八门，但大部分都能从报错信息里找到线索。下面整理了几个高频问题和排查思路。

ClassNotFoundException是最常见的入门问题。很多人用mvn package打出的jar只包含自己的类，不包含Hadoop依赖。提交到集群后，集群上虽然有Hadoop的jar，但如果你用了第三方库（比如Jackson、Guava的特定版本），就会找不到类。解决办法是用maven-shade-plugin打一个包含所有依赖的fat jar。

Container killed on request通常是因为任务使用的内存超过了配置的上限。Hadoop会为每个Map和Reduce任务分配一个容器，容器有内存限制。如果任务实际使用的内存超过限制，会被NodeManager杀掉。排查方法是查看任务日志，找到“Container killed”前面的内存使用信息，然后适当调大mapreduce.map.memory.mb和mapreduce.reduce.memory.mb。

Too many fetch failures是Shuffle阶段的典型问题。Reduce任务从Map任务拉取数据时，如果连续多次失败，会认为该Map输出不可用，触发Map重跑。常见原因是网络不稳定或者Map输出所在的磁盘满了。可以调大mapreduce.reduce.shuffle.maxfetchfailures（默认10）和mapreduce.reduce.shuffle.read.timeout（默认180000毫秒）。

5.2 结果不对：数据倾斜与Combiner误用

结果不对比作业跑不起来更让人头疼，因为报错信息不会直接告诉你哪里错了。

数据倾斜是结果不对的一个隐蔽原因。虽然单词计数一般不会出现严重的数据倾斜，但如果你的输入数据里某个单词出现频率极高（比如日志里的“ERROR”），处理这个单词的Reduce任务就会比其他任务慢很多。表现是大部分Reduce任务都完成了，就剩一两个卡在99%不动。解决办法包括：自定义Partitioner把热点key打散、在key后面加随机前缀先做一次聚合再去掉前缀、或者增加Reduce数量。

Combiner误用是另一个坑。前面说过，Combiner的逻辑必须满足交换律和结合律。如果你在Combiner里做了非幂等的操作，比如计数时加了时间戳，结果就会错。还有一种情况是Combiner的输出类型和Reduce的输入类型不一致，这会导致类型转换异常。排查方法是先禁用Combiner跑一遍，如果结果对了，说明问题出在Combiner上。

编码问题也经常导致结果不对。如果输入文件包含中文或其他非ASCII字符，用默认的UTF-8读取一般没问题，但如果文件是GBK编码，就会出现乱码。解决办法是在Driver里设置job.getConfiguration().set("mapreduce.input.fileinputformat.input.dir.recursive", "true")，或者用TextInputFormat的子类指定编码。

5.3 性能调优：让单词计数跑得更快

单词计数虽然简单，但调优空间不小。下面是我在实际操作中总结的几个有效手段。

启用Combiner是最直接的优化。前面已经说过，不再赘述。实测在一个10GB文本的作业里，不加Combiner时Shuffle数据量约8GB，加了之后降到不到1GB，作业时间从12分钟缩短到4分钟。

调整内存缓冲区大小。Map端的环形缓冲区默认100MB，溢写阈值0.8。如果Map输出数据量很大，可以调大到200MB甚至更大，减少溢写次数。配置项是mapreduce.task.io.sort.mb和mapreduce.map.sort.spill.percent。

启用压缩。Map输出和最终输出都可以压缩。Map输出压缩能减少Shuffle阶段的网络传输量，最终输出压缩能节省HDFS空间。常用压缩算法有Snappy（速度快，压缩比一般）和Gzip（压缩比高，速度慢）。配置项是mapreduce.map.output.compress和mapreduce.map.output.compress.codec。

合理设置Reduce数量。默认1个Reduce在数据量大时是瓶颈。一般建议Reduce数量在0.5到1倍于集群Reduce槽位之间。但也不能太多，否则会产生大量小文件。一个经验公式是：Reduce数量 = 输入数据量 / 每个Reduce处理的目标数据量（通常256MB到1GB）。

使用本地聚合。在Mapper里用HashMap先做一次本地聚合，等map方法结束时再一次性输出。这样能大幅减少Map输出的键值对数量。代价是占用更多内存，需要根据数据特征权衡。

提示：调优不是一蹴而就的，建议每次只改一个参数，跑一遍对比效果。同时用Hadoop的Counter机制记录关键指标，比如Map输入记录数、Map输出记录数、Reduce输入记录数等，方便分析瓶颈在哪。

5.4 从单词计数延伸到真实业务场景

单词计数学会了，能做什么？其实很多真实业务场景都是单词计数的变体。

日志分析：统计每种HTTP状态码出现的次数、每个IP的访问次数、每个URL的请求量。本质上都是分组计数，只是key从单词变成了状态码、IP或URL。

用户行为分析：统计每个用户的操作次数、每个功能的点击量、每个页面的停留时长总和。同样是分组聚合，只是value不再是1，而是具体的数值。

倒排索引：给定一堆文档，统计每个单词出现在哪些文档里。这是搜索引擎的基础。Map阶段输出<单词, 文档ID>，Reduce阶段把相同单词的文档ID合并成一个列表。

去重统计：统计独立访客数（UV）。Map阶段输出<用户ID, 1>，Reduce阶段对每个用户ID只输出一次。这需要在Reduce里做去重，而不是简单求和。

这些场景的代码结构和单词计数几乎一样，区别只在于Map阶段如何提取key和value，以及Reduce阶段如何聚合。掌握了单词计数的骨架，换业务逻辑就是换map和reduce函数的事。

我在实际项目中遇到过最接近单词计数的场景是分析应用日志里的异常堆栈。需要统计每种异常类型出现的频率，找出最高频的异常。Map阶段从日志行里提取异常类名作为key，输出<异常类名, 1>；Reduce阶段求和。代码几乎就是把单词计数的分词逻辑换成正则匹配，十分钟就写完了。这就是打好基础的好处——遇到类似需求时，直接套模板就行。

6. 几个容易被忽略的细节与个人经验

6.1 关于Text和String的转换开销

Text和String之间的转换是有成本的。每次调用value.toString()都会创建一个新的String对象。在map方法里，如果一行文本很长，这个开销不容忽视。一个优化技巧是尽量在Text层面操作，比如用Text的find()、split()方法，而不是先转成String再处理。但Text的API不如String丰富，实际开发中需要权衡。

另一个细节是Text的toString()返回的是UTF-8解码后的字符串，如果原始数据不是UTF-8编码，可能会出现乱码。Hadoop默认假设输入是UTF-8，如果数据源是其他编码，需要在读取时做转换。

6.2 计数器：调试和监控的好帮手

Hadoop的Counter机制允许你在Map和Reduce里定义自定义计数器，记录一些关键指标。比如在单词计数里，你可以定义一个计数器记录“空行数”或者“总单词数”。这些计数器会在作业完成后汇总输出，方便你了解数据特征。

context.getCounter("WordCount", "EmptyLine").increment(1);

用计数器比打印日志方便，因为日志分散在各个节点上，收集起来麻烦，而计数器会自动汇总。我习惯在每个MapReduce作业里至少加两三个计数器，记录输入记录数、输出记录数和异常记录数，排查问题时非常有用。

6.3 小文件问题与CombineFileInputFormat

如果输入目录下有大量小文件（比如几千个几KB的文件），每个文件都会启动一个Map任务，导致Map任务数量爆炸，调度开销远大于实际计算开销。解决办法是用CombineFileInputFormat，把多个小文件合并到一个分片里，减少Map任务数量。

配置方法是在Driver里设置：

job.setInputFormatClass(CombineTextInputFormat.class); CombineTextInputFormat.setMaxInputSplitSize(job, 134217728); // 128MB

这样多个小文件会被合并成不超过128MB的分片，Map任务数量大幅减少。这个技巧在处理日志文件时特别有用，因为日志通常按时间切分，产生大量小文件。

6.4 作业日志的查看方法

作业跑失败时，控制台只会打印少量信息，详细的日志需要去YARN的Web UI或者日志目录里找。在伪分布式环境下，日志通常在$HADOOP_HOME/logs/userlogs/目录下，每个应用一个子目录。在集群环境下，可以通过YARN的ResourceManager Web UI（默认8088端口）找到应用，然后点击对应的Map或Reduce任务查看日志。

查看日志时重点关注“Error”、“Exception”、“Caused by”等关键词。有时候真正的错误被埋在几十行堆栈里，需要耐心往下翻。我一般先用grep -i exception过滤一遍，快速定位异常类型，再去看上下文。

6.5 关于本地调试模式

在提交到集群之前，强烈建议先在本地用LocalJobRunner跑一遍。LocalJobRunner会在本地模拟MapReduce的执行流程，不需要Hadoop集群，调试起来快得多。配置方法是在Configuration里设置mapreduce.framework.name=local，并且输入输出路径用本地文件系统路径（file:///...）。

本地模式能帮你快速发现代码逻辑错误，比如类型不匹配、空指针异常等。等本地跑通了再提交到集群，能节省大量时间。我见过不少初学者直接往集群提交，结果因为一个小错误反复提交几十次，每次都要等几分钟，效率极低。

本地模式还有一个好处是可以用IDE的断点调试。在map和reduce方法里打断点，单步跟踪执行流程，观察变量的值。这对于理解MapReduce的内部机制非常有帮助。集群模式下断点调试几乎不可能，因为代码运行在远程节点上。

6.6 序列化与WritableComparable接口

Hadoop的序列化机制和Java原生的Serializable不同。Java的Serializable会写入类名、字段名等元信息，序列化后的体积大、速度慢。Hadoop的Writable接口只写入数据本身，体积小、速度快，适合大规模数据传输。

如果你需要自定义key类型（比如用复合key做二次排序），必须实现WritableComparable接口，重写write、readFields和compareTo方法。write和readFields的顺序必须严格一致，否则反序列化会出错。compareTo决定了key的排序规则，也间接决定了哪些key会被分到同一个Reduce任务。

自定义Writable时有一个常见错误：在readFields里没有按write的顺序读取字段。比如write先写了int再写了String，readFields就必须先读int再读String。顺序错了不会报错，但数据会错乱，排查起来很痛苦。

7. 从单词计数看MapReduce的适用边界

单词计数跑通了，不代表MapReduce就万能了。MapReduce有它的适用场景和局限性。

适合的场景：批处理、离线分析、数据量大且计算逻辑可分解的任务。比如日志分析、数据清洗、ETL、倒排索引构建等。这些场景的特点是数据量大、对延迟不敏感、计算逻辑可以并行化。

不适合的场景：实时计算、迭代计算、图计算、交互式查询。MapReduce的启动开销大，每个作业至少需要几十秒才能跑起来，不适合低延迟场景。迭代计算（比如机器学习训练）需要反复读写HDFS，I/O开销大，后来被Spark的内存计算取代。图计算中节点之间的依赖关系复杂，MapReduce的表达能力有限，后来出现了Pregel、GraphX等专用框架。

但这不意味着MapReduce过时了。在很多企业的数据仓库里，MapReduce仍然是ETL的主力。它的稳定性、容错性和成熟的生态是其他框架难以替代的。而且，理解了MapReduce的分而治之思想，再学Spark、Flink等新框架时，会发现它们的核心思想一脉相承，只是实现上做了优化。

我个人在实际操作中的体会是：单词计数这个案例，值得反复写三遍。第一遍照着教程敲，跑通就行；第二遍不看教程自己写，遇到问题查文档；第三遍尝试优化，加Combiner、调参数、看Counter，观察每一步的变化。三遍下来，MapReduce的编程模型就刻在脑子里了。后面再遇到分组统计类的需求，基本就是条件反射地写出Mapper和Reducer的骨架，剩下的只是填充业务逻辑。

最后再分享一个小技巧：如果你用IDE开发，可以装一个Hadoop的插件，能直接在IDE里提交作业到集群并查看日志，省去手动打包上传的步骤。另外，把常用的配置项写成一个模板文件，每次新建作业时复制一份，能省不少事。这些看起来是小事，但日积月累能节省大量时间。