Flask+ECharts+爬虫+pandas：豆瓣电影数据分析系统全链路实战-北京尧图网络

简介这份资源是面向计算机专业学生与Python初学者的一套完整毕业设计项目主题为豆瓣电影数据爬取、分析与可视化采用Flask搭建Web后端、ECharts完成图表呈现并结合爬虫与pandas进行数据采集与清洗数据库使用MySQL。项目从环境搭建、数据抓取、数据处理到可视化展示形成完整链路适合用作课程设计、毕业设计参考或数据分析入门实战。压缩包共1054个文件以688个py源码文件为主另含pyc缓存、html与js前端页面、jpg与png图片素材、csv数据样本、sql建库脚本及docx论文文档等整体约30.07MB源码、脚本与论文一并提供。已有257人学习下载。读者可据此获得可运行的完整项目代码、数据库脚本与配套论文理解爬虫到可视化的实现思路并参考多角度动态图表设计快速完成自己的数据分析类课题。1. 从一份“跑不起来”的毕设说起豆瓣电影数据分析系统到底要交付什么每年到了毕设开题那几周总有人拿着一份“Python 数据分析”的题目来找我说想做个豆瓣电影的可视化系统结果打开某份网上的源码爬虫跑不通、数据库连不上、前端图表一片空白。问题不在题目本身而在于大多数所谓“完整版”只给了代码没给一条从数据采集到图表呈现的完整链路。这套基于 Flask ECharts 爬虫 pandas 的豆瓣电影数据分析及可视化系统要解决的就是这条链路把电影数据抓下来、洗干净、存进数据库、用 pandas 做统计分析、再通过 Flask 接口喂给 ECharts 出图。它适合两类人正在做 Python 毕设或课程设计、需要一套能讲清楚结构的学生以及想快速搭一个数据分析 Demo 的从业者。下面按需求、设计、实现、避坑、验收的顺序把这份方案拆开讲透。2. 需求与技术选型为什么是 Flask ECharts 爬虫 pandas 这套组合2.1 先把功能需求钉死别一上来就写代码做这类系统最容易翻车的地方是需求没定就开写写到一半发现“排行榜”和“类型分布”要的数据字段对不上。我一般会先把功能拆成四块每块对应一个可验收的产出功能模块输入处理输出数据采集电影列表页、详情页请求、解析、翻页原始电影记录数据清洗与存储原始记录去重、补空、类型转换结构化数据表统计分析数据表pandas 分组、聚合、排序统计结果集可视化展示统计结果Flask 接口 ECharts图表页面这四块是递进关系采集决定字段字段决定表结构表结构决定能算什么能算什么决定能画什么。很多同学反过来做先想“我要画个词云”再去凑数据最后字段缺失、图表硬凑答辩时被问一句“这个评分分布的数据来源是什么”就答不上来。先把这张表填满后面每一步都有依据。字段设计上一部电影至少要有片名、导演、主演、上映年份、类型、评分、评价人数、时长、国家地区。这几个字段能支撑起大部分常见图表——评分分布看直方图类型占比看饼图年份趋势看折线图导演作品数看柱状图评分与评价人数的关系看散点图。字段不在多在于每个都能对应到一张图这样系统才不是“为了可视化而可视化”。2.2 技术选型逐项说清楚别让答辩老师问住选 Flask 而不是 Django理由要能说出口这个系统是轻量级的数据展示型应用没有复杂的用户权限、后台管理需求Flask 的路由和蓝图足够启动快、代码量小学生更容易讲清楚每一行在干什么。Django 那套 ORM 和 admin 对数据分析类项目是负担配置成本高反而模糊了重点。选 ECharts 而不是 matplotlib 直接出图是因为前者是浏览器端渲染能交互——鼠标悬停看数值、图例点击筛选、缩放查看这些在答辩演示时是加分项。matplotlib 生成静态图片适合写进论文插图但做系统界面就偏弱。实际做法是两者都用论文里的统计图用 matplotlib 出静态图系统页面用 ECharts 出交互图各司其职。选 pandas 做分析是因为分组聚合、透视、缺失值处理这些操作它一行顶十行而且和数据库读取能直接对接。爬虫部分用 requests BeautifulSoup 就够页面结构不复杂的话没必要上 Scrapy框架越重调试成本越高学生越难讲明白。数据库选 MySQL 而不是 SQLite主要考虑是这份方案要交“sql 脚本”MySQL 的建表语句、索引、字符集配置更贴近实际工程答辩时也能体现对数据库设计的理解。SQLite 虽然零配置但导出脚本和迁移的规范性弱一些。提示技术选型的每一句话都要能回答“为什么不选另一个”。答辩时老师最爱问的就是对比题提前把 Flask vs Django、ECharts vs matplotlib 的取舍想清楚比多写两百行代码有用。2.3 数据合规与采集边界这条线必须提前划采集电影公开信息用于课程分析属于常见的学习场景但要有边界意识控制请求频率、不采集用户个人隐私数据、不绕过任何访问限制、数据仅用于本地分析展示。具体做法是请求之间加延时、设置合理的 User-Agent、遇到异常状态码就停止而不是反复重试。这些不仅是技术要求也是方案里应该写明的设计约束答辩时主动提一句“采集做了频率控制和异常终止”比被问到再解释要从容得多。3. 总体架构设计四层结构与数据流向的职责划分3.1 分层架构采集层、存储层、分析层、展示层整个系统按四层划分每层只做一件事层与层之间通过明确的数据结构衔接采集层负责发请求、解析页面、产出原始记录字典列表不关心数据怎么存。存储层负责建表、写入、去重把原始记录变成数据库里的行不关心数据怎么分析。分析层从数据库读数据进 DataFrame做清洗和统计产出结果集不关心怎么展示。展示层Flask 提供接口ECharts 消费接口数据渲染图表不关心数据怎么算出来。这样分层的好处是任何一层出问题都能单独定位。爬虫挂了不影响已有数据的分析展示图表不显示可以先查接口返回再查前端配置而不是从头到尾一行行看。我见过太多把爬虫、分析、路由全塞在一个文件里的写法改一个字段要翻五百行调试全靠 print这就是没分层的代价。数据流向是单向的采集层 → 存储层 → 分析层 → 展示层。单向意味着没有循环依赖每层的输入输出都能用一张表或一个 JSON 结构描述清楚。论文里画架构图时就按这个方向画箭头旁边标注每层的关键类或函数名图就立住了。3.2 目录结构让代码结构和论文章节对得上一个能直接交的方案目录结构应该和论文的章节一一对应这样写论文时不用重新组织材料douban_movie_system/ ├── spider/ # 采集层 │ ├── fetch_list.py # 列表页抓取与翻页 │ └── parse_detail.py # 详情页字段解析 ├── database/ # 存储层 │ ├── schema.sql # 建表脚本 │ └── dao.py # 写入与查询封装 ├── analysis/ # 分析层 │ ├── clean.py # 清洗规则 │ └── stats.py # 统计函数 ├── web/ # 展示层 │ ├── app.py # Flask 入口与路由 │ ├── api.py # 数据接口 │ └── templates/ # 页面模板 ├── static/ # ECharts 与前端资源 └── requirements.txt这个结构里spider对应论文的“数据采集”章database对应“数据库设计”章analysis对应“数据分析”章web对应“系统实现”章。写论文时按目录顺序展开逻辑天然连贯。requirements.txt 里锁定依赖版本避免换台机器就装不上——这是“完整版”和“半成品”的分水岭。3.3 数据库表设计三张表撑起整个系统表不用多三张核心表就够关键是字段类型和索引要设计对-- 电影主表存储清洗后的结构化数据 CREATE TABLE movie ( id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(200) NOT NULL COMMENT 片名, director VARCHAR(100) COMMENT 导演, actors VARCHAR(500) COMMENT 主演逗号分隔, year INT COMMENT 上映年份, genre VARCHAR(100) COMMENT 类型逗号分隔, rating DECIMAL(3,1) COMMENT 评分0-10, votes INT COMMENT 评价人数, duration INT COMMENT 时长分钟, country VARCHAR(100) COMMENT 国家地区, UNIQUE KEY uk_title_year (title, year) -- 防重复采集 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 类型维表把逗号分隔的类型拆开方便分组统计 CREATE TABLE genre_dim ( id INT PRIMARY KEY AUTO_INCREMENT, movie_id INT NOT NULL, genre VARCHAR(50) NOT NULL, KEY idx_genre (genre), KEY idx_movie (movie_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 采集日志表记录每次采集的批次、数量、状态便于排查 CREATE TABLE crawl_log ( id INT PRIMARY KEY AUTO_INCREMENT, batch_no VARCHAR(50), total INT, success INT, status VARCHAR(20), created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;设计说明几点。第一uk_title_year唯一索引是防重复采集的关键爬虫重跑时用INSERT ... ON DUPLICATE KEY UPDATE就不会产生脏数据。第二类型字段在电影表里存逗号分隔的原始值同时拆到genre_dim维表这样“统计各类型电影数量”时直接对维表GROUP BY genre不用在 SQL 里做字符串拆分这是很多人忽略的规范化细节。第三crawl_log表看着不起眼但排查“为什么这次只采到 30 条”时它就是黑匣子能快速判断是请求失败还是解析失败。字符集统一用 utf8mb4避免片名里的特殊字符存进去变问号。4. 核心模块实现从爬虫到图表的可复现代码4.1 采集模块请求、解析、翻页与异常终止采集模块的核心是三个动作发请求拿页面、解析出字段、翻页继续。下面这段是列表页抓取与详情解析的骨架import time import requests from bs4 import BeautifulSoup HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36 } def fetch_page(url, retry2): 带重试和延时的单页请求失败返回 None 而不是抛异常中断整批 for i in range(retry): try: resp requests.get(url, headersHEADERS, timeout10) if resp.status_code 200: return resp.text # 非 200 不重试直接放弃避免无效请求堆积 return None except requests.RequestException: time.sleep(2 * (i 1)) # 退避等待逐次拉长 return None def parse_list(html): 从列表页解析出详情页链接和基础字段 soup BeautifulSoup(html, html.parser) items [] for node in soup.select(div.item): title_node node.select_one(span.title) rating_node node.select_one(span.rating_num) link_node node.select_one(a) if not title_node or not link_node: continue # 结构不完整的条目直接跳过不硬解析 items.append({ title: title_node.get_text(stripTrue), rating: float(rating_node.get_text()) if rating_node else None, detail_url: link_node[href], }) return items这段代码有三个设计点值得讲。第一fetch_page失败返回None而不是抛异常因为批量采集时单页失败是常态抛异常会让整批中断返回None让上层决定跳过还是停止。第二重试次数控制在 2 次且非 200 状态码不重试避免对目标站点造成无谓压力这也是前面说的采集边界。第三parse_list里对缺失节点做continue跳过而不是用try/except包住整个循环——结构不完整的条目本来就不该进库跳过比硬解析出脏数据更干净。翻页逻辑放在外层用一个循环控制页码每页之间time.sleep(1)到time.sleep(2)的随机延时。采集完成后把本批的total、success写进crawl_log表这样每次跑完都能对账抓了多少、成功多少、失败多少一目了然。4.2 清洗与分析模块pandas 把脏数据变成可用结果采集下来的原始数据一定有脏的评分缺失、年份格式混乱、类型字段带空格、评价人数是“12345人评价”这种字符串。清洗规则要写成独立函数方便单测和复用import pandas as pd def clean_movies(df): 输入原始 DataFrame输出清洗后的 DataFrame # 评分转数值超出 0-10 的置空 df[rating] pd.to_numeric(df[rating], errorscoerce) df.loc[(df[rating] 0) | (df[rating] 10), rating] None # 年份从字符串里提取四位数字 df[year] df[year].astype(str).str.extract(r(\d{4}))[0] df[year] pd.to_numeric(df[year], errorscoerce) # 评价人数去掉非数字字符再转整型 df[votes] df[votes].astype(str).str.replace(r\D, , regexTrue) df[votes] pd.to_numeric(df[votes], errorscoerce).fillna(0).astype(int) # 类型去空格空值填“未知” df[genre] df[genre].fillna(未知).str.replace( , ) # 按片名年份去重保留评分高的那条 df df.sort_values(rating, ascendingFalse) df df.drop_duplicates(subset[title, year], keepfirst) return df.reset_index(dropTrue)清洗之后是统计几个典型函数对应几张图def rating_distribution(df, bins10): 评分分布返回分箱区间和数量对应直方图 cut pd.cut(df[rating].dropna(), binsbins, range(0, 10)) counts cut.value_counts().sort_index() return [f{int(i.left)}-{int(i.right)} for i in counts.index], counts.tolist() def genre_count(df): 类型统计拆分逗号后展开计数对应饼图/柱状图 exploded df[genre].str.split(,).explode() return exploded.value_counts().head(10).to_dict() def year_trend(df): 年份趋势按年聚合平均评分和数量对应折线图 grouped df.dropna(subset[year]).groupby(year).agg( avg_rating(rating, mean), count(title, count) ).reset_index() return grouped.to_dict(orientrecords)rating_distribution用pd.cut做等宽分箱返回的区间标签直接能当 ECharts 的 x 轴。genre_count用explode把逗号分隔的类型展开成多行再计数这是处理多值字段的标准手法比在 SQL 里写字符串函数清晰得多。year_trend按年聚合同时给出平均评分和影片数量一张折线图能画两条线答辩时信息密度更高。每个函数只做一件事、返回纯 Python 结构列表、字典这样 Flask 接口直接jsonify就能用不需要在接口层再做转换。4.3 展示模块Flask 接口与 ECharts 配置的对接Flask 这一层很薄每个接口对应一个统计函数路由命名和函数名保持一致from flask import Flask, jsonify from analysis.stats import rating_distribution, genre_count, year_trend from database.dao import load_movies app Flask(__name__) app.route(/api/rating) def api_rating(): df load_movies() # 从数据库读全量数据进 DataFrame labels, values rating_distribution(df) return jsonify({labels: labels, values: values}) app.route(/api/genre) def api_genre(): df load_movies() data genre_count(df) return jsonify([{name: k, value: v} for k, v in data.items()]) app.route(/api/year) def api_year(): df load_movies() return jsonify(year_trend(df))接口返回的 JSON 结构是直接按 ECharts 的series.data格式组织的前端拿到就能塞进配置不需要二次加工。比如/api/genre返回[{name: 剧情, value: 120}, ...]正好是饼图series.data要的格式。这种“接口即图表数据”的设计让前后端职责非常清晰后端只管算前端只管画。前端页面里ECharts 的初始化就是标准的echarts.init加setOption数据通过fetch从接口拿// 评分分布直方图从接口取数据后渲染 fetch(/api/rating) .then(res res.json()) .then(data { const chart echarts.init(document.getElementById(ratingChart)); chart.setOption({ title: { text: 评分分布 }, tooltip: { trigger: axis }, xAxis: { type: category, data: data.labels }, yAxis: { type: value, name: 影片数量 }, series: [{ type: bar, data: data.values, itemStyle: { color: #5470c6 } }] }); });这段配置里xAxis.data直接用接口返回的labelsseries.data用values字段名对齐后前端几乎没有逻辑全是配置。答辩演示时改一个type从bar换成line就能切换图表形态这种灵活性是选 ECharts 的直接收益。页面布局上一个页面放两到三张图用 CSS Grid 分栏避免图表挤在一起看不清。5. 避坑与常见问题排查这几处最容易让系统跑不起来5.1 爬虫返回空列表或字段全空现象请求状态码 200但parse_list返回空列表或者解析出的字段全是None。原因通常是页面结构变了选择器对不上也可能是请求被识别为非浏览器访问返回的是验证页而不是真实内容。解决分两步先把resp.text存到本地文件用浏览器打开看实际返回的是什么确认是真实页面还是拦截页如果是结构变化用开发者工具重新定位选择器把div.item这类选择器改成更稳定的属性选择器。我一般会在解析函数里加一行日志打印本页解析出的条目数条目数为 0 就立即停止翻页避免空跑几十页。5.2 中文写入数据库变成问号或乱码现象数据库里片名显示为???或乱码。原因有两个层面数据库和表的字符集不是 utf8mb4或者 Python 连接时的编码参数没设对。解决建表语句里显式写DEFAULT CHARSETutf8mb4连接串里加charsetutf8mb4pandas 写库时确认to_sql的连接引擎也带这个参数。三处只要有一处漏了就会出问题所以建表脚本和连接配置要放在一起检查。这个坑很经典改完记得把已有表ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4一遍。5.3 图表页面空白但接口有数据现象浏览器打开页面图表区域一片空白但直接访问/api/rating能看到 JSON。原因多半是前端fetch的路径写错、跨域被拦或者echarts.init的容器没有高度。ECharts 的容器必须有明确的宽高div默认高度是 0图自然画不出来。解决给容器加stylewidth:100%;height:400px打开浏览器控制台看 Network 面板里接口请求是否 200、Response 是否有数据再看 Console 有没有 JS 报错。按“接口通不通 → 数据有没有 → 容器有没有尺寸”的顺序排查基本三分钟定位。5.4 重复采集导致统计结果翻倍现象同一部电影在库里出现多条评分分布的数量明显偏大。原因是爬虫重跑时没有去重或者唯一索引没生效。解决确认movie表的uk_title_year唯一索引存在写入时用INSERT ... ON DUPLICATE KEY UPDATE而不是普通INSERT如果已经产生重复数据用一条DELETE配合子查询保留id最小的那条。预防手段是在采集入口就做一次内存去重按title year建集合重复的直接跳过双保险。5.5 换台机器就装不上依赖现象在自己电脑上跑得好好的换台机器pip install报版本冲突或者 pandas 读库报 API 不兼容。原因是没锁版本。解决用pip freeze requirements.txt生成锁定版本的文件交付时连同源码一起给。另外注意 pandas 和 numpy 的版本要匹配Flask 2.x 和 3.x 的部分 API 有差异requirements 里写清楚主版本号。这个坑看着小但答辩前换机器演示时最容易翻车提前在干净环境里装一遍验证比什么都稳。6. 验收与答辩怎么证明这套系统真的跑通了验收这件事我一般分三步走每一步都有可检查的产出答辩时按这个顺序演示节奏最稳。第一步是数据链路验收。从空库开始跑一遍采集脚本看crawl_log表里本批的total和success是否合理再查movie表的总行数是否和日志对得上。这一步证明“数据进得来”。检查点采集日志有记录、主表有数据、无重复行用SELECT title, year, COUNT(*) FROM movie GROUP BY title, year HAVING COUNT(*) 1验证返回空。第二步是分析结果验收。对几个统计函数做抽样核对比如手动从库里取 10 条评分算一下落在 8-9 分区间的是不是和rating_distribution返回的一致类型统计的总数是否等于展开后的记录数。这一步证明“算得对”。检查点统计结果与手工核对一致、空值处理不报错、边界值评分 0 和 10能正常分箱。第三步是展示验收。逐个打开页面确认每张图有数据、能交互、刷新后不报错。再模拟一次接口异常比如临时改错一个路由看前端是否有兜底提示而不是白屏。这一步证明“看得见、扛得住”。检查点所有图表有数据、图例和提示框正常、控制台无报错。答辩时的技巧在于“主动暴露设计决策”。演示到数据库时主动说一句“这里用了唯一索引防重复采集”演示到图表时说一句“接口返回结构直接对齐 ECharts 的 series 格式前端零加工”。老师听到这些会认为你理解自己的代码而不是拼凑出来的。反过来如果被问到“你这个爬虫会不会被封”就答采集频率控制和异常终止的设计把话题引到你准备好的地方。还有一个容易被忽略的点论文里的图和系统里的图要能对上。论文放静态统计图正文里说明“系统对应页面见图 X”两张图的数据口径一致这样文字、图表、系统三者互相印证可信度立刻不一样。注意答辩前一定在演示用的机器上完整跑一遍“清库 → 采集 → 分析 → 打开页面”的全流程别只在自己开发机上验证。我见过太多在别人电脑上因为数据库没启动、依赖没装全而卡住的场面。这套方案我从头到尾走过一遍之后最大的教训是毕设的分数不取决于代码写得多花哨而取决于每一层能不能被单独讲清楚、单独验证。从那以后我每次带这类项目都强制先填功能需求表、再定表结构、最后才写代码顺序反了一定返工。希望这套拆解能帮到你把手上这份豆瓣电影数据分析系统真正跑通、讲明白。本文还有配套的精品资源点击获取

Flask+ECharts+爬虫+pandas：豆瓣电影数据分析系统全链路实战

相关推荐

OpenCV水果识别实战：苹果香蕉梨子三分类样本与SVM流水线

Eclipse项目关闭操作与性能优化指南

Java网络聊天室实战：Socket通信、多线程与消息持久化

更多资讯

7天AI扫盲路线图：技术人快速掌握大模型、Agent与AI应用

企业级问卷系统测试实战：从功能到性能的全面优化

LTC681X AFE驱动源码拆解：SPI帧结构、PEC15校验与BMS采样实现

Vue动态组件性能优化：从渲染链路到内存治理的实战指南

MCP协议与Sealos的云原生实践指南

小米MiMo-V2.6开源大模型深度解析：K2架构如何实现长上下文与端侧AI

今日更新

PLFM_RADAR：从被动告警到主动感知的微服务健康监控系统

SPI隔离设计实战：MAX14431BAEE+与STM32F407工业级应用

数字隔离器如何根治SPI通信地环路干扰：MAX14431与TM4C129实战

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？