企业官网建设流程全解析

1. 这不是“Hello World”，而是理解分布式计算的真正起点

MapReduce这个词，现在听起来有点老派——就像在说“我用过诺基亚3310”。但如果你真想搞懂大数据系统底层怎么运转，绕不开它。我带过不少刚转行进数据工程的同学，他们一上来就猛学Spark、Flink，结果调个Join性能翻车，查半天才发现是Shuffle阶段数据倾斜没处理好。而这个“倾斜”问题的根源，恰恰就埋在MapReduce最朴素的两阶段模型里：Map负责拆解，Reduce负责聚合。官方wordcount实例，表面看只是统计文本里每个单词出现几次，但它像一把解剖刀，把分布式计算中数据分片、并行执行、中间键值传递、分区排序、归并聚合这些核心机制全摊开给你看。它不炫技，不包装，没有自动内存管理，没有SQL抽象层，你写的每一行map()和reduce()，都直接对应着物理节点上的真实计算行为。关键词“MapReduce学习”“wordcount实例”“Hadoop官方示例”，指向的从来不是一段可运行的代码，而是一套思维范式：如何把一个大问题，安全、可控、可预测地切开，再稳稳当当地拼回去。适合谁？不是只适合想考Hadoop认证的人，而是所有需要理解“为什么我的Spark作业跑得比别人慢三倍”的工程师；是那些在云上部署Flink任务时，发现checkpoint失败却不知从何排查的运维同学；甚至是做机器学习的算法同学——当你把特征工程写成MapReduce Job提交到集群，你就突然明白了什么叫“数据就绪成本”。它不教你怎么写花哨的UI，它教你如何让数据在千台机器间不迷路、不丢件、不超载。

2. 为什么非得从wordcount开始？这不是偷懒，是设计使然

2.1 官方案例的“极简主义”背后有严密逻辑

很多人觉得wordcount太简单，甚至有点“小儿科”。我第一次带实习生跑这个例子时，也这么想。直到有天凌晨两点，某公司生产环境的实时日志分析Pipeline卡死，下游告警狂响。我们回溯发现，问题出在一个自定义的Partitioner实现上——它本该把相同用户ID的日志打到同一个Reducer，结果因为哈希函数没处理null值，导致大量key被路由到同一个Reducer，整个Job卡在Shuffle阶段。而这个问题，在wordcount的源码里，Partitioner就是最基础的HashPartitioner，它的getPartition()方法只有三行：

public int getPartition(K2 key, V2 value, int numReduceTasks) { return (key.hashCode() & Integer.MAX_VALUE) % numReduceTasks; }

你看，它连null检查都没做。但这恰恰是教学意图：它逼你去想，“如果key是null，会怎样？”“如果numReduceTasks是0，会崩吗？”“& Integer.MAX_VALUE这步为什么不能少？”——这些看似琐碎的问题，正是分布式系统健壮性的基石。官方选择wordcount，不是因为它容易，而是因为它足够“干净”，没有任何业务逻辑干扰，所有复杂度都来自框架本身。它像一台拆掉外壳的发动机，活塞、曲轴、点火系统全部裸露，你一眼就能看清能量是怎么从燃料转化成扭矩的。相比之下，如果一上来就学“电商用户行为漏斗分析”，你会被埋在埋点格式、会话切割规则、设备ID归因逻辑里，根本看不到MapReduce在其中扮演什么角色。wordcount强制你聚焦在“数据流”本身：输入路径→InputFormat解析→Mapper处理→Shuffle传输→Reducer聚合→OutputFormat写出。每一个环节，你都能用System.out.println()打点验证，能用hadoop fs -cat直接查看中间文件，能用YARN UI看到每个Container的CPU/内存曲线。这种“可触摸感”，是任何高级框架封装都给不了的。

2.2 它精准覆盖了MapReduce的四大核心契约

MapReduce不是一堆API的集合，它是一组必须严格遵守的契约（Contract）。wordcount实例恰好把这四条契约全踩中了：

1. 输入契约：InputFormat必须将输入数据划分为逻辑上的InputSplit，每个Split由一个Mapper处理。官方示例用TextInputFormat，它把文件按行切分，每行生成一个<LongWritable, Text>键值对。这里的关键是：Split是逻辑切分，不是物理切分。一个10GB的大文件，可能被切成100个Split，但每个Split不一定对应一个独立文件块——HDFS的Block大小（默认128MB）和Split大小可以不同。实操中我见过有人误以为“一个Split=一个HDFS Block”，结果在小文件场景下，启动了上千个Mapper，光是JVM启动开销就把集群压垮。wordcount让你直面这个区别。

2. Mapper契约：Mapper类必须继承Mapper<KEYIN, VALUEIN, KEYOUT, VALUEOUT>，且map()方法必须是无状态的、幂等的。这意味着你不能在map()里缓存全局变量，不能依赖上一次调用的结果。我试过在map()里用static Map<String, Integer>计数，本地测试OK，一上集群就错——因为每个Mapper运行在独立JVM里，静态变量互不相通。wordcount的WordCountMapper只做一件事：把一行文本切词，对每个词输出<word, 1>。它不关心“上一行有没有这个词”，也不记录“总共处理了多少行”。这种纯粹性，是分布式并行的前提。

3. Shuffle契约：这是MapReduce最魔幻也最容易出错的一环。Mapper输出的<key, value>不会直接发给Reducer，而是先经过Partitioner分区、Sorter排序、Combiner（可选）局部聚合、GroupingComparator分组。wordcount默认用HashPartitioner，保证相同单词一定进同一个Reducer；用KeyComparator按字典序排；IdentityReducer作为Combiner时，能把<hello,1>,<hello,1>提前合并成<hello,2>，大幅减少网络传输量。很多初学者卡在这里，以为“Mapper输出啥，Reducer就收到啥”，结果发现Reducer收到的key已经排好序，value还是个迭代器——这正是Shuffle在默默工作。

4. Reducer契约：Reducer接收的是<key, Iterable<value>>，不是单个value。这是因为Shuffle已把所有相同key的value聚合成一个列表。wordcount的IntSumReducer遍历这个Iterable，累加求和。注意：这个Iterable不是Java的List，它是个延迟加载的迭代器，背后可能连着磁盘或网络流。你不能把它转成ArrayList再操作，否则可能OOM。我踩过坑：在Reducer里写了List<IntWritable> list = new ArrayList<>(values)，本地小数据没问题，一跑TB级数据，直接内存溢出。正确做法是边遍历边累加。

这四条契约，构成了MapReduce的“宪法”。wordcount不是教你怎么写业务代码，它是用最简案例，让你把这四条宪法刻进肌肉记忆。

2.3 它暴露了Hadoop生态最真实的“脏活累活”

现在大家谈大数据，张口闭口“云原生”“Serverless”，仿佛数据处理是点点鼠标就能完成的事。但wordcount会立刻把你拽回地面。比如，你得手动配置Job对象：

Job job = Job.getInstance(conf, "word count"); job.setJarByClass(WordCount.class); job.setMapperClass(TokenizerMapper.class); job.setCombinerClass(IntSumReducer.class); // 注意：Combiner不是必须，但这里用了 job.setReducerClass(IntSumReducer.class); job.setOutputKeyClass(Text.class); job.setOutputValueClass(IntWritable.class); FileInputFormat.addInputPath(job, new Path(args[0])); FileOutputFormat.setOutputPath(job, new Path(args[1]));

这段代码里藏着多少“脏活”？setJarByClass告诉集群：把包含这个类的jar包分发到所有Worker节点。如果忘了这句，集群会报ClassNotFoundException，而错误日志里根本不会提示你缺jar包，只会说“找不到Mapper类”。FileOutputFormat.setOutputPath指定的输出路径，必须是不存在的目录，否则Job直接失败——Hadoop拒绝覆盖，这是为数据一致性设的硬约束。还有args[0]和args[1]，它们是HDFS路径，不是本地路径。我见过太多人写new Path("/home/user/input.txt")，结果Mapper读不到文件，因为Worker节点的/home/user/下根本没有这个文件。你必须用hadoop fs -put先把本地文件上传到HDFS，再传HDFS路径进去。这些不是“设计缺陷”，而是分布式系统对确定性的敬畏：它宁可让你多敲几行命令，也不愿让你在数据丢失后抓瞎。wordcount强迫你直面这些细节，而不是躲在Spark SQL的spark.read.text()后面假装一切自动发生。

3. 深度拆解：从源码到集群，每一步都在教你怎么思考

3.1 Mapper的“切词”远不止String.split()那么简单

TokenizerMapper的核心逻辑是：

public 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); } }

表面看就是StringTokenizer切词，但这里有三个关键点常被忽略：

第一，StringTokenizer的默认分隔符是空格、制表符、换行符、回车符、换页符（\t\n\r\f）。它不处理标点符号。所以输入"Hello, world!"会被切为["Hello,", "world!"]，逗号和感叹号成了单词的一部分。这在真实场景中是灾难性的。解决方案不是换正则，而是用更鲁棒的分词器。我在某日志分析项目中，用Pattern.compile("\\W+").split(line)替代StringTokenizer，\W+匹配一个或多个非单词字符，这样"Hello, world!"就正确切为["Hello", "world"]。但要注意：正则编译有开销，如果每行都Pattern.compile()，性能会暴跌。正确做法是在Mapper的setup()方法里预编译一次：

private Pattern pattern; protected void setup(Context context) { pattern = Pattern.compile("\\W+"); } public void map(LongWritable key, Text value, Context context) { String line = value.toString().toLowerCase(); // 统一小写 String[] words = pattern.split(line); for (String word : words) { if (!word.trim().isEmpty()) { // 过滤空字符串 wordOut.set(word.trim()); context.write(wordOut, one); } } }

第二，context.write()不是立即发送，而是写入一个环形缓冲区（Ring Buffer）。这个缓冲区默认100MB，当使用率达到80%（io.sort.spill.percent=0.8f）时，触发Spill（溢写）：把缓冲区里的数据按key排序，写入本地磁盘，生成一个spillN.out文件。这个过程是异步的，由一个单独的线程执行，不影响Mapper继续处理新数据。但如果你的Mapper输出数据量极大（比如每行输出1000个key），缓冲区频繁Spill，磁盘IO会成为瓶颈。这时要调大缓冲区：conf.set("io.sort.mb", "200")。我在线上遇到过，一个Mapper处理压缩日志，解压后每行百万级token，不调缓冲区，Spill次数超500次，Job耗时增加40%。

第三，Text和IntWritable是Hadoop的序列化类型，不是Java原生类型。Text内部用byte[]存储，支持UTF-8编码；IntWritable是int的封装，实现了Writable接口，能高效序列化。你不能用String或Integer代替，否则context.write()会报错。为什么？因为Hadoop需要跨网络传输数据，必须知道怎么把对象变成字节流（serialize），又怎么从字节流还原（deserialize）。Writable接口强制你实现write(DataOutput out)和readFields(DataInput in)方法。Text.write()直接把byte[]写出去，IntWritable.write()写4个字节的int值。这种设计牺牲了Java的灵活性，换来了网络传输的极致效率。你写业务代码时，永远要用Text、IntWritable、LongWritable这些类型，这是铁律。

3.2 Shuffle阶段：MapReduce的“心脏”，也是最易被误解的部分

Shuffle常被简化为“Map端输出，Reduce端输入”，但真相复杂得多。它分为Map端和Reduce端两部分，wordcount的默认配置下，流程如下：

Map端Shuffle（Spill → Merge → Partition）：

• Mapper输出写入环形缓冲区。
• 缓冲区满80%，启动Spill线程：对缓冲区数据按key排序（QuickSort），按Partitioner分区（默认Hash），写入本地磁盘，生成spill0.out。
• 如果Mapper产生多个Spill文件（如spill0.out,spill1.out），在Mapper结束前，会启动Merge线程：把所有Spill文件归并（Merge Sort），按Partition合并成一个大文件all-r-00000，每个Partition的数据连续存放。这个文件就是Reducer要拉取的“Map Output”。

Reduce端Shuffle（Fetch → Merge → Sort → Reduce）：

• Reduce Task启动后，向所有Map Task所在节点发起HTTP请求，拉取属于自己Partition的数据（即all-r-00000中对应分区的片段）。
• 拉取的数据先存入内存缓冲区（mapred.reduce.parallel.copies=5，默认并发拉5个），当内存使用率达66%（mapred.job.shuffle.input.buffer.percent=0.7f），或拉取数据超256MB（mapred.job.shuffle.merge.percent=0.66f），触发Merge：把内存和磁盘中的数据归并排序，生成最终的reduce-input文件。
• 此时数据已按key全局排序，且相同key的value已分组。Reducer的reduce()方法才开始执行。

这个过程暴露了两个关键设计哲学：

1. “本地优先”原则：Reduce尽量从同一机架（Rack）的NodeManager拉取数据，减少跨机架网络流量。Hadoop通过NetworkTopology类维护节点拓扑，getDistance()方法计算距离。如果集群跨机房部署，这个距离计算直接影响Shuffle速度。

2. “内存-磁盘”双缓冲策略：既不让数据全进内存（OOM风险），也不全写磁盘（IO瓶颈），而是动态平衡。参数mapred.job.reduce.input.buffer.percent控制Reduce端内存缓冲区占比，默认0.0，即全走磁盘。我在线上把这值调到0.7，配合加大mapred.reduce.child.java.opts="-Xmx4g"，Shuffle阶段耗时下降35%。

最常被问的问题：“为什么Reducer收到的value是Iterable，不是List？”答案就在Merge过程：归并排序后，相同key的value是物理连续的，但数量未知。Iterable是一个轻量级接口，它不加载所有value到内存，而是按需从磁盘/网络流中读取下一个value。你调用iterator.next()时，它才去读。这避免了Reducer内存被海量value撑爆。如果你强行Lists.newArrayList(values)，等于把整个磁盘文件读进内存，是典型反模式。

3.3 Reducer的“求和”藏着资源调度的生死线

IntSumReducer代码极简：

public 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); }

但这一小段，决定了整个Job的资源消耗模式：

第一，Reducer的并行度由numReduceTasks决定，它不是越多越好。numReduceTasks默认是1，意味着所有key都送到一个Reducer。如果输入是10亿行日志，单词总数千万级，这个Reducer要处理所有<word, [1,1,1,...]>，内存和CPU压力巨大。合理设置是：numReduceTasks = min(可用Reducer Slots, 估计key数 / 1000)。例如，集群有100个Reducer Slot，预计单词数500万，则设numReduceTasks=50。计算依据是：每个Reducer处理约10万个key，内存占用可控。我见过有人设成200，结果YARN拒绝分配资源，因为集群没那么多Slot。

第二，context.write()在Reducer里同样走缓冲区，但触发条件不同。Reducer的缓冲区叫reduce-output-buffer，默认100MB。当它满时，不是Spill，而是直接写入最终输出目录（HDFS）。这意味着：Reducer的输出是“流式”的，不是等所有key处理完才写。这对大Job很关键——你能在Job运行中，用hadoop fs -ls /output/_temporary/看到不断生成的part-r-00000,part-r-00001等文件。

第三，输出路径的“临时目录”机制保障原子性。Job成功时，Hadoop把/output/_temporary/下的所有part-r-*文件移到/output/下，并删除临时目录。Job失败时，临时目录保留，方便排查。你绝不能手动删/output/，否则下次Job会因输出路径存在而失败。正确清理方式是：hadoop fs -rm -r /output，然后重跑。

还有一个隐藏陷阱：IntWritable的get()方法返回int，但如果value是LongWritable，get()会强制转型，可能丢失精度。wordcount用IntWritable是因为单词频次一般不大。但如果你统计PV，一天百亿次，就得用LongWritable。类型不匹配，get()返回0，结果全错。我在某广告计费系统里，就因Mapper输出LongWritable，Reducer用IntWritable接收，导致所有曝光量显示为0，排查三天才发现。

4. 实操全流程：从本地调试到集群提交，一步都不能省

4.1 本地模式（LocalRunner）：你的第一道防火墙

别急着上集群。90%的逻辑错误，能在本地模式发现。Hadoop提供LocalRunner，它用单JVM模拟MapReduce全流程，不依赖HDFS/YARN。

步骤一：准备本地输入文件创建input/wordcount.txt：

Hello World Hello Hadoop Goodbye World

步骤二：编写主类，强制启用本地模式

public class WordCountLocal { public static void main(String[] args) throws Exception { Configuration conf = new Configuration(); // 关键：强制本地模式 conf.set("fs.defaultFS", "file:///"); conf.set("mapreduce.framework.name", "local"); String[] otherArgs = new GenericOptionsParser(conf, args).getRemainingArgs(); if (otherArgs.length != 2) { System.err.println("Usage: wordcount <in> <out>"); System.exit(2); } Job job = Job.getInstance(conf, "word count local"); job.setJarByClass(WordCountLocal.class); job.setMapperClass(TokenizerMapper.class); job.setCombinerClass(IntSumReducer.class); job.setReducerClass(IntSumReducer.class); job.setOutputKeyClass(Text.class); job.setOutputValueClass(IntWritable.class); FileInputFormat.addInputPath(job, new Path(otherArgs[0])); FileOutputFormat.setOutputPath(job, new Path(otherArgs[1])); System.exit(job.waitForCompletion(true) ? 0 : 1); } }

步骤三：编译打包，本地运行

# 编译 javac -cp $(hadoop classpath) *.java # 打jar包（注意Main-Class） jar -cvf wordcount-local.jar -C . . -e WordCountLocal # 运行（输入输出都是本地路径） hadoop jar wordcount-local.jar input/wordcount.txt output-local # 查看结果 cat output-local/part-r-00000

为什么本地模式是防火墙？

• 它能捕获NullPointerException、ClassCastException等运行时异常。集群模式下，这些错误常被淹没在YARN日志里，定位极难。
• 它验证InputFormat/OutputFormat是否正确。比如TextInputFormat读二进制文件会报错，本地模式立刻告诉你。
• 它测试Combiner逻辑。Combiner是Map端的Reducer，如果逻辑有误（如IntSumReducer用于非求和场景），本地模式会直接失败。

我坚持一个原则：任何MapReduce Job，必须先通过本地模式，再上集群。这是节省时间的最有效方式。

4.2 伪分布式模式（Pseudo-Distributed）：集群的“缩小版沙盒”

本地模式不涉及HDFS和YARN，伪分布式模式则启动真正的HDFS NameNode/DataNode和YARN ResourceManager/NodeManager，但全在一台机器上。这是上线前的必经沙盒。

配置要点（$HADOOP_HOME/etc/hadoop/）：

• core-site.xml：fs.defaultFS指向hdfs://localhost:9000
• hdfs-site.xml：dfs.replication设为1（单节点，无法副本）
• mapred-site.xml：mapreduce.framework.name设为yarn
• yarn-site.xml：yarn.nodemanager.aux-services设为mapreduce_shuffle

启动流程：

# 格式化HDFS hdfs namenode -format # 启动HDFS start-dfs.sh # 启动YARN start-yarn.sh # 验证：jps应看到NameNode, DataNode, ResourceManager, NodeManager jps

上传输入文件到HDFS：

hadoop fs -mkdir -p /input hadoop fs -put input/wordcount.txt /input/

提交Job（注意路径是HDFS路径）：

hadoop jar wordcount.jar WordCount /input /output

监控与日志：

• Web UI：http://localhost:9870（HDFS）,http://localhost:8088（YARN）
• 查看Job历史：yarn logs -applicationId application_XXXXX_XXXX
• 查看Task日志：YARN UI里点进Application，再点“Logs”标签页

伪分布式模式的价值在于：它暴露了真实集群的交互细节。比如，你第一次会发现hadoop fs -ls /output看不到结果，因为Job还没完成；你会看到YARN UI里Application的状态从ACCEPTED到RUNNING再到FINISHED；你会在DataNode日志里看到块复制的INFO信息。这些体验，是本地模式给不了的。

4.3 真实集群提交：参数调优是成败关键

上生产集群，不能再靠默认参数。以下是我总结的6个必调参数，基于wordcount类Job的通用规律：

提交命令示例（带参数）：

hadoop jar wordcount.jar WordCount \ -D mapreduce.map.memory.mb=2048 \ -D mapreduce.reduce.memory.mb=3072 \ -D mapreduce.task.io.sort.mb=200 \ -D mapreduce.reduce.shuffle.parallelcopies=10 \ -D mapreduce.input.fileinputformat.split.minsize=134217728 \ -D mapreduce.output.fileoutputformat.compress=true \ /input /output

关键经验：

• 不要一次性调所有参数。先调split.minsize解决Mapper爆炸问题，再调内存参数。每次只改1-2个，对比YARN UI里的Duration和Resource Usage。
• 内存参数单位是MB，不是GB。写成-D mapreduce.map.memory.mb=2G会报错，必须是数字。
• 压缩需额外配置。开启compress=true后，还需指定编码器：-D mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.LzopCodec，并确保集群所有节点安装了LZO库。

我曾帮某客户优化一个日志分析Job，他们用默认参数跑1TB数据要8小时。按上表调参后，降到3.2小时，成本直接降60%。参数不是玄学，是可测量、可复现的工程实践。

5. 常见问题与排查技巧实录：那些年踩过的坑，都成了经验

5.1 “No job jar set” —— 最经典的入门陷阱

现象：本地运行OK，集群提交报错：

Exception in thread "main" java.lang.IllegalArgumentException: No job jar set. Please set the jar file with: setJar(String jar) or setJarByClass(Class<?> cls)

原因：Job.getInstance(conf)创建的Job对象，没有设置jar包路径。虽然setJarByClass()写了，但可能位置不对，或者类名写错。

排查步骤：

1. 检查setJarByClass()是否在Job job = Job.getInstance(...)之后立即调用；
2. 检查传入的Class是否是当前Job的主类（含main方法的类），不是Mapper或Reducer类；
3. 检查jar包是否真的包含这个类：jar -tf wordcount.jar | grep WordCount。

根治方案：在main方法开头，用getClass().getProtectionDomain().getCodeSource().getLocation()动态获取jar路径：

URL jarUrl = WordCount.class.getProtectionDomain() .getCodeSource().getLocation(); job.setJar(jarUrl.getPath());

5.2 “Output directory already exists” —— 数据一致性的铁律

现象：第二次运行Job失败，报错：

org.apache.hadoop.mapred.FileAlreadyExistsException: Output directory hdfs://.../output already exists

原因：Hadoop要求输出路径必须不存在，这是为防止意外覆盖数据。不是Bug，是Feature。

解决方案：

• 开发阶段：每次运行前加清理命令hadoop fs -rm -r /output
• 生产阶段：用时间戳命名输出路径，如/output/20231001，或用Date生成唯一路径
• 脚本化：写Shell脚本，自动检测并清理：

  OUTPUT_PATH="/output" if hadoop fs -test -d $OUTPUT_PATH; then echo "Output path exists, deleting..." hadoop fs -rm -r $OUTPUT_PATH fi

提示：永远不要在Reducer里写FileSystem.delete()清理输出路径，这违反了MapReduce的职责分离原则，且可能导致竞态条件。

5.3 “Too many fetch failures” —— Shuffle失败的幽灵

现象：Job卡在RUNNING，Reducer状态一直是COPYING，YARN日志里反复出现：

Fetcher failed to fetch from ... Too many fetch failures

原因：Reduce拉取Map输出时失败次数超限（默认3次）。常见于：

• Map Task所在NodeManager宕机；
• 网络抖动，HTTP连接超时（默认60秒）；
• Map输出文件损坏（Spill时磁盘满）。

排查与解决：

1. 在YARN UI里，点开失败的Application，看“Failed Tasks”里哪个Reducer失败，再点进去看“Logs”；
2. 搜索日志中的Fetcher关键字，看具体失败原因；
3. 调大重试参数：-D mapreduce.reduce.shuffle.maxfetchfailures=10；
4. 调长超时：-D mapreduce.reduce.shuffle.fetch.retry.timeout-ms=120000；
5. 检查集群磁盘空间：df -h，DataNode磁盘满是高频原因。

5.4 “java.lang.OutOfMemoryError: Java heap space” —— 内存泄漏的信号

现象：Mapper或Reducer Container崩溃，YARN日志报OOM。

定位方法：

• 查YARN日志，找到OOM的Container ID（如container_123456789_0001_01_000002）；
• 用yarn logs -applicationId application_123456789_0001 -containerId container_123456789_0001_01_000002下载完整日志；
• 搜索java.lang.OutOfMemoryError，看是heap space还是metaspace。

针对性解决：

• Heap OOM：增大mapreduce.map.memory.mb或mapreduce.reduce.memory.mb，同时调大JVM堆：-D mapreduce.map.java.opts="-Xmx1800m"（堆设为内存的80%）；
• Metaspace OOM：增大-D mapreduce.map.java.opts="-XX:MaxMetaspaceSize=512m"；
• 代码级泄漏：检查Mapper/Reducer里是否有静态集合（static List）、未关闭的流（InputStream）、大对象缓存。我修复过一个案例：Mapper里用static Map<String, String>缓存配置，导致内存随Mapper数线性增长。

5.5 “Illegal partition for …” —— 分区越界的静默杀手

现象：Job运行中突然失败，错误：

java.lang.IllegalArgumentException: Illegal partition for hello (2) instead of between 0 and 1

原因：Partitioner.getPartition()返回的分区号超出了Reducer数量范围。例如，numReduceTasks=2，但Partitioner返回了2或更大。

根因分析：

• 自定义Partitioner里，return key.hashCode() % numReduceTasks，但hashCode()可能为负数，负数取模结果为负，再加numReduceTasks才能归正；
• 或者numReduceTasks配置为0（非法值）。

修复代码：

public int getPartition(Text key, IntWritable value, int numReduceTasks) { int hash = key.hashCode(); // 处理负数hashCode return (hash & Integer.MAX_VALUE) % numReduceTasks; }

注意：& Integer.MAX_VALUE是标准做法，它把最高位（符号位）清零，得到一个正整数，再取模就安全了。

5.6 “No route to host” —— 网络配置的隐形墙

现象：Reducer无法连接Map Task，报错No route to host或Connection refused。

排查清单：

• 检查防火墙：sudo ufw status（Ubuntu）或sudo firewall-cmd --state（CentOS），确保9000（HDFS）、8032（YARN RM）、8042（YARN NM）端口开放；
• 检查/etc/hosts：确保所有节点的hostname能正确解析，不能只写127.0.0.1 localhost，要加上集群IP和hostname映射；
• 检查Hadoop配置：yarn-site.xml里yarn.resourcemanager.hostname必须是可被所有NodeManager访问的IP，不能是localhost；
• 检查SELinux：sudo sestatus，如为enabled，临时禁用sudo setenforce 0测试。

这个问题往往耗费最多时间，因为它不在代码里，而在基础设施层。我的建议是：集群搭建完成后，先用telnet <host> <port>逐个测试所有关键端口连通性，再跑wordcount。

6. 从wordcount出发，你能走多远？

写到这里，你可能觉得：“不就是个统计单词的程序吗？值得讲这么多？”但我想说，wordcount不是终点，它是你进入分布式数据世界的船票。我见过太多人，把MapReduce当成过时技术，转身扑向Spark，结果在Spark的repartition()和coalesce()之间反复横跳，却说不清它们和MapReduce的Partitioner本质区别在哪。其实，repartition()就是Shuffle，coalesce()就是不Shuffle的合并，底层逻辑一脉相承。

你可以用wordcount的骨架，快速搭建真实场景：

• 日志清洗：Mapper里加正则过滤无效日志，Reducer里聚合错误码分布；
• ETL流水线：Mapper解析JSON日志，输出<user_id, event_json>，Reducer按用户ID聚合行为序列；
• 机器学习特征工程：Mapper计算单条样本的TF-IDF，Reducer做全局词频统计；
• 图计算预处理：Mapper把邻接表转为