打开 CSDN几乎每天都能刷到同一类问题“推荐系统毕业设计选什么方向”“基于 Spark 的推荐系统好不好做”“Hadoop 和 Spark 都装上了但不明白它们到底在项目里干什么。”这类问题的背后是一个很典型的现象很多人把“基于 Spark 的个性化短视频推荐系统”当成一个算法项目来选结果做起来才发现自己大部分时间不是在调算法而是在配环境、找数据、改路径、调接口、写页面。我看了不少相关项目源码和文档后发现一个基于 Spark 的短视频推荐毕设项目真正检验的不是你会不会用协同过滤而是你能否把一条完整链路跑通从用户行为数据产生到 Hadoop 存储到 Spark 批量计算再到 Django 接口和前端页面展示。项目标题里的每个技术名词都不是装饰而是这套链路里不可或缺的一环。这篇文章我想拆开聊聊这类项目到底该怎么做、各个框架在系统里到底是什么角色、最容易在哪些地方翻车以及如果将来想把它从毕业设计升级成真正可用的推荐系统还差哪些东西。1. 先搞清楚它解决的是算法问题还是链路问题1.1 推荐系统毕设最容易被误解的一件事很多人在选“个性化短视频推荐系统”这个题目时心里想的都是推荐算法本身——协同过滤、矩阵分解、深度学习、注意力机制。但当你真的打开一份毕设源码按 README 把环境装好、把数据导进去、点开 Web 页面之后你会发现你看到的不是“算法有多好”而是一整套工程结构。这个项目里的推荐逻辑可能只是一个基于协同过滤或物品相似度的短脚本真正占代码量和工作量的反而是这些部分爬取或生成短视频数据、启动 Hadoop 和 Spark 环境、写 PySpark 任务处理行为日志、建立 Django 模型、写推荐接口、把推荐结果渲染到页面。也就是说这类项目真正的主线是“数据链路”而不是“算法模型”。它能做出来的推荐效果很可能不是靠模型有多先进而是靠基础流程能跑通。这是一个非常重要的认知校正。如果你把它当算法项目做会很痛苦因为你很难在毕设周期里做出明显优于基准的模型提升。如果你把它当数据工程项目做一切都顺了环境搭建、数据清洗、批量计算、接口串接、页面展示每一步都有明确产出。1.2 为什么偏偏是 Spark、Hadoop 和 Django 这个组合这个组合在毕设里出现频率非常高原因并不复杂。Hadoop 解决的是“大量数据存哪里”的问题。推荐系统需要处理用户行为日志如果数据量达到一定规模单机文件系统就不够看了。HDFS 作为一个分布式文件系统正好用来存放这些原始日志和中间结果。Spark 解决的是“这么多数据怎么算”的问题。传统单机 Python 脚本处理几百万条用户行为记录速度会非常慢。Spark 通过内存计算和分布式任务调度把统计、过滤、相似度计算这类操作拆到多个节点并行执行。哪怕你只是用伪分布式模式跑在一台电脑上它也能让你体验分布式计算的流程。Django 解决的是“结果怎么给别人用”的问题。推荐结果算出来之后不能摆在那里需要提供一个 Web 服务让用户登录、看视频、点赞、收藏、刷新推荐同时把新的行为数据写回存储。Django 的 ORM、Admin 后台和 MTV 架构可以让这部分快速成型。所以这三个技术出现不是随意拼凑而是分别对应了存储、计算、服务三个核心环节。1.3 这类项目的真实能力边界这里需要说清楚一件事这毕竟是一个毕业设计体量的项目它的推荐能力是有边界的。在实际落地时它通常能做到这些基于用户历史行为观看、点赞、收藏、评论统计出用户偏好。基于物品相似度或用户相似度给用户推荐未看过的内容。用 Spark 批量更新推荐结果定时或按需刷新。用 Django 提供推荐接口并把结果展示成短视频信息流。但它通常做不到这些分钟级或秒级的实时推荐。因为整个链路是基于批量计算的HDFS 存放数据、Spark 定时跑任务天然有一定的延迟。工业级的特征工程和模型训练。毕设项目一般不会引入复杂的深度模型更多是传统协同过滤和热度统计。应对海量并发。Django 默认的开发服务器、单机部署环境并不适合高并发访问。把这个边界提前写出来是为了避免一个误区不要用生产级推荐系统的标准要求毕设项目也不要因为“算法看起来简单”就觉得项目没价值。它的价值在于链路完整、技术栈清晰、可演示、可讲解。2. 从用户点击到推荐输出一条完整的数据流水线2.1 系统分层先画一张架构图再动手我见过很多同学拿到这类项目后第一件事就是打开代码看模型看了半天也看不明白。更好的方式是先理解系统的分层结构不管代码是别人写的还是自己写的这个架构认知会帮你快速定位每一部分。这个项目按数据流向可以拆成这几层数据接入层负责产生或获取原始数据比如用户注册信息、视频信息、用户行为数据浏览、点赞、收藏、评论、搜索。毕设里常见做法是写脚本爬取公开数据集或者用 Python 脚本模拟生成行为日志。存储层原始数据经过处理后存入 MySQL业务数据和 HDFS日志数据、中间结果。Hadoop 在这一层承担的是分布式存储任务。计算层Spark 从 HDFS 或 MySQL 读取数据进行数据清洗、用户偏好统计、物品相似度计算、TOP-N 推荐列表生成再把结果写回 MySQL 或 Redis。服务层Django 提供登录注册、视频管理、收藏点赞、推荐结果查询等接口。当用户请求“我的推荐”时Django 从数据库里读取 Spark 预先算好的推荐列表而不是现场用 Spark 计算。展示层前端页面渲染短视频卡片、信息流或列表。用户观看、点赞产生的行为又会被记录下来写回存储层形成闭环。这个分层结构非常重要。尤其是“Spark 预计算 Django 接口读取”这个模式。很多人在做这个项目时会误以为用户每次请求推荐系统都要现场跑一遍 Spark 任务。如果真这样做接口响应会非常慢用户体验很差而且会让你在答辩时被追问到很难受。正确的做法是Spark 是离线的、批量的、预计算的Django 是在线的、按需查询的。2.2 推荐流程从原始日志到用户看到推荐结果下面用一个更细的视角看一条用户行为数据是怎么变成推荐结果的。第一步用户在某一个环节留下行为记录。比如在 Django 页面上点击了某个视频系统会把“用户 ID、视频 ID、行为类型、时间戳”记录到数据库。第二步Spark 定时任务从数据源读取一段时间内的行为记录。数据源可以是 MySQL、日志文件或 HDFS。项目里常见的是从 MySQL 导出到 HDFS再让 Spark 处理。第三步Spark 对行为数据进行预处理。包括去重、过滤异常数据、给不同行为赋权重。比如“观看”权重低“点赞”中等“收藏”较高“评论”很高。第四步构建用户和物品的关系矩阵。最经典的就是用户-物品评分矩阵。基于这个矩阵可以计算物品之间的相似度也可以给用户生成推荐候选集。第五步生成每个用户的 TOP-N 推荐列表写回数据库。比如一个用户最可能喜欢的 20 个视频按推荐分数降序排列。第六步用户打开 Django 页面请求推荐接口。Django 从数据库查出这个用户的推荐列表再带上视频封面、标题、分类等信息返回给前端渲染。这一步一个脚印走下来你会发现系统并不是一个黑盒而是一条非常清晰的流水线。2.3 为什么单机也能跑分布式框架还有一个让很多人困惑的问题我没有服务器集群只有一台笔记本电脑怎么能跑 Hadoop 和 Spark答案是伪分布式模式。在伪分布式模式下Hadoop 的 NameNode、DataNode、ResourceManager、NodeManager 都运行在同一台机器上模拟出一个“一个节点组成的集群”。Spark 也可以在 local 模式下运行不依赖 Hadoop 集群也能跑。但这里要提醒一个思路虽然 Spark 可以不依赖 Hadoop 启动但在这个项目里它们的角色是配合的。Hadoop 的 HDFS 负责存储规模较大的日志文件Spark 从 HDFS 读取数据计算计算中间结果也可能写回 HDFS。使用 HDFS 的意义在于它更接近真实大数据系统的存储方式也更能体现 Hadoop 在项目中的作用。如果你的电脑配置比较低一个更轻量的方案是Spark 读取本地文件或 MySQL 数据HDFS 只负责存储部分离线日志。但项目名称里如果写了 Hadoop建议在文档和答辩中至少保留 HDFS 存储日志这一层否则容易被认为技术栈只用了名字、没有落地。3. Spark、Hadoop 和 Django各自到底在做什么3.1 Hadoop 不是用来“算推荐”的而是用来“存数据”的一个非常常见的误区是认为推荐结果由 Hadoop 算出来。实际上Hadoop 在这个项目里主要负责两件事分布式文件存储HDFS和资源调度YARN。HDFS 上存什么一般是这些数据用户行为日志原始文件Spark 计算过程中的中间结果清洗后的行为数据文件这里的重点不是数据量有多大而是你要有一个清晰的“数据分层放置”意识。哪些数据放 MySQL哪些数据放 HDFS在答辩时能讲清楚会让整个系统逻辑更完整。一个常见做法是用 Python 脚本生成 CSV 格式的用户行为日志上传到 HDFSSpark 任务从 HDFS 读取日志统计完毕后把结果写入 MySQLDjango 从 MySQL 读取推荐结果和视频信息。3.2 Spark 才是真正干计算活的Spark 在这个项目里承担的是数据处理和推荐计算任务。常见操作包括读取 HDFS 上的行为日志文件解析成结构化数据。使用 Spark SQL 或 DataFrame API 进行聚合统计比如每个视频被点赞多少次、每个用户观看过哪些分类。进行数据清洗过滤行为异常、视频不存在的记录。计算物品相似度或用户相似度生成候选推荐集合。为每个用户生成最终的推荐列表写回 MySQL。用 PySpark 写一个简单的统计任务结构大致如下from pyspark.sql import SparkSession from pyspark.sql.functions import count, col spark SparkSession.builder.appName(video_stats).getOrCreate() # 从本地或 HDFS 读取行为日志 df spark.read.csv(hdfs://localhost:9000/user/behavior/logs.csv, headerTrue, inferSchemaTrue) # 统计每个视频的播放量 video_view_count df.groupBy(video_id).agg(count(*).alias(view_count)) # 过滤高质量视频 hot_videos video_view_count.filter(col(view_count) 100) hot_videos.show()需要注意这只是一个统计维度。真正的推荐计算通常会结合行为权重、分类偏好和相似度计算逻辑会更长一些。Spark 的优势不是“在单机跑得快”而是当数据量上来时它可以扩展到多节点。这个特性在毕设中可能无法完全体现但你必须能讲清楚它的设计思路。写 Spark 任务时还有一个常见问题任务跑完后不要把结果只打印在控制台。结果必须落库或落文件否则 Django 没有数据可读。result_df.write.jdbc( urljdbc:mysql://localhost:3306/recommend, tableuser_recommend, modeoverwrite, properties{user: root, password: 123456} )3.3 Django 是推荐系统的“门面”和“行为采集器”在这个系统里Django 承担了三个任务。第一个任务提供用户和视频的基础管理功能。包括用户注册登录、视频上传/管理、分类管理。这些功能通过 Django 的 MTV 架构快速实现Admin 后台可以直接用来管理数据。第二个任务采集用户行为。用户在页面上点击“喜欢”或“收藏”Django 的视图函数接收请求后把行为记录写入数据库。这个记录就是 Spark 推荐计算的原材料。# 一个简单的收藏记录视图 from django.http import JsonResponse from .models import Video, UserFavorite def favorite_view(request): user request.user video_id request.POST.get(video_id) video Video.objects.get(idvideo_id) UserFavorite.objects.create(useruser, videovideo) return JsonResponse({code: 0, message: 收藏成功})第三个任务提供推荐结果接口。用户打开“推荐”页面时Django 从 Spark 预计算好的表中读取该用户的推荐视频列表组装成 JSON 或渲染到页面。def recommend_list(request): user request.user recs UserRecommend.objects.filter(useruser).order_by(-score)[:20] video_ids [rec.video_id for rec in recs] videos Video.objects.filter(id__invideo_ids) return render(request, recommend.html, {videos: videos})这里的重点在于Django 永远不要直接调 Spark 跑任务哪怕技术上可以也不建议这么设计。原因有两个一是响应速度太慢用户会等很久二是这种做法混淆了离线计算和在线服务之间的边界答辩时很容易被质疑。4. 最容易让毕设翻车的五个细节4.1 环境版本不一致代码跑不起来这是出现频率最高的问题。Spark、Hadoop、Python、JDK、Django 任何一个版本对不上都可能出现莫名其妙的报错。常见的组合是JDK 1.8 或 11Hadoop 3.xSpark 3.xPython 3.8 或 3.10Django 3.2 或 4.x但每个版本之间不是随意组合的。建议拿到项目源码后先看 README 或 requirements 里锁定的版本再检查本机环境。安装阶段最好把版本记录下来写进自己的文档避免以后重装时忘记。如果报错信息指向某个类或方法不存在优先检查是不是版本差异导致的 API 改动。4.2 数据路径写死换个电脑就崩很多源码里会写绝对路径比如df spark.read.csv(/home/user/bigdata/logs.csv)这种写法在作者电脑上能跑换一台电脑就崩。更稳妥的做法是统一数据存放位置或者在顶部集中配置路径。DATA_PATH hdfs://localhost:9000/user/logs/behavior.csv RESULT_PATH jdbc:mysql://localhost:3306/recommend建议把可变配置统一放到配置文件里不要把路径散落在各个脚本中。这不只是为了跑通而是为了让项目后续可以复用。4.3 只有一个推荐结果表缺少中间过程有些同学做完项目后数据库里只有一张user_recommend表里面直接存着“用户 ID、视频 ID、分数”。看起来能演示但答辩时一旦被问“推荐结果怎么来的”就讲不清楚。更合理的做法是保留这些中间产物用户行为原始表清洗后的行为数据视频热度统计表物品相似度表用户偏好分类表最终推荐结果表每一张表都对应 Spark 任务中的一个步骤。有了这些表答辩时就能讲清楚整个计算流程而不是只给一个结果。4.4 页面和真实数据脱节有的项目为了演示效果好前端写死了一组视频列表结果用户看不到自己的行为对推荐结果的影响。这类页面虽然好看但无法证明推荐系统是“个性化”的。正确的做法是用户 A 和用户 B 看到的推荐列表应该不同而且这种差异是由行为数据驱动的。演示的时候最好准备两个测试账号分别积累不同的行为数据展示推荐结果的差异。4.5 没有准备好“重跑一遍”的流程答辩时老师可能会说“你现场跑一遍看看。”如果你从搭建环境开始准备那就来不及了。更稳妥的做法是准备一个一键化脚本或至少准备一套清晰的重跑步骤清空推荐结果表。执行 Spark 任务重新计算推荐结果。刷新 Django 页面查看推荐变化。建议把这些步骤写进 README 里并实际验证一遍。一个能重跑的流程比一百页文档更有说服力。5. 推荐结果不对或不更新按这五层链路来排查5.1 先确认问题出现在哪一层推荐系统一旦表现异常很容易让人一头雾水。很多人第一反应是“算法是不是写错了”但实际排查下来绝大多数问题出在数据、路径、调度或接口层。这里给出一个排查链路按顺序检查能覆盖大部分问题。排查层常见现象优先检查项数据层推荐列表为空、数据缺失、行为无效果用户是否有行为记录行为是否写入对应表行为时间是否在 Spark 读取范围内存储层Spark 读取不到数据、文件路径错误HDFS 路径是否存在MySQL 连接配置是否正确文件格式和表结构是否匹配计算层任务报错、结果不全、推荐分数异常Spark 任务日志数据是否过滤过激相似度计算输入是否为空服务层页面有报错、接口返回空Django 日志推荐结果表是否有数据接口查询条件是否正确展示层页面能打开但内容异常模板变量是否对应页面是否缓存了旧数据前端是否请求了正确接口这个表格可以当作你自己的排查清单。每一步先确认“输入有没有问题”再确认“处理逻辑有没有问题”最后确认“输出有没有被正确消费”。5.2 最常见的五类报错和应对方法第一类Spark 连接 MySQL 报错。常见原因是缺少 JDBC 驱动或者 URL 格式不对。检查 Spark 启动命令里是否加了--jars参数确认驱动包路径正确。第二类HDFS 文件找不到。先执行hdfs dfs -ls查看文件是否存在再确认执行 Spark 任务的用户是否有权限访问该目录。第三类Django 页面显示 500。看 Django 日志多数是数据库查询字段写错、模型字段不存在或模板变量名称不匹配。第四类推荐结果不更新。先检查 Spark 任务是否真的重新运行并写库再检查 Django 是不是读了旧数据最后检查页面是否被浏览器缓存。第五类数据量太小导致推荐效果差。这是毕设里很正常的情况。解决思路是生成规模更大的模拟数据或者在文档里明确说明当前数据为小规模验证数据生产环境需要更大的数据量训练效果才明显。# 一个提交 Spark 任务的示例 spark-submit \ --master local[2] \ --jars mysql-connector-java-8.0.30.jar \ --driver-class-path mysql-connector-java-8.0.30.jar \ recommend_task.py注意这里的关键不是命令写得有多漂亮而是你要理解每一部分的作用。--master local[2]表示本地双线程运行--jars表示引入外部依赖包。排查任务报错时优先看堆栈信息而不是盲目改参数。5.3 推荐列表为空时按这个顺序查如果用户打开页面推荐列表是空的按下面的顺序排查查数据库确认这个用户有行为记录吗如果行为记录为空说明用户行为采集没生效。先回到 Django 页面去点几个“喜欢”或“收藏”。如果行为记录有数据查 Spark 任务是否跑过。去看推荐结果表里有没有这个用户的记录。如果推荐结果表为空直接运行一次 Spark 任务观察日志。如果 Spark 日志报错找到第一个异常根据异常类型判断是路径问题、权限问题、还是字段问题。如果 Spark 任务跑通但没有生成记录检查过滤条件是否太严格比如把行为数量少的用户全部过滤掉了。如果推荐结果表有数据查 Django 接口的查询条件。是否按用户名过滤是否查询的表名不对这一条链路走完后绝大多数“推荐列表为空”的问题都能定位到具体环节。6. 从毕设到工程化推荐系统还差什么6.1 数据和训练流程的完善度毕业设计里的模拟数据通常规模小、噪声少、分布理想。真实的短视频推荐场景中用户行为数据非常稀疏存在大量异常点击、机器行为、无效播放。如果要把这个项目升级为更接近真实应用的系统至少要考虑更完整的行为埋点记录停留时长、滑动速度、是否完播。更细粒度的行为权重设计不同行为的价值不同。用户和视频的内容画像比如视频分类、标签、作者特征。更合理的训练集和测试集划分评估推荐效果而不是只展示推荐结果。6.2 从批量计算到实时计算目前这套架构是典型的离线批处理Spark 定时跑任务结果写库Django 读取。真实的推荐系统通常需要实时部分比如用户刚看完一个视频下拉刷新时就能看到相似内容。Spark Streaming 或 Flink 可以承担这部分实时计算任务。但这也意味着系统复杂度会大幅上升对于毕设来说一般不推荐。更好的路径是先把离线推荐做到完整、稳定、可解释再考虑引入实时链路。6.3 从“能跑”到“能评估”很多毕设项目止步于“结果能显示”。但如果想让自己在答辩时有更多底气建议补上一块内容推荐效果评估。常见的做法是把用户行为数据按时间切成两部分前 70% 用来生成推荐结果后 30% 用来评估。然后计算这些指标覆盖率推荐结果覆盖了多少视频。召回率用户实际观看的视频中有多少出现在推荐列表里。精确率推荐列表里有多少视频被用户真正点击了。多样性推荐结果是否集中在少数热门视频。哪怕只是做一个简单的离线评估也能让项目从“演示系统”变成“有实验支撑的推荐系统”。6.4 这类项目真正适合谁回过头来给一个更清晰的适用边界。基于 Spark 的个性化短视频推荐系统适合以下人群需要做大数据方向毕业设计、希望项目覆盖存储、计算、Web 全链路的同学。希望系统学习 Spark 批处理、Hadoop HDFS、PySpark 开发的同学。想在简历上体现“完整大数据项目经验”并且愿意花时间把链路讲清楚的同学。它可能不适合以下人群想只做算法模型、不想碰环境配置和 Web 开发的人。希望推荐效果“看起来非常智能”的人。毕设体量下传统推荐算法的效果提升空间是有限的。只有两三天时间希望不踩任何环境坑就能跑出完美演示的人。这类项目环境问题会消耗大量时间提前要有心理准备。7. 一句话概括这类毕设项目的本质如果让我用一句话评价基于 Spark 的个性化短视频推荐系统我会说它是一次完整的大数据链路训练而不是一次算法实验。你在做这个项目时真正学到的东西不是某一个推荐算法的公式而是理解了一条数据从哪里来、如何存储、如何被分布式计算处理、如何变成服务接口、如何展示给用户、又如何产生新数据形成闭环。这套能力比“会用某个推荐算法”更值钱也更接近真实工程系统的运行方式。如果你现在正在做这个项目我的建议是不要急着调算法参数先把数据从产生到展示的链路完整跑通然后保留中间结果把 Spark 任务的每一步讲清楚最后准备两个行为差异明显的测试账号演示给老师看。把链路跑通把过程讲清这个项目就已经成功了。这比任何花哨的算法都更让人信服。