这次我们来看一个非常适合毕业设计和课程设计的大数据方向项目基于 Spark 的猫眼电影数据分析与推荐系统。整体技术栈是 Python Spark Hadoop Django题眼在于“数据分析”和“推荐系统”两条主线而不是单一功能的 CRUD 演示。也就是说它把数据采集、数据存储、离线分析、推荐算法、Web 展示和接口调用完整串在一起是一套典型的大数据应用型毕设项目。先说结论这个项目适合两类人。一类是正在选题、想找一个能讲清楚技术链路的毕设/课设项目的人另一类是已经拿到源码但不知道怎么部署、怎么验证功能、怎么给评委演示的人。项目本身不依赖 GPU主要吃内存和磁盘核心难点在 Hadoop、Spark 环境的搭建和联调而不是 Python 业务代码本身。如果你能在一台普通开发机上跑通伪分布式 Hadoop再用 Spark 提交分析任务最后把结果交给 Django 展示出来这套组合在毕设答辩里的完整度是比较高的。这篇文章会按真实部署顺序展开先给核心能力速览和系统架构再讲环境准备与安装步骤然后是 Spark 分析任务、推荐结果验证、Django Web 页面和接口调用最后补上资源占用观察、常见问题排查和合规提醒。项目源码、文档报告和代码讲解属于配套资料建议拿到手后先对照本文的模块划分确认文件结构再开始部署能少踩很多弯路。1. 项目核心能力速览能力项说明项目类型大数据方向毕业设计 / 课程设计项目核心功能猫眼电影数据采集与存储、Spark 离线数据分析、电影推荐系统、Django Web 可视化技术栈Python、Spark、Hadoop、HDFS、Django、关系型数据库、推荐算法数据来源猫眼电影页面数据爬取或使用已有数据文件需确认项目具体实现是否依赖 GPU通常不需要重点看 CPU、内存和磁盘运行模式Hadoop 伪分布式 / 集群 Spark 本地或 YARN 模式对外服务Django Web 页面 HTTP 接口批量任务Spark 离线分析天然支持批量数据处理交付内容源码、文档报告、代码讲解以实际项目包为准适合场景毕设答辩、课设演示、大数据技术入门练手这里单独强调一点Hadoop 相关项目不建议一上来就配置完整集群。毕设场景下伪分布式是性价比最高的验证方式如果以后要扩展再把 Spark 的 Master 地址和 Hadoop 的 NameNode 地址改掉即可。实际的显存占用是零内存占用则取决于 HDFS 的 DataNode、NameNode、Spark Executor 以及 Django 进程的总和常规 8G 内存的开发机可以跑16G 会更从容。2. 系统整体架构与技术选型从项目标题看这个系统至少包含四个层次2.1 数据采集层猫眼电影数据的获取方式通常是 Python 爬虫目标字段包括电影名称、类型、评分、主演、上映日期、票房、评论数等。需要特别提醒的是爬虫代码只能用于学习和技术演示必须遵守目标网站的 robots 协议和相关法律法规控制请求频率不要对线上服务造成压力更不能把爬到的数据用于商业用途。如果项目已经内置了数据文件部署阶段可以先跳过爬虫直接验证后续链路。2.2 数据存储层采集到的结构化数据通常保存到 MySQL 或直接落盘成 CSV/JSON 文件而 Hadoop 生态里更主流的做法是把数据上传到 HDFS作为 Spark 离线分析的数据源。很多初学者会在这里卡住明明 MySQL 里已经有数据为什么还要放一份到 HDFS答案是为了让 Spark 的 RDD/DataFrame 读取流程更接近真实大数据场景。如果数据量很小也可以直接用 Spark 读本地文件不需要强行写 HDFS。2.3 数据处理与分析层这是项目的核心层。Spark 负责对数据进行 ETL 清洗、统计分析、聚合计算比如电影评分分布统计票房 Top N 排行电影类型分布上映年份趋势用户评分行为分析基于协同过滤的推荐结果计算。从题目设计看“数据分析”更多体现在统计聚合和可视化报表而“推荐系统”通常采用基于物品的协同过滤或基于用户的协同过滤输出每个用户或每部电影的 TopN 推荐列表结果写回数据库供 Django 读取。2.4 Web 展示层Django 在这一层负责数据可视化、推荐结果展示和接口服务。前后端之间可以是 Django 模板渲染也可以是 Django REST Framework 返回 JSON 由前端异步渲染具体要看项目源码里的 urls.py 和 views.py 实现。3. 适用场景与使用边界这个项目最适合的场景是教学演示和毕设答辩。它最大的优点是技术栈全、链路完整、可讲性强——从数据到结果每一环都能在答辩时展开说明。3.1 适合谁正在准备大数据方向毕业论文或课程设计的学生。尤其是想同时体现“大数据框架使用能力”和“算法应用能力”的选题这个题目比纯爬虫或者固定 B 端管理系统更有技术层次。3.2 能解决什么问题它解决的是“怎么把大数据技术栈串起来”的问题。很多初学者单独学过 Hadoop、Spark、Python、Django但不知道如何做成一个完整项目。这个项目给出了一个可复用的模块组合方式数据入 HDFSSpark 跑批结果落库Django 展示和提供接口。3.3 不适合什么场景不适合生产级应用。电影推荐只是教学场景的简化实现没有考虑用户冷启动、实时特征、高并发缓存、AB 实验等工程问题。如果直接拿去支撑真实业务从数据规模到响应时延都会有明显瓶颈。3.4 版权、隐私与安全边界这个项目涉及爬虫、电影数据和用户行为数据使用前必须注意爬虫应控制频率不得绕过反爬机制获取非公开数据电影海报、简介、评论等内容仅用于学习研究如果系统包含用户评分等模拟数据不得使用真实用户隐私Django 服务绑定地址不要直接暴露到公网确需远程访问时建议限制 IP 并开启身份认证。4. 本地部署环境准备没有具体源码时先按通用大数据项目清单准备环境。拿到项目后再对照配套文档里的版本号做调整。4.1 操作系统与基础软件软件组件用途检查命令JDKHadoop 和 Spark 运行依赖java -versionHadoopHDFS 和 YARN 环境hadoop versionSpark离线分析和推荐计算spark-submit --versionPython 3Django 和数据分析脚本python --versionDjangoWeb 服务python -m django --versionMySQL存储结构化结果mysql --version4.2 关键配置建议Hadoop 推荐先用伪分布式。核心配置文件包括core-site.xml、hdfs-site.xml、yarn-site.xml和mapred-site.xml其中fs.defaultFS默认指向hdfs://localhost:9000访问页面默认端口是9870。Spark 则要注意SPARK_HOME环境变量和spark-defaults.conf里的 Master 配置本地测试先用local[*]后续再切换到yarn。4.3 虚拟环境与 Python 依赖Django 项目建议使用 Python 虚拟环境避免把依赖装到系统环境里# 创建虚拟环境实际路径按项目目录调整 python -m venv venv # 激活虚拟环境 # Windows venv\Scripts\activate # Linux/macOS source venv/bin/activate # 安装依赖 pip install -r requirements.txt如果requirements.txt不存在手动安装时优先保证 Django、PyMySQL、pandas、requests、djangorestframework 这几类常见依赖可用具体以项目文档为准。4.4 磁盘与端口Hadoop 和 Spark 运行日志会占用一定磁盘空间建议预留 20G 以上。端口方面尤其注意HDFS NameNode 的 9870、DataNode 的 9864、Spark Web UI 的 4040、Django 默认的 8000 都是高频端口冲突时逐个排查。5. 安装部署与启动流程毕设项目的整体启动顺序建议是先启动 HDFS再提交 Spark 任务最后启动 Django。不要颠倒顺序否则 Spark 任务读不到 HDFS 数据Django 也查不到分析结果。5.1 启动 Hadoop# 首次运行需要格式化 NameNode注意会清空 HDFS 元数据 hdfs namenode -format # 启动 HDFS start-dfs.sh # 启动 YARN start-yarn.sh # 进程检查 jpsjps输出里应该出现 NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager 等进程。如果没有 NameNode去logs目录看启动日志常见原因是格式化路径冲突或端口被占用。5.2 上传数据到 HDFS# 创建数据目录 hdfs dfs -mkdir -p /movie/data # 上传本地数据文件实际文件路径按项目目录调整 hdfs dfs -put ./data/movie.csv /movie/data/ # 验证文件 hdfs dfs -ls /movie/data如果项目里没有现成的数据文件可以先准备一份包含电影 ID、标题、类型、评分、票房的 CSV 样例数据至少几百条否则后续推荐结果很容易因为数据稀疏而为空。5.3 提交 Spark 分析任务Spark 任务的入口通常是 jar 包或 Python 脚本。如果项目是 PySpark 实现命令一般是# 伪代码示例实际脚本路径以项目为准 spark-submit \ --master local[*] \ --driver-memory 2g \ analysis.py启动后可以在 http://localhost:4040 看到 Spark Web UI。这里重点观察两个东西一是任务是否出现失败重试二是输出结果是否写入指定目录或数据库。从项目标题和常见实现看Spark 分析任务的核心流程可以参考下面的模板# Spark 离线分析通用模板实际业务逻辑以项目源码为准 from pyspark.sql import SparkSession spark SparkSession.builder \ .appName(MovieAnalysis) \ .getOrCreate() # 读取 HDFS 数据 df spark.read.csv(hdfs://localhost:9000/movie/data/movie.csv, headerTrue, inferSchemaTrue) # 统计票房 Top10 top10 df.orderBy(df[box_office].desc()).limit(10) top10.show() # 输出结果到 HDFS 或 MySQL这里以 HDFS 为例 top10.write.mode(overwrite).csv(hdfs://localhost:9000/movie/output/top10) spark.stop()注意hdfs://localhost:9000是伪分布式默认地址如果实际端口不同或数据在本地需要替换。5.4 初始化数据库并启动 DjangoSpark 分析结果写回 MySQL 后Django 才能查询展示。数据库初始化通常包含两步# 生成数据库迁移文件 python manage.py makemigrations # 执行迁移 python manage.py migrate # 创建管理员账号 python manage.py createsuperuser # 启动 Django 服务 python manage.py runserver 0.0.0.0:8000如果启动时报数据库连接错误先检查 MySQL 是否启动、数据库名和账号密码是否和settings.py一致。Django 的runserver只是开发服务器毕设演示够用不涉及生产部署。6. 功能测试与效果验证系统启动完成后不要急着截几张图就结束按下面的验证顺序过一遍能提前发现大部分隐藏问题。6.1 数据导入与 ETL 验证测试目的确认原始数据成功进入 HDFSSpark 能正常读取和清洗数据。操作步骤在 HDFS 的/movie/data目录放置数据文件运行 Spark ETL 脚本使用hdfs dfs -cat或 Spark UI 查看输出。验证标准Spark UI 中 Job 状态为 Succeeded输出目录生成有效文件。如果输出为空优先检查 CSV 的 header 字段和类型推断是否出错。6.2 数据分析指标测试测试目的验证票房榜、评分榜等统计结果是否正确。操作步骤运行分析脚本对比 MySQL 中的结果表和原始数据手工计算值。验证标准Top10 结果的排序和数值与原始数据一致。这里是最容易暴露问题的地方比如字段类型把票房列读成了字符串导致排序变成字典序10 排在 9 前面。6.3 推荐系统功能测试推荐系统是答辩时最容易被追问的部分需要提前明确使用的是什么算法的简化版本。如果是协同过滤通常要验证输入一个用户 ID能否返回 TopN 电影输入一个电影 ID能否返回相似电影用户行为数据很少时是否有降级策略比如默认返回热门榜。验证操作建议从 Django 管理后台或接口先做小范围验证避免直接改前端页面。如果推荐结果为空排查顺序是用户历史行为数据是否太少、物品相似度矩阵是否生成了、结果表是否被正确读取。6.4 Web 页面可视化验证Django 页面通常包括首页、电影列表、数据分析图表、推荐结果页。测试时重点查看图表是否正常加载数据是否来自 Spark 计算结果点击详情页是否返回正确内容。如果页面打开但数据空白大概率是后端接口返回异常在浏览器开发者工具的 Network 面板里查看请求状态码再定位 Django 日志。7. Django Web 展示与接口 API 调用Django 在这个项目里既是展示层也是接口服务层。即使项目没有专门做前后端分离也可以用视图函数返回 JSON供前端 Ajax 调用。7.1 Django 接口设计思路常见接口包括/api/movies/获取电影列表/api/movies/top10/获取票房 Top10/api/recommend/user_id/获取某用户的推荐列表。具体路由要以项目的urls.py为准。下面是一个通用的 Django 视图模板演示“推荐接口”的后端写法# 通用 Django 视图模板实际路由和模型以项目源码为准 from django.http import JsonResponse def recommend_view(request, user_id): # 伪代码从数据库读取 Spark 提前算好的推荐结果 recommendations [ {movie_id: 1, title: 电影A, score: 9.2}, {movie_id: 3, title: 电影B, score: 8.8}, ] return JsonResponse({ user_id: user_id, recommendations: recommendations })7.2 HTTP 接口调用示例Django 服务启动后可以直接用 curl 验证接口是否可以访问# 通用示例实际接口地址以项目 urls.py 为准 curl http://127.0.0.1:8000/api/recommend/1/正常返回应该是 JSON 结构。如果返回 404检查路由是否匹配如果返回 500查看 Django 控制台报错日志常见原因是数据库连接失败或模型字段名写错。7.3 Python 请求接口接口供前后端联调时使用 Python requests 也可以快速验证import requests url http://127.0.0.1:8000/api/recommend/1/ response requests.get(url, timeout10) if response.status_code 200: data response.json() print(data[recommendations]) else: print(fHTTP {response.status_code}: {response.text})需要强调一点这个接口返回的是 Spark 离线计算后落库的结果不是实时计算。答辩时如果被问到实时性可以解释为“离线批量更新适合日级或小时级推荐更新场景”这是合理的架构取舍。8. 批量任务与数据处理流程Spark 离线分析本身就是一个批处理过程很适合扩展到定时任务场景。8.1 批量任务设计整个项目的批量处理流程可以概括为数据文件按批次上传到 HDFSSpark 任务对全量数据执行清洗和分析推荐算法计算物品或用户相似度矩阵生成推荐结果结果写入 MySQL覆盖上一次运行结果Django 页面和接口读取 MySQL 数据。这样做的好处是把计算密集型的 Spark 处理结果和 Web 服务访问解耦。Django 只查数据库不直接跑 Spark页面响应速度会稳定很多。8.2 定时调度思路如果希望系统自动周期更新数据可以在 Linux 上使用 crontab 定时提交 Spark 任务# 每天凌晨 2 点执行一次分析任务实际任务脚本按项目路径调整 0 2 * * * cd /home/user/movie_project spark-submit --master local[*] analysis.py logs/spark.log 21Windows 开发环境下则可以使用计划任务或者先在开发阶段手动执行。更复杂的调度可以引入 Apache Airflow但毕设场景没有必要crontab 已经足够讲清楚“定时离线计算”的设计思路。8.3 失败重试建议大数据任务失败重试是工程上绕不开的问题。实践中建议Spark 任务输出使用mode(overwrite)保证重复执行不会残留脏数据任务脚本加上日志输出落盘到独立的 logs 目录调度脚本记录每次运行的开始时间和结束时间如果依赖爬虫更新数据爬虫任务失败不要继续执行下游分析任务MySQL 写入使用事务避免半截写入造成推荐结果缺失。9. 资源占用与性能观察方法这个项目没有 GPU 占用资源观察重点放在 CPU、内存、磁盘和端口四个维度。9.1 Spark 任务资源占用Spark 任务启动后访问http://localhost:4040可以看到 Executor 数量、运行中的 Job、Stage 耗时和 Shuffle 数据量。出现内存不足时优先调整spark.driver.memory和spark.executor.memory。伪分布式环境下不要一次性给到 8G会直接拖垮开发机先用 2G 配额定一版再逐步增加。9.2 Hadoop 的资源占用Hadoop 伪分布式启动后会有多个 Java 进程常驻内存NameNode、DataNode、ResourceManager、NodeManager 加起来通常需要 2G 到 4G 内存具体和 JVM 参数有关。如果机器内存吃紧可以降低HADOOP_HEAPSIZE的值但不要低于 512M否则启动容易失败。9.3 Django 和 MySQLDjango 开发服务本身占用不高但查询大数据表时要注意索引。推荐结果表和电影表规模不大时问题不明显如果数据量增长一些慢查询会拖慢页面。可以用 MySQL 的EXPLAIN查看查询计划给推荐表的user_id字段加上索引这是低成本高收益的优化点。9.4 资源占用观察命令# 查看系统整体内存和 CPU 使用 free -h top -c # 查看 Hadoop 相关进程 jps -l # 查看端口监听状态 netstat -tunlp | grep -E 8000|9000|9870|404010. 常见问题与排查方法问题现象可能原因排查方式解决方案jps看不到 NameNodeHDFS 格式化异常或端口占用查看 Hadoop logs修改core-site.xml端口重新格式化 NameNodeHDFS 页面打不开NameNode 未启动或防火墙拦截检查 9870 端口启动 HDFS或关闭防火墙并确认绑定地址Spark 任务报 “Could not locate Hadoop”HADOOP_HOME未配置执行echo $HADOOP_HOME配置 Hadoop 环境变量并重启 Spark 任务Spark 读不到 HDFS 文件地址端口不对或文件不存在hdfs dfs -ls验证路径修正hdfs://地址和文件路径Django migrate 报数据库错误MySQL 未启动或连接信息错误检查数据库服务确认settings.py中的数据库名、账号、密码Django 接口返回 500模型字段或查询逻辑报错查看 Django 控制台日志根据 Traceback 定位代码问题推荐结果为空用户行为数据太少或结果表为空查看 MySQL 推荐表记录数增加用户评分数据或设置热门榜兜底端口 8000 被占用另一个 Django 服务在运行netstat -tunlp | grep 8000使用python manage.py runserver 0.0.0.0:8001换端口Spark 页面 4040 打不开Spark 任务已结束或提交失败查看终端中的 Spark 日志以--master local[*]重新提交并保持任务运行爬虫请求被限制请求频率太高或缺少请求头查看爬虫日志降低频率暂停一段时间仅保留学习用途的样例数据11. 最佳实践与合规建议基于这类毕设项目的常见踩坑点给出几个工程化建议无论最后代码怎么写保持这些习惯都能让项目更好维护、更容易答辩。第一第一次运行先用小数据量。不要一上来就全量导入几十万条电影评论数据先用几百条验证代码链路跑通后再放大数据量。这样排查问题的时间会大幅缩短。第二目录结构一定要清晰。建议把爬虫脚本、Spark 分析脚本、Django 项目、数据文件、输出结果、日志目录分开管理。典型目录结构可以这样规划movie_project/ ├── crawler/ # 爬虫脚本 ├── spark_jobs/ # Spark 分析脚本 ├── data/ # 原始数据和样例数据 ├── output/ # Spark 输出结果 ├── logs/ # 运行日志 ├── web/ # Django 项目 │ ├── manage.py │ ├── movie_app/ │ └── requirements.txt └── docs/ # 文档报告第三结果表要能做幂等覆盖。Spark 每次运行后写入 MySQL 的推荐结果必须是完整全量结果而不是增量追加否则重复执行会导致重复数据影响推荐展示。第四给 Django 接口加访问控制。如果只是本地演示runserver 0.0.0.0:8000就够了如果要在局域网里让老师访问不要直接裸奔最好加一层 Token 校验或只绑定内网 IP。第五注意爬虫和数据的合规性。作为毕设展示建议代码里只保留公开字段控制抓取频率不处理真实用户的个人信息不把爬取内容用于商业用途。答辩时如果被问到数据来源如实说明是学习用途的模拟数据比含糊其辞更稳妥。第六保留一套最小可运行配置。项目跑通后把 Hadoop、Spark、Django 的配置内容记录到文档里特别是修改过的端口、内存参数和数据库连接信息。这样即使换一台电脑重新部署也能快速还原环境。12. 总结与下一步这个项目最值得尝试的点是用一套完整的组合把“数据 - 计算 - 存储 - 展示 - 接口”串了起来毕设答辩时可以展示的不只是某个函数而是一条完整链路。最先应该验证的功能建议按这个顺序来先确认 HDFS 能上传读取数据再提交一个最简单的 Spark 统计任务最后再联调 Django三个阶段分别确认后再进入推荐系统和图表展示可以避免“全部跑不起来”的窘境。最容易踩的坑集中在两处Hadoop 和 Spark 的环境配置以及推荐结果因为数据稀疏而显示为空。前者要沉住气看日志尤其是logs目录下的报错后者可以在测试阶段准备一份用户行为矩阵更密集的模拟数据并在代码里预留热门榜兜底逻辑。后续如果想扩展有几个方向都是不错的选择把 Spark 分析维度进一步丰富比如增加导演、演员、上映地区等维度的交叉分析把协同过滤算法改成交替最小二乘的显式反馈版本和当前的隐式反馈思路做对比实验或者用 Kafka 模拟实时日志流让 Django 页面展示的指标具备更接近生产环境的实时性。不过要记住扩展之前先保证现有系统在换一台电脑后仍然能稳定复现这也是毕设项目最重要的评分点之一。建议收藏备用部署时把这篇文章的排查清单打印出来对照操作能省下不少调试时间。