Hadoop电影推荐系统实战：MapReduce协同过滤全流程解析

毕设选题的时候，我盯着屏幕上的题目列表整整纠结了两天。最后选了这个“基于 Hadoop 平台的电影推荐系统”，Java 语言实现。说实话，当时我对 Hadoop 的印象只停留在“大数据框架”这五个字上，连 HDFS 和 MapReduce 都说不利索。但正因为如此，这个题目对我这种想真正学点东西、又不想纯抄代码交差的人来说，反而是一个绝佳的切入点——它既能覆盖传统 Java Web 开发，又能触及分布式存储和分布式计算的真实场景，还自带“推荐系统”这个听起来很有说服力的亮点。

这篇文章会把我从选题、环境搭建、算法落地到 Web 端展示和答辩前的性能调优完整复盘一遍，重点讲清楚几件容易卡壳的事：MapReduce 到底怎么跑协同过滤、HDFS 上的数据怎么设计、伪分布式环境下会遇到哪些隐藏很深的坑，以及算法结果怎么变成界面上“猜你喜欢”的那几部电影。如果你也在做一个类似的大数据毕设，或者只是好奇推荐系统和 Hadoop 结合起来的真实工作量，这份记录可以直接拿来当路线图。我不保证你照着做能拿满分，但至少能让你少熬夜。

1. 毕设选题复盘：为什么偏偏是 Hadoop 电影推荐系统

1.1 选题背后的真实考虑

每年毕设题海里，推荐系统相关的题目一抓一大把，但绝大多数是“基于 Python 的豆瓣电影推荐”“基于 Spark 的协同过滤算法实现”。选 Hadoop 的原因，不是因为它比 Spark 快，恰恰相反，在很多场景下 Hadoop 的 MapReduce 计算效率并不高，但它的学习曲线更平缓，原理更直观。

推荐系统的核心是“相似度计算”和“聚合统计”，这两个操作天然能映射到 MapReduce 的“分而治之”模型上。比如统计两部电影被多少用户共同看过，本质上就是一个 word count 变种；计算用户对电影的评分矩阵，就是典型的“按用户分组”操作。这种映射关系，比 Spark 里封装好的 DataFrame API 更能帮助理解分布式计算的本质。

另一个更现实的原因是：毕设要的是“工作量可见”。Hadoop 的伪分布式模式能在一台电脑上完整模拟分布式环境，HDFS 的 NameNode、DataNode，YARN 的 ResourceManager、NodeManager，这些进程一个个启动起来，截图放进论文里，工作量一目了然。

1.2 这个系统到底要做什么

按照当时我给自己定的需求边界，这个系统要完成四件事：

第一，把电影评分数据清洗成 Hadoop 能直接处理的格式，存进 HDFS。第二，用 Java 编写 MapReduce 任务，基于用户的历史评分计算电影之间的相似度，找到每部电影的“邻居”。第三，根据用户看过的电影和相似度矩阵，生成每个用户的候选推荐列表并过滤掉已经看过的影片。第四，用一个 Web 前端把推荐结果展示出来，用户能登录、能点电影、能看到系统推荐的另外五部电影。

需求边界很重要，我见过不少同学把毕设越做越大，最后连实时推荐和爬虫都加进去了。在 Hadoop 平台上做推荐系统，最舒服的定位是离线批量推荐——数据不是实时来的，推荐结果也不是实时算的，而是每天或者每次触发时跑一遍离线作业，把结果写回数据库，前端只负责展示。这个定位和 Hadoop 本身的批处理属性完全吻合。

1.3 技术选型里最有争议的三个决定

决定一，为什么不用 Spark？如果开发周期有三年，我肯定选 Spark，MLlib 里直接有 ALS 推荐算法，一行配置就能跑。但毕设周期只有几个月，而且最终答辩时老师更想看的是“你是否理解原理”，而不是“你会不会调包”。手写 MapReduce 实现协同过滤，虽然代码多一些，但每一行都是在跟算法原理做映射，问答环节基本不会卡壳。

决定二，为什么用 Java 而不是 Python？这个题目本身限定了 Java，但换个角度想也合理。Java 是 Hadoop 的原生语言，MapReduce 的 API 设计完全是 Java 风格，写起来不用跨语言理解。再加上 Spring Boot 做 Web 端、JDBC 操作 MySQL，一套 Java 全家桶搞完，连环境配置都能少折腾。

决定三，数据集用什么？网上能公开下载的经典数据集是 MovieLens，它有几个不同规模：100k、1M、10M。毕设场景我选了 1M 这个档位，数据量足够说明问题（约 100 万条评分），又不会让本机伪分布式环境跑太久。100k 太小，跑出来的推荐结果说服力不足；10M 太大，伪分布式的单机性能扛不住，一个作业跑半小时是常事。

2. 整体架构与数据流转：从 MovieLens 数据集到“猜你喜欢”

2.1 四个模块一条链

整个系统分成四层：数据层、计算层、服务层、展示层。

数据层是 HDFS，存原始评分数据和中间结果。计算层是跑在 YARN 上的 MapReduce 作业，负责实现协同过滤的每一步。服务层是 Spring Boot 写的后端接口，负责从数据库读推荐结果、处理用户请求。展示层是前端页面，用最简单的 Bootstrap + Thymeleaf 模板渲染，毕竟毕设重心不在前端。

数据流向是一条单向链路：MovieLens 的原始数据从本地上传到 HDFS，MapReduce 作业按顺序跑，每一步的输出作为下一步的输入，最后的推荐结果写到 MySQL，Spring Boot 从 MySQL 读取后通过接口返回给前端。整个链路是线性的，没有回环，这也是离线批处理推荐系统最简单的形态。

2.2 MovieLens 数据集长什么样，为什么要先看懂它

MovieLens 1M 解压后有三个文件：ratings.dat、users.dat、movies.dat。ratings.dat 每一行是一条评分记录，字段用双冒号分隔：用户ID::电影ID::评分::时间戳。比如 1::1193::5::978300760 表示第 1 个用户给第 1193 部电影打了 5 分。movies.dat 格式是 电影ID::电影标题::类型，注意标题里可能包含冒号，比如 Toy Story (1995) 这种，所以解析的时候只能按前两个双冒号切分，后面的类型字段可能含有冒号。

这里有个很容易踩的坑：直接用 String.split("::") 解析 movies.dat 没问题，因为规则是固定的三段，但如果你处理的是自定义数据集，一定不要用正则里的 :: 做全局切分，它在某些字符集下会有转义问题。稳妥的做法是用 Apache Commons Lang 里的 StringUtils.splitPreserveAllTokens，或者干脆用 Guava 的 Splitter.on("::")，处理起来干净利落。

理解数据格式是后面所有 ETL 工作的前提，因为 MapReduce 的 Mapper 读入一行原始字符串，第一个动作就是解析字段。解析不对，后面全错。

2.3 为什么选 ItemCF 而不是 UserCF

协同过滤有两大流派：基于用户的 UserCF 和基于物品的 ItemCF。电影推荐这个场景下，ItemCF 是更主流的选择，原因有三点。

第一，电影的数量相对用户来说更稳定。MovieLens 1M 里有 6000 多部电影、6000 多个用户，数量级差不多，但实际系统中用户量会远大于物品量，ItemCF 的计算量和存储量更可控。第二，用户的兴趣变化比电影之间的相似关系更频繁。UserCF 需要实时计算用户之间的相似度，用户一多就扛不住；ItemCF 计算的是“看过这部电影的人还喜欢什么”，这个关系相对稳定，可以离线算好。第三，解释性好。“因为你之前喜欢《盗梦空间》，而喜欢《盗梦空间》的人也喜欢《星际穿越》”这个推荐理由，比“因为和你兴趣相似的人也喜欢《星际穿越》”更直观。

从算法实现的角度，ItemCF 的完整计算链路是：先根据所有用户的评分记录，统计电影之间的共现次数——两个电影被同一个用户看过，就算一次共现；然后基于共现次数和各自的评分分布计算相似度；最后针对目标用户看过的电影集合，累加相似电影的加权分数，得到推荐列表。这三步正好可以拆成三个 MapReduce 作业，链路清晰，代码结构也漂亮。

3. 推荐算法落地：用 MapReduce 手写 ItemCF 协同过滤

3.1 怎么把协同过滤拆成 MapReduce 步骤

这是我整个项目里耗时最久、收获最大的一部分。最开始我试图在一个 MapReduce 作业里完成所有计算，结果代码写得绕来绕去。后来想通了：MapReduce 的本质是串行执行多个作业，每个作业只做一件事，输出结果作为下一个作业的输入。

我最终设计了三段式的作业链路：

Job 1：按用户归组，生成评分矩阵
输入是 ratings.dat 原始数据，Mapper 按 用户ID 作为 key，电影ID:评分 作为 value 输出。Reducer 把同一个用户的所有电影拼接成一行，输出格式为 用户ID\t电影1:评分,电影2:评分,电影3:评分。这一步本质上就是把行为数据变成矩阵的一行。

Job 2：计算电影共现矩阵
这一步是推荐的骨架。Mapper 读取 Job 1 的输出，对每一行（即同一个用户的所有电影）做两两组合，输出 key 为 电影A:电影B（保证 A < B，避免重复），value 为 1。Reducer 累加同一个 key 的计数，就得到两部电影被共同看过的次数。

Job 3：计算相似度并生成推荐
这一步负责合并共现次数、电影各自的被评分次数以及用户的历史评分，最终算出推荐结果。

这里面最简单的是 Job 2，逻辑上就是一个 word count 的变体，但也是最重要的，因为共现次数直接影响最终的相似度质量。

3.2 核心代码：Job 1 和 Job 2 的 Java 实现

Job 1 的 Mapper 代码非常简洁，但有个细节要注意：输出 value 最好是 Text 类型，不要直接输出整个评分对象，否则 Reducer 端的序列化开销会变大。伪分布式环境下这点开销还不明显，但集群环境下会直接拖慢作业速度。

java复制public class UserRatingMapper extends Mapper<Object, Text, Text, Text> {
    private Text outKey = new Text();
    private Text outValue = new Text();

    @Override
    protected void map(Object key, Text value, Context context)
            throws IOException, InterruptedException {
        String[] fields = value.toString().trim().split("::");
        if (fields.length < 4) {
            return;
        }
        String userId = fields[0];
        String movieId = fields[1];
        String rating = fields[2];
        outKey.set(userId);
        outValue.set(movieId + ":" + rating);
        context.write(outKey, outValue);
    }
}

Reducer 这边把同一个用户的所有电影评分拼成一行：

java复制public class UserRatingReducer extends Reducer<Text, Text, Text, Text> {
    private Text outValue = new Text();
    private StringBuilder sb = new StringBuilder();

    @Override
    protected void reduce(Text key, Iterable<Text> values, Context context)
            throws IOException, InterruptedException {
        sb.setLength(0);
        for (Text value : values) {
            if (sb.length() > 0) {
                sb.append(",");
            }
            sb.append(value.toString());
        }
        outValue.set(sb.toString());
        context.write(key, outValue);
    }
}

注意：这里有个隐藏问题。 Iterable<Text> values 是惰性加载的，在循环里面直接拼接没问题，但如果想先存成 List 再统一处理，内存占用会暴涨。伪分布式环境下测试数据 1M 条可能不明显，但最好从一开始就养成“能流式处理就流式处理”的习惯，这也是分布式编程跟单机编程最不一样的思维点。

Job 2 的 Mapper 需要解析 Job 1 的输出，对每一行做两两组合。这里有个性能优化点：不要重复计算同一对电影，在代码里统一处理成 A < B 的字典序，输出 key 固定为 A:B，这样能在 Map 端就过滤掉一半的重复对。

java复制public class CoOccurrenceMapper extends Mapper<Object, Text, Text, IntWritable> {
    private Text pairKey = new Text();
    private IntWritable one = new IntWritable(1);

    @Override
    protected void map(Object key, Text value, Context context)
            throws IOException, InterruptedException {
        String[] parts = value.toString().trim().split("\t");
        if (parts.length != 2) {
            return;
        }
        String[] movies = parts[1].split(",");
        for (int i = 0; i < movies.length - 1; i++) {
            String movieA = movies[i].split(":")[0];
            for (int j = i + 1; j < movies.length; j++) {
                String movieB = movies[j].split(":")[0];
                // 保证字典序，避免重复统计
                if (movieA.compareTo(movieB) < 0) {
                    pairKey.set(movieA + ":" + movieB);
                } else {
                    pairKey.set(movieB + ":" + movieA);
                }
                context.write(pairKey, one);
            }
        }
    }
}

Reducer 端就是一个简单的求和：

java复制public class CoOccurrenceReducer 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);
    }
}

运行完 Job 2，HDFS 上会生成一个文件，每一行是一对电影和它们共同出现的次数。到这里，推荐算法的“原料”就备齐了。

3.3 相似度公式的选择与实现要点

有了共现次数，接下来要算相似度。业界最常用的两个公式是余弦相似度和皮尔逊相关系数，但这两个公式需要用到评分值。在刚才的 Job 2 设计中，我只统计了共现次数，没有记录评分详情。如果想做精确的余弦相似度，需要在 Job 2 的 Mapper 里同时输出每个电影的评分向量——这样设计会复杂很多。

对于毕设项目，我采用的是一种工程化的简化方案：用改进的共现系数作为相似度的近似。公式是 相似度 = 共现次数 / sqrt(电影A被评分次数 * 电影B被评分次数)。这个公式本质上是余弦相似度的简化版，不需要评分向量，只需要计数。分母的平方根可以惩罚那些“因为太热门所以经常一起出现”的电影对，避免《阿甘正传》和任何电影都像“邻居”。

这个设计有明确的取舍：实现简单，MapReduce 任务少跑一个，效果在 MovieLens 数据集上经测试是够用的，准确率比纯共现次数好不少。但如果你的指导老师对算法细节抠得很细，可以考虑在 Job 3 里把评分向量也带进来，实现真正的余弦相似度。这个后续优化我放在第 6 章讲。

3.4 Job 3 的设计：怎么把相似度和用户历史评分结合成最终推荐

Job 3 是整个链路里最“多表关联”的一步，它会涉及两个输入：Job 2 的共现矩阵输出，以及 Job 1 的用户评分矩阵输出。MapReduce 的 DistributedCache 机制可以简化这个关联过程。

我当时的做法是：把共现矩阵文件放进 DistributedCache。Mapper 读取用户评分矩阵（Job 1 输出）的每一行，即某个用户的电影列表，对该列表里的每一部电影，去 DistributedCache 里查找它的所有相似电影，累加相似度分数。考虑到“这个用户已经看过的电影”要过滤掉，只保留没看过的电影。

这个方案的缺点很明显：DistributedCache 里的共现矩阵如果很大，放进内存会爆。MovieLens 1M 下共现矩阵大约有几十万行，每行是“电影A:电影B\t共现次数”，全部加载进内存不算太大，Java 默认堆内存 1G 够用，但我还是建议把堆内存调到 2G，给自己留点余量。后面踩坑记录里会细说。

4. HDFS 上的数据准备与 ETL 实操

4.1 数据上传前必须做的三件事

第一件事，检查格式。MovieLens 的 ratings.dat 要从 :: 分隔转成 \t 分隔吗？不一定。Hadoop 的 TextInputFormat 默认按 \n 分文件行，对行内分隔符没有要求。所以我直接把 .dat 文件上传 HDFS，Mapper 里用 split("::") 解析即可。

不过我的做法是事先写了一个本地 Java 小工具，把 .dat 里的 :: 统一替换成 \t，顺便过滤空行和格式异常的行。为啥要这么做？因为后面写 Web 端的时候，MySQL 里存的数据也想用同一种格式，提前统一能少写一堆解析代码。这一步不是 Hadoop 要求，是从数据管理的角度给自己省事。

第二件事，检查字符集。MovieLens 的数据是纯英文的 ISO-8859-1 编码，但如果你实际处理的是中文电影数据，一定确保 HDFS 上的文件是 UTF-8 无 BOM 格式。Hadoop 的 Text 类型默认按 UTF-8 解析，如果文件是 GBK 编码，Mapper 读出来全是乱码，而且这种错误很难定位，因为 MapReduce 不会报错，只会输出错误结果。

第三件事，规划目录结构。不要在 HDFS 根目录乱放文件。我建议的目录规划是：

code复制/user/hadoop/movielens/
├── input/
│   ├── ratings.dat
│   ├── movies.dat
│   └── users.dat
├── job1_output/
├── job2_output/
└── job3_output/

每个 job 的 output 目录都必须是不存在的，否则作业会直接报错，这是 MapReduce 的一个硬性约束。所以在写 shell 脚本跑作业链的时候，每次执行前要 hadoop fs -rm -r 清掉旧的输出目录。

4.2 “Java 中对 Hadoop 上传文件就是对 HDFS 操作吗”——这个问题的答案

网上搜 Java 和 Hadoop 相关的问题，经常能看到“java中对hadoop上传文件和下载就是对hdfs操作吗”这类提问。答案其实是：你操作的是 HDFS，而 Hadoop 这个框架提供了 Java API 让你操作它。 Hadoop 是一个生态系统，HDFS 只是其中负责存储的组件。你通过 Java 代码调用 FileSystem API，本质上是把文件写进分布式文件系统，而不是写进某个本地目录。

最简单的本地上传到 HDFS，可以用命令行：hadoop fs -put ratings.dat /user/hadoop/movielens/input/。但如果你想在 Java 程序里控制上传流程，或者毕设答辩时要演示“程序自动把数据上传到 HDFS”，可以用下面的代码：

java复制import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
import java.net.URI;

public class HdfsUploader {
    public static void main(String[] args) throws Exception {
        String hdfsUri = "hdfs://localhost:9000";
        Configuration conf = new Configuration();
        FileSystem fs = FileSystem.get(URI.create(hdfsUri), conf, "hadoop");

        Path localPath = new Path("data/ratings.dat");
        Path hdfsPath = new Path("/user/hadoop/movielens/input/ratings.dat");
        fs.copyFromLocalFile(localPath, hdfsPath);

        System.out.println("上传成功");
        fs.close();
    }
}

注意第三行 FileSystem.get(URI.create(hdfsUri), conf, "hadoop") 里的 "hadoop" 是 HDFS 上的用户名。如果你没传这个参数，程序默认使用你本机操作系统的用户名去访问 HDFS，而你在伪分布式环境里往往是用 hadoop 这个用户启动的 NameNode，权限对不上就会抛出 Permission denied 异常。这个坑非常隐蔽，但排查思路很简单：去看 HDFS 服务端的日志，或者用 hadoop fs -ls /user 确认当前用户的权限。

4.3 ETL 的 MapReduce 实现：清洗与格式化

如果你不想用本地 Java 小工具做 ETL，也可以用 MapReduce 做清洗。核心思路是：Mapper 读取原始数据，通过正则或分隔符解析字段，过滤掉评分为空、用户 ID 不合法、时间戳格式错误等异常记录，输出标准化的 key-value 对。Reducer 在这类 ETL 中通常做的是去重或者简单聚合。

比如过滤评分数据中的异常值：

java复制public class RatingCleanMapper extends Mapper<Object, Text, Text, Text> {
    private Text outKey = new Text();
    private Text outValue = new Text();

    @Override
    protected void map(Object key, Text value, Context context)
            throws IOException, InterruptedException {
        String line = value.toString().trim();
        if (line.isEmpty()) {
            return;
        }
        String[] fields = line.split("::");
        if (fields.length != 4) {
            context.getCounter("ETL", "invalid_line").increment(1);
            return;
        }
        try {
            int userId = Integer.parseInt(fields[0].trim());
            int movieId = Integer.parseInt(fields[1].trim());
            double rating = Double.parseDouble(fields[2].trim());
            if (rating < 1 || rating > 5) {
                context.getCounter("ETL", "invalid_rating").increment(1);
                return;
            }
            outKey.set(String.valueOf(userId));
            outValue.set(movieId + "\t" + rating);
            context.write(outKey, outValue);
        } catch (NumberFormatException e) {
            context.getCounter("ETL", "parse_error").increment(1);
        }
    }
}

这里用了 context.getCounter 来记录清洗过程中各种丢弃数据的数量。这个技巧对毕设来说是个加分项，因为答辩时你可以直接展示“原始数据 100 万条，清洗后剩 98.7 万条，丢掉的 1.3 万条里有 8000 条是评分越界、5000 条是解析异常”，这个数据支撑非常能体现工程素养。

4.4 文件输出格式：SequenceFile 与传统 Text 的取舍

MapReduce 作业的输出默认是文本文件，每行一条记录。但你也可以设置成 SequenceFile——Hadoop 原生的二进制格式，存储紧凑，读取速度快，支持压缩。

我的建议是：如果中间结果还要被多个作业消费，用 SequenceFile 能省不少时间。如果只是最终结果给 MySQL 用，老老实实用文本格式。因为 SequenceFile 是二进制格式，你拿文本工具直接打开是一堆乱码，排查问题很痛苦。毕设的场景以“能看懂中间过程”为重，文本格式优先。

还有个细节：TextOutputFormat 默认把 key 和 value 用 \t 分隔输出。如果你想让输出格式看起来像 SQL 的 INSERT 语句，可以在 Reducer 里直接拼好整行字符串输出，value 设为空字符串。比如输出 INSERT INTO t_recommend VALUES (1, 1193, 5); 这种，后面导入 MySQL 就很方便。

5. 从 MapReduce 结果到可展示的 Web 平台

5.1 推荐结果怎么落到 MySQL

直接让 Spring Boot 去读 HDFS 上的文本文件也能做，但太绕了，而且每次展示都要去解析文件，性能一塌糊涂。标准做法是：MapReduce 作业跑完后，用 hadoop fs -cat 或 hadoop fs -get 把结果文件拉下来，然后通过 LOAD DATA LOCAL INFILE 导入 MySQL。这个 SQL 语句特别适合批量导入 \t 分隔的文本文件。

我当时的导入命令是这样：

bash复制hadoop fs -get /user/hadoop/movielens/job3_output/part-r-00000 /tmp/recommend.txt
mysql -u root -p --local-infile=1 movie_db -e "LOAD DATA LOCAL INFILE '/tmp/recommend.txt' INTO TABLE t_recommend (user_id, movie_id, score);"

注意 t_recommend 表结构要和输出文件字段对应。这里有一个巨坑：如果 Rducer 输出的 key 是“用户ID:电影ID”这种组合格式，导入前必须先在 MySQL 里拆分。我的建议是，Reducer 输出直接设计成三个字段：用户ID\t电影ID\t推荐分数，这样导入一步到位。

5.2 Spring Boot 后端只做三件事

后端不要太复杂，只做三件事：用户登录注册、展示电影列表、展示推荐列表。用户和电影的关联通过评分记录建立，推荐结果直接查 t_recommend 表。

Controller 层核心逻辑大概这样：

java复制@RestController
@RequestMapping("/api/recommend")
public class RecommendController {

    @Autowired
    private RecommendService recommendService;

    @GetMapping("/{userId}")
    public Result getRecommendList(@PathVariable Integer userId) {
        List<RecommendVO> list = recommendService.getRecommendByUser(userId);
        return Result.success(list);
    }
}

这个接口查询的 SQL 很简单：SELECT r.movie_id, m.title, r.score FROM t_recommend r JOIN t_movie m ON r.movie_id = m.movie_id WHERE r.user_id = ? ORDER BY r.score DESC LIMIT 10。连接查询把电影标题带出来，前端直接展示。

一个重要提醒： Spring Boot 连接 MySQL 之前，务必保证自己先手动用 MySQL 客户端执行一遍这条 SQL，确认数据能查出来。如果查不出来，问题大概率不在代码，而在导入的数据。因为 MapReduce 输出的用户 ID 和评分表里的用户 ID 对不上、或者有空值，都会导致 JOIN 结果为空。

5.3 前端展示的“够用”标准

前端不需要花哨，但也不能太简陋。我当时用的是 Bootstrap + Thymeleaf，页面除了登录注册，就三个：首页（电影列表）、推荐页（猜你喜欢）、我的评分页。推荐页是核心，展示了“根据你看过的电影，为你推荐以下影片”，下面是卡片列表，每张卡片有电影海报、标题、类型和推荐分数。

海报图片可以直接用静态资源，也可以从电影数据库接口拉，但毕设别去申请第三方 API 了，直接塞几张本地图片或者用占位图就行。核心是演示链路是通的——用户 A 登录后看到的推荐列表，和他看过的电影是有逻辑关系的。

这里有个演示技巧：答辩的时候，先找一个用户，看他评过分的电影，再切到推荐页，如果有推荐的电影和他评过分的电影在类型上高度重合，这个场景特别有说服力。

5.4 一次完整的“算法结果到前端展示”链路演示

拿 MovieLens 里的实际数据举例：假设用户 ID 为 88 的用户看过《星球大战》（260）、《夺宝奇兵》（1196）、《终结者 2》（589），评分都在 4 分以上。Job 2 会计算出这些电影和《黑客帝国》（2571）的共同出现次数很高，因为喜欢科幻动作片的用户群体高度重合。

Job 3 把相似度分数和用户的历史评分加权相乘，最终给用户 88 推荐《黑客帝国》的分数可能在 4.6 左右，排在推荐列表第一位。前端就显示“因为你看过《星球大战》，我们为你推荐《黑客帝国》”，这个推荐理由是 ItemCF 最自然的解释。展示时留出 3—5 部“冷门但高分”的电影，比清一色热门大片更能体现算法的个性化能力——如果所有用户的推荐列表都长一样，那算法基本失效了。

6. 伪分布式环境搭建与真实踩坑记录

6.1 伪分布式模式的环境准备

毕设基本不可能开真正的多节点集群，伪分布式模式（Pseudo-Distributed Mode）是唯一现实的选择。在一台机器上，NameNode、DataNode、ResourceManager、NodeManager 都以独立 JVM 进程跑，能模拟真集群的通信过程。

我的环境如下：Ubuntu 20.04、Hadoop 3.3.4、JDK 1.8、Spring Boot 2.7、MySQL 5.7。你可能会问为什么不用 JDK 17？这里有个兼容性大坑：Hadoop 3.3.x 官方支持 JDK 8 和 JDK 11，JDK 17 能跑但会出现一些底层反射访问的警告，hadoop dfs 命令在某些版本下会报错。毕设求稳，JDK 8 永远是最保险的选择。

安装步骤用一句话总结：官网下载 Hadoop 二进制包，解压，配置 JAVA_HOME、HADOOP_HOME，在 etc/hadoop/ 下改四个配置文件，然后 hdfs namenode -format，再 start-dfs.sh 和 start-yarn.sh。但真正的难点全在细节，下面把最容易出事的四个配置列出来。

6.2 四个关键配置文件的正确打开方式

core-site.xml 里配置 HDFS 的访问地址：

xml复制<configuration>
    <property>
        <name>fs.defaultFS</name>
        <value>hdfs://localhost:9000</value>
    </property>
    <property>
        <name>hadoop.tmp.dir</name>
        <value>/home/hadoop/data/tmp</value>
    </property>
</configuration>

注意 hadoop.tmp.dir 必须设成一个真实的本地目录，而且每个用户都有默认值，如果你不配，默认是 /tmp/hadoop-${user}，系统重启后有可能被清掉，导致 NameNode 元数据丢失。这个坑我踩过：有一次重启机器后，HDFS 里数据全没了，就是因为 /tmp 被系统清理了。

hdfs-site.xml 里配置副本数：

xml复制<configuration>
    <property>
        <name>dfs.replication</name>
        <value>1</value>
    </property>
    <property>
        <name>dfs.namenode.name.dir</name>
        <value>/home/hadoop/data/namenode</value>
    </property>
    <property>
        <name>dfs.datanode.data.dir</name>
        <value>/home/hadoop/data/datanode</value>
    </property>
</configuration>

dfs.replication 设为 1 是因为伪分布式只有一个 DataNode，默认 3 会一直报块副本不足的警告。dfs.namenode.name.dir 和 dfs.datanode.data.dir 是元数据和块数据的存储路径，千万不要放在 /tmp 目录下面，原因同上。

mapred-site.xml 里指定用 YARN 作为资源调度器：

xml复制<configuration>
    <property>
        <name>mapreduce.framework.name</name>
        <value>yarn</value>
    </property>
</configuration>

yarn-site.xml 里配置资源管理的地址，顺便处理一个最经典的内存问题，后面单独说。

6.3 一个让所有新手崩溃的报错：内存不足

这个报错太典型了，搜 “java: outofmemoryerror: insufficient memory” 能搜出无数人。我的情况是：跑 Job 2 的时候，到 Reduce 阶段直接报错，容器被 YARN 杀掉，日志里写着 “Container killed by the ApplicationMaster” 和 “OutOfMemoryError”。

排查链路是：首先看 yarn-site.xml 里 ResourceManager 给每个容器分配的内存。默认情况下，YARN 的 yarn.nodemanager.resource.memory-mb 是 8192，每个容器默认 yarn.scheduler.minimum-allocation-mb 是 1024。但如果 mapred-site.xml 里没配置 mapreduce.map.memory.mb 和 mapreduce.reduce.memory.mb，默认每个 Map 和 Reduce 任务只有 1024MB，对于复杂作业不够。

解决方法是把 reduce 任务的内存调大：

xml复制<property>
    <name>mapreduce.reduce.memory.mb</name>
    <value>2048</value>
</property>
<property>
    <name>mapreduce.reduce.java.opts</name>
    <value>-Xmx1792m</value>
</property>

注意 mapreduce.reduce.java.opts 的堆大小要比 mapreduce.reduce.memory.mb 小约 300MB，因为 JVM 本身还要占用一部分非堆内存。如果不留这个余量，容器内存和 JVM 堆内存相互挤压，会触发 cgroup 的强制杀掉进程——表现就是报错，进程直接消失。

6.4 伪分布式下最容易忽略的三个操作细节

细节一：SSH localhost 免密必须配好。start-dfs.sh 会 SSH 到本机启动 DataNode 和 NameNode，如果没配免密，启动脚本会卡在让你输密码，每次都输很崩溃。配置方式：ssh-keygen -t rsa 然后 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys。这事做过一次就再也不用管了。

细节二：每次修改核心配置或机器重启后，可能遇到“NameNode 启动但 DataNode 起不来”的情况。原因是格式化 NameNode 后生成的 clusterID 和 DataNode 里存的不一致。解决办法是：先停掉所有 Hadoop 进程，删掉 dfs.namenode.name.dir 和 dfs.datanode.data.dir 下的所有内容，重新 hdfs namenode -format，再启动。注意：这个操作会清空 HDFS 里的所有数据，数据已经导入的话要先备份或重新上传。

细节三：Hadoop 3.x 的 Web UI 端口。NameNode 的网页端是 http://localhost:9870（旧版本是 50070），YARN ResourceManager 的网页端是 http://localhost:8088。启动完所有进程后，可以先访问这两个页面，确认 DataNode 和 NodeManager 都注册上来了，再开始跑作业。这一步能帮你把“环境问题”和“代码问题”隔离开——页面正常说明集群没事，作业报错才有可能是代码问题。

6.5 作业跑起来之后，怎么看日志找问题

MapReduce 作业跑挂，第一反应不是看 IDE 控制台，而是去 YARN 的 Web UI 看 Application 详情。8088 端口那个页面能列出每个作业的 Map 和 Reduce 进度、失败次数，点进去能看到每个 Task 的日志。日志才是真正的案发现场。

我遇到过的一次典型排查：Map 阶段 100%，Reduce 阶段一直卡在 33%。去 YARN 页面看日志，发现 reduce 端正在拉取 map 输出的数据，但有一个 map 任务的输出文件特别大——前面提到的用 List 保存全部 value 的问题就发生在这种场景下。找到原因后，改成流式拼接，任务从 10 分钟缩短到 2 分钟。日志不一定能直接告诉你“代码哪里错了”，但它能告诉你“卡在哪个阶段”，结合阶段特点就能反推问题所在。

6.5 作业跑起来之后，怎么看日志找问题

MapReduce 作业跑挂，第一反应不是看 IDE 控制台，而是去 YARN 的 Web UI 看 Application 详情。8088 端口那个页面能列出每个作业的 Map 和 Reduce 进度、失败次数，点进去能看到每个 Task 的日志。日志才是真正的案发现场。

我遇到过的一次典型排查：Map 阶段 100%，Reduce 阶段一直卡在 33%。去 YARN 页面看日志，发现 reduce 端正在拉取 map 输出的数据，但有一个 map 任务的输出文件特别大——前面提到的用 List 保存全部 value 的问题就发生在这种场景下。找到原因后，改成流式拼接，任务从 10 分钟缩短到 2 分钟。日志不一定能直接告诉你“代码哪里错了”，但它能告诉你“卡在哪个阶段”，结合阶段特点就能反推问题所在。

7. 效果验证和后续优化：推荐结果到底准不准

7.1 用离线指标量化推荐效果

毕设代码跑完，最关键的一步是证明“推荐是有效的”。经验主义的“看着还行”是不够的，答辩时老师必然会问：你怎么证明推荐效果？这里我用的是离线评测里的两个基础指标：准确率和召回率。

做法是：把评分数据集按 8:2 划分成训练集和测试集，训练集跑推荐算法，对测试集中每个用户实际产生过评分行为的电影，检查是否出现在推荐列表里。比如测试集中用户 88 实际看了 10 部电影，算法推荐的 20 部里有 6 部是他实际看过的，那准确率就是 6/20=30%，召回率就是 6/10=60%。这两个指标一个看“推荐对了多少”，一个看“漏掉了多少”，合在一起能说明问题。

我当时的结果是：推荐 20 部电影时准确率约 19%，召回率约 34%。这个数值没法跟工业界比，但对于一个基于共现矩阵简化计算的毕设项目，已经是及格水平。答辩时主动把这个量化指标摆出来，比干巴巴说“效果很好”更有说服力。

7.2 冷启动和热门偏向这两个绕不开的问题

毕设答辩时，老师大概率会追问两个问题，提前准备好答案能让你不慌。

第一个是冷启动问题：新用户没有任何评分记录，ItemCF 怎么给他推荐？实际做法是：对于评分记录少于 5 条的用户，直接推荐全站热门电影 Top 10。推荐系统里这个叫“冷启动策略”，不算算法缺陷，而是产品策略。毕设里用热门榜兜底，讲清楚即可。

第二个是热门偏向问题：共现矩阵天然偏向热门电影，因为热门电影被很多用户评分过，共现次数高，所以推荐列表容易被《星球大战》《阿甘正传》这类超级热门霸占。我的简化相似度公式里已经用分母做了缓冲，但依然存在。优化办法是引入“惩罚项”：在两个电影共现时，考虑它们各自被评分总次数的倒数作为权重。如果你想让算法效果更好，这是最值得优先改进的地方。

7.3 如果想继续扩展：从离线到在线

毕设答辩后如果想把这个项目继续做下去，有几个明确的扩展方向。一个是算法升级：从共现矩阵近似升级成完整的余弦相似度或皮尔逊相关系数，需要把评分向量带进计算流程；另一个是计算引擎升级：从 MapReduce 换到 Spark，用 Spark SQL 和 DataFrame API 重写一遍协同过滤，代码量能减少一半以上，运行速度提升几个数量级；还有一个是数据时效性升级：从离线天级更新，变成实时增量更新，那就要引入消息队列和流处理框架。

每个方向都有值得研究的技术细节，而且都能作为毕业论文里的“下一步工作展望”。但如果你只是想顺利毕业，先把前面的基础流程跑通，把原理讲透，已经完全够用了。

8. 最后说几句体己话

从选题到现在完整跑通整个链路，我最深的体会是：Hadoop 推荐系统的难点不在算法本身，而在“数据在不同组件间流转”这条链路的每一环都可能断掉。 数据格式不统一、HDFS 权限不对、MapReduce 内存不够、MySQL 导不进去、前端查不到数据——任何一个环节出问题，整个系统都跑不起来。但反过来想，正因为它涉及这么多环节，每排掉一个坑，你对大数据生态的理解就会扎实一分。这是写一个纯 Spring Boot CRUD 项目完全给不了的体验。

最后给正在准备类似毕设的同学一个最实用的建议：从第一天开始，就要养成看日志的习惯。 无论是 Hadoop 的 YARN 日志、Spring Boot 的控制台日志，还是 MySQL 的错误日志，报错信息永远不会骗你，它只是委婉了一点，需要你耐心地多读几遍。你要做的不是背答案，而是学会顺着日志的线索一步步定位问题，这才是这个项目真正训练出来的能力。