简介：《大数据技术原理与应用》实验报告四围绕MapReduce初级编程实践，是一份面向计算机专业学生、大数据初学者及相关开发者的完整技术报告。资源为单个docx文档，压缩包体积为10.48MB，基于VMWare虚拟机、Ubuntu、JDK1.8、Hadoop与HBase环境，系统介绍了MapReduce编程模型的实际用法。报告依次完成三项典型任务：文件合并与去重、输入数据排序、表格信息挖掘，每项均给出完整Java代码、运行结果及Shell验证命令，方便读者直接对照操作。文档还专门整理了实验过程中常见的Hadoop配置错误、权限不足等故障现象，并逐一说明排查思路，帮助读者快速定位问题；同时结合数据倾斜、格式不一致等真实挑战分享了实验心得，强调编程能力在数据处理中的关键价值。目前已有133人学习使用，适合希望从零掌握MapReduce编程、提升大数据处理水平的学习者参考，整体内容详实、结构清晰，便于课程实验备查和自学实践。
1. MapReduce 初级编程实践：跑通 WordCount 只是第一道坎
实验报告四「MapReduce 初级编程实践」是很多大数据方向同学的第一道坎：老师给的示例代码能跑，但换一道题目就不知道 Mapper 里该输出什么 key、Reducer 里该聚合什么维度。这里面的核心不是 Java 语法，而是想清楚 shuffle 阶段在数据落入 Reducer 之前替你做了什么。这份报告真正的价值不在 WordCount 本身，而在于你能否从三行模板里看出分区、排序、合并的完整链路。写这份实验的人通常刚上完《大数据技术原理与应用》课程，恰好处于“会部署集群、没写过作业”的阶段。本笔记把提交一份合格实验报告的完整路径拆开，适合正在赶这门实验的学生，也适合刚转行做离线数据开发、想用 MapReduce 补齐分布式思维的新人。实验不难，但值得把每条报错背后的原理搞清楚。
2. 从黑盒看 MapReduce：三个类与 shuffle 的默认行为
在动手改代码之前，先花半小时做一个动作：打开一个已有的 WordCount 示例，把 Mapper、Reducer、Driver 三个方法签名抄下来，然后对着下面这段最小骨架，在注释里标出“谁在哪个阶段执行”。这一步能避免你后面绝大多数改错方向。
2.1 三个类如何拼出一个统计任务
一段标准 MapReduce 作业由三块组成：Mapper 把输入拆成中间键值对，Reducer 把相同 key 的值合并，Driver 负责把 job 提交给集群。对应到代码里是最常见的最小骨架：
public class WordCountDriver { public static void main(String[] args) throws Exception { Job job = Job.getInstance(getConf(), "word count"); job.setJarByClass(WordCountDriver.class); job.setMapperClass(TokenizerMapper.class); job.setReducerClass(IntSumReducer.class); // 实验阶段常把 Combiner 直接挂成 Reducer 类 job.setCombinerClass(IntSumReducer.class); FileInputFormat.addInputPath(job, new Path(args[0])); FileOutputFormat.setOutputPath(job, new Path(args[1])); System.exit(job.waitForCompletion(true) ? 0 : 1); } }这段代码里三处容易被忽略：setJarByClass 决定集群上加载哪个 jar，漏了会报找不到主类；addInputPath 指向的路径必须是 HDFS 上的目录，而不是本地目录；waitForCompletion 返回 true 才说明作业成功，实验报告里截日志时不要截到 exit code 为 1 的那一行。Mapper 和 Reducer 内部逻辑不复杂，但要清楚两个约定：Mapper 输出的 key 必须实现 WritableComparable，因为 shuffle 要拿它排序；Reducer 的输出要写成 context.write(key, value) 而不是 println，因为结果最终要落到 HDFS 的 part-r-00000 文件里。
2.2 shuffle 的默认行为：分区、排序、合并
shuffle 是 MapReduce 里最容易成黑匣子的阶段。它横跨 Map 和 Reduce 两端：map 端做完分区和排序，reduce 端拉取对应分区的数据再做归并排序。即便你在代码里一个分区逻辑都没写，框架也默认帮你执行了三个动作。
第一个是分区。默认分区器是 HashPartitioner，算法是 key.hashCode() 与最大整数按位与之后再对分区数取模，目的是让相同 key 进入同一个 Reducer。这个默认行为直接决定了后面“按关键词分区输出”这类题要从改 Partitioner 入手。第二个是排序。每个 map 任务会把自己的输出按 key 排序后再落盘，多个 map 的输出被 reduce 拉取后还要再过一次归并排序。所以对 Reducer 来说，它收到的数据天然是“key 有序、相同 key 连续”的。全排序实验就是钻了这个空子：只要一个 Reducer，天然就是全局有序。第三个是合并，由 Combiner 完成。它在 map 端先做一次局部聚合，减少写盘的中间数据量。注意 Combiner 的输入输出类型必须和 Reducer 一致，而且只能用于满足交换律和结合律的场景，比如求和、最大值、最小值。做平均数统计时挂 Combiner 计算结果会差一大截，这是非常经典的翻车点。
运行一次作业后，可以在日志或 Web 页面上看 Counter 数值：MAP_INPUT_RECORDS 是 Mapper 实际处理的记录数，REDUCE_OUTPUT_RECORDS 是最终落盘记录数。两个数一对比，能直观看到 shuffle 帮你消掉了多少重复聚合，这也是报告里证明“框架生效”最轻量的证据。
2.3 什么任务适合 MapReduce：初级实验最容易跑偏的点
MapReduce 适合“单次扫描 + 按 key 聚合”这类批量计算，不适合迭代类算法、实时查询和需要反复 join 的复杂 DAG。初级实验里最常见的跑偏是：拿 MapReduce 去实现迭代式聚类或图算法，每轮迭代都要启停作业，还怪框架慢。这其实不是框架慢，是选型错了。
另一个容易踩的点是把所有转换都塞进 Mapper，Reducer 只做透传。这种写法能跑，但失去了 shuffle 分组提供的合并能力。正确的习惯是先问“我的 key 应该设成什么粒度”，再想 value 里放什么对象。数据会先按 key 分组再进 Reducer，key 的粒度决定了聚合边界。我一般会让同学动手前填一张小表：输入记录长什么样、按哪个字段聚合、中间结果要不要排序、输出有几列。四行填完，Mapper 输出什么 key 基本就定了，剩下只是类型声明的问题。
3. 把第一个作业跑起来：环境自检、最小骨架与提交命令
实验报告普遍要求在 Hadoop 集群上提交真实作业，所以先把环境管道打通。别急着写代码，先用自带示例验证一遍 HDFS 读写、YARN 调度、日志回传这三个链路。
3.1 环境自检：用自带示例验证输入输出通道
在 hadoop 安装目录下执行自带示例包里的 wordcount：
# 准备实验目录，把数据放进 HDFS hdfs dfs -mkdir -p /user/student/input hdfs dfs -put /home/student/input_data/*.txt /user/student/input/ # 跑自带示例，jar 包名带版本号，用通配符省得敲版本 hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar \ wordcount \ /user/student/input \ /user/student/output-wc-check # 确认结果目录与文件数 hdfs dfs -ls /user/student/output-wc-check/这段命令里要解释的细节是：输出目录绝不能提前建好，否则会直接抛 FileAlreadyExistsException；hadoop jar 会把后面的字符串拆成 main 方法的 args，wordcount 子命令、输入路径、输出路径依次落到 args[0] 到 args[2]。自检通过后，把输出目录删掉再跑自己的作业，不要图省事复用路径。如果自检阶段就失败，先检查 hdfs dfs -ls / 能否正常返回，再确认 ResourceManager 的 Web 页面状态，最后看 yarn logs 里的异常堆栈，按这个顺序排查能省下大量时间。
3.2 最小骨架：WordCount 三件套完整代码
实验报告里最常见的方式是三个类全部写进一个 Java 文件，用内部类实现。这样做打包简单，报告贴代码也干净：
import java.io.IOException; import java.util.StringTokenizer; 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.Mapper; import org.apache.hadoop.mapreduce.Reducer; import org.apache.hadoop.mapreduce.lib.input.FileInputFormat; import org.apache.hadoop.mapreduce.lib.output.FileOutputFormat; public class WordCountDemo { // Mapper：输入是行偏移量与整行文本，输出是单词与计数 1 public static class TokenizerMapper extends Mapper<Object, Text, Text, IntWritable> { private final static IntWritable one = new IntWritable(1); private Text word = new Text(); public void map(Object key, Text value, Context context ) throws IOException, InterruptedException { StringTokenizer itr = new StringTokenizer(value.toString()); while (itr.hasMoreTokens()) { word.set(itr.nextToken()); context.write(word, one); } } } // Reducer：相同 key 的 value 列表在 shuffle 后已排好序，这里逐项累加 public static class IntSumReducer extends Reducer<Text, IntWritable, Text, IntWritable> { private IntWritable result = new IntWritable(); 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); } } public static void main(String[] args) throws Exception { Configuration conf = new Configuration(); Job job = Job.getInstance(conf, "word count demo"); job.setJarByClass(WordCountDemo.class); job.setMapperClass(TokenizerMapper.class); job.setReducerClass(IntSumReducer.class); job.setCombinerClass(IntSumReducer.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); } }三个参数要解释清楚。第一个是 Mapper 的输入 key 类型，这里用 Object 或 LongWritable 都行，TextInputFormat 会把行偏移量传进来，但大多数统计任务用不到它。第二个是 job.setOutputKeyClass 和 setOutputValueClass，它描述的是 Reducer 最终输出类型；如果 Mapper 的中间类型和最终类型不一致，还要额外调 setMapOutputKeyClass 和 setMapOutputValueClass，否则会在 shuffle 阶段抛 ClassCastException。第三个是 Combiner，这里直接复用 IntSumReducer，因为求和满足交换律和结合律，所以挂它安全。这个例子跑出来的 part-r-00000 里每一行是“单词 + 制表符 + 词频”，WordCount 默认的输出分隔符就是制表符。
注意：输出目录必须由框架创建，任何情况下都不要手动创建输出目录。
3.3 打包与提交：jar、输入路径、输出路径三要素
编译用 javac 配合 hadoop classpath，打包用 jar 命令，提交用 hadoop jar。三步命令连写：
# 编译：classpath 由 hadoop 命令动态生成，避免手动拼一堆 jar 路径 javac -classpath $(hadoop classpath) WordCountDemo.java # 打包：-C 进入 classes 目录，保证 jar 内部路径不含多余层级 jar cf wc-demo.jar -C classes . # 提交：输出路径用随机后缀，避免上次残留文件导致失败 hadoop jar wc-demo.jar WordCountDemo \ /user/student/input \ /user/student/output-wc-demo-$(date +%s)编译时最容易出的是 javac 找不到 Hadoop 类，因为没把 hadoop classpath 的结果传给 -classpath。打包时不要用 jar cf wc-demo.jar *.class，因为这种写法会把 .class 文件放在 jar 根目录，如果类里声明了包名，运行时会报类找不到。提交前确认输出路径不存在，用 $(date +%s) 追加时间戳是实验室里最省心的习惯。提交后通常会在终端看到 map 和 reduce 的进度滚动，跑到 100% 后再等几秒，出现“Map-Reduce Finished”字样才算成功。如果中途报错，按 Ctrl+C 只会杀掉客户端，作业可能还在集群上跑，需要到 YARN 页面上 kill 对应 application，这是新手常忽略的一点。
4. 实验里真正卡人的进阶题：全排序、去重与自定义 Writable
基础作业跑通之后，实验报告后半部分的题目通常会换成「全排序」「去重」「统计流量并输出到文件」这几种。它们都基于同一个原理：shuffle 已经按 key 排好序、按 key 分好组，你要做的只是选对 key 的类型和粒度。
4.1 全排序：单 Reducer 能跑，但你要说清为什么
全排序任务通常给一批数字文本，要求输出全局升序结果。让所有数据进入同一个 Reducer 是最直接的实现，因为 Reducer 收到的 key 经过 shuffle 排序后天然全局有序。代码关键是 Mapper 里用 IntWritable 做 key：
public static class SortMapper extends Mapper<Object, Text, IntWritable, NullWritable> { private IntWritable outKey = new IntWritable(); public void map(Object key, Text value, Context context ) throws IOException, InterruptedException { // 每行一个数字，去掉空白后转成 int int num = Integer.parseInt(value.toString().trim()); outKey.set(num); context.write(outKey, NullWritable.get()); } }这里 value 用 NullWritable，因为排序不需要携带关联内容，NullWritable 的序列化开销是 0 字节，比输一个占空间的 Text 更省。Reducer 直接使用 Mapper 的输出类型，把 key 原样写出。唯一要注意的是 IntWritable 默认升序，若要求降序需自定义比较器：
job.setSortComparatorClass(IntWritable.DecreasingComparator.class);DecreasingComparator 是 Hadoop 自带的反转比较器，实验阶段够用；生产环境需要自定义 WritableComparator 时，记得重写 compare 方法而不是在 Map 端取负数，否则取负数后再哈希可能改变分区结果。单 Reducer 全排序的代价是吞吐上限只有单机，实验报告里主动写一句“该方案只适合小数据量验证，线上全排序应改用区间分区，把数据按范围拆到多个 Reducer 后再拼接”，这一步就能体现对分区的理解。
4.2 去重任务：让 shuffle 替你完成分组去重
去重题的标准套路是：Mapper 把待去重的字段作为 key 输出，value 统一用 NullWritable；Reducer 里忽略 values，直接输出 key。分组去重的动作全部发生在 shuffle 阶段，Reducer 只是把每组里第一个 key 写出去。
public static class DistinctMapper extends Mapper<Object, Text, Text, NullWritable> { private Text outKey = new Text(); public void map(Object key, Text value, Context context ) throws IOException, InterruptedException { // 假设每行一个待去重字段，去掉空白后直接作为 key outKey.set(value.toString().trim()); context.write(outKey, NullWritable.get()); } } public static class DistinctReducer extends Reducer<Text, NullWritable, Text, NullWritable> { public void reduce(Text key, Iterable<NullWritable> values, Context context) throws IOException, InterruptedException { context.write(key, NullWritable.get()); } }这个实现里 Combiner 可以不挂，因为去重逻辑在 shuffle 分组时已经完成了绝大部分；若想减少 map 到 reduce 的传输量，把 DistinctReducer 挂成 Combiner 也没有副作用，它是幂等的。更常见的问题是空格和换行符没清干净，导致同一个字段被识别成两个 key。实验数据来源杂，建议先跑一遍输入样例，确认每行的分隔符是空格、制表符还是其他不可见字符。去重和 SQL 里的 DISTINCT 在语义上等价，报告里如果能说清“Hadoop 的去重是分组后取首条，MySQL 的去重是排序后去重”，会让读报告的人觉得你是真做过，而不是套模板。
4.3 自定义 Writable：流量统计对象的序列化约定
流量统计是自定义 Writable 的经典题：输入一行包含手机号、上行流量、下行流量，要求按手机号聚合求和。Text 只能解决字符串，多字段数字必须自己封装一个可序列化对象。
import java.io.DataInput; import java.io.DataOutput; import java.io.IOException; import org.apache.hadoop.io.Writable; public class FlowBean implements Writable { private long upFlow; private long downFlow; private long sumFlow; // 必须保留无参构造器，框架反序列化时靠反射创建实例 public FlowBean() {} public FlowBean(long upFlow, long downFlow) { this.upFlow = upFlow; this.downFlow = downFlow; this.sumFlow = upFlow + downFlow; } // 序列化：字段写入顺序必须与 readFields 完全一致 public void write(DataOutput out) throws IOException { out.writeLong(upFlow); out.writeLong(downFlow); out.writeLong(sumFlow); } public void readFields(DataInput in) throws IOException { this.upFlow = in.readLong(); this.downFlow = in.readLong(); this.sumFlow = in.readLong(); } @Override public String toString() { return upFlow + "\t" + downFlow + "\t" + sumFlow; } }然后写一个 Mapper 读一行、切三列，Reducer 里累加并 new 一个 FlowBean 输出。注意 write 与 readFields 的顺序若不一致，Reduce 端反序列化出来的字段会错位，日志里只显示为异常数字，定位起来很隐蔽。另外输出到文本文件时，FlowBean 的 toString 就是最终落盘内容，用制表符分隔，报告里贴出来直接复制进 Excel 就是干净的表格。自定义 Writable 题在报告里还有一问是“为什么 Hadoop 不用 Java 自带的 Serializable”，标准说法是 Java Serializable 会写入大量类继承信息，序列化体积大且迭代开销高，Writable 接口只保留数据本身，更适合网络传输和磁盘读写。这个点答出来，报告分通常能往上走一档。
5. 避坑指南：实验室里最常见的五个报错与现场处理
下面这五条按出现频率排，占了实验答疑里的绝大多数问题。每条都按「现象 → 原因 → 解决」说清楚，处理完顺手把日志截图放进报告，这一章就是现成的排障记录。
5.1 输出目录已存在：FileAlreadyExistsException 的彻底解法
现象：提交作业后很快报错，堆栈里能看到 org.apache.hadoop.mapred.FileAlreadyExistsException: Output directory hdfs://.../output already exists。
原因：MapReduce 的输出目录由框架创建，不允许提前存在，这是防止上一轮残留数据污染新结果的保护机制。新手第一次跑通后看结果很兴奋，第二次直接重跑同一个命令就翻车。
解决：每次提交前确认输出路径不存在。命令行里用 hdfs dfs -rm -r /user/student/output；脚本里更推荐在提交命令前加时间戳路径，例如 output-wc-$(date +%s)。注意不要用 -rmr 这种老式参数，新版本更规范的是 -rm -r。
5.2 shuffle 阶段 ClassCastException：Map 输出类型不一致
现象：作业在 map 阶段或 reduce 阶段抛 java.lang.ClassCastException，提示某个 Writable 类型无法转成另一个，常见于任务需要二次排序或者 Map 输出类型和 Reduce 输入类型不一致。
原因：Reducer 的输入 key/value 类型由 job 的 Map 输出类型决定，而不是由 Reducer 的泛型声明决定。只设置了 setOutputKeyClass，没设置 setMapOutputKeyClass，框架会默认把 Map 输出也当成最终输出类型，中间类型一交错就崩溃。
解决：给 job 明确配置四个类型：
job.setMapOutputKeyClass(Text.class); job.setMapOutputValueClass(IntWritable.class); job.setOutputKeyClass(Text.class); job.setOutputValueClass(IntWritable.class);排查时打开 YARN 日志看堆栈第一行，它会直接告诉你期望的类型和实际拿到的类型，照着改 job 配置即可。
5.3 中文乱码或单词被拆错：编码问题
现象：中文文本统计出来是一串乱码，或者一个中文词被拆成多个碎片，统计结果和预期差一倍。
原因：TextInputFormat 默认按 UTF-8 解码。如果实验数据在 Windows 里编辑过，很可能是 GBK 编码，Hadoop 读进来后逐字节解码导致汉字被拆开。日志里看不到报错，表现就是结果不对，十足的玄学。
解决：统一转码再上传。本地执行 iconv -f gbk -t utf-8 input.txt -o input_utf8.txt；也可以在 map 里对 value.toString().getBytes("GBK") 做补偿转码，但工程上更推荐前者，数据源干净比代码里兜底更重要。顺带注意：文本文件开头如果带 UTF-8 BOM，第一行第一个词会多出一个不可见字符，统计结果里会多一个“词”。
5.4 自定义 Writable 的 NoSuchMethodException：无参构造器不能省
现象：任务正常提交，但 reduce 阶段报 java.lang.NoSuchMethodException: FlowBean. () 或 java.lang.RuntimeException: java.lang.NoSuchMethodException。
原因：框架在反序列化中间结果时，用反射调用 FlowBean 的无参构造器创建实例。凡是只写了带参构造器而没保留无参构造器，反射直接失败。这个报错只出现在自定义 Writable 接入 shuffle 之后，本地单元测试只测 getter 和 setter 根本发现不了。
解决：在类里显式写出 public FlowBean() {}。如果类里还有带参构造器，无参构造器必须手动补上，不会自动生成。同理适用于实现 WritableComparable 的类，compareTo 方法也别漏。
5.5 作业卡在 map 100% reduce 0%：内存参数与数据倾斜
现象：YARN 页面上 map 进度已经 100%，reduce 一直停在 0%，跑十几分钟不动，最后还是超时被杀。
原因：要么是 reduce 端拉取数据后内存不足反复 GC，要么是某个 key 的数据量特别大导致单个 reduce 倾斜。最容易被忽略的是默认容器内存和集群实际配置不匹配，本地能跑是因为 LocalJobRunner 不按 YARN 容器调度。
解决：先看某个 reduce task 的日志里有没有频繁 Full GC。有则调内存参数：
conf.set("mapreduce.map.memory.mb", "1024"); conf.set("mapreduce.reduce.memory.mb", "2048");没有 GC 但单个 reduce 耗时异常，则十有八九是数据倾斜。实验阶段最简单的验证方式是换一个输入数据量更小的文件，先把逻辑问题排除，再谈参数调优。遇到两个问题混在一起时，排查顺序应该是日志、内存、数据分布，不要一上来就调内存。
6. 离生产更近一步：三个可以立刻改的实验习惯
实验做完别急着删代码，把下面三个习惯顺手加上，后面做实习项目或真实离线任务会少踩不少坑。
6.1 用 ToolRunner 接收参数而不是写死路径
直接把主类改造成继承 Configured 并实现 Tool，可以让命令行任意传参、设配置，避免在代码里把 HDFS 路径写死：
public class WordCountTool extends Configured implements Tool { public int run(String[] args) throws Exception { String input = args[0]; String output = args[1]; // 其余 Driver 逻辑不变 return 0; } }入口处调用 ToolRunner.run(new WordCountTool(), args)。改动量很小，但报告里可以写一句“作业参数与逻辑解耦”，面试被问起也答得出来。
6.2 提交前算一下输入分片数，判断是否值得上集群
分片大小的公式是 max(minSize, min(maxSize, blockSize))。输入数据远小于一个块时，本地模式比集群模式快，集群的启动、调度开销反而拖慢你。判断习惯：先执行 hdfs dfs -du -h /user/student/input 看一眼总量，如果只有几十 MB，本地跑通再上集群，别拿集群当单机用。
6.3 输出先想清楚给谁消费
实验报告的输出文件是给人看的，保持 part-r-00000 是 UTF-8 文本即可。如果后续还有下游任务要读同份数据，考虑 SequenceFile 和压缩。压缩能省大量带宽，但压缩格式选错会让下游任务被迫解压反而更慢。对报告而言，最稳的输出是 TextOutputFormat 加制表符分隔，方便后续任何工具读取。
我当年做这份实验报告时，最大的教训就是太早把“能跑”当成了“会了”。后来在模拟项目X里接手一个聚合任务，数据量上来后 job 卡在 shuffle，回头排查才发现是当年跳过的 Combiner 语义没吃透。所以这次把链路里每个黑盒都拆开讲清楚，希望帮到你，别重复我那次翻车。
本文还有配套的精品资源，点击获取
