简介基于Spark的电影推荐系统综合资源包主要面向计算机相关专业在校学生、教师及企业开发者尤其适合作为毕业设计、课程设计、项目初期立项或推荐系统进阶学习的参考方案。资源整合了Python爬虫项目、Web网站、后台管理系统以及Spark推荐系统核心模块覆盖数据采集、前端展示、业务管理、推荐算法训练与离线评估等完整技术链路对理解真实推荐系统从数据到应用的工程项目很有帮助。压缩包共包含1417个文件以html、css、js前端页面java、scala后端代码xml、json配置数据以及sql数据库文件为主整体大小59.61MB目录结构清晰便于按模块检索学习。项目代码经测试运行成功并配有详细文档读者既可在此基础上二次开发扩展功能也可直接用于课设、毕设等场景。目前已有59人学习下载是Spark推荐系统从零搭建到工程落地的实用资料。1. 一套能毕业也能上简历的Spark电影推荐系统到底在做什么如果你在招聘软件上搜“推荐系统”相关岗位会发现一个共性JD里写的全是“熟悉Spark”“有推荐算法落地经验”但真正问起来绝大多数候选人只做过调包调参的demo。而“基于Spark的电影推荐系统包含爬虫项目、web网站、后台管理系统以及spark推荐系统详细文档资料齐全.zip”这个标题所指向的恰好是弥补这种落差的一套完整工程闭环——从数据采集、数据清洗、离线训练到在线推荐再到前后端展示与管理一应俱全。这类项目最典型的出现场景是计算机相关专业的毕业设计但它的价值远不止“能答辩”。真正把它跑通的人相当于亲手走过一遍实时/离线大数据系统的标准开发流程爬虫负责把外部数据变成自己的数据集MySQL承接业务数据Spark负责离线计算推荐结果Web端和后台管理系统负责把结果呈现出来并被用户操作反馈最终形成数据闭环。适合的人群很明确正在做毕设的学生、想往大数据方向转的Java/Python工程师、以及需要快速搭建一套可演示推荐系统的团队。但有一条必须一开始就说明白这套系统的核心难点不在算法而在“串起来”。我会按从数据采集到前端展示的顺序把这套系统的每个环节怎么搭、参数怎么设、坑在哪一步步拆开讲。2. 推荐系统不是单机模型是一条完整的工程链路很多新手拿到这类项目压缩包第一件事就是打开Spark代码找模型这是方向性错误。推荐系统本质上是一条数据管线模型只是其中一个环节。在动手碰代码之前先把这条管线画清楚你的改造和调试才有据可依。2.1 数据从哪来、往哪去七层结构与你需要关心的数据流一套完整的电影推荐系统按数据走向可以拆成七层采集层爬虫程序从公开电影网站抓取电影基本信息片名、导演、演员、分类、地区、上映时间、封面图等以及用户观影/评分行为数据。存储层数据落到MySQL核心表通常有三张——movies电影信息表、users用户表、ratings评分或行为表。如果你的爬虫抓到了标签数据可能还有第四张tags表。清洗层在Spark Job里做数据质量处理比如去重、过滤异常评分、统一时间格式。计算层Spark读取MySQL数据跑ALS交替最小二乘协同过滤算法产出“每个用户对未看过的电影的预测评分”以及“相似电影列表”。服务层把模型产出的Top-N推荐结果写入Redisweb后端通过接口读出来而不是每次请求都现算。展示层Web网站面向普通用户展示推荐结果、电影详情、用户评分入口后台管理系统面向管理员维护电影数据、查看用户列表、监控推荐效果。反馈层用户在前端的每一次点击、评分、收藏再次写回MySQL成为下一轮模型训练的新数据。这个闭环里最容易被人忽略的是反馈层。很多毕设作品做完前面六层就收工了看起来一切正常但系统没有“越用越准”的能力本质上还是一个单向展示系统。如果你想让这个项目在答辩或面试时有亮点务必把用户行为埋点做上——哪怕只是一个简单的“用户对推荐列表的点击记录表”。2.2 为什么是这套技术组合选型逻辑比代码本身更值钱标题里出现了四个关键词Spark、爬虫、web、后台管理系统。这套组合不是随便拼凑的它对应的是国内大数据岗位最常用的一套技术栈。先说爬虫为什么选Python而不是Java。Python的requests加BeautifulSoup组合写一个单线程爬虫不过几十行代码解析HTML时bs4的API比Java的Jsoup更加直接更关键的是后续你如果想扩展scrapy框架迁移成本很低。Java写爬虫不是不行但在这个项目里属于“把简单的事做复杂”。存储层用MySQL也值得说道。很多新手第一反应是“大数据项目应该上HBase或者HDFS”。但冷静想一下一套毕设级别的电影推荐系统数据量撑死了几十万条评分记录MySQL单表处理毫无压力。用HDFS反而给自己挖坑——部署Hadoop集群、维护NameNode、处理小文件问题每一样都能耗掉你大量时间。用MySQLSpark自带JDBC连接器读数据一个方法的事。计算层选Spark ALS是共识。电影推荐场景下ALS是协同过滤里最容易落地、效果相对稳定、并且Spark MLlib直接内置的算法。比起自己写KNN或者SVDALS的训练过程被封装得很干净你要关心的核心参数就三个后面第四章展开这让它成为毕设和入门项目的首选。Web端和后台管理系统常见组合是Spring Boot加Vue3。Spring Boot负责提供REST接口Vue3做前后端分离后台管理系统用Element Plus组件库能省掉大量样式工作。如果你的前端基础比较薄弱也可以直接用Thymeleaf模板渲染少一层跨域问题但简历上的含金量会低一些。2.3 冷启动阶段的种子数据没有评分任何算法都是纸上谈兵这里必须泼一盆冷水当你把整条链路搭好打开前端页面看到的推荐结果大概率是空的——因为你的ratings表里一条数据都没有。ALS算法需要用户-物品评分矩阵作为输入。冷启动阶段没有任何用户行为数据这是所有推荐系统都会遇到的经典问题。从业界的做法来看解决方案分三种爬取公开评分数据做种子从公开数据集比如MovieLens导入一批现成的评分记录先让系统“有东西可推”。这是最省事的办法也符合毕设初始化数据的需求。做法将MovieLens的ratings.csv和movies.csv清洗后导入MySQL数据量选择10万条左右就够了再配合你自己爬虫抓的电影信息做关联。爬虫抓取影评网站的“默认评分”比如某些电影网站会有编辑评分或用户平均分把这些数据作为初始评分写入ratings表用户ID标记为0代表“匿名用户”。基于流行度的兜底推荐在模型产出结果之前前端页面先展示一个“热门电影排行榜”按评分人数和平均分加权排序。这就是最朴素的“热门推荐”保证界面不是空的。我一般建议种子数据采用第一种加第三种组合从公开数据集导入一批历史评分让模型先跑起来同时保留一个基于SQL统计的热门榜单做兜底。这样哪怕ALS训练结果因为某种原因没写回Redis用户打开网站时也不至于对着白屏发呆。3. 爬虫项目数据采集与入库的最小可复现方案爬虫在这套系统里的角色是“数据供给”。你需要抓两类数据一类是电影的基础信息一类是用户行为数据。前者决定网站能展示什么后者决定推荐算法能算什么。3.1 抓取层requests加限速重试先把页面稳定地拿下来一个稳定的爬虫核心不在于解析能力而在于“请求—重试—限速”这套基本功。下面是抓取电影列表页的完整代码这是整个爬虫项目最小可运行的核心import time import random import requests from requests.adapters import HTTPAdapter def fetch_page(url, retries3, timeout10): 带重试和超时控制的页面抓取函数 session requests.Session() # 设置重试策略连接错误、超时等均触发重试 adapter HTTPAdapter(max_retriesretries, pool_connections10, pool_maxsize10) session.mount(http://, adapter) session.mount(https://, adapter) headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8 } for attempt in range(retries): try: resp session.get(url, headersheaders, timeouttimeout) if resp.status_code 200: return resp.text else: print(fHTTP {resp.status_code}, retry {attempt1}/{retries}) except requests.exceptions.RequestException as e: print(fRequest error: {e}, retry {attempt1}/{retries}) time.sleep(random.uniform(1, 3)) # 随机休眠避免高频请求被封 return None这段代码解决了三个核心问题第一通过HTTPAdapter设置了连接池和重试次数网络抖动时不会直接崩溃第二构造了常见的浏览器请求头避免被目标服务器以“非浏览器请求”为由拒绝第三每次请求后随机休眠1到3秒给自己留出操作间隔这也是最基本的抓取礼貌。参数调整说明retries不建议超过5次重试太多次只会加重对方服务器压力并且大概率还是失败timeout设置为10秒是因为电影网站页面通常包含较多图片资源和动态内容短超时容易误伤。random.uniform(1, 3)的间隔是根据“单机脚本抓取、频率不高”的场景设定的如果你用的是scrapy框架这个值可以相应调低到0.5到1秒配合并发使用。3.2 解析层BeautifulSoup提取电影字段与用户行为标记拿到HTML之后接下来的任务是解析出结构化字段。以解析电影列表页为例from bs4 import BeautifulSoup def parse_movie_list(html): 解析电影列表页提取每部电影的id、标题、评分和详情页链接 if not html: return [] soup BeautifulSoup(html, html.parser) movies [] # 假设每个电影条目是一个class为movie-item的div具体选择器以实际页面为准 for item in soup.select(div.movie-item): title_elem item.select_one(.title) score_elem item.select_one(.rating) link_elem item.select_one(a) if not title_elem or not link_elem: continue movie { title: title_elem.get_text(stripTrue), score: float(score_elem.get_text(stripTrue)) if score_elem else 0.0, detail_url: link_elem.get(href) } # 从详情页链接中提取电影ID做后续数据关联的主键 # 示例链接格式/movies/12345/ import re match re.search(r/movies/(\d)/, movie[detail_url]) if match: movie[movie_id] int(match.group(1)) movies.append(movie) return movies这一段的关键思路是“页面结构选择器要留注释、字段要做空值保护”。select_one返回None的情况在真实页面中非常常见某个条目少一个字段不应该让整个爬虫崩溃。stripTrue用于去除标题两侧空白字符。另外注意正则提取ID的这一步——这个ID就是你后续和Spark训练数据关联的主键如果这里取不到ID后面全链路都会出问题。3.3 入库层SQLAlchemy的会话管理与幂等写入爬虫抓到的数据不能直接往MySQL里怼原因有二一是重复抓取时会插入重复记录二是逐条插入性能太差。用SQLAlchemy做入库管理是Python爬虫项目的主流做法因为它既能提供ORM操作也保留了原生SQL的灵活性from sqlalchemy import create_engine, Column, Integer, String, Float, DateTime from sqlalchemy.orm import declarative_base, sessionmaker from sqlalchemy.dialects.mysql import insert from datetime import datetime Base declarative_base() class Movie(Base): __tablename__ movies movie_id Column(Integer, primary_keyTrue) # 电影ID作为主键 title Column(String(255), nullableFalse) rating Column(Float, default0.0) detail_url Column(String(500)) created_at Column(DateTime, defaultdatetime.now) class Rating(Base): __tablename__ ratings id Column(Integer, primary_keyTrue, autoincrementTrue) user_id Column(Integer, indexTrue) # 用户ID频繁按用户查询需加索引 movie_id Column(Integer, indexTrue) # 电影ID rating Column(Float, nullableFalse) # 用户评分1-5分 created_at Column(DateTime, defaultdatetime.now) # 创建连接关闭自动提交以便手动控制事务 engine create_engine(mysqlpymysql://root:passwordlocalhost:3306/movie_db?charsetutf8mb4, echoFalse) Base.metadata.create_all(engine) Session sessionmaker(bindengine) def save_movies_batch(movie_list): 批量插入电影数据使用MySQL的upsert语义避免主键冲突 if not movie_list: return 0 session Session() try: # MySQL原生INSERT ... ON DUPLICATE KEY UPDATE stmt insert(Movie).values(movie_list) stmt stmt.on_duplicate_key_update( titlestmt.inserted.title, ratingstmt.inserted.rating, detail_urlstmt.inserted.detail_url ) session.execute(stmt) session.commit() return len(movie_list) except Exception as e: session.rollback() print(fBatch insert failed: {e}) return 0 finally: session.close()这里的核心技巧是用了MySQL的ON DUPLICATE KEY UPDATE实现“存在即更新、不存在即插入”的幂等语义。你的爬虫无论跑多少轮movies表里不会出现重复ID的记录这对后续Spark读取数据非常重要——脏数据少模型训练才稳定。参数说明charsetutf8mb4是为了支持中文和特殊字符比如某些电影标题里带emoji符号echoFalse表示不打印SQL日志调试时可以临时改为Truepool_recycle3600建议加上防止MySQL默认的wait_timeout把空闲连接断开。关于session.close()很多人会漏掉它导致连接池被耗尽所以务必养成“用完即关”的习惯。3.4 爬虫运行策略增量抓取与断点续爬一次性全量抓取几万条电影信息既耗时又容易触发对方网站的反爬机制。业界通用做法是增量抓取——每天只抓“新增内容”和“页面数据有变化”的部分。常见做法是维护一张crawl_record表记录每个详情页URL的最后抓取时间。每次启动爬虫时先查这张表跳过距离上次抓取不足72小时的URLdef should_fetch(url, session): 判断URL是否需要重新抓取不在记录表中或距离上次抓取超过72小时 result session.execute( SELECT last_crawl_time FROM crawl_record WHERE url :url, {url: url} ).fetchone() if result is None: return True last_time result[0] hours_diff (datetime.now() - last_time).total_seconds() / 3600 return hours_diff 72这样做的直接收益是爬虫每天的运行时间从“几小时”缩短到“几分钟”而且对目标站点造成的访问压力小了一个数量级。对你自己的项目而言增量策略让整个数据采集过程更加可持续也更贴近工业界爬虫的标准形态。4. Spark推荐系统ALS模型的训练、调参与结果落地这是整个项目的核心章节。ALSAlternating Least Squares算法的核心思想是把用户-物品评分矩阵分解成两个低维矩阵的乘积通过交替固定其中一个矩阵来优化另一个最终补全矩阵中的未知值——也就是用户对未看过的电影的预测评分。4.1 数据准备从MySQL抽取训练集和验证集Spark读取MySQL的方式很简单但有几个参数值得注意。推荐用spark.read.jdbc的方式读取不要用JdbcRDD——前者支持分区读取后者实现繁琐且容易出错import org.apache.spark.sql.SparkSession val spark SparkSession.builder() .appName(MovieRec) .master(local[*]) .config(spark.sql.shuffle.partitions, 4) .getOrCreate() // 读取MySQL评分表 val ratingsDF spark.read .format(jdbc) .option(url, jdbc:mysql://localhost:3306/movie_db?useSSLfalseserverTimezoneAsia/Shanghai) .option(dbtable, ratings) .option(user, root) .option(password, password) .option(numPartitions, 4) // 分区数根据数据量调整 .option(partitionColumn, id) // 分区依据列必须是数值类型 .option(lowerBound, 1) .option(upperBound, 100000) .load() // 过滤异常评分只保留1-5分之间的记录 val ratingsClean ratingsDF .filter(rating 1 AND rating 5) .select(user_id, movie_id, rating) .cache() println(s有效评分记录数: ${ratingsClean.count()})这里numPartitions的设置有讲究。Spark JDBC读取时每个分区会开启一个独立的数据库连接去拉数据。分区数太少大数据量时单分区压力大分区数太多会给MySQL造成大量并发连接。对于10万到50万条数据量级4到6个分区是比较平衡的区间。另一个关键点是partitionColumn必须是数值类型且最好有索引否则Spark的按范围分区查询会很慢。4.2 ALS训练三个核心参数的调优逻辑ALS模型在MLlib里的调用极其简洁但参数含义必须理解透彻import org.apache.spark.ml.recommendation.ALS import org.apache.spark.ml.evaluation.RegressionEvaluator // 按8:2切分训练集和测试集测试集用于评估模型效果 val Array(training, test) ratingsClean.randomSplit(Array(0.8, 0.2), seed 42L) // 构建ALS推荐模型 val als new ALS() .setRank(20) // 隐特征数量决定向量表达的维度 .setMaxIter(10) // 最大迭代次数 .setRegParam(0.1) // 正则化参数防止过拟合 .setUserCol(user_id) .setItemCol(movie_id) .setRatingCol(rating) .setColdStartStrategy(drop) // 对未知user/item不抛异常 // 训练模型 val model als.fit(training) // 对测试集进行预测评估RMSE val predictions model.transform(test) val evaluator new RegressionEvaluator() .setMetricName(rmse) .setLabelCol(rating) .setPredictionCol(prediction) val rmse evaluator.evaluate(predictions) println(sRoot-mean-square error $rmse)三个参数是调优的核心rank表示隐特征的维度。它决定用户和物品被压缩成多少维的向量去表达。取值建议从10到50之间搜索。rank太小表达力不足欠拟合rank太大矩阵存储开销增加且容易过拟合。毕设场景下数据量在十万级rank20是一个稳妥的起点。maxIter控制迭代次数。ALS是迭代优化算法每次迭代都会交替更新用户矩阵和物品矩阵。一般的经验是8到15次之间达到收敛。设置过大的迭代次数不会带来明显提升只会增加训练时间。如果你发现训练时损失函数在最后几次迭代几乎不变就说明已经收敛了。regParam是正则化系数控制模型复杂度。0.01到1之间搜索。正则化太小模型记住了训练集的噪声道正则化太大模型变得过于平滑推荐结果缺乏个性化。一个实用技巧用RMSE做基准先用默认参数跑一轮然后只调整rank固定其它参数记录结果再来回对比。另外说一个很容易被忽略的点setColdStartStrategy(drop)。如果没有设置这个策略测试集里出现训练集没见过的user或movie时ALS会抛出异常。设置成drop后这些样本会被自动过滤但你要意识到这会轻微影响评估指标的准确度。4.3 推荐结果落地写入Redis与MySQL双通道训练出来的模型本身没有价值价值在于产出的推荐结果能被业务系统消费。推荐结果的落地方式决定了你前端接口的查询效率。我采用的做法是双通道写入每个用户的Top-N推荐列表写入Redis的List结构前端实时推荐接口直接读取。每个电影的相似电影列表写入MySQL的movie_similar表详情页的“相似推荐”模块通过SQL查询。import org.apache.spark.sql.SaveMode // 为每个用户生成Top-10推荐列表 val userRecs model.recommendForAllUsers(10) // 为每部电影生成Top-10相似电影列表 val movieRecs model.recommendForAllItems(10) // 写入MySQL的推荐结果表 userRecs.write .mode(SaveMode.Overwrite) .jdbc(jdbc:mysql://localhost:3306/movie_db, user_recommendations, new java.util.Properties() {{ setProperty(user, root) setProperty(password, password) put(driver, com.mysql.jdbc.Driver) }})写入Redis的部分可以在Spark里直接调用Jedis客户端也可以用map算子把数据转成(user_id, List[movie_id])之后再批量推送给Redis。后者更高效因为减少了Spark到Redis之间的连接次数。这里提示一个效率陷阱不要在RDD的foreachPartition里创建Jedis连接池而是应该在Driver端创建连接池配置、在每个Partition内创建单个连接并复用。否则每次处理一行数据就new一个连接Redis连接数会瞬间打满。4.4 离线评估你的推荐结果到底准不准RMSE衡量的是“预测评分和真实评分的误差”但它不能完全代表推荐系统的业务价值。用户可能真正关心的是推荐列表里有没有用户真正想看的东西。所以除了RMSE建议补充两个指标召回率RecallK在测试集中用户真实看过的电影有多少比例出现在推荐列表的前K个位置。多样性推荐列表中不同类型电影的占比分布。如果推荐列表里全是同一类型的电影用户很快就会审美疲劳。召回率的计算方式如下对测试集中的每个用户获取其真实看过的电影集合与推荐列表的前10个电影做交集计算交集大小除以真实集合大小。这个指标不复杂但能让你的项目在答辩时多一个维度去讲——别人都在谈RMSE你还能讲出“我算了召回率和多样性发现rank20时召回率最高”。这种细节是区分“会调包”和“真理解”的关键。5. 踩坑记录Spark电影推荐系统最容易翻车的5个地方这部分直接写我在搭这类系统时遇到的真实问题每一条都是“血泪经验”。你需要知道的是这些坑几乎每个人都会踩区别只在于踩完之后能不能快速爬出来。5.1 Scala和Spark版本不匹配报错信息完全看不懂现象程序启动后控制台抛出java.lang.NoSuchMethodError或者java.lang.NoClassDefFoundError错误信息指向某个内部类完全看不出是自己代码的问题。原因Spark是Scala写的不同版本编译时用的Scala版本不同。Spark 3.x对应Scala 2.12Spark 2.4对应Scala 2.11。如果你的Maven或sbt依赖里Spark是3.x但Scala编译版本是2.11就会在运行时出现找不到类的错误。解决在pom.xml或build.sbt里确保Spark和Scala版本匹配。推荐的稳定组合是Spark 3.2.x Scala 2.12 JDK 8。不要追新用JDK 17Spark的老版本对JDK 17的模块化支持有问题。5.2 MySQL驱动不写全JDBC连接报ClassNotFoundException现象Spark读取MySQL时报java.sql.SQLException: No suitable driver found但你明明已经在pom里引入了mysql-connector-java。原因Spark在分布式环境下需要每个Executor节点都能加载到MySQL驱动。如果驱动依赖在打包时没有被包含进jar包或者没有在spark-submit时用--jars参数指定就会在Driver端正常、Executor端报错。解决spark-submit时加上--jars mysql-connector-java-8.0.20.jar或者在打包时用maven-shade-plugin把驱动打进去。另外注意MySQL 8.x以上版本用com.mysql.cj.jdbc.Driver老版本才是com.mysql.jdbc.Driver。5.3 ALS训练结果全为null推荐接口永远返回空列表现象模型训练没有报错recommendForAllUsers也能跑出来结果但前端的推荐接口始终返回空数组。原因别怀疑算法先怀疑数据。最常见的可能性是ratings表里userId或movieId没有连续编号而是存在大段空洞。ALS对ID类型有要求如果原始ID是字符串比如UUID必须先做映射转换如果原始ID是Long且有空洞部分用户可能因为训练样本太少导致无法生成推荐。解决给ratings表添加自增ID列并确保Spark读取的user_id和movie_id是从0或1开始的连续整数。如果不连续用StringIndexer做一次映射import org.apache.spark.ml.feature.StringIndexer val userIndexer new StringIndexer() .setInputCol(user_id) .setOutputCol(userIdx) .fit(ratingsClean) val movieIndexer new StringIndexer() .setInputCol(movie_id) .setOutputCol(movieIdx) .fit(ratingsClean) val ratingsIndexed movieIndexer.transform(userIndexer.transform(ratingsClean))这个操作是此类项目里最常见的“隐形前置条件”新手往往在这里耗掉一整天。5.4 写入Redis的连接被拒因为连接数超限现象模型训练完成后写入Redis时报ERR max number of clients reached。原因默认的Jedis写法是在每个RDD分区内创建Jedis实例如果分区数设置得过大比如默认200个并发连接直接打满Redis的默认最大连接数10000。解决通过spark.conf.set(spark.sql.shuffle.partitions, 4)降低分区数同时在Executor端使用连接池而非每行创建一个连接// 使用JedisPool单例每个分区内共用 val pool new JedisPool(new JedisPoolConfig(), localhost, 6379)另外给Redis的配置里显式设置maxclients 20000也可以解决但这不是治本——控制Spark这边的并发度才是正解。5.5 Web端查询超时Spark结果没预热就上线现象用户点击“推荐”按钮接口平均响应时间超过5秒页面一直转圈。原因有的团队把推荐查询写成了“在线计算”——每次请求都去调Spark重新跑一遍模型。这是架构层面的错误理解。Spark ALS是离线推荐引擎适合批处理不适合在线实时查询。解决接上本章前面写的落地策略——离线训练结果写入RedisWeb接口只查Redis不再碰Spark。Redis的List类型用LRANGE key 0 9取前10个元素毫秒级响应。把Spark保留为“每天凌晨2点定时训练一次”的角色这才是标准的离线推荐架构。6. 把前端与后台管理系统接通最终验证的三种手段当前面的链路全部打通就到了最后一步用Web和后台管理系统来验证整体效果。这一步经常被忽视但恰恰是能让你的项目在验收时不被问倒的关键。6.1 Web前端如何对接推荐接口前端展示层通常只需要三个接口GET /api/recommend/{userId}获取用户的个性化推荐列表从Redis读取Top-N电影ID再关联movies表查询详情。GET /api/movie/{id}获取电影详情和相似推荐相似推荐从movie_similar表读取。POST /api/rating接收用户评分行为写回ratings表成为下一轮模型训练的输入。这三个接口的数据量都不大返回JSON交给前端渲染即可。Spring Boot实现起来非常快核心逻辑就是Redis查询加MySQL关联查询。6.2 后台管理系统的必要功能清单后台管理系统不需要做得很炫但有四个功能模块是这个项目必须包含的电影管理对movies表的增删改查手动录入爬虫没抓到的电影。用户管理查看用户列表和用户行为记录支持禁用异常用户。推荐结果管理查看每个用户当前推荐列表手动屏蔽某部电影冷启动和内容安全都需要。监控面板显示评分数据总量、每日新增评分数量、模型最近一次训练时间。这个模块虽然简单但在答辩时能直接展示“系统是活的”。6.3 验收技巧跑通最小闭环的检查清单最后给出一个我每次搭完这类系统的自检流程按顺序执行可以快速定位问题命令行执行curl http://localhost:8080/api/recommend/1确认返回JSON不为空。在后台管理系统给某部电影改个标题刷新前端页面确认改动生效。手动往ratings表插入一条新评分然后重跑Spark训练Job确认新评分会改变推荐列表的前几名。这三步分别验证了推荐接口通路、CRUD通路和数据闭环通路。很多人的项目挂在第三步——因为评分数据更新后推荐结果没有变化说明训练-落库-展示的链路还有断点。找到断点的方法很简单从MySQL里直接查user_recommendations表看结果是否更新如果没更新问题在Spark训练环节如果更新了但前端没变化问题在Redis缓存。这套系统做到这里已经完整覆盖了标题里的全部内容爬虫、Spark、web、后台管理、文档资料。我自己的感受是这类项目真正有价值的部分不是模型效果有多好——毕竟训练数据只有几十万条——而是那条从数据采集到前端展示的完整链路。每次跑通一条断掉的链路你对整个系统架构的理解就深一层。把这些经验沉淀下来就是你的项目文档里最值钱的内容。希望帮到你。本文还有配套的精品资源点击获取
