简介：这套基于SSM与Spark的电影推荐系统项目包，面向计算机专业准备毕业设计、期末大作业或大数据项目实战的学生，解决从算法原理到工程落地的完整参考需求。资源包含源码、论文、开发文档与数据库文档，源码已经本地编译调试通过，可直接运行。压缩包共1419个文件，包含Java/Scala源代码、JSP前端页面、HTML/CSS/JS界面资源、XML配置文件、SQL数据库脚本等，另附Spark相关数据文件与PySpark辅助脚本，整体体积92.58MB，目录结构清晰。已有51人学习下载。项目中Spark MLlib用于处理用户行为数据并生成个性化推荐，SSM框架负责业务层与持久层实现，论文详述了系统设计思路与测试结果，开发文档覆盖需求分析到编码测试全过程，数据库文档则说明了表结构与字段定义，便于二次开发或论文撰写参考。对希望掌握大数据推荐系统开发流程的学习者而言，是一份理论与实践结合的高质量资料。
1. 用Hadoop、SSM和Spark搭一套电影推荐系统：毕业设计级的完整落地路线
如果你正在做大数据方向的毕业设计，或者想在企业里从零搭一套离线推荐服务，“基于SSM+Spark的电影推荐系统”是一个出现频率很高的项目形态。它把Hadoop做存储底座、Spark做模型训练、SSM做Web服务三层串起来，覆盖了数据采集、预处理、协同过滤训练、接口展示的完整闭环。这套组合的好处是每一层都有一眼能看懂的技术选型逻辑，坏处是坑也集中在“三层怎么接上”这个环节。这篇笔记按我实际做过的类似方案来写，给你一套能照抄的步骤、参数和踩坑清单。
2. 推荐系统在Hadoop生态里怎么组织：数据分块、计算分层与三大件分工
2.1 数据分层：把原始日志“预处理”成一张能算的评分表
不管后端是Web还是App，推荐系统的输入最初都是行为日志——用户看了哪部电影、点了什么、评了几分、收藏了哪些。这些日志往往散落在多个文本文件里，格式不统一，有的含JSON嵌套，有的字段缺失，直接灌给Spark跑ALS会出各种脏数据问题。常见的做法是先做一层数据预处理，把原始日志解析成结构化格式，再落到HDFS上。
# 把原始日志上传到HDFS的/raw目录 hdfs dfs -mkdir -p /data/movie/raw hdfs dfs -put user_log.csv /data/movie/raw/ hdfs dfs -put movie_info.csv /data/movie/raw/上传之后不要急着训练。先用一个简单的Spark任务做数据探查，比如统计每个用户的评分数量、每部电影的被评次数，判断稀疏程度。这个探查结果的输出直接决定ALS参数怎么调。如果你在伪分布式环境下跑，注意HDFS的默认副本数是3，磁盘吃紧时可以先改成1，但这个改动要在hdfs-site.xml里做，不是临时命令能覆盖的。
预处理完成之后，建议把结果写成Parquet格式，不要继续用CSV。Parquet有列式存储和压缩优势，在Spark里读取速度明显更快，而且在后面对接Hive或数仓时也更顺。这个习惯虽然初期多写两行配置，但后面做增量更新会省很多事。
2.2 Spark在这里算什么：离线协同过滤与ALS模型训练
Spark在这个项目里的核心角色是离线计算引擎，主要做两件事：一是处理上面说的原始日志，二是跑协同过滤训练。常用的算法是ALS，交替最小二乘，官方MLlib里直接有实现，不需要自己推导矩阵分解的数学细节。
import org.apache.spark.ml.evaluation.RegressionEvaluator import org.apache.spark.ml.recommendation.ALS val training = spark.read.parquet("/data/movie/processed") val als = new ALS() .setMaxIter(10) .setRegParam(0.1) .setRank(20) .setUserCol("userId") .setItemCol("movieId") .setRatingCol("rating") val model = als.fit(training) model.write.save("/data/movie/model/als_model_v1")这段代码里的三个参数是ALS最核心的配置。maxIter控制迭代次数，太少了模型不收敛，太多了训练时间成倍涨，一般10到20之间起步。regParam是正则化参数，防过拟合，评分数据稀疏时建议调大，0.1到1之间来回试。rank是隐含特征维数，决定模型表达能力，电影场景下20到50比较常见。
模型训练完记得做一次离线评测，用RMSE指标看预测评分和真实评分的偏差。这一步容易被跳过，但恰恰是答辩时最有说服力的数据。你可以顺手把测试集的结果打印出来，形成一张误差对比表，后面写论文时直接用。
2.3 SSM在推荐系统里的位置：业务接口与推荐结果展示
SSM是Spring + Spring MVC + MyBatis的组合，在推荐系统里不负责算法，只负责把训练好的结果变成Web接口。常见做法是Spark训练完后把每个用户的Top N推荐列表写回MySQL，SSM从数据库查出来渲染到页面。这么做的好处是接口响应快，不需要在请求链路上再触发Spark任务。
CREATE TABLE `rec_result` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) NOT NULL, `movie_id` int(11) NOT NULL, `score` double DEFAULT NULL, `rank` int(11) DEFAULT NULL, `update_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这张表设计的要点是user_id上一定要建索引，因为线上接口是按用户查推荐列表。rank字段保存推荐次序，展示的时候直接按它排序，不需要在代码里二次排序。update_time标记本次推荐批次，方便做AB对比或数据回滚。
写回MySQL这一步，可以从Spark用JDBC批量写入。要注意批量提交的size别太大，默认1000比较稳，JDBC驱动连接串里加上rewriteBatchedStatements=true能明显提高写入速度。
2.4 ALS两个核心参数：rank与regParam怎么定
参数怎么定是面试和答辩环节最容易问的问题。rank太小，模型抓不住用户和电影之间的隐含关系，推荐结果看着像随机排序；rank太大，训练耗时暴涨，而且在小数据集上容易过拟合。经验值是先固定rank=20，regParam=0.1跑一版，记录RMSE；然后把rank从10到50每次加10，各跑一遍，画一条误差曲线。
regParam的调整比rank更依赖数据稀疏程度。如果80%的用户评分少于5条，regParam直接从0.5起步，0.1容易让模型把个别评分学得过死。反过来，如果评分覆盖很均匀，比如平均每用户有30条评分，regParam在0.01到0.1之间比较合适。
3. 搭建Hadoop+Spark开发环境：从伪分布式到集群的最小可跑方案
3.1 Hadoop伪分布式是起步配置，至少走一遍完整流程
对于学生项目或者个人学习，不必要也没条件直接上三台以上服务器。伪分布式模式是先在单机上把所有服务角色跑起来，NameNode、DataNode、ResourceManager、NodeManager都各自一个进程，体验完整的HDFS读写和YARN调度流程。等伪分布式完全跑通，再扩展集群只是横向复制节点的事。
# 格式化NameNode，只在首次搭建时执行 hdfs namenode -format # 启动HDFS和YARN start-dfs.sh start-yarn.sh # 验证进程和节点状态 jps hdfs dfsadmin -report格式化这一步要特别注意，很多人翻车是因为初始化完成后又重复执行格式化，导致NameNode的namespace ID和DataNode不一致，DataNode起不来。Hadoop集群部署策略里有一条原则：格式化是“后悔药”操作，非必要不重来。如果你实在需要重来，记得把DataNode的临时目录一起清掉，不然两者元数据对不上。
3.2 Spark on YARN这样接：让集群给你分配计算资源
Spark可以跑在standalone模式，也可以跑在YARN上。推荐系统的项目建议直接跑YARN，因为YARN负责资源调度，Spark只管算，以后上多租户任务更方便。配置的时候把spark.master设成yarn，同时确认HADOOP_CONF_DIR环境变量指向Hadoop配置目录。
export HADOOP_CONF_DIR=/usr/local/hadoop/etc/hadoop spark-submit \ --master yarn \ --deploy-mode cluster \ --driver-memory 2g \ --executor-memory 2g \ --num-executors 2 \ --class com.example.MovieRecTrain \ movie-recsys.jar--deploy-mode cluster表示Driver也跑在YARN容器里，适合离线训练任务。--num-executors和--executor-memory的分配要看集群总资源，伪分布式下不要无脑设大，默认2个executor、每个2G内存就够了。如果你同时跑HDFS和YARN，内存总共也就8G或者16G，给Spark太多反而挤占DataNode。
3.3 用IDEA把本地代码提交到集群：开发与部署的衔接
本地写Spark代码时，用IDEA直接连集群提交是有技巧的。常见的做法是本地写好代码打成jar包，再用spark-submit提交。不要试图让本机代码直接访问HDFS上的数据，网络和环境都不一样，问题极多。
IDEA里要做两件事：一是把Spark和Hadoop相关的依赖设为provided，因为集群环境已经带了一份，打jar时不要打进去；二是resources目录里放一份log4j配置，避免Spark任务在跑的时候日志刷屏。
<dependency> <groupId>org.apache.spark</groupId> <artifactId>spark-core_2.12</artifactId> <version>3.0.0</version> <scope>provided</scope> </dependency> <dependency> <groupId>org.apache.spark</groupId> <artifactId>spark-mllib_2.12</artifactId> <version>3.0.0</version> <scope>provided</scope> </dependency>3.4 数据库文档该怎么读：表结构直接决定代码层设计
数据库文档在这个项目包里不是摆设，它是你理解整个系统的钥匙。拿到文档后第一件事看三张表：用户表、电影表、评分表。用户表决定userId的类型和长度，评分表决定时间字段有没有、评分区间是多少，电影表决定推荐结果展示时有哪些字段可以直接取。
看数据库文档还有一个作用：判断数据是真实采集的还是构造的。如果评分表的时间戳集中在同一天，或者用户ID是连续自增的，那基本可以确定是构造数据，这时候ALS的训练效果会跟真实场景有偏差。写论文时不要回避这个问题，直接说明数据来源和局限性，反而是加分项。
4. 用SSM把推荐结果做成Web服务：接口设计、Mapper写法和数据流转
4.1 项目结构：先按模块拆，再谈代码
SSM项目的包结构一般按controller、service、mapper、entity四层来拆。推荐系统的特殊性在于，除了常规的用户管理、电影管理，还要有推荐模块。推荐结果不是用户主动产生的，而是系统计算的，所以service层要区分“计算推荐”和“查询推荐”两个维度。
常见项目里会单独建一个RecService，里面放两个方法：一个从MySQL查某个用户的TopN列表，一个在后台触发Spark训练任务。前一个用于前台展示，后一个用于管理员手动更新模型，相当于给你留了一个人工干预的口子。
4.2 推荐结果表与用户行为表的Mapper与SQL示例
Mapper层是SSM里最容易写错的地方，尤其推荐结果表，涉及到多条件查询。下面是一段按用户ID查推荐列表的SQL示例，附带按评分阈值过滤的逻辑。
<select id="selectTopNByUser" resultType="com.example.entity.RecResult"> SELECT movie_id, score, rank FROM rec_result WHERE user_id = #{userId} AND score >= #{minScore} ORDER BY rank ASC LIMIT #{limit} </select>#{minScore}这个参数在实际场景中负责过滤低质量推荐结果。比如评分低于3.5的，可能是模型给用户匹配了不喜欢的类型，展示出来反而影响体验。
MyBatis里写动态SQL时要小心：#{userId}和${userId}有本质区别，前者是预处理参数占位符，能防SQL注入；后者是字符串拼接，用户传入恶意内容会直接拼进SQL。推荐系统接口是人能访问到的，必须全员用#{}。
4.3 实时推荐还是离线推荐：各写一个接口，看业务节奏差异
先明确一点：SSM+Spark这套组合不适合做实时推荐。Spark任务从提交到模型加载再到结果返回，分钟级别起步，不可能挂在用户请求链路上。所以实时接口只是个“立即刷新”操作，比如用户标记了某个电影“不喜欢”，前台调用接口，后台异步触发一次针对该用户的单独计算，几秒后返回新的TopN。
@RestController @RequestMapping("/api/rec") public class RecController { @Autowired private RecService recService; @GetMapping("/refresh") public Result refresh(@RequestParam Integer userId) { recService.asyncRefreshByUser(userId); return Result.success("刷新任务已提交"); } @GetMapping("/list") public Result list(@RequestParam Integer userId, @RequestParam(defaultValue = "10") Integer limit) { return Result.success(recService.topN(userId, limit)); } }list接口是高频查询，走MySQL；refresh接口是低频触发，走异步。接口拆开之后，压力承受点很清晰：list接口扛日常流量，refresh接口只是偶发的校正动作。很多项目把两边混在一个接口里，导致刷新时阻塞其他请求，这是最容易埋雷的地方。
4.4 前后端联调出现“查不到推荐结果”该怎么排查
联调阶段最常见的报错是接口返回空列表。先别急着查前端，按这个顺序排查：第一步看数据库里rec_result表有没有该用户的数据；第二步看SQL里能不能查出记录，用Navicat或命令行直接执行同样的SQL；第三步看Controller到Service的传参是不是被截断了，比如userId被解析成字符串导致SQL走错索引。
如果数据库里有记录但接口返回空，八成是MyBatis的resultType字段映射对不上，比如数据库字段rank跟Java类的rank属性类型不一致。这种问题日志里不一定会打完整报错，要看MyBatis的nested exception提示，重点是Unknown column或Cannot find setter两类关键词。
5. Hadoop+Spark项目必踩的坑：环境、数据和资源三类翻车现场
5.1 伪分布式里看不到DataNode：端口、格式化与目录权限一起查
现象是jps能看到NameNode，hdfs dfsadmin -report显示只有NameNode在线，没有DataNode。原因最常见是格式化过两次以上，DataNode的clusterID和NameNode不一致。解决办法是停掉所有Hadoop进程，清空NameNode和DataNode的元数据目录，重新格式化再启动。这是最彻底的方案，如果你担心误删数据，先备份相关目录。
5.2 Python/Scala版本不一致导致Spark任务失败
现象是Spark作业在本地IDEA里跑得通，放到集群上用spark-submit提交不到1分钟就报ClassCastException或NoSuchMethodError。原因大概率是本地打的jar包依赖版本和集群Spark版本不一致。解决方法是先看集群的spark-submit --version确认Scala版本，再回头改Maven里的scala.version和spark.version保持一致，然后clean package重新打包。
5.3 评分数据太稀疏，ALS训练结果全是一堆默认值
现象是RMSE看着很低，但实际推荐结果里都是热门电影，用户个性化表现不明显。原因是评分数据覆盖度不够，大量用户只有一两条评分记录，模型学到的是“全局热门”而不是“个人偏好”。解决方法是设置ALS的setColdStartStrategy("drop")，同时在预处理时把评分少于5条的用户过滤掉。论文里可以把过滤前后的用户数和推荐命中率作对比，增强可信度。
5.4 YARN资源总是不够：内存设置与任务并行度的关系
现象是提交任务后一直卡在ACCEPTED状态，日志里提示Maximum resource allocation exceeded。原因是你给executor申请的内存超过了YARN允许的单容器上限。解决方法是修改yarn-site.xml里的yarn.scheduler.maximum-allocation-mb和yarn.nodemanager.resource.memory-mb，两个值需要同时匹配，只改一个照样报错。经验值是nodemanager设成物理内存的80%，maximum-allocation别超过这个值。
5.5 SSM链接Spark时经常出现的序列化和类加载报错
现象是SSM工程里直接new一个SparkSession，启动Tomcat时频繁报SerializationException或NoClassDefFoundError。原因是Spark的类和Tomcat的类加载器冲突，把Spark代码塞进Web应用里本身就是不合理的设计。解决方式是拆分工程：SSM工程只负责业务展示，Spark训练做成独立jar包，通过命令行触发或写到后台定时任务里。二者之间唯一交互是数据库这张rec_result表。
6. 让数据质量先过一遍：评分数值分布、召回率验证与模型保存
6.1 评分分布检查：用SQL先算清楚均值、中位数与稀疏度
在训练ALS之前，先花10分钟用SQL查一下评分数据的基础分布，可以省掉后面调参的大量时间。我一般固定查三样：总评分条数、每用户平均评分条数、评分值的分布比例。查到结果后基本能判断数据是适合ALS还是需要换算法。
SELECT COUNT(*) AS total_ratings, COUNT(DISTINCT user_id) AS total_users, COUNT(DISTINCT movie_id) AS total_movies, AVG(rating) AS avg_rating FROM ratings; SELECT rating, COUNT(*) AS cnt FROM ratings GROUP BY rating ORDER BY rating;如果评分值集中在高分区，比如4到5占80%以上，推荐结果会失真。因为ALS是回归模型，目标变量方差太小，训练出来的模型区分度会很弱。处理办法不是删数据，而是引入负反馈信号，比如把浏览未评分的行为记为低分，扩大方差。
6.2 召回率与精确率的验证脚本：离线评测推荐效果
RMSE只能说明评分预测准不准，不能说明推荐列表好不好。答辩时更硬核的数据是召回率和精确率，两者要一起看。下面这段脚本按“每个用户留出最后一条评分作为测试”的方式做评测。
from pyspark.sql import functions as F from pyspark.ml.evaluation import RankingMetrics # 针对每个用户取评分最高的5部作为推荐结果 recs = model.recommendForAllUsers(5) recs = recs.withColumn("recommend_list", F.col("recommendations.movieId")) # 测试集：每个用户只保留最后一条评分作为真实交互 test = ratings.withColumn("row_num", F.row_number().over( Window.partitionBy("userId").orderBy(F.desc("timestamp")) )).filter(F.col("row_num") == 1) # 格式转换后计算RankingMetricsRankingMetrics里，推荐列表里每命中一个真实交互就算一次召回，最终结果是一个0到1的区间。这个数字别追求极致，0.05以上已经说明推荐质量不差。如果结果接近0，先检查是不是推荐列表全部是热门电影，这种假阳性对召回率的贡献特别低。
6.3 模型持久化与定期更新：打通“训练-预测-展示”的闭环
模型训练完不要每次启动都重新训练。把模型持久化到HDFS，每天凌晨定时任务跑一次增量训练，然后用一个Shell脚本把新模型目录软链到稳定版本路径，SSM端不需要改代码。
# 每日增量训练后切换稳定模型版本 hdfs dfs -rm -r /data/movie/model/als_model_current hdfs dfs -cp /data/movie/model/als_model_$(date +%Y%m%d) \ /data/movie/model/als_model_current这个做法的意义在于：前端始终读同一个路径，后台可以随时更新模型版本，出问题就回滚到上一版。我在实际项目里吃过不设稳定路径的亏，模型路径带时间戳，前端配置跟着改了三次，后面再也不敢不设软链。
推荐系统上线后，每周至少检查一次推荐结果里有没有异常数据，比如某部冷门电影突然排在所有用户第一位。这种异常往往不是算法问题，而是源数据里混入了刷分行为。处理方式是加一层数据质量监控，评分次数超过阈值就告警。
从Hadoop存储、Spark训练到SSM展示，整条链路真正难的不是某一个组件用得多熟，而是接口处不出问题。希望这篇文章能帮你把路上的坑提前填平。
本文还有配套的精品资源，点击获取
