尧图网站建设 
简介这是一套基于Hadoop实现的电影推荐系统完整项目面向计算机相关专业的毕业设计、期末大作业与课程设计人群也适合想入门大数据推荐算法的开发者。项目含源代码与SQL脚本代码附有注释新手也能看懂部署后即可运行可解决推荐系统选题缺少可落地实现的问题。压缩包共801个文件约16.27MB以340个js、151个css等前端资源为主另有60个py、47个pyc等Python程序文件以及31个map、30个less、29个svg、21个html等页面与样式资源并包含9个sql脚本、若干图片字体与说明文档前后端与数据层结构较为完整。目前已有253人学习下载。项目为作者手打并获98分评价导师认可度高读者可据此理解Hadoop环境下推荐算法的实现思路、数据表设计与前后端交互方式快速完成环境搭建与功能验证也可作为二次开发与答辩展示的基础。1. 从一份「高分项目」说起Hadoop 电影推荐系统到底在做什么很多同学在课程设计或毕设选题时会看到「基于 Hadoop 实现的电影推荐系统 源代码 SQL」这类项目第一反应是这不就是把推荐算法搬到 Hadoop 上跑吗真动手才发现难点根本不在算法本身而在数据怎么进 HDFS、离线任务怎么调度、推荐结果怎么落回 SQL 给前端查。我见过太多人卡在伪分布式环境起不来或者把 MovieLens 数据塞进 HDFS 后不知道下一步该干嘛。这个标题背后其实是一条完整的离线推荐链路用 Hadoop 生态HDFS 存原始评分数据、MapReduce 或 Spark 做协同过滤计算产出用户对未看电影的预测评分再把 TopN 结果写入 MySQL 之类的 SQL 数据库供 Web 端查询展示。它适合两类人一是需要交课程设计、毕设的在校生二是想练手 Hadoop 离线计算全流程的初中级工程师。整套东西不追求线上实时推荐那种毫秒级响应而是把「数据存储 → 分布式计算 → 结果落库」这条链路走通这才是高分项目真正的得分点。2. 环境与数据准备伪分布式 Hadoop 和 MovieLens 怎么配2.1 为什么先用伪分布式而不是真集群真集群搭建动辄三台机器对只想跑通推荐流程的人来说性价比太低。伪分布式Single Node Setup在一台机器上模拟 NameNode、DataNode、ResourceManager、NodeManager 全部角色能验证 HDFS 读写和 MapReduce 提交代码逻辑和真集群完全一致后面要扩成集群只需改配置文件里的主机名。常见做法是 Ubuntu 20.04 或 CentOS 7 上装 JDK 8 Hadoop 3.x注意 Hadoop 3.x 对 JDK 版本有要求JDK 8 最稳别用 JDK 17 去找不痛快。安装步骤我一般这么走解压 Hadoop 到/usr/local/hadoop配置core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml四个文件然后格式化 NameNode 并启动。下面这段是核心配置直接抄改主机名即可。# core-site.xml 关键项指定 HDFS 的默认文件系统地址 # fs.defaultFS 告诉客户端 NameNode 在哪伪分布式就是 localhost:9000 configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/usr/local/hadoop/tmp/value /property /configuration # hdfs-site.xml副本数设为 1伪分布式只有一块盘 configuration property namedfs.replication/name value1/value /property /configuration配置完执行hdfs namenode -format再start-dfs.sh和start-yarn.sh。用jps能看到 NameNode、DataNode、ResourceManager、NodeManager、SecondaryNameNode 五个进程才算成功。这里有个血泪经验hadoop.tmp.dir一定要显式指定默认落在/tmp下机器一重启数据全没NameNode 直接罢工。2.2 MovieLens 数据集的结构与入库方式推荐系统最常用的公开数据集是 MovieLens小到 100K 评分、大到 25M 评分都有。以 ml-latest-small 为例核心两个文件ratings.csvuserId, movieId, rating, timestamp和movies.csvmovieId, title, genres。评分是 0.5 到 5.0 的浮点数时间戳是秒级 Unix 时间。把数据放进 HDFS 之前先想清楚要不要清洗。原始 ratings 里可能有用户评分条数过少比如少于 5 条的噪声这类用户在协同过滤里贡献极小还拖慢计算我一般会先过滤掉。上传命令很直接# 在 HDFS 上建目录把本地清洗后的评分数据传上去 hdfs dfs -mkdir -p /movie/input hdfs dfs -put ratings_clean.csv /movie/input/ # 验证是否上传成功顺便看下文件大小 hdfs dfs -ls /movie/input/ hdfs dfs -cat /movie/input/ratings_clean.csv | head -5参数说明-p递归建目录-put是本地到 HDFS反过来用-get。head -5只是抽样看格式别对大文件直接cat会把终端刷爆。数据进 HDFS 后SQL 那边还要建对应的元数据表movies表存电影信息ratings表存评分字段类型注意rating用DECIMAL(2,1)而不是FLOAT避免浮点误差导致排序错乱。3. 协同过滤的 MapReduce 实现从评分矩阵到用户相似度3.1 基于用户的协同过滤原理与选型理由推荐算法里协同过滤分两大派基于用户UserCF和基于物品ItemCF。电影场景下我通常选 ItemCF因为电影数量相对稳定用户数量会持续增长物品相似度矩阵可以离线算好复用不用每次新用户来了重算。但课程设计里 UserCF 更好讲清楚「相似用户喜欢的东西推荐给你」这个直觉所以两种都实现一遍最能体现工作量。UserCF 的核心是三步第一构建用户-物品评分矩阵第二用余弦相似度或皮尔逊相关系数算用户两两之间的相似度第三对目标用户找 K 个最相似用户把他们看过而目标用户没看过的电影按相似度加权打分取 TopN。MapReduce 实现时第一步和第三步适合用 MapReduce第二步相似度计算因为要两两配对数据量小时可以放内存数据量大时得用分块策略。3.2 用 MapReduce 算物品相似度的完整代码下面这段是 ItemCF 相似度计算的 MapReduce 核心逻辑思路是Mapper 输出「物品对 → 评分乘积」Reducer 对同一物品对求和再结合各物品的评分模长算余弦相似度。// Mapper对每个用户看过的电影列表两两组合输出 // 输入userId, movieId, rating // 输出movieA:movieB - ratingA * ratingB public class SimilarityMapper extends MapperLongWritable, Text, Text, Text { Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { String[] fields value.toString().split(,); String userId fields[0]; String movieId fields[1]; double rating Double.parseDouble(fields[2]); // 用 userId 作为 key 做一次 shuffle保证同一用户的电影聚到一起 context.write(new Text(userId), new Text(movieId : rating)); } } // Reducer同一用户的电影两两配对输出物品对和评分乘积 public class SimilarityReducer extends ReducerText, Text, Text, Text { Override protected void reduce(Text key, IterableText values, Context context) throws IOException, InterruptedException { ListString[] items new ArrayList(); for (Text v : values) { String[] parts v.toString().split(:); items.add(parts); } // 两两组合注意去重和顺序保证 A:B 和 B:A 只算一次 for (int i 0; i items.size(); i) { for (int j i 1; j items.size(); j) { String pair items.get(i)[0] : items.get(j)[0]; double product Double.parseDouble(items.get(i)[1]) * Double.parseDouble(items.get(j)[1]); context.write(new Text(pair), new Text(String.valueOf(product))); } } } }逻辑说明Mapper 阶段用 userId 做 key是为了让同一个用户的所有评分进入同一个 Reducer这样 Reducer 里才能做两两组合。参数上items.size()如果很大比如一个用户看了上千部电影两两组合会爆炸实际生产里会设一个上限比如只取评分最高的 50 部参与相似度计算。Reducer 输出的 pair 用冒号分隔后续再起一个 Job 对 pair 求和并除以模长得到最终相似度。跑的时候用hadoop jar提交输入输出路径都指向 HDFS。3.3 生成推荐结果并写入 SQL 表相似度算完后最后一步是给每个用户生成推荐列表。逻辑是对目标用户看过的每部电影找出与其最相似的 N 部电影按相似度加权评分排除已看过的取 Top10。这一步输出格式建议直接对齐 SQL 表结构方便后续用 Sqoop 或 JDBC 导入。-- 推荐结果表结构字段和 MapReduce 输出一一对应 CREATE TABLE recommend_result ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, movie_id INT NOT NULL, predicted_score DECIMAL(4,2) NOT NULL, create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP, INDEX idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意predicted_score用DECIMAL(4,2)因为预测分可能超过 5.0加权求和后留两位小数够用。导入时如果用 Sqoop记得加--fields-terminated-by和 HDFS 输出格式对齐否则字段错位是高频翻车点。4. 避坑与排查Hadoop 电影推荐系统最常见的 5 个坑4.1 坑一NameNode 反复进入安全模式现象执行hdfs dfs -put报错「NameNode is in safe mode」什么写操作都做不了。原因通常是 DataNode 没起来或者磁盘空间不足触发了阈值保护。解决先jps确认 DataNode 进程在不在不在就查hdfs-site.xml里dfs.datanode.data.dir路径权限如果进程在用hdfs dfsadmin -safemode get看状态确认数据块报告正常后hdfs dfsadmin -safemode leave手动退出。根治办法是保证hadoop.tmp.dir所在分区剩余空间大于 10%。4.2 坑二MapReduce 任务卡在 map 100% reduce 0%现象Job 进度条一直停在 map 完成、reduce 不动等半天最后超时失败。原因多半是 Reducer 里做了全量数据排序或内存聚合数据倾斜导致某个 reduce key 特别大。解决在 Reducer 里加计数器看每个 key 的记录数如果某个电影被评分次数远超平均说明是热门物品可以在 Mapper 阶段对热门物品做抽样或加随机前缀打散。参数上调大mapreduce.reduce.memory.mb和mapreduce.reduce.java.opts的堆内存也有帮助。4.3 坑三相似度矩阵结果为空或全零现象跑完相似度 Job输出文件是空的或者所有相似度都是 0。原因通常是 Mapper 输出的 key 格式不对或者 Reducer 里两两组合时用了错误的索引。解决先拿 10 行小数据本地跑一遍打印中间输出检查split(,)后字段顺序是否和 CSV 列一致MovieLens 的 ratings.csv 第一列是 userId 不是 movieId这个顺序搞反是新手高频错误。4.4 坑四SQL 导入时中文电影名乱码现象推荐结果里的电影名在 Web 端显示成问号或方块。原因是从 HDFS 导出到 SQL 时字符集没统一Hadoop 默认按 UTF-8 处理MySQL 建表时如果用了 latin1 就会乱码。解决建库建表时显式指定CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ciJDBC 连接串加useUnicodetruecharacterEncodingutf8Sqoop 导入加--default-character-setutf8。4.5 坑五伪分布式重启后数据丢失现象机器重启后hdfs dfs -ls /发现之前上传的数据全没了。原因就是前面提过的hadoop.tmp.dir默认在/tmp系统清理临时目录时被删。解决在core-site.xml里把hadoop.tmp.dir指到一个持久化路径比如/data/hadoop/tmp改完重新格式化 NameNode。注意格式化会清空所有数据生产环境千万别随便执行-format。5. 进阶技巧用 Spark 替代 MapReduce 提速与结果验证MapReduce 写协同过滤代码量大、迭代慢每轮相似度计算都要落盘。如果项目允许我强烈建议把计算层换成 Spark同样的 ItemCF 用 Scala 或 PySpark 几十行就能搞定而且能缓存评分矩阵到内存迭代计算快一个数量级。下面是用 PySpark 算物品相似度的核心片段。from pyspark import SparkContext from itertools import combinations sc SparkContext(local[*], MovieRecommender) # 读 HDFS 上的评分数据格式 userId,movieId,rating raw sc.textFile(hdfs://localhost:9000/movie/input/ratings_clean.csv) # 按用户分组得到每个用户看过的 (movieId, rating) 列表 user_ratings raw.map(lambda line: line.split(,)) \ .map(lambda f: (f[0], (f[1], float(f[2])))) \ .groupByKey() # 对每个用户的电影两两组合输出 ((movieA, movieB), ratingA*ratingB) pairs user_ratings.flatMap(lambda kv: [ ((a[0], b[0]), a[1] * b[1]) for a, b in combinations(list(kv[1]), 2) ]) # 按物品对聚合求和得到相似度分子 similarity pairs.reduceByKey(lambda x, y: x y) similarity.saveAsTextFile(hdfs://localhost:9000/movie/output/sim)参数说明local[*]表示用本机所有 CPU 核伪分布式下够用groupByKey在用户评分数据量大时会有内存压力可以换成combineByKey优化。算完相似度后验证环节别偷懒随机抽 5 个用户人工看推荐结果是否合理比如给喜欢《玩具总动员》的用户推《虫虫危机》就对了推恐怖片就说明相似度算反了。我自己的习惯是每次改完相似度公式先跑一个 100 用户的小子集确认 TopN 结果符合直觉再上全量。这套流程走下来课程设计拿高分不难难的是养成「先小数据验证再全量跑」的习惯这个习惯能帮你省下大量排查时间。希望帮到你。本文还有配套的精品资源点击获取 Hadoop电影推荐系统实战：从伪分布式环境到协同过滤与SQL落库
简介这是一套基于Hadoop实现的电影推荐系统完整项目面向计算机相关专业的毕业设计、期末大作业与课程设计人群也适合想入门大数据推荐算法的开发者。项目含源代码与SQL脚本代码附有注释新手也能看懂部署后即可运行可解决推荐系统选题缺少可落地实现的问题。压缩包共801个文件约16.27MB以340个js、151个css等前端资源为主另有60个py、47个pyc等Python程序文件以及31个map、30个less、29个svg、21个html等页面与样式资源并包含9个sql脚本、若干图片字体与说明文档前后端与数据层结构较为完整。目前已有253人学习下载。项目为作者手打并获98分评价导师认可度高读者可据此理解Hadoop环境下推荐算法的实现思路、数据表设计与前后端交互方式快速完成环境搭建与功能验证也可作为二次开发与答辩展示的基础。1. 从一份「高分项目」说起Hadoop 电影推荐系统到底在做什么很多同学在课程设计或毕设选题时会看到「基于 Hadoop 实现的电影推荐系统 源代码 SQL」这类项目第一反应是这不就是把推荐算法搬到 Hadoop 上跑吗真动手才发现难点根本不在算法本身而在数据怎么进 HDFS、离线任务怎么调度、推荐结果怎么落回 SQL 给前端查。我见过太多人卡在伪分布式环境起不来或者把 MovieLens 数据塞进 HDFS 后不知道下一步该干嘛。这个标题背后其实是一条完整的离线推荐链路用 Hadoop 生态HDFS 存原始评分数据、MapReduce 或 Spark 做协同过滤计算产出用户对未看电影的预测评分再把 TopN 结果写入 MySQL 之类的 SQL 数据库供 Web 端查询展示。它适合两类人一是需要交课程设计、毕设的在校生二是想练手 Hadoop 离线计算全流程的初中级工程师。整套东西不追求线上实时推荐那种毫秒级响应而是把「数据存储 → 分布式计算 → 结果落库」这条链路走通这才是高分项目真正的得分点。2. 环境与数据准备伪分布式 Hadoop 和 MovieLens 怎么配2.1 为什么先用伪分布式而不是真集群真集群搭建动辄三台机器对只想跑通推荐流程的人来说性价比太低。伪分布式Single Node Setup在一台机器上模拟 NameNode、DataNode、ResourceManager、NodeManager 全部角色能验证 HDFS 读写和 MapReduce 提交代码逻辑和真集群完全一致后面要扩成集群只需改配置文件里的主机名。常见做法是 Ubuntu 20.04 或 CentOS 7 上装 JDK 8 Hadoop 3.x注意 Hadoop 3.x 对 JDK 版本有要求JDK 8 最稳别用 JDK 17 去找不痛快。安装步骤我一般这么走解压 Hadoop 到/usr/local/hadoop配置core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml四个文件然后格式化 NameNode 并启动。下面这段是核心配置直接抄改主机名即可。# core-site.xml 关键项指定 HDFS 的默认文件系统地址 # fs.defaultFS 告诉客户端 NameNode 在哪伪分布式就是 localhost:9000 configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/usr/local/hadoop/tmp/value /property /configuration # hdfs-site.xml副本数设为 1伪分布式只有一块盘 configuration property namedfs.replication/name value1/value /property /configuration配置完执行hdfs namenode -format再start-dfs.sh和start-yarn.sh。用jps能看到 NameNode、DataNode、ResourceManager、NodeManager、SecondaryNameNode 五个进程才算成功。这里有个血泪经验hadoop.tmp.dir一定要显式指定默认落在/tmp下机器一重启数据全没NameNode 直接罢工。2.2 MovieLens 数据集的结构与入库方式推荐系统最常用的公开数据集是 MovieLens小到 100K 评分、大到 25M 评分都有。以 ml-latest-small 为例核心两个文件ratings.csvuserId, movieId, rating, timestamp和movies.csvmovieId, title, genres。评分是 0.5 到 5.0 的浮点数时间戳是秒级 Unix 时间。把数据放进 HDFS 之前先想清楚要不要清洗。原始 ratings 里可能有用户评分条数过少比如少于 5 条的噪声这类用户在协同过滤里贡献极小还拖慢计算我一般会先过滤掉。上传命令很直接# 在 HDFS 上建目录把本地清洗后的评分数据传上去 hdfs dfs -mkdir -p /movie/input hdfs dfs -put ratings_clean.csv /movie/input/ # 验证是否上传成功顺便看下文件大小 hdfs dfs -ls /movie/input/ hdfs dfs -cat /movie/input/ratings_clean.csv | head -5参数说明-p递归建目录-put是本地到 HDFS反过来用-get。head -5只是抽样看格式别对大文件直接cat会把终端刷爆。数据进 HDFS 后SQL 那边还要建对应的元数据表movies表存电影信息ratings表存评分字段类型注意rating用DECIMAL(2,1)而不是FLOAT避免浮点误差导致排序错乱。3. 协同过滤的 MapReduce 实现从评分矩阵到用户相似度3.1 基于用户的协同过滤原理与选型理由推荐算法里协同过滤分两大派基于用户UserCF和基于物品ItemCF。电影场景下我通常选 ItemCF因为电影数量相对稳定用户数量会持续增长物品相似度矩阵可以离线算好复用不用每次新用户来了重算。但课程设计里 UserCF 更好讲清楚「相似用户喜欢的东西推荐给你」这个直觉所以两种都实现一遍最能体现工作量。UserCF 的核心是三步第一构建用户-物品评分矩阵第二用余弦相似度或皮尔逊相关系数算用户两两之间的相似度第三对目标用户找 K 个最相似用户把他们看过而目标用户没看过的电影按相似度加权打分取 TopN。MapReduce 实现时第一步和第三步适合用 MapReduce第二步相似度计算因为要两两配对数据量小时可以放内存数据量大时得用分块策略。3.2 用 MapReduce 算物品相似度的完整代码下面这段是 ItemCF 相似度计算的 MapReduce 核心逻辑思路是Mapper 输出「物品对 → 评分乘积」Reducer 对同一物品对求和再结合各物品的评分模长算余弦相似度。// Mapper对每个用户看过的电影列表两两组合输出 // 输入userId, movieId, rating // 输出movieA:movieB - ratingA * ratingB public class SimilarityMapper extends MapperLongWritable, Text, Text, Text { Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { String[] fields value.toString().split(,); String userId fields[0]; String movieId fields[1]; double rating Double.parseDouble(fields[2]); // 用 userId 作为 key 做一次 shuffle保证同一用户的电影聚到一起 context.write(new Text(userId), new Text(movieId : rating)); } } // Reducer同一用户的电影两两配对输出物品对和评分乘积 public class SimilarityReducer extends ReducerText, Text, Text, Text { Override protected void reduce(Text key, IterableText values, Context context) throws IOException, InterruptedException { ListString[] items new ArrayList(); for (Text v : values) { String[] parts v.toString().split(:); items.add(parts); } // 两两组合注意去重和顺序保证 A:B 和 B:A 只算一次 for (int i 0; i items.size(); i) { for (int j i 1; j items.size(); j) { String pair items.get(i)[0] : items.get(j)[0]; double product Double.parseDouble(items.get(i)[1]) * Double.parseDouble(items.get(j)[1]); context.write(new Text(pair), new Text(String.valueOf(product))); } } } }逻辑说明Mapper 阶段用 userId 做 key是为了让同一个用户的所有评分进入同一个 Reducer这样 Reducer 里才能做两两组合。参数上items.size()如果很大比如一个用户看了上千部电影两两组合会爆炸实际生产里会设一个上限比如只取评分最高的 50 部参与相似度计算。Reducer 输出的 pair 用冒号分隔后续再起一个 Job 对 pair 求和并除以模长得到最终相似度。跑的时候用hadoop jar提交输入输出路径都指向 HDFS。3.3 生成推荐结果并写入 SQL 表相似度算完后最后一步是给每个用户生成推荐列表。逻辑是对目标用户看过的每部电影找出与其最相似的 N 部电影按相似度加权评分排除已看过的取 Top10。这一步输出格式建议直接对齐 SQL 表结构方便后续用 Sqoop 或 JDBC 导入。-- 推荐结果表结构字段和 MapReduce 输出一一对应 CREATE TABLE recommend_result ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, movie_id INT NOT NULL, predicted_score DECIMAL(4,2) NOT NULL, create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP, INDEX idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意predicted_score用DECIMAL(4,2)因为预测分可能超过 5.0加权求和后留两位小数够用。导入时如果用 Sqoop记得加--fields-terminated-by和 HDFS 输出格式对齐否则字段错位是高频翻车点。4. 避坑与排查Hadoop 电影推荐系统最常见的 5 个坑4.1 坑一NameNode 反复进入安全模式现象执行hdfs dfs -put报错「NameNode is in safe mode」什么写操作都做不了。原因通常是 DataNode 没起来或者磁盘空间不足触发了阈值保护。解决先jps确认 DataNode 进程在不在不在就查hdfs-site.xml里dfs.datanode.data.dir路径权限如果进程在用hdfs dfsadmin -safemode get看状态确认数据块报告正常后hdfs dfsadmin -safemode leave手动退出。根治办法是保证hadoop.tmp.dir所在分区剩余空间大于 10%。4.2 坑二MapReduce 任务卡在 map 100% reduce 0%现象Job 进度条一直停在 map 完成、reduce 不动等半天最后超时失败。原因多半是 Reducer 里做了全量数据排序或内存聚合数据倾斜导致某个 reduce key 特别大。解决在 Reducer 里加计数器看每个 key 的记录数如果某个电影被评分次数远超平均说明是热门物品可以在 Mapper 阶段对热门物品做抽样或加随机前缀打散。参数上调大mapreduce.reduce.memory.mb和mapreduce.reduce.java.opts的堆内存也有帮助。4.3 坑三相似度矩阵结果为空或全零现象跑完相似度 Job输出文件是空的或者所有相似度都是 0。原因通常是 Mapper 输出的 key 格式不对或者 Reducer 里两两组合时用了错误的索引。解决先拿 10 行小数据本地跑一遍打印中间输出检查split(,)后字段顺序是否和 CSV 列一致MovieLens 的 ratings.csv 第一列是 userId 不是 movieId这个顺序搞反是新手高频错误。4.4 坑四SQL 导入时中文电影名乱码现象推荐结果里的电影名在 Web 端显示成问号或方块。原因是从 HDFS 导出到 SQL 时字符集没统一Hadoop 默认按 UTF-8 处理MySQL 建表时如果用了 latin1 就会乱码。解决建库建表时显式指定CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ciJDBC 连接串加useUnicodetruecharacterEncodingutf8Sqoop 导入加--default-character-setutf8。4.5 坑五伪分布式重启后数据丢失现象机器重启后hdfs dfs -ls /发现之前上传的数据全没了。原因就是前面提过的hadoop.tmp.dir默认在/tmp系统清理临时目录时被删。解决在core-site.xml里把hadoop.tmp.dir指到一个持久化路径比如/data/hadoop/tmp改完重新格式化 NameNode。注意格式化会清空所有数据生产环境千万别随便执行-format。5. 进阶技巧用 Spark 替代 MapReduce 提速与结果验证MapReduce 写协同过滤代码量大、迭代慢每轮相似度计算都要落盘。如果项目允许我强烈建议把计算层换成 Spark同样的 ItemCF 用 Scala 或 PySpark 几十行就能搞定而且能缓存评分矩阵到内存迭代计算快一个数量级。下面是用 PySpark 算物品相似度的核心片段。from pyspark import SparkContext from itertools import combinations sc SparkContext(local[*], MovieRecommender) # 读 HDFS 上的评分数据格式 userId,movieId,rating raw sc.textFile(hdfs://localhost:9000/movie/input/ratings_clean.csv) # 按用户分组得到每个用户看过的 (movieId, rating) 列表 user_ratings raw.map(lambda line: line.split(,)) \ .map(lambda f: (f[0], (f[1], float(f[2])))) \ .groupByKey() # 对每个用户的电影两两组合输出 ((movieA, movieB), ratingA*ratingB) pairs user_ratings.flatMap(lambda kv: [ ((a[0], b[0]), a[1] * b[1]) for a, b in combinations(list(kv[1]), 2) ]) # 按物品对聚合求和得到相似度分子 similarity pairs.reduceByKey(lambda x, y: x y) similarity.saveAsTextFile(hdfs://localhost:9000/movie/output/sim)参数说明local[*]表示用本机所有 CPU 核伪分布式下够用groupByKey在用户评分数据量大时会有内存压力可以换成combineByKey优化。算完相似度后验证环节别偷懒随机抽 5 个用户人工看推荐结果是否合理比如给喜欢《玩具总动员》的用户推《虫虫危机》就对了推恐怖片就说明相似度算反了。我自己的习惯是每次改完相似度公式先跑一个 100 用户的小子集确认 TopN 结果符合直觉再上全量。这套流程走下来课程设计拿高分不难难的是养成「先小数据验证再全量跑」的习惯这个习惯能帮你省下大量排查时间。希望帮到你。本文还有配套的精品资源点击获取