Python爬虫数据可视化大作业：从爬取到答辩的完整落地指南

简介这是一套面向高校大数据或Python课程的大作业完整项目包整合了爬虫、数据处理、可视化和分析预测全流程。项目以百万级电影数据为对象覆盖豆瓣Top250、实时票房、短评情感分析等场景适合需要完成课程设计、毕业设计或入门数据挖掘的读者参考。压缩包共45个文件以Python脚本、PNG图表、CSV数据集、TXT说明文档为主另有SQL、Shell、HTML等辅助文件整体仅7.13MB结构清晰便于按模块复用。已有1127人学习或下载。从中可拿到可运行的爬虫与预测代码、电影词云与票房排行图、MapReduce与Hive统计过程记录以及情感分析、评分预测等完整实现思路能帮助快速理解从数据采集到可视化落地的工程化流程。1. Python爬虫数据可视化分析大作业.zip与其搜现成代码不如搞懂这套东西怎么做才不会被问倒打开一个名为“Python爬虫数据可视化分析大作业.zip”的压缩包里面通常是一个包含爬虫脚本、数据文件、可视化图表的课程设计或毕业设计项目。这类大作业的标准路径是选定一个主题用 Python 爬取网站数据做清洗和存储再用可视化库把数据变成图表最后产出一份能讲清楚的分析报告。它面向的是正在修 Python、数据分析或网络编程课程的学生以及想用一个完整项目来检验自己爬虫和可视化能力的开发者。但这类 zip 最容易踩的坑是代码能跑、图能出却经不起答辩时一句「这个数据代表什么」。本文就当着一线工程师的面把这条落地路径完整拆开。2. 爬虫选型与落地先搞清楚数据从哪来再决定怎么写代码做爬虫可视化大作业90% 的人一上来就写代码结果爬到一半发现页面是动态渲染的requests 拿到的是空壳 HTML。这个顺序应该反过来先确认数据源的类型再选爬虫方案。数据源大致分三类——静态 HTML 页面、动态渲染页面、以及直接暴露的 JSON 接口。不同的数据源对应完全不同的抓取策略选错方案后面的重构代价远大于重写一个文件。2.1 静态 HTML 解析requests BeautifulSoup 的最小闭环对付大部分静态网站requests 拿页面 BeautifulSoup 解析是最经典、最不容易出错的组合。我在做课程项目时用这个方案爬过图书网站、新闻列表、天气历史数据。这类页面的特征是按 F12 查看网页源代码能直接看到想要的数据标签。import requests from bs4 import BeautifulSoup headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } resp requests.get(https://example.com/list, headersheaders, timeout10) resp.encoding utf-8 # 有些网站是 gbk需要按实际页面 meta 指定 soup BeautifulSoup(resp.text, html.parser) items soup.select(div.item-list ul li) for it in items[:20]: title it.select_one(a.title).text.strip() date it.select_one(span.date).text.strip() print(title, date)这段代码的要点在 requests 和 BeautifulSoup 的分工requests 只负责把网页源码拿到内存BeautifulSoup 负责从源码里提取结构化字段。select_one返回第一个匹配元素select返回全部匹配列表用 CSS 选择器来定位要比逐层find快得多也更容易维护。headers里的 User-Agent 请求头是礼貌性的浏览器身份声明很多站点会拦截裸 Python 请求头。timeout10也不是随便写的——没有超时时间某个请求卡住会让整个爬虫死等。这个方案的上限是约每秒数次请求足够支撑课程作业量级的数据量。2.2 动态渲染页面Selenium 还是 Playwright如果打开网页源码发现数据不在 HTML 里而是页面加载后才由 JavaScript 填充的那就是另一类问题。最常见的是两种方案Selenium 和 Playwright。Selenium 老牌稳定但启动浏览器慢、占用高Playwright 是后起之秀接口更现代内置等待和自动截图调试。我个人的习惯是新项目优先 Playwright只有课程环境强制要求 Selenium 时才用回它。from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.goto(https://example.com/dynamic) page.wait_for_selector(div.data-row) # 等渲染完 rows page.query_selector_all(div.data-row) for row in rows[:10]: print(row.inner_text()) browser.close()这里最容易翻车的是wait_for_selector用得不够。动态页面渲染有快有慢不加等待直接取元素大概率拿到空列表。等待策略上wait_for_selector比time.sleep(3)更可靠前者是条件触发后者是拍脑袋拍出来的时长。Playwright 的headlessTrue是无头模式即不弹出浏览器窗口适合在服务器或后台跑调试代码时改成headlessFalse能看到每一步在页面上发生了什么这是当时救过我的调试技巧。2.3 反爬应对请求头、Cookie 与限速三板斧目标网站的常规反爬手段大致有三层——校验请求头、校验 Cookie 状态、检测请求频率。对付课程的模拟项目不需要过验证码和指纹识别做好这三板斧已经足够。请求头补全一般需要 User-Agent、Referer、Origin 三者配合Cookie 要先手动登录一次把浏览器里拿到的值粘进代码限速就是每两次请求之间主动 sleep。import time from random import uniform for page_no in range(1, 10): url fhttps://example.com/page/{page_no} headers { User-Agent: Mozilla/5.0, Referer: https://example.com/home } cookies {sessionid: 这里替换成真实会话值} resp requests.get(url, headersheaders, cookiescookies, timeout10) # 解析逻辑... time.sleep(uniform(1, 3)) # 随机间隔比固定 sleep 更不容易触发风控uniform(1,3)的意思是在 1 到 3 秒之间随机取一个值作为间隔。固定间隔会被频率检测模型识别为机器行为随机间隔会让请求节奏更接近真人浏览。这个细节在评分答辩时经常能成为加分点因为它体现了对反爬机制的思考。Cookie 若拿不到退一步的做法是用requests.Session()先请求一次首页再请求列表页Session 会保留服务端下发的 Cookie这也是我遇到过的大多数课程项目的可行解。3. 数据清洗与存储爬下来只是开始能分析才是目的爬虫把数据带回来之后离“可视化分析”还隔着最枯燥但最影响质量的一环清洗与存储。很多大作业在这步草草了事直接把 DataFrame 塞给图表库结果图上出现 2023 年 13 月这种离谱坐标或者空值把折线图拉出断崖。数据清洗不是为了追求完美而是为了不让脏数据在你的可视图里笑话你。3.1 清洗规则空值、重复、类型转换与异常值洗数据的第一要务是看全貌。拿到 DataFrame 后我一般先跑三行代码df.info()查空值分布df.duplicated().sum()查重复量df.describe()看数值列的分布区间。这三行能在一分钟内暴露大多数数据质量问题。空值的处理策略取决于占比占比低于 5% 且是数值列用中位数填充占比高且是描述性文本直接删除该行。重复数据则要区分全行重复和关键字段重复前者直接 drop后者按业务规则保留最新一条。类型转换是另一个重灾区特别是字符串数字混合列异常值要结合主题来定边界比如爬取气温数据出现 300 摄氏度那显然是单位或解析错误。import pandas as pd df pd.read_csv(raw_data.csv) df df.drop_duplicates(subset[title, date]) # 按关键字段去重 df[price] df[price].astype(str).str.replace(¥, ).astype(float) df[date] pd.to_datetime(df[date], errorscoerce) # 非法日期变 NaT df df.dropna(subset[date, price]) # 关键字段为空就删 q1 df[price].quantile(0.25) q3 df[price].quantile(0.75) iqr q3 - q1 df df[(df[price] q1 - 1.5 * iqr) (df[price] q3 1.5 * iqr)]IQR 即四分位距剔除异常值的方法适合价格、销量这类有显著分布边界的字段。这里的quantile方法把数据从小到大排序后切成四段取第 25% 与第 75% 分位点之间的范围再向外放 1.5 倍间距作为合理区间。这个方法在数据量大于几百条时比手动设最大最小值更客观。errorscoerce参数意味着转换失败的值会被置为 NaT之后统一 drop 掉。价格列先转字符串、再替换符号、最后转 float是为了防止“¥12.5”这种混合内容直接转类型报错。3.2 存储选型CSV、SQLite 还是 MySQL存储选型基本看两个约束数据量和交付方式。数据量低于 10 万行且大作业要求提交文件那就直接存 CSV方便老师打开核查数据量高或者程序要反复查询用 SQLite单文件免安装要求学习数据库操作则上 MySQL但注意需要在答辩环境装好服务。我见过不少大作业栽在这里爬了 50 万条数据存 CSV打开 Excel 直接卡死最后又重新入库。CSV 适合交付展示SQLite 适合内部使用。import sqlite3 conn sqlite3.connect(project.db) cur conn.cursor() cur.execute( CREATE TABLE IF NOT EXISTS house_data ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, district TEXT, price REAL, date TEXT ) ) conn.commit() df.to_sql(house_data, conn, if_existsreplace, indexFalse) conn.close()SQLite 连接是一个本地文件不需要启动服务适合课程项目。to_sql是 pandas 提供的一行入库接口if_existsreplace表示表存在时直接替换这在重复跑爬虫场景下很实用调试阶段不要担心丢数据因为数据随时可以重爬。真正要注意的是字段类型设计——price REAL存浮点数district TEXT存文本写进 CREATE TABLE 的注释建立了数据规范。3.3 数据入库的最佳实践字段设计决定分析上限爬虫可视化项目的分析上限一半在爬虫阶段就定死了另一半在字段设计阶段。爬虫时多抓一个字段的成本极低但后续分析时缺一个字段的代价极高。例如爬房价除了价格之外还应记录所在区、户型、面积、挂牌日期缺了面积就没法做单价分析没法画“各区域均价对比”。因此在写爬虫解析代码之前先拿纸列一个目标分析问题清单再由问题倒推字段列表。# 推荐的做法爬取阶段就按目标分析字段来组织 field_map { title: (h3.item-title, lambda t: t.text.strip()), district: (span.district, lambda t: t.text.strip().replace(区域, )), price_text: (span.price, lambda t: t.text.strip()), area: (span.area, lambda t: float(t.text.replace(㎡, ))), date: (span.date, lambda t: t.text.strip()) }这种“选择器 转换函数”的结构最大的好处是把解析规则和清洗规则合并定义。field_map里每个字段对应一个 CSS 选择器和一个 lambda 函数lambda 负责从元素文本里清洗出目标类型。对比在代码里散落大量.strip()和.replace()这种集中式的字段映射让你在答辩前修改规则时只需要改一处。数据入库前的最后一步是跑一次全字段空值统计这会告诉你哪些字段在目标网站上本来就缺失方便分析阶段提前规避。4. 数据可视化分析从图表库选型到输出一个能讲的结论可视化是这类型大作业的颜值担当也是最容易被导师一眼看出敷衍的部分。图表不是越花哨越好关键是每个图都要有存在的理由——能回答某个分析问题。我在这次任务里看到不少项目柱状图、折线图、饼图堆了一屏但问任何一个图“你想说明什么”都答不上来。这个章节就把选库到出图的完整链路理顺。4.1 图表库对比Matplotlib、PyECharts、Plotly 怎么选Python 可视化三件套各有各的适用场景。Matplotlib 是底层库定制能力强但代码量大、默认样式偏学术PyECharts 生成的是 HTML 交互图鼠标悬停有提示适合网页展示和课程答辩Plotly 交互性最强支持缩放、框选、联动但中文环境和离线打包都需要额外配置。大作业的常规推荐是 PyECharts——生成 HTML 文件直接可用浏览器打开不需要依赖 Jupyter 环境提交和展示都方便。Matplotlib 更适合论文插图风格追求答辩现场的演示效果PyECharts 是优选。from pyecharts.charts import Bar from pyecharts import options as opts data df.groupby(district)[price].mean().sort_values() bar ( Bar() .add_xaxis(data.index.tolist()) .add_yaxis(平均价格, [round(v, 2) for v in data.values]) .set_global_opts( title_optsopts.TitleOpts(title各区平均房价对比), yaxis_optsopts.AxisOpts(name价格万元) ) ) bar.render(district_price.html)groupby(district)[price].mean()算出每个区域的价格均值sort_values()排序后传给图表库。PyECharts 的链式调用让配置项集中在set_global_opts里标题、轴名称、图例等都在这一个地方管理。这段代码生成一个独立的 HTML 文件双击即可在浏览器打开且支持鼠标悬停查看精确数值。数据量较大的折线图建议开启datazoom_opts让读者可以缩放时间轴查看局部细节。4.2 可视化图表选型不同分析问题对应不同图图表选型有基本规律可循时间趋势用折线图类别对比用柱状图占比结构用饼图相关关系用散点图数据分布用箱线图。但很多大作业连箱线图都不敢用因为不知道它的价值。箱线图展示一组数据的分布、异常点、四分位数特别适合回答“哪个区域的房价离散程度最大”这类问题。下面是一段用 Matplotlib 画箱线图的示例配合 PyECharts 的柱状图形成互补。import matplotlib.pyplot as plt plt.rcParams[font.sans-serif] [SimHei] # 防止中文乱码 plt.rcParams[axes.unicode_minus] False df.boxplot(columnprice, bydistrict, figsize(12, 6)) plt.title(各区域价格分布箱线图) plt.suptitle() plt.xticks(rotation45) plt.tight_layout() plt.savefig(boxplot.png, dpi150)plt.rcParams两行是 Matplotlib 中文显示的标配前一行指定中文字体为黑体后一行让负号正常显示。箱线图中矩形盒代表从第一四分位数到第三四分位数的范围盒中横线是中位数盒外的点代表异常值。这张图能直接回答“哪个区域价格内部差异最大”的分析问题。分析阶段建议至少产出一张趋势图、一张对比图、一张分布图这组组合在答辩时讲起来有层次。4.3 从图表到结论让分析报告有主线而不是图表的堆砌可视化大作业最常见的翻车现场是报告里每张图旁边只写一句话“从图中可以看出房价在 2023 年整体上升。”这句话等于没分析。一份能被认可的分析报告需要有分析主线先提出一个问题再选择合适的图去佐证最后写出结论与原因推测。答辩评分中“数据洞察”与“编程实现”往往占据同等分量而这正是很多 zip 项目的薄弱环节。分析问题选用图表结论方向示例价格随时间如何变化折线图2023 年 5 月出现明显拐点与政策调整时间吻合哪个类别占比最大饼图/环形图三居室占比超 50%改善型需求占主导两个变量是否相关散点图面积与总价正相关但大户型存在价格分化哪个区域内部差异最大箱线图核心区离散度最大低价与高价并存写分析结论时有一个技巧结论必须包含“数据现象 可能原因 影响”。只描述现象叫看图说话加上原因推测才叫分析。对数据的解读可以结合实际常识但务必说清楚那是推测而不是事实比如“推测与地铁线路开通有关”而不是“因为地铁开通所以涨价”。这种表述方式在答辩时更严谨也不容易被追问倒。图表的布局上优先保证一张图回答一个问题不要把多个变量硬塞在同一张图里展示。5. Python爬虫可视化大作业避坑指南5 个让我翻过车的细节做这类大作业血泪经验往往比教程更有价值。以下 5 个问题是我在帮别人排查项目时反复遇到的也是答辩前最容易暴露的软肋。每条按“现象 → 原因 → 解决”展开方便你对号入座。5.1 爬虫跑到一半被服务器拒绝403/418 状态码现象是爬虫爬了几页之后请求开始返回 403 Forbidden 或 418 Im a teapot有时候是 IP 被临时封锁。原因通常是请求频率过快或者请求头缺失关键字段。解决方法是降频并补全请求头。常见做法是每页之间 sleep 2 到 5 秒同时带上完整的 Accept-Language 和 Referer。频率检测一般有阈值把节奏控制在每秒 0.5 次以内基本安全。除此之外检查代码里是否复用了同一个 Session 对象有些站点会在会话内累积风险分。5.2 爬回来的中文全是乱码编码声明不一致现象是网页源码里文字部分显示为类似中文的乱码。原因是目标页面使用 gbk 或 gb2312 编码而 requests 默认按响应头猜测编码猜错了就会乱。解决方式是打印resp.encoding查看实际编码再手动指定。多数中文旧站点用 gbk指定resp.encoding gbk即可。在解析前先看一眼resp.apparent_encoding这个方法会从字节流中推测实际编码如果它和resp.encoding不一致以apparent_encoding为准。这个排查过程我在很多次项目里重复过基本上编码问题 5 分钟能定位。5.3 数据量大到内存溢出DataFrame 撑爆内存现象是爬完数据后程序报MemoryError或者 Jupyter 直接内核崩溃。原因是把所有数据一次性读进内存且中途没有释放中间对象。解决思路是分块处理。pandas 的read_csv支持chunksize参数逐块读取而不是全量载入爬虫端则每爬完一批就入库而不是全存内存最后一次性写文件。课程项目的数据量一般不会真到几十 GB但每次循环里把大列表 append 到 DataFrame 再重建是常见的内存杀手。养成好习惯爬取循环内直接写 CSV 或 SQLite分析时才把数据 read 回内存。5.4 图表中文显示成方块缺字体或缺配置现象是 Matplotlib 图上所有中文都是空心方块。原因是运行时环境没有找到中文字体或者没有显式配置字体。解决方法是plt.rcParams[font.sans-serif] [SimHei]但要确认系统装了这个字体Linux 环境常需要安装中文字体包较稳妥的做法是用matplotlib.font_manager列出所有可用字体选一个存在的。PyECharts 走的是浏览器渲染不太有这个问题但要注意生成 HTML 的字符编码要为 utf-8否则打开是乱码。5.5 提交前发现爬的数据不全没有校验与断点续爬现象是写报告时发现某个日期范围的数据缺失或某个分类只有一半记录。原因是爬虫没有做完整性校验中断后从头重爬又浪费时间。解决方法是爬取过程中记录一个进度文件每完成一页就更新这样中断后可以从断点继续。同时每爬完一个批次输出统计信息与目标总数比对。示例中我用一个简单的 JSON 记录已完成页码。import json import os progress_file progress.json completed [] if os.path.exists(progress_file): completed json.load(open(progress_file)) for page_no in range(1, 101): if page_no in completed: continue # 爬取逻辑... completed.append(page_no) json.dump(completed, open(progress_file, w))这个断点续爬的写法在课程项目和实际工作中都通用。progress.json记录了已完成的页码重跑时自动跳过已完成的部分。提交前做一个数据量完整性的简单统计例如按日期分组计数看每天的记录数有没有明显断档。这个小习惯在答辩前救了我一次——当时因为网络中断漏了两天数据正是靠进度检查发现的。除了进度文件爬完后再跑一个df[date].value_counts()排序看一眼就能快速定位缺失范围。6. 进阶把大作业从「能跑」升级成「能答辩」的三个验证手段如果你已经走通了从爬虫到可视化的完整链路接下来这一步决定项目能否从“交差”变成“拿得出手”。第一个手段是代码模块化把爬虫、清洗、可视化拆成三个独立脚本让答辩老师能按阶段查看而不是靠一个巨型文件从开头跑到结尾。模块化的另外一个好处是某一段改了之后不需要重跑全流程。# 推荐的项目文件组织结构 project/ ├── crawler.py # 负责数据采集输出 raw_data.csv ├── clean.py # 负责清洗与入库输出 clean_data.db ├── analyze.py # 负责统计分析与可视化输出 HTML/PNG ├── data/ # 存放中间数据文件 └── report/ # 存放生成的图表和说明文档第二个手段是写一个自动验证脚本跑完后检查数据量和图表文件是否生成。比如用os.path.exists确认每个图表文件都在用len(df)确认数据量超过预设阈值。这个验证脚本本身就是工程素养的体现——它证明你有“交付物完整性”的意识这在答辩中非常加分。我当时被问“你怎么知道爬到的数据是完整的”时正是靠这段校验代码顶住了追问。第三个手段是准备 2 到 3 个「为什么」问题为什么选这个数据源、为什么用这种图表、为什么这样清洗。把每个选择背后的理由写成一段话放在报告的附录里。答辩老师大概率不会读完整个报告但一定会针对其中一个图表追一句“为什么”。这时我能讲清楚字段结构从哪来、IQR 规则为什么适用、为什么不用线性插值填充空值整个答辩的质感立刻不一样。最后说一个我自己的习惯每次在 project 里跑完整个流程后我会删掉中间过程生成的缓存文件重新从原始爬虫脚本开始完整执行一遍确认一键能跑通。那些在 IDE 里能跑、换台机器跑不了的项目多半是漏掉了相对路径或依赖声明。requirements.txt里至少列出 requests、pandas、matplotlib、pyecharts 四个库的版本提交时连同一份简短 README 说明“先装依赖、再按顺序运行三个脚本”。这个动作在老师评阅和同学参考时都会省掉大麻烦。这个方向值不值得投入如果目标是快速交作业那照上述路径三五天就能走完如果目标是真正掌握爬虫与数据分析的协作方式那这份 zip 值得你多打磨一轮。至少我自己在做了两三个同类项目之后再去看任何网页都能下意识判断“这个数据适不适合爬、该用什么方式爬”这种判断力是跑十个教程都换不来的。希望帮到你。本文还有配套的精品资源点击获取