尧图网页设计 
简介这是一套面向计算机相关专业学生的Spark电影推荐系统毕业设计完整资料涵盖源码与配套论文适合正在准备毕业设计、课程设计或期末大作业的学习者也适合希望积累推荐系统实战经验的项目练习者。资源包共80个文件以44个Java、20个Python、7个Scala源码为主辅以XML配置、properties参数文件及一份PDF论文压缩包约16.18MB结构清晰便于按模块查阅。项目融合SpringBoot后端与微信小程序前端包含数据采集、评论解析、离线与流式推荐、Kafka流处理等模块并附有基于多模型融合策略的论文文档可帮助读者理解推荐算法从数据到服务的完整链路。已有93人学习下载代码完整可运行适合作为毕业设计参考或推荐系统入门实战素材。1. 从一份毕业设计说起Spark 电影推荐系统到底在做什么如果你正在搜「基于Spark的电影推荐系统源码论文」大概率不是想听推荐算法的发展史而是想搞清楚三件事这套东西能不能跑起来、论文里的模型到底怎么落到代码上、答辩时老师会追问哪些参数。我见过太多计算机毕业设计卡在同一个地方——离线脚本能跑出几条推荐结果但一上集群就报序列化错误或者论文里写的 RMSE 和代码里跑出来的对不上。这个方向的核心其实不复杂用 Spark 把 MovieLens 这类评分数据读进来做清洗和特征处理再用 ALS交替最小二乘矩阵分解训练出用户和物品的隐向量最后给每个用户生成 TopN 推荐列表。它适合大数据、软件工程、计算机方向的本科或专硕毕业设计也适合想补一段 Spark 实战经历的人。真正决定这份毕设能不能过、能不能讲清楚的不是算法多花哨而是数据流、参数和评估这三块有没有闭环。2. 环境与数据把 Spark 电影推荐系统的地基打牢2.1 本地伪分布式还是三节点集群先想清楚答辩现场毕业设计最常见的翻车不是代码写错而是环境跑不起来。我的建议很直接开发阶段用本地模式local[*]答辩演示前再决定要不要上集群。原因很简单ALS 在 MovieLens 1M 这种规模上单机 8 核 16G 完全够用而三节点集群的搭建、网络、SSH 免密、时间同步这些事任何一个环节出问题都会吃掉你两三天。如果你确实需要「spark集群搭建」这个工作量来撑论文的第三章那就搭三台虚拟机角色分配如下节点角色内存建议masterMaster Worker4Gslave1Worker4Gslave2Worker4GSpark 版本选择上3.x 系列对 Java 11 支持更好2.4.x 则资料最多、和 Hadoop 2.7 搭配最稳。毕业设计不追求新追求能跑通、能截图、能写进论文。安装步骤概括为解压、配置spark-env.sh里的JAVA_HOME和SPARK_MASTER_HOST、配置workers文件、分发到各节点、启动sbin/start-all.sh。启动后用jps确认 Master 和 Worker 进程都在再打开 8080 端口看 Web UI。提示虚拟机内存不要都给 2GSpark 的 executor 起不来会一直卡在WAITING状态这是新手最常遇到的「玄学」问题之一。2.2 MovieLens 数据集的读取与字段含义MovieLens 是电影推荐方向最标准的数据集常见的有 100K、1M、10M 三个版本。毕业设计用 1M 版本最合适100 万条评分、6040 个用户、3706 部电影规模足够体现 Spark 的价值又不会让训练时间失控。ratings.dat的格式是UserID::MovieID::Rating::Timestamp分隔符是双冒号。用 Spark 读取时不要直接当 CSV 处理否则字段会错位。下面是我常用的读取和解析代码from pyspark.sql import SparkSession from pyspark.sql.functions import col, split, to_timestamp, from_unixtime spark SparkSession.builder \ .appName(MovieRecommend) \ .master(local[*]) \ .config(spark.sql.shuffle.partitions, 8) \ .getOrCreate() # 读取原始 ratings.dat按 :: 切分 raw spark.read.text(data/ratings.dat) ratings raw.select( split(col(value), ::).getItem(0).cast(int).alias(user_id), split(col(value), ::).getItem(1).cast(int).alias(movie_id), split(col(value), ::).getItem(2).cast(float).alias(rating), split(col(value), ::).getItem(3).cast(long).alias(ts) ).withColumn(rating_time, from_unixtime(col(ts)).cast(timestamp)) ratings.cache() print(总评分条数:, ratings.count()) print(独立用户数:, ratings.select(user_id).distinct().count())这段代码的关键点有三个。第一split之后必须用getItem按位置取值不能依赖 schema 推断。第二spark.sql.shuffle.partitions默认是 200本地跑会开 200 个分区小数据集上反而拖慢速度设成 8 或 16 更合理。第三cache()是必须的ALS 训练会多次扫描 ratings不缓存的话每次都要重新解析文本。2.3 数据清洗把评分低于 3 的记录和冷启动用户处理掉原始数据不能直接喂给 ALS。常见做法是先做两件事过滤掉评分次数过少的用户和电影以及决定是否只保留「正向」评分。MovieLens 的评分是 1 到 5如果目标是「推荐用户可能喜欢的电影」通常只保留 rating 3 的记录把 1 到 2 分当作负反馈剔除。# 统计每个用户和每部电影的评分数 user_counts ratings.groupBy(user_id).count() movie_counts ratings.groupBy(movie_id).count() # 过滤用户至少评 10 部电影至少被评 20 次 valid_users user_counts.filter(col(count) 10).select(user_id) valid_movies movie_counts.filter(col(count) 20).select(movie_id) clean ratings.join(valid_users, user_id) \ .join(valid_movies, movie_id) \ .filter(col(rating) 3) print(清洗后条数:, clean.count())阈值 10 和 20 不是拍脑袋定的。用户评分数太少ALS 学不出稳定向量电影被评次数太少推荐出来也没意义。这两个参数在论文里要写清楚答辩时老师很可能问「为什么是 10 不是 5」。你可以回答经过对比实验阈值从 5 提到 10 时 RMSE 下降明显再往上提升有限但数据量损失大。3. ALS 模型训练参数怎么设、结果怎么看3.1 用 Spark MLlib 的 ALS 跑通第一版推荐Spark MLlib 自带ALS这是毕业设计最省事的路径。核心参数有四个rank隐向量维度、maxIter迭代次数、regParam正则化系数、implicitPrefs显式还是隐式反馈。MovieLens 是显式评分所以implicitPrefsFalse。from pyspark.ml.recommendation import ALS from pyspark.ml.evaluation import RegressionEvaluator # 划分训练集和测试集 (training, test) clean.randomSplit([0.8, 0.2], seed42) als ALS( maxIter10, regParam0.1, rank10, userColuser_id, itemColmovie_id, ratingColrating, implicitPrefsFalse, coldStartStrategydrop ) model als.fit(training) # 预测并评估 predictions model.transform(test) evaluator RegressionEvaluator( metricNamermse, labelColrating, predictionColprediction ) rmse evaluator.evaluate(predictions) print(测试集 RMSE %.4f % rmse)coldStartStrategydrop这一行非常重要。测试集里可能出现训练集没见过的用户或电影ALS 对这类样本会返回 NaN如果不 dropRMSE 直接变成 NaN你会以为是模型崩了其实是评估方式的问题。这个坑我在第一次做的时候踩了整整一个下午。3.2 rank、regParam、maxIter 三个参数的调法参数调优是论文里最能体现工作量的部分也是答辩最容易追问的地方。我的经验是不要盲目网格搜索先固定两个、调一个观察 RMSE 的变化趋势。参数常用范围作用过大的后果rank10 ~ 200隐向量维度过拟合训练慢regParam0.01 ~ 1.0正则化强度欠拟合RMSE 升高maxIter10 ~ 20迭代次数收益递减耗时增加一个可复现的调参脚本如下results [] for rank in [10, 20, 50]: for reg in [0.01, 0.1, 0.5]: als ALS(maxIter10, regParamreg, rankrank, userColuser_id, itemColmovie_id, ratingColrating, coldStartStrategydrop, seed42) model als.fit(training) pred model.transform(test) rmse evaluator.evaluate(pred) results.append((rank, reg, rmse)) print(frank{rank}, reg{reg}, RMSE{rmse:.4f})在 MovieLens 1M 上rank20、regParam0.1 通常能到 RMSE 0.86 左右rank 继续加大到 50 以上RMSE 可能略降但训练时间翻倍。论文里把这张表放上去比只写「我用了 ALS」有说服力得多。3.3 给用户生成 TopN 推荐列表训练完模型最后一步是给每个用户推荐电影。MLlib 提供了recommendForAllUsers直接返回每个用户的推荐结果。# 为每个用户推荐 10 部电影 user_recs model.recommendForAllUsers(10) # 展开成 (user_id, movie_id, score) 的扁平结构 from pyspark.sql.functions import explode flat user_recs.select( col(user_id), explode(col(recommendations)).alias(rec) ).select( col(user_id), col(rec.movie_id).alias(movie_id), col(rec.rating).alias(score) ) # 关联电影名称方便展示 movies spark.read.text(data/movies.dat).select( split(col(value), ::).getItem(0).cast(int).alias(movie_id), split(col(value), ::).getItem(1).alias(title) ) result flat.join(movies, movie_id).orderBy(user_id, col(score).desc()) result.show(20, truncateFalse)recommendForAllUsers在用户量大时会产生很大的 DataFrame6040 个用户乘 10 部电影还好如果是百万用户就要考虑分批处理。另外推荐分数是 ALS 预测的评分不是概率排序用它没问题但不要解释成「喜欢概率」。4. 避坑与排查那些让毕设卡住的真实问题4.1 现象任务一直卡在 Stage 0Web UI 显示 Shuffle 写入巨大原因通常是spark.sql.shuffle.partitions用了默认的 200而数据量只有几十万条导致大量小分区和调度开销。解决方式是在SparkSession里显式设置成 CPU 核数的 2 到 4 倍本地 8 核就设 16 或 32。改完重启任务Stage 时间会明显下降。4.2 现象RMSE 输出 NaN原因几乎都是测试集里存在训练集没出现过的 user_id 或 movie_idALS 对冷启动样本返回 NaN。解决方式是在 ALS 里加coldStartStrategydrop或者在划分数据集前先做一次全局的用户和电影编码保证训练集和测试集的 ID 空间一致。4.3 现象Java 序列化错误 Task not serializable原因是在 map、filter 这类算子内部引用了外部的 SparkSession 或不可序列化的对象。解决方式是把需要的逻辑写成独立的函数或者用broadcast分发小字典。在 PySpark 里这个错误相对少但如果你在 Scala 里写几乎必踩。4.4 现象训练时间从几分钟变成半小时原因通常是cache()没加或者加了之后又对 DataFrame 做了会破坏缓存的血缘操作。检查方式是打开 Spark UI 的 Storage 页面看 ratings 有没有真正被缓存。另一个可能是 executor 内存不足导致频繁 GC可以在提交时加--executor-memory 4g并观察 GC 时间占比。4.5 现象论文里的 RMSE 和代码跑出来的对不上原因一般是随机种子没固定。randomSplit和 ALS 的seed都要显式设置否则每次运行划分不同结果自然不同。论文里写实验环境时把 seed、rank、regParam、maxIter 全部列出来这是可复现性的基本要求。5. 从能跑到能讲评估、对比与答辩加分项5.1 除了 RMSE再加两个评估指标RMSE 只衡量评分预测误差不衡量推荐列表的质量。答辩时如果老师问「你怎么知道推荐的电影是用户喜欢的」只答 RMSE 会显得单薄。建议补上 PrecisionK 和 RecallK对每个用户把他测试集里评分 4 的电影当作「真正喜欢」看推荐列表里命中了多少。def precision_at_k(pred_df, test_df, k10): # 测试集中评分4的作为相关物品 relevant test_df.filter(col(rating) 4) \ .groupBy(user_id) \ .agg(collect_set(movie_id).alias(rel)) # 每个用户推荐的前k个 topk pred_df.groupBy(user_id) \ .agg(collect_set(movie_id).alias(rec)) joined relevant.join(topk, user_id) # 计算命中比例 hit joined.rdd.map( lambda r: len(set(r[rel]) set(r[rec][:k])) / k ).mean() return hit这段代码用 RDD 做集合交集逻辑直观。注意rec需要先按分数排序再取前 k实际写的时候要在 groupBy 之前用 Window 函数排好序。5.2 和基线方法做对比论文才有说服力单独一个 ALS 的 RMSE 说明不了什么加两个基线对比工作量立刻体现出来。最简单的两个基线是方法思路预期 RMSE全局均值所有预测都填训练集平均分约 1.12用户均值填该用户的历史平均分约 0.95ALS矩阵分解约 0.86把这三行放进论文的实验章节再配一张 RMSE 随 rank 变化的折线图整个推荐系统部分就完整了。全局均值和用户均值用 Spark 的agg就能算代码量很小但对比效果非常直观。5.3 答辩前我会做的一件事每次带毕设我都会让学生在答辩前一天做一次完整的「冷启动演练」把代码从空环境重新跑一遍记录每一步的耗时和输出。不是为了优化而是为了确认没有隐藏的依赖、没有手动改过的中间文件、没有只在特定机器上才有的路径。我自己的习惯是把所有路径写成相对路径把参数集中在一个config.py里这样换台机器只需要改一个文件。这个习惯帮我省过很多次「昨天还能跑今天就不行」的后悔药。希望帮到你。本文还有配套的精品资源点击获取 基于Spark的电影推荐系统毕业设计：ALS实战与避坑指南
简介这是一套面向计算机相关专业学生的Spark电影推荐系统毕业设计完整资料涵盖源码与配套论文适合正在准备毕业设计、课程设计或期末大作业的学习者也适合希望积累推荐系统实战经验的项目练习者。资源包共80个文件以44个Java、20个Python、7个Scala源码为主辅以XML配置、properties参数文件及一份PDF论文压缩包约16.18MB结构清晰便于按模块查阅。项目融合SpringBoot后端与微信小程序前端包含数据采集、评论解析、离线与流式推荐、Kafka流处理等模块并附有基于多模型融合策略的论文文档可帮助读者理解推荐算法从数据到服务的完整链路。已有93人学习下载代码完整可运行适合作为毕业设计参考或推荐系统入门实战素材。1. 从一份毕业设计说起Spark 电影推荐系统到底在做什么如果你正在搜「基于Spark的电影推荐系统源码论文」大概率不是想听推荐算法的发展史而是想搞清楚三件事这套东西能不能跑起来、论文里的模型到底怎么落到代码上、答辩时老师会追问哪些参数。我见过太多计算机毕业设计卡在同一个地方——离线脚本能跑出几条推荐结果但一上集群就报序列化错误或者论文里写的 RMSE 和代码里跑出来的对不上。这个方向的核心其实不复杂用 Spark 把 MovieLens 这类评分数据读进来做清洗和特征处理再用 ALS交替最小二乘矩阵分解训练出用户和物品的隐向量最后给每个用户生成 TopN 推荐列表。它适合大数据、软件工程、计算机方向的本科或专硕毕业设计也适合想补一段 Spark 实战经历的人。真正决定这份毕设能不能过、能不能讲清楚的不是算法多花哨而是数据流、参数和评估这三块有没有闭环。2. 环境与数据把 Spark 电影推荐系统的地基打牢2.1 本地伪分布式还是三节点集群先想清楚答辩现场毕业设计最常见的翻车不是代码写错而是环境跑不起来。我的建议很直接开发阶段用本地模式local[*]答辩演示前再决定要不要上集群。原因很简单ALS 在 MovieLens 1M 这种规模上单机 8 核 16G 完全够用而三节点集群的搭建、网络、SSH 免密、时间同步这些事任何一个环节出问题都会吃掉你两三天。如果你确实需要「spark集群搭建」这个工作量来撑论文的第三章那就搭三台虚拟机角色分配如下节点角色内存建议masterMaster Worker4Gslave1Worker4Gslave2Worker4GSpark 版本选择上3.x 系列对 Java 11 支持更好2.4.x 则资料最多、和 Hadoop 2.7 搭配最稳。毕业设计不追求新追求能跑通、能截图、能写进论文。安装步骤概括为解压、配置spark-env.sh里的JAVA_HOME和SPARK_MASTER_HOST、配置workers文件、分发到各节点、启动sbin/start-all.sh。启动后用jps确认 Master 和 Worker 进程都在再打开 8080 端口看 Web UI。提示虚拟机内存不要都给 2GSpark 的 executor 起不来会一直卡在WAITING状态这是新手最常遇到的「玄学」问题之一。2.2 MovieLens 数据集的读取与字段含义MovieLens 是电影推荐方向最标准的数据集常见的有 100K、1M、10M 三个版本。毕业设计用 1M 版本最合适100 万条评分、6040 个用户、3706 部电影规模足够体现 Spark 的价值又不会让训练时间失控。ratings.dat的格式是UserID::MovieID::Rating::Timestamp分隔符是双冒号。用 Spark 读取时不要直接当 CSV 处理否则字段会错位。下面是我常用的读取和解析代码from pyspark.sql import SparkSession from pyspark.sql.functions import col, split, to_timestamp, from_unixtime spark SparkSession.builder \ .appName(MovieRecommend) \ .master(local[*]) \ .config(spark.sql.shuffle.partitions, 8) \ .getOrCreate() # 读取原始 ratings.dat按 :: 切分 raw spark.read.text(data/ratings.dat) ratings raw.select( split(col(value), ::).getItem(0).cast(int).alias(user_id), split(col(value), ::).getItem(1).cast(int).alias(movie_id), split(col(value), ::).getItem(2).cast(float).alias(rating), split(col(value), ::).getItem(3).cast(long).alias(ts) ).withColumn(rating_time, from_unixtime(col(ts)).cast(timestamp)) ratings.cache() print(总评分条数:, ratings.count()) print(独立用户数:, ratings.select(user_id).distinct().count())这段代码的关键点有三个。第一split之后必须用getItem按位置取值不能依赖 schema 推断。第二spark.sql.shuffle.partitions默认是 200本地跑会开 200 个分区小数据集上反而拖慢速度设成 8 或 16 更合理。第三cache()是必须的ALS 训练会多次扫描 ratings不缓存的话每次都要重新解析文本。2.3 数据清洗把评分低于 3 的记录和冷启动用户处理掉原始数据不能直接喂给 ALS。常见做法是先做两件事过滤掉评分次数过少的用户和电影以及决定是否只保留「正向」评分。MovieLens 的评分是 1 到 5如果目标是「推荐用户可能喜欢的电影」通常只保留 rating 3 的记录把 1 到 2 分当作负反馈剔除。# 统计每个用户和每部电影的评分数 user_counts ratings.groupBy(user_id).count() movie_counts ratings.groupBy(movie_id).count() # 过滤用户至少评 10 部电影至少被评 20 次 valid_users user_counts.filter(col(count) 10).select(user_id) valid_movies movie_counts.filter(col(count) 20).select(movie_id) clean ratings.join(valid_users, user_id) \ .join(valid_movies, movie_id) \ .filter(col(rating) 3) print(清洗后条数:, clean.count())阈值 10 和 20 不是拍脑袋定的。用户评分数太少ALS 学不出稳定向量电影被评次数太少推荐出来也没意义。这两个参数在论文里要写清楚答辩时老师很可能问「为什么是 10 不是 5」。你可以回答经过对比实验阈值从 5 提到 10 时 RMSE 下降明显再往上提升有限但数据量损失大。3. ALS 模型训练参数怎么设、结果怎么看3.1 用 Spark MLlib 的 ALS 跑通第一版推荐Spark MLlib 自带ALS这是毕业设计最省事的路径。核心参数有四个rank隐向量维度、maxIter迭代次数、regParam正则化系数、implicitPrefs显式还是隐式反馈。MovieLens 是显式评分所以implicitPrefsFalse。from pyspark.ml.recommendation import ALS from pyspark.ml.evaluation import RegressionEvaluator # 划分训练集和测试集 (training, test) clean.randomSplit([0.8, 0.2], seed42) als ALS( maxIter10, regParam0.1, rank10, userColuser_id, itemColmovie_id, ratingColrating, implicitPrefsFalse, coldStartStrategydrop ) model als.fit(training) # 预测并评估 predictions model.transform(test) evaluator RegressionEvaluator( metricNamermse, labelColrating, predictionColprediction ) rmse evaluator.evaluate(predictions) print(测试集 RMSE %.4f % rmse)coldStartStrategydrop这一行非常重要。测试集里可能出现训练集没见过的用户或电影ALS 对这类样本会返回 NaN如果不 dropRMSE 直接变成 NaN你会以为是模型崩了其实是评估方式的问题。这个坑我在第一次做的时候踩了整整一个下午。3.2 rank、regParam、maxIter 三个参数的调法参数调优是论文里最能体现工作量的部分也是答辩最容易追问的地方。我的经验是不要盲目网格搜索先固定两个、调一个观察 RMSE 的变化趋势。参数常用范围作用过大的后果rank10 ~ 200隐向量维度过拟合训练慢regParam0.01 ~ 1.0正则化强度欠拟合RMSE 升高maxIter10 ~ 20迭代次数收益递减耗时增加一个可复现的调参脚本如下results [] for rank in [10, 20, 50]: for reg in [0.01, 0.1, 0.5]: als ALS(maxIter10, regParamreg, rankrank, userColuser_id, itemColmovie_id, ratingColrating, coldStartStrategydrop, seed42) model als.fit(training) pred model.transform(test) rmse evaluator.evaluate(pred) results.append((rank, reg, rmse)) print(frank{rank}, reg{reg}, RMSE{rmse:.4f})在 MovieLens 1M 上rank20、regParam0.1 通常能到 RMSE 0.86 左右rank 继续加大到 50 以上RMSE 可能略降但训练时间翻倍。论文里把这张表放上去比只写「我用了 ALS」有说服力得多。3.3 给用户生成 TopN 推荐列表训练完模型最后一步是给每个用户推荐电影。MLlib 提供了recommendForAllUsers直接返回每个用户的推荐结果。# 为每个用户推荐 10 部电影 user_recs model.recommendForAllUsers(10) # 展开成 (user_id, movie_id, score) 的扁平结构 from pyspark.sql.functions import explode flat user_recs.select( col(user_id), explode(col(recommendations)).alias(rec) ).select( col(user_id), col(rec.movie_id).alias(movie_id), col(rec.rating).alias(score) ) # 关联电影名称方便展示 movies spark.read.text(data/movies.dat).select( split(col(value), ::).getItem(0).cast(int).alias(movie_id), split(col(value), ::).getItem(1).alias(title) ) result flat.join(movies, movie_id).orderBy(user_id, col(score).desc()) result.show(20, truncateFalse)recommendForAllUsers在用户量大时会产生很大的 DataFrame6040 个用户乘 10 部电影还好如果是百万用户就要考虑分批处理。另外推荐分数是 ALS 预测的评分不是概率排序用它没问题但不要解释成「喜欢概率」。4. 避坑与排查那些让毕设卡住的真实问题4.1 现象任务一直卡在 Stage 0Web UI 显示 Shuffle 写入巨大原因通常是spark.sql.shuffle.partitions用了默认的 200而数据量只有几十万条导致大量小分区和调度开销。解决方式是在SparkSession里显式设置成 CPU 核数的 2 到 4 倍本地 8 核就设 16 或 32。改完重启任务Stage 时间会明显下降。4.2 现象RMSE 输出 NaN原因几乎都是测试集里存在训练集没出现过的 user_id 或 movie_idALS 对冷启动样本返回 NaN。解决方式是在 ALS 里加coldStartStrategydrop或者在划分数据集前先做一次全局的用户和电影编码保证训练集和测试集的 ID 空间一致。4.3 现象Java 序列化错误 Task not serializable原因是在 map、filter 这类算子内部引用了外部的 SparkSession 或不可序列化的对象。解决方式是把需要的逻辑写成独立的函数或者用broadcast分发小字典。在 PySpark 里这个错误相对少但如果你在 Scala 里写几乎必踩。4.4 现象训练时间从几分钟变成半小时原因通常是cache()没加或者加了之后又对 DataFrame 做了会破坏缓存的血缘操作。检查方式是打开 Spark UI 的 Storage 页面看 ratings 有没有真正被缓存。另一个可能是 executor 内存不足导致频繁 GC可以在提交时加--executor-memory 4g并观察 GC 时间占比。4.5 现象论文里的 RMSE 和代码跑出来的对不上原因一般是随机种子没固定。randomSplit和 ALS 的seed都要显式设置否则每次运行划分不同结果自然不同。论文里写实验环境时把 seed、rank、regParam、maxIter 全部列出来这是可复现性的基本要求。5. 从能跑到能讲评估、对比与答辩加分项5.1 除了 RMSE再加两个评估指标RMSE 只衡量评分预测误差不衡量推荐列表的质量。答辩时如果老师问「你怎么知道推荐的电影是用户喜欢的」只答 RMSE 会显得单薄。建议补上 PrecisionK 和 RecallK对每个用户把他测试集里评分 4 的电影当作「真正喜欢」看推荐列表里命中了多少。def precision_at_k(pred_df, test_df, k10): # 测试集中评分4的作为相关物品 relevant test_df.filter(col(rating) 4) \ .groupBy(user_id) \ .agg(collect_set(movie_id).alias(rel)) # 每个用户推荐的前k个 topk pred_df.groupBy(user_id) \ .agg(collect_set(movie_id).alias(rec)) joined relevant.join(topk, user_id) # 计算命中比例 hit joined.rdd.map( lambda r: len(set(r[rel]) set(r[rec][:k])) / k ).mean() return hit这段代码用 RDD 做集合交集逻辑直观。注意rec需要先按分数排序再取前 k实际写的时候要在 groupBy 之前用 Window 函数排好序。5.2 和基线方法做对比论文才有说服力单独一个 ALS 的 RMSE 说明不了什么加两个基线对比工作量立刻体现出来。最简单的两个基线是方法思路预期 RMSE全局均值所有预测都填训练集平均分约 1.12用户均值填该用户的历史平均分约 0.95ALS矩阵分解约 0.86把这三行放进论文的实验章节再配一张 RMSE 随 rank 变化的折线图整个推荐系统部分就完整了。全局均值和用户均值用 Spark 的agg就能算代码量很小但对比效果非常直观。5.3 答辩前我会做的一件事每次带毕设我都会让学生在答辩前一天做一次完整的「冷启动演练」把代码从空环境重新跑一遍记录每一步的耗时和输出。不是为了优化而是为了确认没有隐藏的依赖、没有手动改过的中间文件、没有只在特定机器上才有的路径。我自己的习惯是把所有路径写成相对路径把参数集中在一个config.py里这样换台机器只需要改一个文件。这个习惯帮我省过很多次「昨天还能跑今天就不行」的后悔药。希望帮到你。本文还有配套的精品资源点击获取