计算机毕业设计Spark_Streaming+Kafka+Hadoop+Hive电影推荐系统 电影可视化 大数据毕业设计(源码+LW文档+PPT+讲解)
计算机毕业设计Spark_Streaming+Kafka+Hadoop+Hive电影推荐系统 电影可视化 大数据毕业设计(源码+LW文档+PPT+讲解)
温馨提示:文末有 CSDN 平台官方提供的学长联系方式的名片!
温馨提示:文末有 CSDN 平台官方提供的学长联系方式的名片!
温馨提示:文末有 CSDN 平台官方提供的学长联系方式的名片!
作者简介:Java领域优质创作者、CSDN博客专家 、CSDN内容合伙人、掘金特邀作者、阿里云博客专家、51CTO特邀作者、多年架构师设计经验、多年校企合作经验,被多个学校常年聘为校外企业导师,指导学生毕业设计并参与学生毕业答辩指导,有较为丰富的相关经验。期待与各位高校教师、企业讲师以及同行交流合作
主要内容:Java项目、Python项目、前端项目、PHP、ASP.NET、人工智能与大数据、单片机开发、物联网设计与开发设计、简历模板、学习资料、面试题库、技术互助、就业指导等
业务范围:免费功能设计、开题报告、任务书、中期检查PPT、系统功能实现、代码编写、论文编写和辅导、论文降重、长期答辩答疑辅导、腾讯会议一对一专业讲解辅导答辩、模拟答辩演练、和理解代码逻辑思路等。
收藏点赞不迷路 关注作者有好处
文末获取源码
感兴趣的可以先收藏起来,还有大家在毕设选题,项目以及论文编写等相关问题都可以给我留言咨询,希望帮助更多的人
介绍资料
表3.1 用户功能需求清单
基于Spark的电影推荐系统 |
|||
角色 |
功能模块 |
具体功能 |
描述 |
用户 |
个人信息模块 |
注册 |
用户输入个人信息进行注册 |
登录 |
用户通过输入账号和密码完成系统登录 |
||
修改密码 |
用户通过获取短信验证码来修改密码 |
||
修改个人信息 |
用户能修改如昵称、生日等个人信息 |
||
修改喜好信息 |
用户能修改自己的电影分类喜好信息 |
||
电影信息模块 |
电影搜索 |
用户能通过输入电影名、电影分类、评分区间、导演名、演员名等来搜索相关影片 |
|
电影详情 |
1.用户能获取电影基本信息,如简介、演员列表、上映时间等; 2.用户能获取评分信息和其他用户的评论; 3.用户能获取该影片的剧照信息; |
||
用户画像分析 |
用户可以获取对该影片有过评价的其他用户的评分分布图表、性别分布图表、年龄分布图表等 |
||
评分评论 |
用户可以对任意影片进行评分和评论、系统会据此作为推荐依据 |
||
电影推荐模块 |
统计推荐 |
1.用户能获取电影历史热门榜单; 2.用户能获取近期的电影热门榜单; 3.用户能获取各个分类电影热门榜单 |
|
相似电影推荐 |
用户能获取和某一电影内容或分类相似的影片 |
||
个性化推荐 |
根据用户之前选择的喜好电影分类标签和历史评论信息,推荐用户感兴趣的电影 |
3.2 非功能性需求
3.2.1 准确性需求
本系统推荐给用户的影片要足够的准确,满足用户的个性化需求。对于统计推荐模块,要注意及时更新历史和近期热门电影;对于个性化推荐模块,要注意符合用户的喜好。
3.2.2 稳定性需求
本系统应当做到一定程度的高并发与高可用。由于本系统用户访问量可能很大,要注意高并发情况下给服务器带来的高负载问题。此外,由于最终系统部署在服务器上,应保证服务器能24小时不宕机。若有意外情况发生,应及时做好数据备份与数据迁移。
3.2.3 性能需求
随着系统的使用,用户数据和电影数据的规模必定不断增长,本系统要尽量减少以此而带来的系统性能下降。用户浏览电影的速度较快,一方面要保证在短时间内计算出推荐结果,另一方面要保证数据的传输速度及数据在网页上的渲染速度足够快来将推荐结果呈现给用户。
3.2.4 可拓展性需求
推荐系统的各种算法各有不足之处,没有最好的推荐算法,只有最适合当前使用场景的推荐算法。当系统的推荐算法需要增加或更改以适应不同使用场景时,系统应当方便地、低耦合性地拓展这些算法。
3.2.5 安全性需求
本系统应具有一定程度的安全性。对于数据库,应当设置角色权限以及访问密码,避免被黑客清空数据库。用户的密码等较为私密的数据在数据库中加密存储,在网络中传输时也应加密传输,避免被不法分子截取并滥用。此外,应当设置IP黑白名单,避免不发分子过于频繁访问本系统而增加服务器压力。
3.3 本章小结
本章详细说明了基于Spark的电影推荐系统的需求分析。首先说明了本系统的功能模块划分为个人模块、电影信息模块和电影推荐模块,并给出了功能需求清单;接着详细说明了一些非功能性需求,以期将本系统实现得更加完善。
本系统的数据主要分为基本数据(用户信息、电影信息、评分数据等)和推荐结果集。基本数据的数据量较大,结构性比较强,存放在关系型数据库MySQL中;对于电影数据,由于访问频繁,额外存放在ElasticSearch中,便于搜索,如果存在热点数据,再将其放于Redis中,用于加快访问速度。推荐结果集由于有嵌套数据,不便于放在关系型数据库中,选择将其放于MongoDB中;计算的中间结果集也放在MongoDB中,由于MongoDB的数据都放于内存,会在一定程度上加快数据存取速度。
4.4.1基本数据的数据库设计
本系统的基本数据设计存储在7张表中,分别为电影详情表movie_detail,电影标签表movie_tag,用户信息表movie_user,用户评论表movie_reviews,用户评分简表movie_user_ratings,用户喜爱标签表user_tag_prefer,IMDb网用户评分表imdb_ratings。每张表的详细设计如下:
- 电影标签表movie_tag
表4.1 电影标签表
字段名 |
字段类型 |
说明 |
tag_id |
int |
标签id |
tag_name |
varchar |
标签名 |
- 用户喜爱标签表user_tag_prefer
表4.2 用户喜爱标签表
字段名 |
字段类型 |
说明 |
user_id |
int |
用户id |
tag_list |
varchar |
用户喜欢的分类列表,英文逗号,分隔 |
- 电影详情表movie_detail
表4.3 电影详情表
字段类型 |
说明 |
|
douban_id |
int |
豆瓣id |
title |
varchar |
电影名 |
brief_instruction |
text |
电影简介 |
directors |
varchar |
导演列表,/分割,注意两边有空格 |
screenwriters |
varchar |
编剧列表,/分割,注意两边有空格 |
casts |
varchar |
演员列表,/分割,注意两边有空格 |
types |
varchar |
类型列表,/分割,注意两边有空格 |
production_country_area |
varchar |
制片国家/地区 |
language |
varchar |
语言 |
publish_date` |
varchar |
上映日期列表,/分割,注意两边有空格 |
runtime` |
varchar |
片长 |
rating_score |
double |
评分分数,10分制 |
rating_star |
int |
评分星级,5星制 |
rating_num |
int |
评分人数 |
rating_5_star_weight |
char |
评5星占比 |
rating_4_star_weight |
char |
评4星占比 |
rating_3_star_weight |
char |
评3星占比 |
rating_2_star_weight |
char |
评2星占比 |
rating_1_star_weight |
char |
评1星占比 |
better_than |
varchar |
好于其他类型影片占比,列表 |
douban_url |
varchar |
豆瓣电影链接 |
cover_url |
varchar |
电影海报链接 |
imdb_url |
varchar |
IMDb链接 |
img_list |
text |
电影图片列表,逗号分割 |
- 用户信息表movie_user
表4.4 用户信息表
字段名 |
字段类型 |
说明 |
user_id |
int |
用户id |
user_name |
varchar |
用户名 |
user_unique_name |
varchar |
用户唯一名字标志,短评上没有id,以此做唯一标志 |
account |
char |
用户账户 |
password |
varchar |
账号密码,加密 |
|
varchar |
用户邮箱 |
phone |
varchar |
用户联系电话 |
sex |
char |
用户性别 |
birth |
varchar |
用户生日 |
age |
int |
用户年龄 |
profession |
varchar |
用户职业 |
user_head_portrait_url |
varchar |
用户头像url |
user_url |
varchar |
用户豆瓣主页链接 |
- 用户评分简表movie_user_ratings
表4.5 用户评分简表
字段名 |
字段类型 |
说明 |
review_id |
char |
评论id |
douban_id |
int |
豆瓣id |
user_id |
int |
用户id |
user_movie_rating |
double |
用户评分 |
user_movie_rating_time |
varchar |
评分时间 |
- 用户评论表movie_reviews
表4.6 用户评论表
字段名 |
字段类型 |
说明 |
review_id |
char |
评论id |
douban_id |
int |
电影豆瓣id |
user_unique_name |
varchar |
用户唯一名字标志,短评上没有id,以此做唯一标志 |
user_head_portrait_url |
varchar |
用户头像url |
user_url |
varchar |
用户主页链接 |
user_name |
varchar |
用户名 |
user_movie_rating` |
int |
用户对电影的评分星级,5星级 |
user_movie_rating_time |
varchar |
用户对电影的评分时间 |
user_movie_rating_agree |
int |
其他用户对此评论的赞同数 |
user_movie_rating_content |
text |
评论内容 |
movie_positive_rate |
varchar |
电影评论好评率 |
movie_general_rate |
varchar |
电影评论一般评率 |
movie_negative_rate |
varchar |
电影评论差评率 |
- IMDb网用户评分表imdb_ratings
表4.7 IMDb网用户评分表
字段名 |
字段类型 |
说明 |
imdb_id |
char |
IMDb id |
douban_id |
int |
豆瓣id |
imdb_rating |
double |
IMDb评分 |
rating_scores |
varchar |
各级评分,1-10,|分割 |
rating_scores_weights |
varchar |
各级评分权重,|分割 |
rating_scores_votes |
varchar |
各级评分投票数,|分割 |
age_all |
varchar |
全年龄段评分情况,评分|投票数 |
age_less_than_18 |
varchar |
年龄小于18的评分情况,评分|投票数 |
age_18_29 |
varchar |
年龄18-29的评分情况,评分|投票数 |
age_30_44 |
varchar |
年龄30-44的评分情况,评分|投票数 |
age_more_than_45 |
varchar |
年龄大于45的评分情况,评分|投票数 |
male_ratings |
varchar |
男性评分情况 |
female_ratings |
varchar |
女性评分情况 |
4.4.2推荐结果及中间结果集的数据库设计
ElasticSearch和Redis中均存放电影信息数据,其结构与表5.1相同。
MongoDB中存放的是计算中间结果和推荐结果集,总共设计7张表,分别为:
- 历史热门电影表history_top_20,字段和表5.1相同;
- 近期热门电影表recently_top,字段为豆瓣id,本月评分总数,年份月份;
- 各分类热门电影表genre_top,字段为分类,该分类下推荐列表,列表中包含豆瓣id和评分分数字段。
- 电影相似度表als_movie_sim,字段为豆瓣id,相似电影列表,列表中包含豆瓣id和相似度字段。
- 基于ALS的隐语义模型推荐表,字段为用户id,推荐列表,列表中包含豆瓣id和预测评分字段。
- 基于物品的协同过滤推荐表,字段为豆瓣id,推荐列表,列表中包含豆瓣id和余弦相似度字段。
- 实时推荐列表,字段为用户id,推荐列表,列表中包含豆瓣id和推荐优先级字段。
4.4.3 数据库优化策略
由于本系统的数量规模较为庞大,电影信息表有8000多条电影数据,用户表中有14多万条用户数据,评分表中有100多万条数据。如果不对数据库进行优化,那么以后随着数据规模不断增长,数据库查询将会越来越耗时。针对这种情况,本系统对数据库做出了如下优化策略:
- 索引优化
为表中某些字段添加索引(Unique、Normal或FullText类型),比如给电影信息表的电影名字段添加FullText类型的索引,便于用户在根据电影名搜索电影时更快地匹配;比如给电影评论表的豆瓣id字段添加Normal索引,方便查询某个电影下的评论信息。
- SQL优化
在系统的SQL代码中避免使用一些比较耗时的函数或关键字,当涉及到多表查询时,尽量使用join关键字来优化子查询。如果遇到了慢SQL,可以在SQL语句前加上explain关键字分析SQL的详细执行情况,然后确保其尽可能使用索引或其他优化。
- 表结构优化
优化表的数据类型,最大程度减小字段的长度。比如用户信息表的性别字段可以用“1”或“0”来代替中文的“男”和“女”,因为在MySQL中英文占1个字节,而中文占3个字节。
垂直拆分用户评论表,因为用户评论表的一些字段如评论内容字段在推荐计算时用处不大并且数据长度很长,纯属浪费计算资源,所以只保留必须字段,减少后面推荐算法的计算压力。
4.5 环境配置
4.5.1开发环境
在系统未上线之前,所有的开发和测试工作都在本地电脑上进行。本人的电脑配置信息如下表所示:
表4.8 本地电脑配置表
CPU |
i5-7300HQ @ 2.50GHz 四核 |
内存 |
16GB DDR4 2667MHz |
硬盘 |
HGST HTS721010A9E630 ( 1000GB ) |
操作系统 |
Windows 10 家庭中文版 64位 |
4.5.2开发工具
要完成一个完整的系统,开发中需要涉及到前端、后端及数据库,最终还要进行测试和部署,需要很多工具来完成这些工作。本系统使用的开发工具如下表所示:
表4.9 开发工具表
所属工作范围 |
工具名 |
版本 |
前端开发工具 |
WebStorm |
2020.3.2 |
前端查看工具 |
Chrome浏览器 |
90.0.4430.93 |
后端开发工具 |
IntelliJ IDEA |
2020.3.2 |
数据库开发工具 |
Navicat Premium |
12 |
接口测试工具 |
Postman |
8.5.1 |
并发测试工具 |
JMeter |
|
远程连接工具 |
FinalShell |
3.8.3 |
4.6 技术选型
本系统所涉及的所有开发技术及其选型如下所示:
表4.10 技术选型清单
所属范围 |
类型 |
技术名 |
版本 |
前端 |
开发语言 |
HTML |
5 |
CSS |
3 |
||
Javascript |
ES6 |
||
开发框架 |
Vue |
2.6.11 |
|
网络通信库 |
Axios |
0.21.1 |
|
图表库 |
ECharts |
5.0.2 |
|
组件库 |
vuetify |
2.4.0 |
|
element-ui |
2.15.1 |
||
后端 |
开发语言 |
Java |
1.8 |
Scala |
2.12.12 |
||
开发框架 |
SpringBoot |
2.4.1 |
|
数据库 |
MySQL |
5.7.32 |
|
MongoDB |
4.0.22 |
||
缓存 |
Redis |
6.0.9 |
|
搜索引擎 |
ElasticSearch |
7.9.3 |
|
持久层框架 |
Mybatis |
2.1.4 |
|
安全框架 |
Shiro |
1.7.0 |
|
计算框架 |
Spark |
3.0.0 |
|
消息队列 |
Kafka |
2.6.0 |
|
短信服务 |
aliyun-core |
4.5.9 |
|
接口文档 |
Swagger |
2.9.2 |
|
日志 |
Logback |
1.2.3 |
|
静态资源访问 |
Nginx |
1.18.0 |
性能测试
本系统最终部署在 Linux 服务器上,使用 JMeter工具对服务器进行并发访问测试。在 JMeter 上设置并发访问数量、并发访问时间以及需要访问的 URL 模拟多名用户对服务器进行同时访问的情况。本次测试的线程从10到1000依次增多,并且所有的线程均在1秒内启动完毕,模拟系统的高并发情况。测试的接口为: http://192.168.126.66:8090/api/recommendation/movieDetail/3231742,请求类型为GET。详细测试结果如下表所示:
表5.1性能测试表
Sample |
Average |
Max |
Min |
Error% |
Throughput |
10 |
53 ms |
56 ms |
51 ms |
0.00% |
10.4/sec |
20 |
53 ms |
58 ms |
50 ms |
0.00% |
19.9/sec |
50 |
52 ms |
57 ms |
49 ms |
0.00% |
48.2/sec |
100 |
52 ms |
59 ms |
49 ms |
0.00% |
96.3/sec |
500 |
500 ms |
3420 ms |
55 ms |
0.00% |
124.8/sec |
1000 |
2845 ms |
9702 ms |
54 ms |
0.00% |
89.2/sec |
Samples:并发数,每个并发模拟一个用户;
Average:平均响应时间,默认情况下是单个 Request 的平均响应时间;
Min:最小响应时间;
Max:最大响应时间;
Error%:错误率,错误请求数/请求总数;
Throughput:吞吐量,默认情况下表示每秒完成的请求数。
从上表可以看出,即使并发数达到1000,本系统也能正确返回数据,错误率为0.00%,说明本系统的并发能力还不错。在并发数较少时,响应时间都很短,这与热点数据都存于Redis有关。但是当并发数到达500和1000时,部分请求的响应时间却很长,并且系统的吞吐也有所下降,这可能造成用户在访问页面是数据加载会有延迟。这种情况也与服务器的CPU等硬件配置有关。
5.2 系统部署
5.2.1部署环境
本系统的前端和后端都将部署在远程云服务器上,该服务器的配置如下所示:
表5.2 部署环境配置表
CPU |
AMD EPYC 7K62 48-Core Processor |
内存 |
8GB |
硬盘 |
100GB |
操作系统 |
CentOS Linux release 7.9.2009 (Core) |
5.2.2后端部署
后端jar包需要部署在服务器中,其部署过程如下:
- 使用Maven的package命令将各个子项目打成jar包;
- 将jar包上传至云服务器;
- 执行以下命令启动业务服务, 为了防止关闭终端窗口导致程序挂掉,采用nohup和&组合命令来操作,并且将日志文件输出到指定文件夹;
nohup java -jar /opt/module/movie_recommendation_system/backend/business_server/businessServer-0.0.1-SNAPSHOT.jar
>/opt/module/movie_recommendation_system/backend/business_server/business_server_run.log &
- 执行以下命令启动推荐服务,该命令中通过nohup指定后台运行,通过--class参数指定启动主类,通过--driver-memory和--executor-memory参数指定driver端和executor端的运行内存,最后指定无日志文件输出。
nohup ./spark-submit
--class com.pcy.movierecommendation.spark.service.StreamingRecommender
--driver-memory 2G
--executor-memory 2G
../../my-jars/steamingRecommender-0.0.1-SNAPSHOT.jar
>/dev/null 2>&1 &
nohup /opt/module/spark-3.0.0-bin-hadoop3.2/bin/spark-submit
--class com.pcy.movierecommendation.spark.service.StreamingRecommender
--driver-memory 2G
--executor-memory 2G
/opt/module/movie_recommendation_system/backend/recommender/steamingRecommender-0.0.1-SNAPSHOT-jar-with-dependencies.jar
>/opt/module/movie_recommendation_system/backend/recommender/streaming_recommend_run.log
&
如此一来,后端已成功部署,现在可以随时随地访问后端获取数据了。
5.2.3前端部署
前端文件需要部署在服务器中,其部署过程如下:
- 使用npm打包工具,执行以下命令对整个前端项目打包;
npm run build
- 将生成的dist文件夹上传至云服务器;
- 在nginx中配置访问地址,配置文件如下;
server{
listen 9266;
server_name 192.168.126.66:
location / {
root /opt/module/movie_recommendation_system/frontend/dist;
try_files $uri $uri/ @router;
index index.html;
}
location @router {
rewrite ^.*$ /index.html last;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
如此一来,前端也部署成功了,现在可以在任意浏览器中输入以下网址即可访问本系统。
192.168.126.66:9266
5.3 本章小结
本章在系统实现后,对本系统进行测试和部署。首先介绍了算法误差和并发性能测试的测试情况,然后部署了本系统的前后端,方便用户更便捷地访问本系统。
6 总结与展望
6.1 总结
本文从实际生活的应用出发,综合运用各类技术,设计并实现了基于Spark的电影推荐系统。在本次课题研究中,所做的工作总结有以下几点:
- 学习了许多推荐算法的原理;
- 学习了许多之前的未接触过的技术,如Spark计算框架、ElasticSearch搜索引擎、MongoDB数据库和Vue前端框架等;
- 详细分析了本系统的功能性需求和非功能性需求;
- 详细设计了本系统的架构与各个功能模块,详细设计了系统所需的几种推荐算法,如统计推荐、离线推荐和实时推荐算法,详细设计了数据库并给出了优化策略;
- 测试了推荐算法的误差,以及对系统进行了高并发的性能测试。
6.2 展望
虽然本文最终实现了基于Spark的电影推荐系统,但是仍还有进一步完善、优化和提升的空间。笔者提出以下两点优化意见:
- 搭建Spark集群
目前本系统还是单机模式,但是面对日益庞大的数据量,单机的计算能力就有点捉襟见肘了。当搭建了Spark集群,每台机器的计算和内存压力会减轻不少,大大提高了计算效率。
- 探索其它推荐算法
由于本系统中用户评分矩阵十分稀疏,会对推荐算法的准确性有一定的影响。在以后的学习中,还可以探索其他推荐算法,使本系统具有更高的准确性。
运行截图
推荐项目
上万套Java、Python、大数据、机器学习、深度学习等高级选题(源码+lw+部署文档+讲解等)
项目案例
优势
1-项目均为博主学习开发自研,适合新手入门和学习使用
2-所有源码均一手开发,不是模版!不容易跟班里人重复!
🍅✌感兴趣的可以先收藏起来,点赞关注不迷路,想学习更多项目可以查看主页,大家在毕设选题,项目代码以及论文编写等相关问题都可以给我留言咨询,希望可以帮助同学们顺利毕业!🍅✌
源码获取方式
🍅由于篇幅限制,获取完整文章或源码、代做项目的,拉到文章底部即可看到个人联系方式。🍅
点赞、收藏、关注,不迷路,下方查看👇🏻获取联系方式👇🏻
更多推荐
所有评论(0)