简介面向计算机相关专业毕业设计学生及项目实战学习者的电影数据可视化分析系统源码包适用于课程设计、期末大作业等场景完整覆盖豆瓣高分榜单与猫眼票房数据的爬取、持久化、可视化分析与票房预测流程。包内共38个文件包含6个Python脚本、3个Jupyter Notebook、24张分析结果图以及SQL数据库脚本、PDF与Markdown说明文档压缩包仅5.18MB目录结构清晰便于按需查阅。系统利用爬虫工具获取电影评分、票房等数据借助pandas库将DataFrame存储为CSV文件并支持写入MySQL数据库通过两种方式实现持久化再基于可视化分析结论选取影响票房的因素构建预测模型。项目经过严格调试下载即用。已有4332人学习下载适合需要完整毕设案例或希望快速上手电影数据分析流程的读者既可运行源码观察完整实现也能结合说明文档与结果图理解设计思路并在此基础上进行二次开发。1. 基于Python的电影数据可视化分析系统毕设拿到的源码到底能不能直接跑每年到了毕设季豆瓣、猫眼这类电影数据就会被翻出来做成各种分析题目。这份基于Python的电影数据可视化分析系统源码打包里除了src目录下的全部代码还有douban.sql、README和一张预测结果图是一套从爬虫采集到MySQL落库、再到可视化和票房预测的完整闭环。它不是那种只有画图的半成品数据链路是通的爬虫取数、两种方式持久化、pandas和SQL两条可视化路径、最后用预测模型收口。适合三类人正在做毕设的计算机专业学生、需要课程设计和期末大作业的以及想练一遍“数据采集—清洗—入库—分析—建模”全流程的实战学习者。先花十分钟把结构和踩坑点摸清再决定怎么改造成自己的题能省下大量返工时间。2. 源码结构拆解数据链路与双层持久化是怎么设计的拿到压缩包第一件事不是急着跑main.py而是先把src目录下的文件职责分清楚。这套系统的文件命名基本已经说明了各自的分工main.py是程序入口movie_basic.py和movie_detail.py分别负责电影基础信息和详情数据的采集database.py管 MySQL 连接与写入unit.py是公共工具函数两个visualization开头的 notebook 是分析展示层还有一个predict.ipynb专门做票房预测。根目录的douban.sql是初始化数据库的脚本README.md是说明文档result目录里全是跑出来的图表能直接拿来对比验证自己的运行结果。2.1 文件清单与职责映射main.py 只有一个但链路是通的先看整体文件组织。目录结构大致是这样的├── src │ ├── main.py # 程序入口调度各模块 │ ├── movie_basic.py # 电影基础信息采集榜单、评分 │ ├── movie_detail.py # 电影详情数据采集票房、上映信息 │ ├── database.py # MySQL 持久化封装 │ ├── unit.py # 公共函数路径、时间、格式化处理 │ ├── predict.ipynb # 票房预测模型实验 │ ├── visualization_pandas.ipynb # 基于 pandas/CSV 的可视化 │ └── visualization_sql.ipynb # 基于 MySQL 查询结果的可视化 ├── douban.sql # 建库建表脚本 ├── README.md └── result # 运行结果图表含预测对比图这套结构里最值得注意的设计是“双层持久化”。它同时用了pandas.DataFrame.to_csv()写本地文件和database.py里封装的 MySQL 写入这两个方式不是二选一而是互补的。CSV 路径适合快速验证和绘图MySQL 路径适合正式数据分析和答辩演示因为可以随时用 SQL 查数据面对评委提问“你的数据存在哪、怎么查”时更有底气。main.py作为入口一般按这个顺序调度先采集数据再落库再调用可视化脚本最后输出预测结果。如果只想先体验分析部分跳过爬虫directly读result目录里现成的数据或/movie_basic.py生成的CSV也行。2.2 数据流向从豆瓣榜单到 DataFrame 再到 MySQL 的四个阶段整个系统处理数据的流程可以拆成四个阶段。第一段是数据获取movie_basic.py用爬虫抓豆瓣 TOP250 的评分和基础信息movie_detail.py补抓猫眼票房和详情字段第二段是格式化整理unit.py提供公共方法把字符串类型的票房、日期、片长转换成数值型第三段是持久化一份进 CSV一份进 MySQL 的douban库第四段是分析和预测两个可视化 notebook 读取数据做关系分析predict.ipynb再基于分析结论选择特征去建模。提示如果你在答辩时需要“讲清楚数据流”按上面四段讲就够了。这个项目真正的价值不在某个模型多精确而是把数据分析的标准流水线完整走了一遍。2.3 MySQL 建表脚本的解读douban.sql 里的表结构边界根目录的douban.sql是整个项目唯一一个 SQL 文件运行它就能完成建库和建表。常见的设计是建movie_basic和movie_detail两张表用电影名或豆瓣ID做关联主键。-- 电影基础信息表 CREATE TABLE IF NOT EXISTS movie_basic ( id INT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(200) NOT NULL, rating DECIMAL(3,1), rating_num INT, quote VARCHAR(500), url VARCHAR(300) ) DEFAULT CHARSETutf8mb4;DECIMAL(3,1)存评分刚刚好不会出现浮点精度问题DEFAULT CHARSETutf8mb4是为了让中文评语和电影名不乱码。如果这张表在 MySQL 8.0 上建的时候报错字符集相关的问题十有八九是连接串里的charset参数没跟着改。注意如果你本机 MySQL 是 5.7utf8mb4 也能支持但导出导入时留意排序规则utf8mb4_general_ci和utf8mb4_unicode_ci混用会出现联表乱码。统一用utf8mb4_general_ci最省事。3. 数据获取与落库豆瓣爬虫的参数细节和 MySQL 写入实操数据获取是整个项目的地基地基没打牢后面分析全是空中楼阁。movie_basic.py里的爬虫主要针对豆瓣 TOP250movie_detail.py则处理猫眼票房数据。这两个页面的反爬机制不一样豆瓣对请求头敏感猫眼对频率敏感所以实操中参数设置必须分开调。3.1 豆瓣 TOP250 采集请求头、翻页参数和解析边界豆瓣 TOP250 的翻页规律比较简单:start25表示从第 26 部开始每次加 25共 10 页。常见的采集写法是import requests from bs4 import BeautifulSoup headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept-Language: zh-CN,zh;q0.9 } movie_list [] for page in range(10): start page * 25 url fhttps://movie.douban.com/top250?start{start}filter resp requests.get(url, headersheaders, timeout10) soup BeautifulSoup(resp.text, html.parser) items soup.select(.grid_view .item) for item in items: title item.select_one(.title).get_text() rating item.select_one(.rating_num).get_text() movie_list.append({title: title, rating: float(rating)})这段代码里最关键的是headers里的User-Agent不带上它豆瓣会直接 418。另一个细节是timeout10防止单个请求卡死整个采集任务。select_one的选择器是标准的 BeautifulSoup 写法.grid_view .item能精确框住每条电影数据块不会把页脚信息误抓进来。如果你在答辩现场不想等 10 页爬完可以把range(10)改成range(2)先取 50 条做演示图表形状不会变化很大。3.2 猫眼票房采集注意频率控制和字段清洗猫眼票房榜的反爬主要靠 IP 频控单位时间内请求太密会直接进入验证码流程。合理做法是每请求一页后time.sleep(random.uniform(1, 3))。这属于常见做法不是复杂算法但对稳定运行很有效。票房字段抓下来后通常是“万”或“亿”为单位的字符串比如“35.2亿”必须清洗成浮点数才能进模型def clean_box_office(value): value value.replace(亿, ).replace(万, ) return float(value) * 1e8 if 亿 in value else float(value) * 1e4这段清洗逻辑里的边界问题是分不清单位会直接把数值算错。项目里unit.py做的就是这类封装。爬虫跑完数据量不大但如果抓取中断暂停在最后一页会重复写入所以落库时要用INSERT ... ON DUPLICATE KEY UPDATE做幂等处理。3.3 database.py 的写入封装连接、建表和去重写入database.py的职责是负责向上层提供写入接口而不是让每个脚本单独连一次数据库。它内部通常长这样import pymysql def get_conn(): return pymysql.connect( hostlocalhost, userroot, passwordyour_password, databasedouban, charsetutf8mb4, cursorclasspymysql.cursors.DictCursor ) def insert_movie_basic(data_list): conn get_conn() sql INSERT INTO movie_basic (title, rating, rating_num, quote, url) VALUES (%(title)s, %(rating)s, %(rating_num)s, %(quote)s, %(url)s) ON DUPLICATE KEY UPDATE ratingVALUES(rating) with conn.cursor() as cursor: cursor.executemany(sql, data_list) conn.commit() conn.close()这里的%(title)s是 PyMySQL 的命名占位符data_list里的字典键要与占位符一一对应。executemany批量插入比循环execute快得多300 条数据量感觉不出差异但这是数据库操作的好习惯。ON DUPLICATE KEY UPDATE是数据采集的后悔药重复跑同一份数据不会产生垃圾行是值得抄走的写法。注意passwordyour_password是占位符实际用的时候改成自己的 MySQL 密码。很多学生第一次跑报Access denied是这个原因不是代码问题。4. 可视化分析的两条路径pandas 直读与 SQL 查询可视化部分是整个项目的门面也是答辩时最容易拿分的地方。它特意拆成了两个 notebookvisualization_pandas.ipynb和visualization_sql.ipynb。前者直接从 CSV 或 DataFrame 画图适合离线分析和快速迭代后者从 MySQL 里SELECT取数再画适合正式演示和查询逻辑展示。4.1 pandas 路径适合演示的快速成图方式pandas 路径的核心思路是把持久化的数据读回 DataFrame然后按维度聚合画图。典型操作是分析评分和电影年份的关系import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(movie_basic.csv) df[year] df[title].str.extract(r\((\d{4})\)) year_rating df.groupby(year)[rating].mean().reset_index() plt.figure(figsize(12, 6)) plt.plot(year_rating[year], year_rating[rating], markero) plt.title(豆瓣TOP250电影年份与平均评分趋势) plt.xlabel(年份) plt.ylabel(平均评分) plt.xticks(rotation45) plt.tight_layout() plt.savefig(year_rating.png, dpi150)这里用正则r\((\d{4})\)从电影名里提取年份是因为豆瓣的标题格式固定是“电影名 (年份)”这个提取方式可以避开合并单元格的坑。plt.xticks(rotation45)是为了防止年份标签挤成一堆plt.tight_layout()保证保存的图片边缘不被裁切。这些参数都是画图时的血泪经验少一个图就难看一分。pandas 路径的最大优势是断点调试方便适合新手刚上手时观察每一行数据的变化。只要控制台有输出图就能出来。4.2 SQL 路径从查询到可视化的完整数据流SQL 路径强调“数据分析师”视角先写查询再画图。以分析不同类型电影的平均评分为例SELECT SUBSTRING_INDEX(title, , 1) AS genre, AVG(rating) AS avg_rating, COUNT(*) AS cnt FROM movie_basic GROUP BY genre ORDER BY avg_rating DESC LIMIT 10;import pymysql import pandas as pd import matplotlib.pyplot as plt conn pymysql.connect( hostlocalhost, userroot, password123456, databasedouban, charsetutf8mb4 ) sql SELECT SUBSTRING_INDEX(title, , 1) AS genre, AVG(rating) AS avg_rating, COUNT(*) AS cnt FROM movie_basic GROUP BY genre ORDER BY avg_rating DESC LIMIT 10; df pd.read_sql(sql, conn) plt.barh(df[genre], df[avg_rating]) plt.xlabel(平均评分) plt.gca().invert_yaxis() plt.tight_layout() plt.savefig(genre_rating_sql.png, dpi150)这段代码体现了 SQL 可视化的特点数据筛选和聚合在 SQL 引擎完成pandas 只负责接结果和绘图。pd.read_sql直接在连接对象上执行查询并用结果构造 DataFrame省掉了手动cursor.fetchall()再拼DataFrame的过程。invert_yaxis()让评分最高的类型排在最上面符合一眼看到结论的阅读习惯。提示因为title里的类型字段并不是严格的 genre 字段这里用了SUBSTRING_INDEX取第一个空格前的单词作为粗糙的类型分类。如果你的爬虫没抓到完整类型字段这个办法可以应急。真正规范的做法是在爬虫里单独解析类型字段存库。4.3 两张图对比什么时候用 pandas什么时候用 SQL判断维度pandas 路径SQL 路径数据来源CSV / DataFrameMySQL适合场景快速验证、断点调试答辩演示、查询逻辑讲解复杂度低适合新手中需要 SQL 基础复用性脚本改了重跑即可改查询条件即可数据一致性CSV 不更新会过期每次查询都是最新库如果你的机器上 MySQL 没装好可以先靠 pandas 路径撑起整个项目的展示如果 MySQL 已经通了建议两条路径都保留来一个“同样的问题两种解法”的对比这在答辩时非常加分。5. 票房预测模块与避坑模型怎么选数据怎么坑人predict.ipynb是这套系统里技术含量最高的一环也是答辩时容易翻车的地方。它的思路不是从零发明预测算法而是基于前面可视化结论——比如评分越高票房往往越高、热门类型的票房均值更大——选取关联度强的因素作为特征用线性回归或简单的树模型做票房预测。5.1 特征选取和模型训练的基本框架通常做法是把评分、类型、主演热度、上映档期等转换成数值型特征然后喂给模型。一个比较稳的基础代码是import pandas as pd from sklearn.model_selection import train_test_split from sklearn.linear_model import LinearRegression from sklearn.metrics import mean_absolute_error df pd.read_csv(movie_full.csv) df[box_office] df[box_office].apply(clean_box_office) features [rating, rating_num, year, is_hot_type] X df[features].fillna(0) y df[box_office] X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, random_state42 ) model LinearRegression() model.fit(X_train, y_train) y_pred model.predict(X_test) print(MAE:, mean_absolute_error(y_test, y_pred))这里的fillna(0)是偷懒但有效的做法——评分或票房字段缺失时先补零保证模型能跑起来。random_state42固定随机种子让每次运行的结果一致这在答辩演示时很重要不然每次预测数字都不一样评委一看就觉得不稳定。predict.ipynb里保存的“预测1.png”和“预测2.png”就是这种模型跑出来的拟合效果图。一个典型的输出结果是真实票房和预测票房的散点对比如果点大致沿着对角线分布说明模型有一定解释力反之说明特征选取有问题。5.2 五个常见踩坑记录坑一MySQL 写入乱码现象movie_basic表里中文标题变成“???”评分正常。原因连接串charset没设置或者建表字符集不是 utf8mb4。解决连接参数加上charsetutf8mb4建表脚本统一DEFAULT CHARSETutf8mb4同时在database.py里检查cursorclass的编码。坑二matplotlib 画图中文显示成方块现象图标题和坐标轴中文全部显示为方框。原因matplotlib 默认字体不支持中文。解决在绘图代码前加两行——plt.rcParams[font.sans-serif] [SimHei, Microsoft YaHei] plt.rcParams[axes.unicode_minus] False第一行指定中文字体第二行解决负号显示成方块的问题。这个坑几乎每个做中文可视化的新手都会踩一次。坑三爬虫请求被拒绝返回 418现象requests.get返回状态码 418。原因豆瓣反爬识别了无User-Agent的请求。解决在headers里带上完整的浏览器 UA 和Accept-Language必要时加 Cookie。不要用默认的python-requestsUA 去请求豆瓣。坑四predict.ipynb里train_test_split报空值错误现象报ValueError: Input contains NaN。原因清洗票房时没处理空行有的电影没有票房数据。解决在特征列拼好后统一加.fillna(0)或者用dropna()把缺失行删掉。数据量不大时用dropna()更干净。坑五两张可视化图得到矛盾的结论现象pandas 路径画出的评分趋势图上涨SQL 路径的查询结果却下降。原因CSV 文件是最早爬取的MySQL 里后来重新写入了更多新数据两个数据源不一致。解决每次重跑数据后用脚本重新生成 CSV或者在答辩现场统一用 SQL 路径。这也是为什么这份源码故意保留了两条可视化路径——但答辩时只能选一条作为主线不要两条混着讲不然逻辑会打结。5.3 预测模型的边界什么能预测什么不能票房预测在这个项目里更多是展示“完整流程”而不是追求精确结果。线性回归在特征不多、数据量几百条时预测误差可能达到几千万甚至上亿这是正常的。评委问“精确度多少”时要主动说清楚模型是用历史数据拟合出来的泛化能力有限真正有价值的是整个分析流程的完整性。如果你想让 MAE 降下来可以从爬虫端补充类型、导演、主演这些特征字段比在模型里调参更有效。6. 跑通后的三个验证技巧让答辩和二次开发都更稳项目能跑起来只是第一步怎么向别人证明“它真的没问题”才是关键。以下三个技巧是我跑通这套系统之后总结出来的建议每一条都实际做一遍。6.1 验证数据链路完整性从删库到恢复的“后悔药”拿到系统后先不要急于看画图效果而是验证“数据链路是通的”。最简单的做法是把 MySQL 里的movie_basic和movie_detail两张表DROP掉然后重新运行douban.sql、重新执行爬虫脚本、再跑可视化 notebook。如果全程没有报错且图表变化不大说明整个系统的数据流是闭环的。这个过程还能顺便检查douban.sql里的IF NOT EXISTS语句是否能正确处理重复建表以及INSERT ... ON DUPLICATE KEY UPDATE是否真的幂等。上了答辩台这一套流程走一遍比嘴上说“我测试过”更有说服力。6.2 把项目改造成自己的题目替换数据源的三步骤很多人直接把这份源码交上去评委一眼就能看出是模板。真正的技巧是替换数据源让它看起来像“你自己的项目”。三个步骤第一步把爬虫的 URL 从豆瓣改成你选定的垂直站点的榜单页比如时光网或IMDb中文站翻版第二步把正则解析字段的名称和类型改一改增加一个类别字段做创新点第三步在predict.ipynb里把特征列换成你自己的数据字段。这样改完后项目的整体骨架还在但数据和结论都变成了你的原创。6.3 答辩演示时的图表选择三张图定胜负答辩现场时间有限不可能把所有图都讲一遍。我的建议是只讲三张第一张是电影评分年份趋势图体现爬虫和 pandas 能力第二张是类型票房分布图体现 SQL 聚合能力和业务理解第三张是票房预测对比图体现建模能力。这三张图分别对应数据采集、数据分析、数据建模三个环节评委想要的考察点全都覆盖了。其他图表放在附录里备用等评委问“还有没有其他分析”时再补充。还有一个小心得每次跑项目前我会把result目录里的旧图清空重新生成后再命名带日期的新文件。这样新旧图不会混在一起答辩讲到“这是最新跑出来的结果”时才不会心虚。从那以后我每次拿到新项目都会强制走一遍“删库重建—数据重采—图表重生成”的流程这套习惯让很多数据链路的隐藏问题在演示之前就暴露了。希望帮到你。本文还有配套的精品资源点击获取