这个项目我前后折腾了三周从看番时的灵光一现到最终跑通完整链路中间踩了不少坑。今天把整个思路、技术选型、核心代码逻辑和排障过程一次性整理出来给想做数据分析实战的同学一个可参考的完整样本。先说这个系统解决什么问题把散落在不同平台的动漫信息、评分、播放量、类型标签等数据通过 Python 完成采集、清洗、入库、分析最后用可视化图表展示规律。比如哪类题材在近五年占比上升、不同制作公司的口碑分布、评分和集数有无相关性这些都能一键生成图表。源码加数据库加文档一套齐全非常适合用来练手或者做课程设计、毕业设计的基础框架。1. 项目定位与功能范围1.1 项目到底做了什么这个系统不是一个单纯爬虫也不是只画两张图就完事的 demo而是跑通了一条完整的数据链路数据获取 → 清洗入库 → 查询分析 → 可视化呈现。从实际项目经验来看大部分刚入门的数据分析项目死在两个地方一是数据源太脏真实场景里字段缺失、格式混乱、取值矛盾全都存在二是只把数据导入了数据库但后续分析完全空白。所以我在设计项目时把功能分成了四层数据采集层抓取动漫番剧的基础信息、评分、播出年份、类型标签、制作公司等数据存储层MySQL 建库建表按主题拆分表结构预留索引优化查询分析计算层Pandas 做数据清洗与聚合统计计算各类分布规律展示呈现层Pyecharts 生成交互式图表按题材、年份、评分等多个维度产出可视化结果这个系统的优点在于每一层都相对独立替换数据源或者换可视化库都不会互相影响。比如你想把前端展示从 Pyecharts 换成 Plotly只需要改展示层的代码采集和分析层完全不用动。1.2 适用人群与项目价值如果你处在这个阶段这个项目很匹配你的需求学了 Python 基础语法但缺少一个完整实战项目的学习者这个项目覆盖爬虫、数据库、数据分析、可视化的完整链路比零散的小练习有价值得多需要课程设计或毕业设计选题的学生功能完整度足够文档齐全答辩时有话可说想熟悉 Python 操作 MySQL 和 Pandas 数据处理的开发初步接触者这套代码可以作为工具箱反复使用这个项目的核心不是教你怎么抓数据而是让你理解真实项目中数据到手之后怎么办。爬虫只是前菜清洗和分析才是主菜这也是实际工作中占比最高的部分。2. 技术选型和架构设计思路2.1 为什么是 Python 加 MySQL 的组合选 Python 是因为它在数据采集和处理生态上几乎没有对手。Requests 搞定 HTTP 请求BeautifulSoup 处理 HTML 结构Pandas 做表格型数据处理Pyecharts 出图表这些库之间的数据格式天然互通不需要做太多转换。而 MySQL 作为存储层既能支持后续扩展的复杂查询又能让初学者快速建立起表结构设计的思维方式这比直接用 Excel 或者 CSV 文件做数据存储要更有工程感。数据库选 MySQL 而不是 SQLite一个是习惯问题——大部分公司实战用的都是 MySQL早点熟悉它的语法和配置方式不是坏事另一个是类型支持更完整比如 DATETIME 类型在 SQLite 里就没有那么直观。当然如果你本地没装 MySQL用 SQLite 改一下连接方式也能跑通这套代码但建议还是装一个。实际里我给的建表 SQL 里花了很多心思在字段类型上比如年份字段不要用2023-01-01这种完整日期格式直接存2023就够查询和聚合反而更快。评分字段用DECIMAL(3,1)精确到一位小数排序和区间筛选都很方便。状态字段用TINYINT加注释说明含义而不是直接存字符串这样数据量上来之后占用的存储空间和检索速度差距会很明显。2.2 整体架构的模块划分项目目录结构我按照职责划分成五个模块这样不管是自己维护还是别人接手看代码都会轻松很多project/ ├── config/ # 数据库连接配置、公共常量 │ └── db_config.py ├── spider/ # 数据采集模块 │ ├── data_fetcher.py │ └── parser.py ├── storage/ # 数据入库模块 │ ├── database.py │ └── models.py ├── analysis/ # 数据分析模块 │ └── analyzer.py ├── visualization/ # 可视化模块 │ ├── charts.py │ └── templates/ └── main.py # 主入口主入口按阶段调用各模块# main.py 核心流程 from spider.data_fetcher import fetch_bangumi_data from storage.database import init_db, save_to_db from analysis.analyzer import process_data from visualization.charts import generate_all_charts if __name__ __main__: # 1. 初始化数据表 init_db() # 2. 抓取原始数据 raw_data fetch_bangumi_data() # 3. 入库并分析 save_to_db(raw_data) # 4. 生成报告 generate_all_charts()这里犯过一个典型的工程错误刚开始我把抓取、存储、分析写在一个脚本里结果发现只要网络一超时重跑就要从头再来。切成模块化之后每层可以单独调试单独重跑效率提升的不是一点半点。3. 数据库设计与数据流转细节3.1 表结构的设计考量数据库一共设计了四张表我挑其中两张说明设计时的思考过程。动漫信息表CREATE TABLE anime_info ( id INT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(200) NOT NULL COMMENT 作品标题, year INT NOT NULL COMMENT 播出年份, season VARCHAR(20) COMMENT 所属季度, genre VARCHAR(100) COMMENT 类型标签, episodes INT COMMENT 总集数, company VARCHAR(100) COMMENT 制作公司, rating DECIMAL(3,1) COMMENT 评分, rating_count INT DEFAULT 0 COMMENT 评分人数, UNIQUE KEY uk_title_year (title, year) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;UNIQUE KEY uk_title_year (title, year)这个设计是第二次重构时才加的。第一次测试时发现同一部作品在不同平台可能被重复抓取比如同一部番剧的两个条目年份一致但标题略有差异或者不同季度标题一样。用title year做唯一键在入库前做去重节省的空间不说起码保证了分析时不会出现同一部作品的重复计数——这样统计结果才具有真实性。类型标签字段用了VARCHAR直接存热血, 冒险, 战斗这种字符串没有单独拆表。这是取舍的结果如果按范式拆分类型表查询时需要 JOIN对于初阶项目来说复杂化且不直观。遇到需要按类型统计的场景直接在 SQL 里用FIND_IN_SET或是在 Pandas 里split后再展开即可简单直接。字段注释我全都写上了过两周自己翻数据库也不会忘记每个字段是什么含义这个习惯我认为收益远大于付出。3.2 数据清洗是关键环节数据采集之后是不能直接入库的能入库也不代表就能直接用来分析。举个例子我抓到的年份字段有的值是2023年有的值是2023-01-05还有直接是数字的统一格式就得先处理。另外评分字段缺失值是空字符串而不是 NULL类型标签里有全角逗号和半角逗号混着用。这些脏数据如果不处理后面画图时轻则显示错乱重则让整个统计直接报错。清洗流程我放在入库之后、分析之前做分几层推进格式统一年份提取四位数字日期字符串截取年份部分评分转换为浮点数缺失处理评分缺失的用该类型平均值填充但填充量不超过总量的百分之五时这样做超过就得考虑重新采集类型标准化全角逗号转半角空白字符剔除统一用顿号分隔异常值过滤集数超过 3000 的判定为 OVA 合集或数据异常直接剔除这里有个实际的对比没做清洗之前按照类型统计出来的数据占比最高的类型是未知因为很多条目的类型字段为空清洗之后这个比重降到了百分之三以内整个分析结果才是可用的。数据清洗不是华丽的部分但恰恰是决定项目能不能出成果的标准所在。它做的好后面的所有环节都会顺畅。4. 爬虫模块与数据采集实操4.1 抓取范围与频率控制这个项目的爬虫抓的是某动漫社区公开的榜单页和详情页不是那种需要复杂交互的站点静态 HTML 加 JSON 接口混合。Requests 加 BeautifulSoup 的组合就能搞定。重点说一下频率控制的必要性刚开始测试时我每分钟发几十个请求结果不到十分钟就被拒绝了。后面加了随机延时每次请求之间time.sleep(random.uniform(1, 3))顺利了很多。抓取流程分两阶段第一阶段抓列表页拿到每部作品的详情链接和基础信息比如标题、年份、类型第二阶段逐一访问详情页提取评分、评分人数、制作公司信息代码核心逻辑import time import random import requests from bs4 import BeautifulSoup HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } def fetch_season_page(base_url, page): resp requests.get( f{base_url}?page{page}, headersHEADERS, timeout10 ) if resp.status_code ! 200: raise RuntimeError(f请求失败: {resp.status_code}) return BeautifulSoup(resp.text, html.parser) def extract_anime_info(soup): items [] for card in soup.select(.anime-card): title_tag card.select_one(.card-title) year_tag card.select_one(.card-year) genre_tag card.select_one(.card-genre) if not title_tag or not year_tag: continue # 结构不完整的条目直接跳过 items.append({ title: title_tag.text.strip(), year: parse_year(year_tag.text.strip()), genre: genre_tag.text.strip() if genre_tag else }) return items这个if not title_tag or not year_tag: continue的处理很关键。页面结构偶尔会有卡片的某个字段缺失如果不判空直接取.text会报AttributeError整个抓取中断。真实爬虫里这种异常情况特别多见得多了你就知道必须把防御性判断写充分。4.2 数据存储与断点续跑抓下来的数据先不直接入库而是先落一份原始 JSON 到本地。这是我认为很值得推荐的习惯——原始数据别丢万一清洗逻辑写错了还能重新处理不用重新抓一遍。每次抓取完成后打印日志记录进度存成带日期时间戳的文件import json from datetime import datetime def save_raw_data(data): timestamp datetime.now().strftime(%Y%m%d_%H%M%S) filename fraw_data_{timestamp}.json with open(filename, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(f原始数据已保存: {filename}) return filename入库前再做一次幂等校验用之前建的唯一索引做去重。具体实现是用INSERT IGNORE语法重复记录自动跳过# 批量入库示意 sql INSERT IGNORE INTO anime_info (title, year, season, genre, episodes, company, rating, rating_count) VALUES (%s, %s, %s, %s, %s, %s, %s, %s) cursor.executemany(sql, batch_data)这样操作之后即使某次抓取因超时中断重跑也不会造成数据重复堆积。数据库里干干净净分析阶段才能放得开手脚。5. 数据分析与可视化实现过程5.1 分析维度选择与实现数据入库之后分析维度的选择决定了这个项目的价值。我选了四个比较有代表性的维度覆盖不同类型的可视化图表年份维度每年播出数量变化趋势用折线图展示类型维度不同题材的作品数量和平均评分用柱状图加折线组合图评分区间分布直方图展示整体评分结构制作公司维度产出量前二十家公司及其评分用条形图分析代码基于 Pandasimport pandas as pd from sqlalchemy import create_engine engine create_engine(mysqlpymysql://user:passlocalhost:3306/anime_db?charsetutf8mb4) df pd.read_sql(SELECT * FROM anime_info, engine) # 类型分布统计 def analyze_by_genre(df): df_expanded df.assign(genredf[genre].str.split(、)).explode(genre) genre_stats df_expanded.groupby(genre).agg( 作品数量(title, count), 平均评分(rating, mean) ).reset_index().sort_values(作品数量, ascendingFalse) return genre_stats这里有个独到设计是explode方法。它按分隔符把类型列表展平优化后一步到位实现了一部作品可以归属到多个类型的映射关系比各种字符串匹配方案都简化不少。用这个操作后统计结果会翻倍计算不过利于分析。再加上assign创建临时列链式调用十分流畅。5.2 Pyecharts 绘制交互式图表可视化部分用的是 Pyecharts我比较看重它能生成交互式 HTML 页面不用起服务双击就能打开看效果。核心图表代码from pyecharts.charts import Bar, Line from pyecharts import options as opts def create_genre_chart(genre_stats): bar ( Bar() .add_xaxis(genre_stats[类型].tolist()) .add_yaxis( 作品数量, genre_stats[作品数量].tolist(), color#5470c6 ) .extend_axis( yaxisopts.AxisOpts( name平均评分, type_value, min_0, max_10, positionright ) ) .set_global_opts( title_optsopts.TitleOpts(title各类型动漫作品数量与评分对比), legend_optsopts.LegendOpts(pos_top5%) ) ) # 用 Line 构建第二个 Y 轴 line ( Line() .add_xaxis(genre_stats[类型].tolist()) .add_yaxis( 平均评分, [round(x, 2) for x in genre_stats[平均评分].tolist()], yaxis_index1, color#fac858 ) ) return bar.overlap(line)这个组合图需要注意双轴刻度的设置。作品数量少的类型可能只有个位数而平均评分在八分左右如果不用双轴评分曲线会贴在最下面完全看不出趋势。用左右双轴可以更好展示两种指标的数量级差异。生成的所有图表最后会统一汇总到一个 HTML 报告页面里用一个简单脚本自动拼接代码块调整模板使多个div容器按网格布局展示。整个分析过程的输出即点即用不需要额外解释该怎么看。6. 系统运行与常见问题排查6.1 本地运行环境准备要跑通这套系统最省心的环境配置是这样Python 版本 3.9 以上低版本在 Pandas 和 Pyecharts 的依赖上会遇到兼容问题MySQL 5.7 或 8.0记得设置字符集为utf8mb4否则中文会显示成乱码在安装依赖时用pip install -r requirements.txt将版本号固定下来不要用pip install pandas pyecharts这样让 pip 自动选最新版——新版本不一定会带来你想要的结果反而可能出现接口变更requirements.txt参考内容requests2.31.0 beautifulsoup44.12.3 pandas2.0.3 mysql-connector-python8.1.0 pyecharts2.0.36.2 高频问题与处理方案类别一连接 MySQL 报错Access denied for user rootlocalhost这种基本就是密码不对或者用户没有远程访问权限。最直接的排查方式是先用命令行工具终端里的 mysql 客户端试一遍用户名和密码排除网络和驱动造成的混淆。如果命令能通但 Python 不行优先检查连接串里的参数拼写和编码格式。类别二中文乱码如果 MySQL 表内中文正常但 Python 读出来乱码问题通常出在连接时没有指定字符集。加charsetutf8mb4即可。曾经有一次我折腾了很久发现是数据库本身的排序规则被设成了latin1_swedish_ci这种情况必须改表的字符集。类别三入库数据重复有些作品同一季有多个版本或者标题大小写不同导致唯一索引没有生效。我最初的解决方案是实现一个normalize_title函数把标题里的全角字符转半角、统一大小写然后再判断重复但后来考虑到数据量不大且不同平台的标题精度其实很难完全统一我就改成了入库前先查一次库用title year匹配存在就跳过不存在才插入。这两种方案都可以用看你的数据规模选择。类别四图表渲染不出来多数不是代码逻辑问题而是生成图表文件时的路径问题。Pyecharts 默认会在当前工作目录找模板如果你用 IDE 运行代码但工作目录不在项目根目录下就会报找不到模板文件。解决办法是用os.chdir()或者在代码里使用绝对路径。提示实际调试时观察 MySQL 中的原始数据有没有尊严感也是工作重要一环。数据仓库里数据不清洗就直接画图图表再好看也经不住追问。7. 项目扩展的几个方向这个项目如果对照着教程做完你还可以继续加点内容把系统的完整度和难度都提高一个档次。如果你想继续深入爬虫可以加入数据源的多平台对比同一部作品抓多个平台的评分分析平台之间的评分差异。这部分代码并不复杂本质上是多抓一遍再做 Jaccard 相似度匹配但最终产出的结论会很有意思——不同圈层对作品的评价模式可能存在显著差别。如果你想升级到更高级的可视化交互可以在系统里加入时间轴滑动筛选器按年选择时间段观察类型占比变化这个用 Pyecharts 的Timeline组件就能实现。或者把类型分布做成力导向图用节点大小代表作品数连线粗细代表评分相似度视觉效果比横向柱状图强很多。如果你想深入数据库方向可以在系统里加入定时调度逻辑比如用系统自带的定时任务每天拉一次数据把系统做成持续运行的数据监控平台。这时候要考虑的问题就变成增量更新策略、数据版本管理、监控告警这些工程问题项目的技术含金量也会明显上一个台阶。8. 实际体会与教训这个项目做下来最大的体会是数据可视化分析的重心不在可视化而在数据分析和数据质量。画图本身不困难困难的是弄清楚你要表达什么以及你的数据支不支持你想要表达的结论。我最初的设计是想做年度霸权番预测模型但数据量只够覆盖最近几年的新番样本不足做出来没有说服力最后砍掉这个功能换成了分布统计类的描述性分析。做项目不要贪大求全在能力范围内把一个闭环做完整比做一个漏洞百出的大框架有用得多。另外给我深刻教训的一点是要有版本管理意识。项目改到第三版的时候我把数据库表结构的字段名改了结果可视化代码里还在用旧的字段名排查了半天。如果你用 Git 管理代码类似的低级错误会少很多。就算项目不大从第一天起就养成分支管理的习惯这是职业素养不完全是技术能力问题。最后分享一个小技巧在入库和分析环节之间加一个数据质量报告函数输出每个字段的缺失率、唯一值数量、异常值数量。每次跑完数据先扫一眼这个报告再开始分析。这个习惯能省下后面无数反复检查的时间值得保留到以后的每个数据项目里。整个系统从爬虫到最终 HTML 报告整个过程已经跑得比较顺畅。我做成了模板式的代码结构以后遇到其他领域的分析需求改改字段名和分析维度就能复用。这个项目的价值也正在于此——它不是终结而是一个起点。
这个项目我前后折腾了三周从看番时的灵光一现到最终跑通完整链路中间踩了不少坑。今天把整个思路、技术选型、核心代码逻辑和排障过程一次性整理出来给想做数据分析实战的同学一个可参考的完整样本。先说这个系统解决什么问题把散落在不同平台的动漫信息、评分、播放量、类型标签等数据通过 Python 完成采集、清洗、入库、分析最后用可视化图表展示规律。比如哪类题材在近五年占比上升、不同制作公司的口碑分布、评分和集数有无相关性这些都能一键生成图表。源码加数据库加文档一套齐全非常适合用来练手或者做课程设计、毕业设计的基础框架。1. 项目定位与功能范围1.1 项目到底做了什么这个系统不是一个单纯爬虫也不是只画两张图就完事的 demo而是跑通了一条完整的数据链路数据获取 → 清洗入库 → 查询分析 → 可视化呈现。从实际项目经验来看大部分刚入门的数据分析项目死在两个地方一是数据源太脏真实场景里字段缺失、格式混乱、取值矛盾全都存在二是只把数据导入了数据库但后续分析完全空白。所以我在设计项目时把功能分成了四层数据采集层抓取动漫番剧的基础信息、评分、播出年份、类型标签、制作公司等数据存储层MySQL 建库建表按主题拆分表结构预留索引优化查询分析计算层Pandas 做数据清洗与聚合统计计算各类分布规律展示呈现层Pyecharts 生成交互式图表按题材、年份、评分等多个维度产出可视化结果这个系统的优点在于每一层都相对独立替换数据源或者换可视化库都不会互相影响。比如你想把前端展示从 Pyecharts 换成 Plotly只需要改展示层的代码采集和分析层完全不用动。1.2 适用人群与项目价值如果你处在这个阶段这个项目很匹配你的需求学了 Python 基础语法但缺少一个完整实战项目的学习者这个项目覆盖爬虫、数据库、数据分析、可视化的完整链路比零散的小练习有价值得多需要课程设计或毕业设计选题的学生功能完整度足够文档齐全答辩时有话可说想熟悉 Python 操作 MySQL 和 Pandas 数据处理的开发初步接触者这套代码可以作为工具箱反复使用这个项目的核心不是教你怎么抓数据而是让你理解真实项目中数据到手之后怎么办。爬虫只是前菜清洗和分析才是主菜这也是实际工作中占比最高的部分。2. 技术选型和架构设计思路2.1 为什么是 Python 加 MySQL 的组合选 Python 是因为它在数据采集和处理生态上几乎没有对手。Requests 搞定 HTTP 请求BeautifulSoup 处理 HTML 结构Pandas 做表格型数据处理Pyecharts 出图表这些库之间的数据格式天然互通不需要做太多转换。而 MySQL 作为存储层既能支持后续扩展的复杂查询又能让初学者快速建立起表结构设计的思维方式这比直接用 Excel 或者 CSV 文件做数据存储要更有工程感。数据库选 MySQL 而不是 SQLite一个是习惯问题——大部分公司实战用的都是 MySQL早点熟悉它的语法和配置方式不是坏事另一个是类型支持更完整比如 DATETIME 类型在 SQLite 里就没有那么直观。当然如果你本地没装 MySQL用 SQLite 改一下连接方式也能跑通这套代码但建议还是装一个。实际里我给的建表 SQL 里花了很多心思在字段类型上比如年份字段不要用2023-01-01这种完整日期格式直接存2023就够查询和聚合反而更快。评分字段用DECIMAL(3,1)精确到一位小数排序和区间筛选都很方便。状态字段用TINYINT加注释说明含义而不是直接存字符串这样数据量上来之后占用的存储空间和检索速度差距会很明显。2.2 整体架构的模块划分项目目录结构我按照职责划分成五个模块这样不管是自己维护还是别人接手看代码都会轻松很多project/ ├── config/ # 数据库连接配置、公共常量 │ └── db_config.py ├── spider/ # 数据采集模块 │ ├── data_fetcher.py │ └── parser.py ├── storage/ # 数据入库模块 │ ├── database.py │ └── models.py ├── analysis/ # 数据分析模块 │ └── analyzer.py ├── visualization/ # 可视化模块 │ ├── charts.py │ └── templates/ └── main.py # 主入口主入口按阶段调用各模块# main.py 核心流程 from spider.data_fetcher import fetch_bangumi_data from storage.database import init_db, save_to_db from analysis.analyzer import process_data from visualization.charts import generate_all_charts if __name__ __main__: # 1. 初始化数据表 init_db() # 2. 抓取原始数据 raw_data fetch_bangumi_data() # 3. 入库并分析 save_to_db(raw_data) # 4. 生成报告 generate_all_charts()这里犯过一个典型的工程错误刚开始我把抓取、存储、分析写在一个脚本里结果发现只要网络一超时重跑就要从头再来。切成模块化之后每层可以单独调试单独重跑效率提升的不是一点半点。3. 数据库设计与数据流转细节3.1 表结构的设计考量数据库一共设计了四张表我挑其中两张说明设计时的思考过程。动漫信息表CREATE TABLE anime_info ( id INT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(200) NOT NULL COMMENT 作品标题, year INT NOT NULL COMMENT 播出年份, season VARCHAR(20) COMMENT 所属季度, genre VARCHAR(100) COMMENT 类型标签, episodes INT COMMENT 总集数, company VARCHAR(100) COMMENT 制作公司, rating DECIMAL(3,1) COMMENT 评分, rating_count INT DEFAULT 0 COMMENT 评分人数, UNIQUE KEY uk_title_year (title, year) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;UNIQUE KEY uk_title_year (title, year)这个设计是第二次重构时才加的。第一次测试时发现同一部作品在不同平台可能被重复抓取比如同一部番剧的两个条目年份一致但标题略有差异或者不同季度标题一样。用title year做唯一键在入库前做去重节省的空间不说起码保证了分析时不会出现同一部作品的重复计数——这样统计结果才具有真实性。类型标签字段用了VARCHAR直接存热血, 冒险, 战斗这种字符串没有单独拆表。这是取舍的结果如果按范式拆分类型表查询时需要 JOIN对于初阶项目来说复杂化且不直观。遇到需要按类型统计的场景直接在 SQL 里用FIND_IN_SET或是在 Pandas 里split后再展开即可简单直接。字段注释我全都写上了过两周自己翻数据库也不会忘记每个字段是什么含义这个习惯我认为收益远大于付出。3.2 数据清洗是关键环节数据采集之后是不能直接入库的能入库也不代表就能直接用来分析。举个例子我抓到的年份字段有的值是2023年有的值是2023-01-05还有直接是数字的统一格式就得先处理。另外评分字段缺失值是空字符串而不是 NULL类型标签里有全角逗号和半角逗号混着用。这些脏数据如果不处理后面画图时轻则显示错乱重则让整个统计直接报错。清洗流程我放在入库之后、分析之前做分几层推进格式统一年份提取四位数字日期字符串截取年份部分评分转换为浮点数缺失处理评分缺失的用该类型平均值填充但填充量不超过总量的百分之五时这样做超过就得考虑重新采集类型标准化全角逗号转半角空白字符剔除统一用顿号分隔异常值过滤集数超过 3000 的判定为 OVA 合集或数据异常直接剔除这里有个实际的对比没做清洗之前按照类型统计出来的数据占比最高的类型是未知因为很多条目的类型字段为空清洗之后这个比重降到了百分之三以内整个分析结果才是可用的。数据清洗不是华丽的部分但恰恰是决定项目能不能出成果的标准所在。它做的好后面的所有环节都会顺畅。4. 爬虫模块与数据采集实操4.1 抓取范围与频率控制这个项目的爬虫抓的是某动漫社区公开的榜单页和详情页不是那种需要复杂交互的站点静态 HTML 加 JSON 接口混合。Requests 加 BeautifulSoup 的组合就能搞定。重点说一下频率控制的必要性刚开始测试时我每分钟发几十个请求结果不到十分钟就被拒绝了。后面加了随机延时每次请求之间time.sleep(random.uniform(1, 3))顺利了很多。抓取流程分两阶段第一阶段抓列表页拿到每部作品的详情链接和基础信息比如标题、年份、类型第二阶段逐一访问详情页提取评分、评分人数、制作公司信息代码核心逻辑import time import random import requests from bs4 import BeautifulSoup HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } def fetch_season_page(base_url, page): resp requests.get( f{base_url}?page{page}, headersHEADERS, timeout10 ) if resp.status_code ! 200: raise RuntimeError(f请求失败: {resp.status_code}) return BeautifulSoup(resp.text, html.parser) def extract_anime_info(soup): items [] for card in soup.select(.anime-card): title_tag card.select_one(.card-title) year_tag card.select_one(.card-year) genre_tag card.select_one(.card-genre) if not title_tag or not year_tag: continue # 结构不完整的条目直接跳过 items.append({ title: title_tag.text.strip(), year: parse_year(year_tag.text.strip()), genre: genre_tag.text.strip() if genre_tag else }) return items这个if not title_tag or not year_tag: continue的处理很关键。页面结构偶尔会有卡片的某个字段缺失如果不判空直接取.text会报AttributeError整个抓取中断。真实爬虫里这种异常情况特别多见得多了你就知道必须把防御性判断写充分。4.2 数据存储与断点续跑抓下来的数据先不直接入库而是先落一份原始 JSON 到本地。这是我认为很值得推荐的习惯——原始数据别丢万一清洗逻辑写错了还能重新处理不用重新抓一遍。每次抓取完成后打印日志记录进度存成带日期时间戳的文件import json from datetime import datetime def save_raw_data(data): timestamp datetime.now().strftime(%Y%m%d_%H%M%S) filename fraw_data_{timestamp}.json with open(filename, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(f原始数据已保存: {filename}) return filename入库前再做一次幂等校验用之前建的唯一索引做去重。具体实现是用INSERT IGNORE语法重复记录自动跳过# 批量入库示意 sql INSERT IGNORE INTO anime_info (title, year, season, genre, episodes, company, rating, rating_count) VALUES (%s, %s, %s, %s, %s, %s, %s, %s) cursor.executemany(sql, batch_data)这样操作之后即使某次抓取因超时中断重跑也不会造成数据重复堆积。数据库里干干净净分析阶段才能放得开手脚。5. 数据分析与可视化实现过程5.1 分析维度选择与实现数据入库之后分析维度的选择决定了这个项目的价值。我选了四个比较有代表性的维度覆盖不同类型的可视化图表年份维度每年播出数量变化趋势用折线图展示类型维度不同题材的作品数量和平均评分用柱状图加折线组合图评分区间分布直方图展示整体评分结构制作公司维度产出量前二十家公司及其评分用条形图分析代码基于 Pandasimport pandas as pd from sqlalchemy import create_engine engine create_engine(mysqlpymysql://user:passlocalhost:3306/anime_db?charsetutf8mb4) df pd.read_sql(SELECT * FROM anime_info, engine) # 类型分布统计 def analyze_by_genre(df): df_expanded df.assign(genredf[genre].str.split(、)).explode(genre) genre_stats df_expanded.groupby(genre).agg( 作品数量(title, count), 平均评分(rating, mean) ).reset_index().sort_values(作品数量, ascendingFalse) return genre_stats这里有个独到设计是explode方法。它按分隔符把类型列表展平优化后一步到位实现了一部作品可以归属到多个类型的映射关系比各种字符串匹配方案都简化不少。用这个操作后统计结果会翻倍计算不过利于分析。再加上assign创建临时列链式调用十分流畅。5.2 Pyecharts 绘制交互式图表可视化部分用的是 Pyecharts我比较看重它能生成交互式 HTML 页面不用起服务双击就能打开看效果。核心图表代码from pyecharts.charts import Bar, Line from pyecharts import options as opts def create_genre_chart(genre_stats): bar ( Bar() .add_xaxis(genre_stats[类型].tolist()) .add_yaxis( 作品数量, genre_stats[作品数量].tolist(), color#5470c6 ) .extend_axis( yaxisopts.AxisOpts( name平均评分, type_value, min_0, max_10, positionright ) ) .set_global_opts( title_optsopts.TitleOpts(title各类型动漫作品数量与评分对比), legend_optsopts.LegendOpts(pos_top5%) ) ) # 用 Line 构建第二个 Y 轴 line ( Line() .add_xaxis(genre_stats[类型].tolist()) .add_yaxis( 平均评分, [round(x, 2) for x in genre_stats[平均评分].tolist()], yaxis_index1, color#fac858 ) ) return bar.overlap(line)这个组合图需要注意双轴刻度的设置。作品数量少的类型可能只有个位数而平均评分在八分左右如果不用双轴评分曲线会贴在最下面完全看不出趋势。用左右双轴可以更好展示两种指标的数量级差异。生成的所有图表最后会统一汇总到一个 HTML 报告页面里用一个简单脚本自动拼接代码块调整模板使多个div容器按网格布局展示。整个分析过程的输出即点即用不需要额外解释该怎么看。6. 系统运行与常见问题排查6.1 本地运行环境准备要跑通这套系统最省心的环境配置是这样Python 版本 3.9 以上低版本在 Pandas 和 Pyecharts 的依赖上会遇到兼容问题MySQL 5.7 或 8.0记得设置字符集为utf8mb4否则中文会显示成乱码在安装依赖时用pip install -r requirements.txt将版本号固定下来不要用pip install pandas pyecharts这样让 pip 自动选最新版——新版本不一定会带来你想要的结果反而可能出现接口变更requirements.txt参考内容requests2.31.0 beautifulsoup44.12.3 pandas2.0.3 mysql-connector-python8.1.0 pyecharts2.0.36.2 高频问题与处理方案类别一连接 MySQL 报错Access denied for user rootlocalhost这种基本就是密码不对或者用户没有远程访问权限。最直接的排查方式是先用命令行工具终端里的 mysql 客户端试一遍用户名和密码排除网络和驱动造成的混淆。如果命令能通但 Python 不行优先检查连接串里的参数拼写和编码格式。类别二中文乱码如果 MySQL 表内中文正常但 Python 读出来乱码问题通常出在连接时没有指定字符集。加charsetutf8mb4即可。曾经有一次我折腾了很久发现是数据库本身的排序规则被设成了latin1_swedish_ci这种情况必须改表的字符集。类别三入库数据重复有些作品同一季有多个版本或者标题大小写不同导致唯一索引没有生效。我最初的解决方案是实现一个normalize_title函数把标题里的全角字符转半角、统一大小写然后再判断重复但后来考虑到数据量不大且不同平台的标题精度其实很难完全统一我就改成了入库前先查一次库用title year匹配存在就跳过不存在才插入。这两种方案都可以用看你的数据规模选择。类别四图表渲染不出来多数不是代码逻辑问题而是生成图表文件时的路径问题。Pyecharts 默认会在当前工作目录找模板如果你用 IDE 运行代码但工作目录不在项目根目录下就会报找不到模板文件。解决办法是用os.chdir()或者在代码里使用绝对路径。提示实际调试时观察 MySQL 中的原始数据有没有尊严感也是工作重要一环。数据仓库里数据不清洗就直接画图图表再好看也经不住追问。7. 项目扩展的几个方向这个项目如果对照着教程做完你还可以继续加点内容把系统的完整度和难度都提高一个档次。如果你想继续深入爬虫可以加入数据源的多平台对比同一部作品抓多个平台的评分分析平台之间的评分差异。这部分代码并不复杂本质上是多抓一遍再做 Jaccard 相似度匹配但最终产出的结论会很有意思——不同圈层对作品的评价模式可能存在显著差别。如果你想升级到更高级的可视化交互可以在系统里加入时间轴滑动筛选器按年选择时间段观察类型占比变化这个用 Pyecharts 的Timeline组件就能实现。或者把类型分布做成力导向图用节点大小代表作品数连线粗细代表评分相似度视觉效果比横向柱状图强很多。如果你想深入数据库方向可以在系统里加入定时调度逻辑比如用系统自带的定时任务每天拉一次数据把系统做成持续运行的数据监控平台。这时候要考虑的问题就变成增量更新策略、数据版本管理、监控告警这些工程问题项目的技术含金量也会明显上一个台阶。8. 实际体会与教训这个项目做下来最大的体会是数据可视化分析的重心不在可视化而在数据分析和数据质量。画图本身不困难困难的是弄清楚你要表达什么以及你的数据支不支持你想要表达的结论。我最初的设计是想做年度霸权番预测模型但数据量只够覆盖最近几年的新番样本不足做出来没有说服力最后砍掉这个功能换成了分布统计类的描述性分析。做项目不要贪大求全在能力范围内把一个闭环做完整比做一个漏洞百出的大框架有用得多。另外给我深刻教训的一点是要有版本管理意识。项目改到第三版的时候我把数据库表结构的字段名改了结果可视化代码里还在用旧的字段名排查了半天。如果你用 Git 管理代码类似的低级错误会少很多。就算项目不大从第一天起就养成分支管理的习惯这是职业素养不完全是技术能力问题。最后分享一个小技巧在入库和分析环节之间加一个数据质量报告函数输出每个字段的缺失率、唯一值数量、异常值数量。每次跑完数据先扫一眼这个报告再开始分析。这个习惯能省下后面无数反复检查的时间值得保留到以后的每个数据项目里。整个系统从爬虫到最终 HTML 报告整个过程已经跑得比较顺畅。我做成了模板式的代码结构以后遇到其他领域的分析需求改改字段名和分析维度就能复用。这个项目的价值也正在于此——它不是终结而是一个起点。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
