企业官网建设流程全解析

简介：Hadoop实验报告资源包内含1份doc文档，对应一个完整的MapReduce编程实践案例，适合刚接触大数据平台的学生或初级开发者参考。报告基于Window11与Hadoop虚拟机环境，围绕WordCount单词统计程序从环境配置、Eclipse插件安装、MapReduce项目创建到代码编写与运行展开，详细展示了Hadoop编程入门的关键步骤。其中附有可直接使用的Wordcount.java源码，涵盖Mapper、Reducer及Job配置的完整实现，并包含实验目的、环境说明、操作流程和结果分析，可帮助读者少走弯路。文档整体仅758KB，内容紧凑，便于下载阅读。该资源已有1727人学习下载，对于正在完成相关课程设计或准备Hadoop实验报告的用户具有一定借鉴价值。

1. WordCount凭什么成为Hadoop入门的第一道坎

很多人第一次接触Hadoop，就是被老师丢过来一个实验题目——“用MapReduce写一个WordCount单词统计程序”。看起来不过是数一数每个单词出现了几次，好像随便用Python写几行就能搞定的事，为什么要跑到分布式框架里绕一大圈。但如果你真的在虚拟机上配过伪分布式环境、写完了Java代码、打成一个jar包再扔给Hadoop跑完，你会发现这个“Hello World”其实把MapReduce的核心心智模型全串起来了：数据怎么切分、Map阶段怎么并行、Shuffle怎么做中间传输、Reduce怎么汇总输出。这篇文章就是按照一份标准的大数据实验报告流程，从零到一讲清楚WordCount该怎么落地，环境怎么搭、代码每一行什么意思、运行报错怎么排查，以及实验报告里哪些坑不值得再踩一遍。

2. 环境准备：伪分布式Hadoop的搭建与最低可行配置

2.1 为什么推荐先在单机伪分布式上练手

一开始就上分布式集群其实是给自己挖坑。三种部署模式里，集群模式适合已经能熟练定位问题的人，单机本地模式适合跑通逻辑，但真正贴近实验报告要求的，是伪分布式模式——用一台机器上的多个Java进程模拟HDFS的NameNode、DataNode以及YARN的ResourceManager、NodeManager。这样的好处很明显：WordCount的提交方式、日志输出、资源分配流程和真实集群几乎一致，而排查问题只需要盯着一台机器。

Hadoop的安装方式常见的有源码编译、从Apache官网下载release tar包、用Docker镜像拉起来。对实验报告这种场景，我一般首选Apache官方编译好的二进制tar包，不需要碰编译工具链，版本直接选Hadoop 2.10.x或者3.3.x皆可。3.x版本在YARN默认端口上有变化，但WordCount本身不受影响。关键是JDK版本要匹配——如果用的是Hadoop 3.x，JDK 8或11都可以；如果是2.10.x，老老实实用JDK 8，否则启动ResourceManager时会被莫名其妙的Java版本问题卡住。

2.2 从解压到启动五步走

第一步，把tar包解压到固定路径并配置环境变量。常见的做法是：

sudo tar -xzvf hadoop-3.3.6.tar.gz -C /usr/local/ sudo mv /usr/local/hadoop-3.3.6 /usr/local/hadoop sudo chown -R $USER:$USER /usr/local/hadoop

为什么要单独执行一次chown？因为Hadoop在运行过程中会往安装目录下写临时文件和pid文件，如果你用root启动再切换到普通用户操作，后续删日志、改配置都会遇到权限问题。这一步看起来琐碎，实际能省掉后面很多“Permission denied”的报错。

第二步，配置~/.bashrc里JAVA_HOME和HADOOP_HOME：

export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 export HADOOP_HOME=/usr/local/hadoop export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin

配好后务必执行source ~/.bashrc并验证hadoop version能正常输出。这一步翻车率最高，但如果hadoop version输出了版本信息，说明最底层的环境变量链路已经通了。

第三步，修改etc/hadoop/hadoop-env.sh里的JAVA_HOME。这步很关键，因为hadoop命令本身能读到环境变量，不代表NameNode的启动脚本也能读到，启动脚本会独立解析hadoop-env.sh里的配置。

echo "export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64" >> $HADOOP_HOME/etc/hadoop/hadoop-env.sh

第四步，配置三个核心文件。core-site.xml声明NameNode地址和临时目录：

<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/usr/local/hadoop/tmp</value> </property> </configuration>

hdfs-site.xml设置副本数为1，因为伪分布式只有一个DataNode：

<configuration> <property> <name>dfs.replication</name> <value>1</value> </property> </configuration>

mapred-site.xml声明MapReduce运行在YARN之上。注意这个文件在发行包里可能叫mapred-site.xml.template，需要先复制一份再改。用YARN而不是local模式，目的是让WordCount的提交路径贴近真实集群。

<configuration> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> </configuration>

第五步，格式化NameNode并启动服务。这里有一条血泪经验：NameNode的格式化只需要做一次。很多新手第一次把配置文件改好之后，启动时发现进程挂掉，于是反复执行hadoop namenode -format，第二次格式化会生成新的clusterId，导致DataNode拿着旧clusterId注册不上，反过来报NameNode连接失败。正确姿势是只格式化一次，然后用start-dfs.sh和start-yarn.sh启动，用jps命令确认五个Java进程都在：NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager。

2.3 HDFS上的目录准备与数据上传

WordCount要处理的文件在HDFS上，所以先建好目录，再把你准备统计的文本文件传进去。

hdfs dfs -mkdir -p /input hdfs dfs -put /home/user/word.txt /input/

常见做法是用一些公开语料做测试，比如把莎士比亚文集、或者几十篇英文新闻稿拼成一个文件。不过实验报告场景下，我建议自己准备两个以上的小文件分别上传到两个目录，这样可以验证Map阶段能处理多个分片。文件不用大，几百KB足够体现出MapReduce的价值，也方便你反复跑测试而不必等待太久的调度时间。

如果你只想快速验证，也可以直接在HDFS上用命令行生成输入文件：

echo "hello hadoop hello world hadoop" | hdfs dfs -appendToFile - /input/word.txt

这种方式绕开了本地和远程目录的混淆问题，也不用担心-put目录指错。

3. 编写WordCount程序：Map阶段到Reduce阶段全拆解

3.1 Mapper类的输入输出到底在传什么

写MapReduce实验报告，最怕的是把Map和Reduce当成两个孤立的函数来写，代码能跑，但问起中间的Shuffle阶段发生了什么就答不上来。实际上MapReduce的数据流是固定的：Mapper吃进去的是LongWritable偏移量和Text一行文本，吐出来的是Text单词和IntWritable计数1；这些KV对经过Shuffle的排序、分组之后，Reducer收到的是Text单词和Iterable<IntWritable>的一组计数列表。

这里为什么不用Java的String和Integer？因为Hadoop的序列化机制要求所有在节点间传输的数据类型必须是Writable接口的实现，这样才能被高效地序列化和反序列化。LongWritable、IntWritable、Text本质上是Hadoop对基础Java类型的分布式封装。知道这一层，你写Mapper的泛型声明时就不会随手写错。

import java.io.IOException; import org.apache.hadoop.io.IntWritable; import org.apache.hadoop.io.LongWritable; import org.apache.hadoop.io.Text; import org.apache.hadoop.mapreduce.Mapper; 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(); String[] words = line.split("\\s+"); for (String w : words) { if (w.isEmpty()) { continue; } word.set(w); context.write(word, one); } } }

这段代码的逻辑说明：split("\\s+")按空白字符切分一整行，能同时处理空格、Tab等分隔符；空字符串跳过，避免把连续的多个空格切出来的空串也写进结果。context.write(word, one)每遇到一个单词就输出一个(word, 1)，相同单词会在Shuffle阶段自动聚合到同一个Reducer。有个细节值得注意：word被复用为同一个对象，只是因为每次set覆盖了内容，而context.write在写入时会序列化当前内容，所以这个复用习惯在MapReduce编程里是安全的。

3.2 Reducer类不能只做加法

Reducer的输入是(单词, [1, 1, 1, ...])，最朴素的实现当然是全部加起来输出(单词, 总数)。但从实验报告的角度，Reducer是可以展示更多设计感的：你可以在累加的同时输出词频排名，或者在Reducer里做一次全局统计，看哪些单词超过某个阈值。不过这些都属于进阶内容，最基础的实现长这样：

import java.io.IOException; import org.apache.hadoop.io.IntWritable; import org.apache.hadoop.io.Text; import org.apache.hadoop.mapreduce.Reducer; 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<IntWritable>是Shuffle完成后Reducer收到的同一个key对应的全部value迭代器。这里有一个容易忽略的细节，values迭代器只能遍历一次，如果你在第一次循环里做了累加，又想再遍历一遍计算其他指标，会发现拿不到数据了——因为Hadoop为了内存效率，这个Iterable不是内存中的完整List，而是从底层数据流里边读边丢。如果想二次遍历，中途就得手动暂存成List<IntWritable>。

3.3 main里三个参数的顺序别搞反

主类负责组装整个Job。MapReduce的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 WordCount { public static void main(String[] args) throws Exception { Configuration conf = new Configuration(); Job job = Job.getInstance(conf, "word count"); job.setJarByClass(WordCount.class); job.setMapperClass(WordCountMapper.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); } }

参数说明：setOutputKeyClass和setOutputValueClass设置的是Reducer的输出类型，也就是最终写进HDFS的KV类型。如果你的Map输出类型和Reduce输出类型不一样，还要额外用setMapOutputKeyClass和setMapOutputValueClass声明。waitForCompletion(true)的参数表示是否打印进度信息，实验时建议保持true，这样能在控制台实时看到Map和Reduce的进度百分比。

如果你在运行后看到“java.lang.Exception: java.io.IOException: Type mismatch in key from map”这类错误，十有八九是Map的输出类型声明和实际情况对不上。这个错在基础实验里很典型，因为Map输出是(Text, IntWritable)，如果只设了setOutputKeyClass(Text.class)而没设Map输出类型，框架会默认把setOutputKeyClass当作Map和Reduce共同的输出类型，一旦Reducer输出类型不同就翻车。

4. 打包运行：从Eclipse/IDEA到命令行提交

4.1 用Maven管理依赖最省心

写实验代码时可以不用Maven，直接下载Hadoop安装目录下的全部jar包加到classpath里。这种做法在第一次跑通时没什么问题，但有一个隐患：Hadoop 3.x的安装包里有几百个jar，官方自带的lib目录中依赖版本繁杂，你import包的时候很容易引入重复的依赖，运行时抛出ClassNotFoundException或者NoSuchMethodError。更干净的做法是新建Maven项目，只声明需要的hadoop-client依赖。

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

Maven会自动把hadoop-client相关的依赖树拉下来。如果你的网络环境访问Maven中央仓库慢，可以临时换用阿里云镜像。值得注意的是，hadoop-client依赖并不会把所有Hadoop模块都打包进来，但MapReduce客户端所需的最小子集肯定够了。实验环境的Hadoop版本和Maven依赖版本最好保持一致，版本差太远时，客户端提交作业可能和ResourceManager的协议对不上，报InvalidConfigurationException或ApplicationSubmissionException。

4.2 打jar包的小细节

用IDEA打成jar包时，常规做法是在Project Structure里添加Artifact，选择“JAR → From modules with dependencies”。这里有一个极容易踩的坑：如果你选了“Include dependencies in JAR”，Maven打出的fat jar会把Hadoop的很多类也压进去，运行时如果Hadoop自己的classpath顺序导致类加载冲突，可能报一堆奇怪的异常。正确做法是选“extract”还是“copy dependencies”其实无所谓，关键是打出jar后确认体积。一般WordCount项目的jar包只有几KB，那说明是干净包；如果几十MB，说明把依赖也打进去了，运行时出问题的概率会明显变大。

下面是在命令行用Maven直接打包的方式：

mvn clean package -DskipTests

成功后，在target/目录下会得到类似wordcount-1.0-SNAPSHOT.jar的文件。提交作业时的格式是hadoop jar <jar包> <主类全类名> <输入路径> <输出路径>，主类全类名指像com.example.WordCount这样的完全限定名。有的人会省略主类名，前提是META-INF/MANIFEST.MF里配置了Main-Class，但如果换机器重新打包，这一项往往会丢，所以命令里显式写主类名最稳。

4.3 在YARN上提交并观察任务生命周期

hadoop jar target/wordcount-1.0-SNAPSHOT.jar com.example.WordCount /input /output

这条命令背后的完整流程是：客户端读取配置，向ResourceManager提交Application；ResourceManager找一个NodeManager启动ApplicationMaster；ApplicationMaster再为Map和Reduce任务申请Container。因此你会在控制台看到一段动态进度日志，从map 0% reduce 0%逐步增长。如果一切正常，任务结束后执行以下命令验证结果：

hdfs dfs -cat /output/part-r-00000

补充一个验证的小技巧：HDFS输出目录必须是“不存在”的，因为框架怕覆盖原有数据，如果目录存在会直接报FileAlreadyExistsException。这是设计行为，不是bug。写完一篇实验报告的同学，至少有一半会在这里反复翻车，所以每次跑新任务前，要么换一个新输出路径，要么先hdfs dfs -rm -r /output。

4.4 从part-r-00000文件里读出点什么

正确跑通的输出文件不止一个，part-r-00000是第一个Reducer的结果文件。因为输入文件很小，最终只有一个Reducer，所以只会有一个part文件。如果Reduce任务数大于1，你会看到part-r-00000、part-r-00001等多个文件，文件里的内容是各个Reducer“分到”的那部分单词统计结果。如果需要把所有结果合并成一个文件用于后续分析，常见做法是：

hdfs dfs -getmerge /output /home/user/wordcount_result.txt

getmerge会把多个part文件按名字顺序拼接成一个本地文件。这个小命令在写实验报告的数据分析部分非常有用，不用逐个去cat。另外，文件的第一列是单词，第二列是频次，两列之间是Tab，如果后面要导入Excel或Python做进一步统计，这个格式可以直接读。

5. WordCount运行排错：5个高频故障从现象到根治

5.1 现象：运行命令后提示“Permission denied: user=root, inode=/user”

这个错出现在你把输入文件上传到HDFS后准备提交作业时。原因是HDFS的根目录/user默认权限是drwxr-xr-x，但Hadoop作业的工作目录需要是/user/<当前用户名>，如果当前用户是root，而HDFS上根本没有/user/root这个目录，就会被拒。

解决方法是直接在HDFS上创建对应目录并授权：

hdfs dfs -mkdir -p /user/root hdfs dfs -chown root:root /user/root

顺带说明一下：实验报告里这个错误经常和“本地文件权限”混淆，其实HDFS的权限模型和Linux是独立的，本地chmod 777改变不了HDFS侧的授权判断。

5.2 现象：Map完成100%后卡住不动，Reduce进度一直为0%

在网络上的Hadoop实验报告里，这是出现频率极高的“Bug”。原因往往不是代码错了，而是伪分布式环境下NodeManager给Map任务分配的Container资源没有被正确回收，或者说在提交作业时YARN没有正确配置虚拟内存检查。常见表现是日志里反复出现Container is running beyond virtual memory limits。

解决方向有两个：一是关掉虚拟内存检查，二是把物理内存设置调大。实验环境直接关掉最省事，编辑etc/hadoop/yarn-site.xml，增加：

<property> <name>yarn.nodemanager.vmem-check-enabled</name> <value>false</value> </property>

修改后重启yarn-daemon.sh stop resourcemanager和start-yarn.sh。但注意，如果是在真实小集群上跑正式任务，不建议关这个检查，它本身是为了防止单个Container吃掉整机内存。

5.3 现象：Jar包能提交，但运行到一半报“ClassNotFoundException: com.example.WordCountMapper”

这个错误非常迷惑，因为提交日志显示主类找到了，作业也申请到了Container，但在Map任务启动加载Mapper类时找不到了。这种情况最可能的根因是打的jar包没有把Mapper和Reducer类打进去，只是把主类打了进去，或者打的是“空的”jar包。运行下面的命令检查jar包内容：

jar tf target/wordcount-1.0-SNAPSHOT.jar | grep WordCount

如果输出里确实没有WordCountMapper或WordCountReducer的class，那就回到Maven的pom.xml，确认没有把maven-jar-plugin错误配置成“只打包主类”。另一种常见情况是fat jar依赖冲突，把Hadoop自带的某个旧版本类给覆盖了，此时优先改成干净jar包。

5.4 现象：提示“java.lang.OutOfMemoryError: Java heap space”

这个报错通常出现在两个地方：一个是Map阶段的split大文件，另一个是Reducer收获大量key时JVM堆不够。你在本机跑通时不会遇到，因为本机内存大，而到了伪分布式环境，默认Map和Reduce任务的堆大小都很保守。

在实验报告中体现解决办法有两种方式，推荐直接调整mapred-site.xml里的参数，不要改代码：

<property> <name>mapreduce.map.java.opts</name> <value>-Xmx1024m</value> </property> <property> <name>mapreduce.reduce.java.opts</name> <value>-Xmx1024m</value> </property>

注意mapreduce.map.memory.mb和mapreduce.map.java.opts要配套，前者是Container内存上限，后者是JVM堆上限。如果只改java.opts，而Container上限不够，作业会在启动阶段直接被NodeManager杀掉。

5.5 现象：HDFS进入SafeMode，文件只读不能写入

如果你在跑WordCount之前做了文件删除或格式化操作，可能遇到NameNode进入SafeMode的情况。此时你执行hdfs dfs -put或-rm都会得到Name node is in safe mode提示。

原因通常是DataNode上报的数据块数量还没有达到阈值，或者你重启HDFS时强制退出了某进程。这不是致命故障，但会中断实验。可以强制退出等待，也可以用命令直接离开SafeMode：

hdfs dfsadmin -safemode leave

需要注意的是，leave只是临时退出状态，如果底层块上报不完整，NameNode可能会再次进入SafeMode。此时应该检查hdfs dfsadmin -report看DataNode是否正常注册，不要反复执行格式化。

6. 从WordCount延伸出去：Combiner、自定义InputFormat和实验报告的加分写法

6.1 一个最少必要改动：加Combiner减少Shuffle传输量

WordCount的代码跑通之后，最值得做的第一个优化就是给自己写的Reducer加一个Combiner。Combiner是一个运行在Map端的“预Reducer”，它在数据被写入磁盘和传输给Reducer之前先做一次本地汇总。对于WordCount这种累加型任务，Combiner的类可以直接复用Reducer类，然后只在Job配置里加一行：

job.setCombinerClass(WordCountReducer.class);

注意Combiner不能随便复用Reducer类：Combiner的输入和输出类型必须兼容Map的输出类型和Reduce的输入类型。WordCount里Map输出(单词, 1)，Combiner也输出(单词, 累加和)，类型完全一致，所以可以直接复用。凡是遇到“求平均值”这类任务，直接复用Reducer做Combiner会把结果算错，因为平均值不可叠加。这是MapReduce面试里非常经典的一个考点，在实验报告的“结果分析”部分提一句Combiner对传输数据的削减作用，很容易让报告显得不只是在应付作业。

6.2 自定义InputFormat处理非纯文本输入

很多实验报告写到这里就收尾了，但如果你有精力，可以向“自定义InputFormat”的方向再走一小步。WordCount默认用的是TextInputFormat，它把文件按行切分。如果输入文件不是纯文本，比如日志文件中每行的时间戳和消息混合在一起，你需要自定义InputFormat的RecordReader，让它只把消息部分作为value传给Mapper。

自定义InputFormat的核心类是FileInputFormat的子类加一个RecordReader。不过这个改动对实验报告的复杂度跳跃比较大，建议只在最终讨论环节提出思路，不必把完整代码写进实验报告。真实项目中，比如分析Nginx日志、处理JSON格式的半结构化数据时，这种定制化能力才是WordCount无法覆盖的边界。

6.3 实验报告里怎么写“运行结果分析”才不空洞

实验报告的“结果与分析”章节是最容易被写成流水账的地方。很多人的写法是：“运行成功，控制台输出如下，结果正确，实验结束。”这样写分数一般不会高。更有说服力的写法是：

一是记录不同输入规模下的运行时间对比。可以准备一个10MB的文件和一个100MB的文件，分别统计Map阶段的处理时长，分析“随输入增大，Map任务耗时接近线性增长这一事实是否成立”。伪分布式环境下，单节点并行度有限，增长趋势与理论接近但不完全一致，这个“不一致”本身就是分析素材。

二是展示Shuffle阶段的统计信息。提交作业时控制台会打印出类似“Map input records=xxx, Map output records=xxx”的计数器信息，把这些数据摘进报告，解释为什么Map输出的record数大于输入文件的原始行数——因为一行中多个单词会产生多条KV记录。能主动解释清楚这条链路，说明你真的理解了MapReduce的数据流。

三是从代码角度说明Combiner存在的意义。如果你在第6.1节加了Combiner，把开启前后的Map output bytes做个对比，差出一截就说明Shuffle阶段减少了很多网络传输。这个数据比任何文字描述都有说服力。

6.4 我给自己留的一个检查习惯

每次跑完WordCount实验，我会习惯性地做两件事：第一，用hdfs dfs -ls /output看输出的文件大小，确认part文件只有预期那几份；第二，把输出文件拉到本地，用sort -k2 -n按词频排序，看Top 10的单词是否符合直觉。比如我上传的是一堆英文技术文档，拿到的Top 10里如果全是辅助性虚词，说明停用词表这步以后有优化空间。这种做法看似简单，但能让你在写任何MapReduce作业时都保持对结果的敏感度，而不是只满足于“跑通了”。这算是带过不少实验之后留下的一个职业习惯，希望你跑完这个实验也能用得上，希望帮到你。

本文还有配套的精品资源，点击获取