1. 毕设选这个题目的真正理由不是爬虫而是完整数据链路如果你在毕业设计或课程设计里看到“基于爬虫技术的新闻聚合平台”这个题目第一反应很可能是先写一个爬虫把新闻抓下来再用 Django 做个页面展示最后交给老师。这个思路不能说错但很容易踩进一个隐藏陷阱——做完之后发现爬虫是爬虫Django 是 DjangoHadoop 是 Hadoop三个模块之间没有任何关系。我见过不少类似的毕设项目爬虫能跑网页也能看但数据量只有几十条Hadoop 只是装了个伪分布式环境最后答辩时老师问“你项目里 Hadoop 起了什么作用”回答变成“存了爬下来的新闻”。如果只是这样那这个项目本质上还是一个“带数据库的爬虫展示页”和「基于爬虫技术的新闻聚合平台」这个题目的预期差了很远。这个题目真正值得做的地方不是“爬虫”而是“完整数据链路”。一条新闻从目标网站的 HTML 页面到被爬虫提取成结构化字段到存入 HDFS再到被离线分析任务统计成热点结果最后通过 Django 渲染成浏览器里可读的新闻聚合页面——这条链路完整跑通才是这个毕设的核心价值。为什么它适合做毕设因为新闻数据天然适合练习数据处理公开、结构半结构化、时效性强、天然有来源、时间、标题、正文、热度等多个维度。你可以从零开始完成一套“采集—清洗—存储—分析—展示”的工程流程每一层都有明确产出也都有话可讲。但也要先说清楚边界这个题目不是给“只想快速出个页面”的人准备的。它的前置门槛包括 Python 基础、Django 项目经验、Linux 常用命令以及愿意在 Hadoop 伪分布式环境上折腾几天的耐心。如果前面这些你还不熟建议先把它当作课程设计级别的练习项目而不是一上来就追求生产级架构。相反如果你已经有一定 Python 基础并且想通过毕设系统接触一次“大数据处理流程”那这个题目会比单纯做“新闻发布管理系统”有价值得多。1.1 为什么新闻聚合平台能同时覆盖爬虫、大数据和 Web 开发这个选题最大的优势是技术栈覆盖面足够广但每一层又没有复杂到完全失控。从业务场景看新闻聚合平台需要做的几件事非常明确从多个新闻网站采集公开信息把网页里的标题、发布时间、来源、正文摘录等字段提取出来将清洗后的数据保存下来形成可供查询和分析的基础数据集统计来源分布、发布时间趋势、关键词热度等信息在 Web 端展示新闻列表、分类、搜索和热点排行。你会发现这天然就是一套数据管道。它不像“电商系统”那样要处理复杂的业务规则也不像“算法模型”那样依赖训练数据和调参经验。它的每一步都有标准答案可循但又不至于幼稚到“一个 CRUD 就能交差”。更重要的是这个选题允许你按自己的进度拆层次先做单机小数据量版本再逐步加 Hadoop 伪分布式先跑通一条新闻再扩展成批量化采集先展示简单列表再叠加统计图表。这种递进式开发非常适合毕设节奏也适合在文档报告里写清楚“我做了哪几步为什么这么做结果是什么”。1.2 Hadoop 在这个题目里到底是为了什么很多人会把 Hadoop 当成一个“简历关键词”放进去仿佛不引入 Hadoop 就显得项目不够高级。但如果你不能在答辩时解释清楚“为什么非用它”那就等于给自己埋了一颗雷。从工程角度看新闻数据有几条特点数量持续增长、来源非常多、格式五花八门、需要批量统计。这恰恰是 HDFS 和 MapReduce 的经典场景。HDFS 负责把大量原始新闻文件分布式存起来MapReduce 负责离线批量统计比如按来源站点统计新闻数量、按时间窗口统计发布趋势、对正文做简单的关键词频次统计。当然如果你的毕设数据量只有几百条Django 直接读 MySQL 反而更简单。但引入 Hadoop 的意义不在于“当前这个演示数据量必须用它”而在于“你把一套面向大数据量的处理流程模拟了出来”。所以在实际项目中更稳妥的做法是让爬虫产出的数据既导入 MySQL 用于 Web 端快速查询也以文件形式放到 HDFS 上用于离线分析再把分析结果导回 MySQL。这样 Hadoop 就不是一个摆设而是真正参与了数据链路。在单机环境里Hadoop 伪分布式模式足够做毕设演示。它可以跑 HDFS 文件上传下载也可以运行 MapReduce 任务或 Hive 查询。缺点是内存开销比较大启动时如果电脑只有 8G 内存会比较吃力。因此建议先在最小配置下启动确认日志正常再逐步加数据。1.3 这个题目适合哪些人不适合哪些人我把它拆成一个比较直白的判断标准适合你想通过一次完整的项目实践理解“爬虫到数据仓库再到前端展示”到底是怎么串起来的你有耐心处理环境问题你愿意花时间做数据清洗和日志排错。不适合你只想尽快出一个能演示的网页不想折腾 Hadoop你对 Python 基础语法还不太熟你不准备写文档只想把代码跑起来。如果从就业角度看这组技术栈也很有意思。Python 爬虫对应数据采集岗位的基础技能Hadoop 对应大数据入门Django 对应 Web 后端。虽然它不等于“精通大数据”但能证明你有过从零搭建完整数据管道的经验这在面试初级数据开发或 Python 后端岗位时是能讲出细节的。2. 整体架构怎么搭从新闻网页到前端展示的数据流向在设计一个毕设项目时最忌讳的是一上来就写代码。正确的顺序是先画数据流再确定每一层的输入和输出然后再动手实现。哪怕你的架构图只是一个简单的框图也能帮你避免“写到一半发现各模块接不上”的尴尬。2.1 系统分层与数据流向这个项目可以分成五层每一层都只和上下游交换特定格式的数据。层核心职责常用技术选型采集层从新闻网站抓取 HTML 或 API 数据Requests / Scrapy / BeautifulSoup清洗层提取字段、去重、格式化Python 脚本文本处理存储层保存原始数据和分析结果HDFS、MySQL、SQLite可选项分析层统计来源分布、热词、时间趋势MapReduce / Hive展示层新闻列表、搜索、热榜、管理后台Django、HTML CSS JavaScript整体数据流向是这样的爬虫请求目标新闻网站获取页面内容解析页面提取标题、链接、发布时间、来源等字段做基本清洗去掉重复 URL、残缺字段和无效内容将清洗后的数据以结构化格式保存比如 JSON / CSV / 数据库把文件导入 HDFS启动 MapReduce 或 Hive 任务做离线统计将统计结果导出回 MySQLDjango 读取 MySQL 渲染新闻页面。在这个流程里最关键的设计决策是不要让爬虫直接往 Django 的数据库里写数据而是先落到一个“中间态”。这样做的原因很实际爬虫抓到的数据需要检查、清洗、去重直接写入最终表会让 Web 端数据和统计逻辑混在一起出了问题很难排查。2.2 为什么中间要加“清洗”和“暂时存储”很多同学会问“我能不能爬虫直接入库Django 直接读”答案是可以但那会把项目变成一个“展示爬虫抓取内容的站点”而不是“新闻聚合平台”。真正的新闻聚合平台必须有数据从采集到分析的过程而不是简单搬运网页。加一层“暂时存储”的好处有三个第一你可以不依赖目标网站当前状态来做演示。爬虫可能会因为目标网站改版、网络波动、反爬策略而临时失效但只要你把最近一次成功采集的数据留在中间层页面展示就有数据可用。这能避免答辩现场突然拿不出内容的尴尬。第二数据清洗可以独立调试。你可以先跑一个页面打印出解析出来的字段确认标题、时间、正文是否提取正确再决定是否发起批量抓取。如果直接入库调试成本会高很多。第三Hadoop 需要的是文件而不是数据库记录。你最终要把数据导入 HDFS清洗后的 JSON 或 CSV 文件是最自然的中间格式。如果你坚持“爬虫直接写 MySQL”再去 MySQL 导出文件到 HDFS反而多了一道转换过程。2.3 环境准备建议如果你准备按完整链路落地我建议先用一台 Linux 虚拟机或自己的电脑完成以下准备Python 3.8 以上建议使用venv或conda创建独立虚拟环境Django 3.2 或 4.x根据你自己熟悉的版本选一个不要追新Hadoop 3.x 伪分布式或者用 Docker 镜像跑一个单节点 Hadoop降低环境配置成本MySQL 开启用于最终展示数据如果用 Scrapy还需要安装 Scrapy 及相关依赖。这里最大的坑是版本匹配。Hadoop 依赖 Java 环境Java 版本和 Hadoop 版本有对应关系Django 又依赖 Python 版本。如果这些版本不匹配你会浪费大量时间在启动报错上。建议不要在自己不熟悉的环境上直接追求“全分布式”。毕设场景下Hadoop 伪分布式已经完全够用。你要证明的是你对架构的理解而不是真的搭了一个几十台机器的大数据集群。3. 爬虫模块先跑通目标站点再谈稳定采集爬虫是新闻聚合平台的第一入口也是最容易出问题的模块。很多人的毕设失败不是因为 Hadoop 没配好而是爬虫在演示前一天突然失效了。原因往往是前期太依赖“能跑一次”忽略了后面几个关键点。3.1 用什么框架写爬虫常见的选择有两个Requests BeautifulSoup或者 Scrapy。Requests BeautifulSoup 更轻量可以按自己的思路一步一步写对新手友好也容易在答辩时讲清逻辑。缺点是要自己处理并发、重试、去重等细节。Scrapy 更像一个工程化框架自带调度器、下载中间件、去重和 Item Pipeline适合做批量采集。缺点是在开始之前需要学框架概念初期上手成本稍高。我个人的建议是如果你只是做毕设并且不打算以后深入爬虫开发用 Requests BeautifulSoup 就够了。它代码逻辑直观每一条请求和解析你都能讲明白。如果你已经熟悉 Scrapy那就直接用 Scrapy它工程化程度更高给人感觉也更“完整”。无论选哪一种这里最关键的不是框架本身而是你是否知道“数据从哪里来要提取哪些字段怎么验证提取结果”。3.2 抓取目标站点前先想清三个问题在写任何代码前先回答三个问题你要抓哪几个站点建议不要超过 3 到 5 个并且优先选择结构稳定、更新频率正常的公开新闻站。你需要的字段是什么标题、URL、发布时间、来源、正文摘要这是最基础的一组。如果你想做热词分析还需要至少保存正文或正文摘要。你如何判断一条新闻是“新的”简单做法是记录 URL 的 MD5 值或直接用 URL 字段查重。更稳妥的做法是保存新闻发布时间并设置采集的时间窗口。这里特别提醒爬虫过程中一定要遵守 robots 协议控制访问频率不要对目标站点造成访问压力。毕设代码里尽量加一个下载延迟比如time.sleep(random.uniform(1, 3))。这样既显得专业也能减少触发反爬机制的概率。3.3 一个最小可用的解析示例如果用 Requests BeautifulSoup常见的伪代码结构是这样的import requests from bs4 import BeautifulSoup url https://example.com/news headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } resp requests.get(url, headersheaders, timeout10) resp.encoding resp.apparent_encoding soup BeautifulSoup(resp.text, html.parser) for item in soup.select(div.news-item): title item.select_one(h2 a).get_text(stripTrue) link item.select_one(h2 a).get(href) pub_time item.select_one(span.time).get_text(stripTrue) print(title, link, pub_time)这只是一个示例结构不同站点的页面结构差异非常大。实际开发时你需要先用浏览器开发者工具查看目标页面的 HTML确认标题、链接、时间对应的选择器再写解析逻辑。这里最容易踩的坑是你以为页面里有某个字段但某些文章没有配图、没有摘要、没有时间导致None值异常。因此解析后一定要做字段校验缺失字段的新闻可以跳过或标记为“待补全”不要直接崩掉整个任务。3.4 从“能爬一次”到“能稳定爬”的四个关键点增量爬取每次抓取前先查询已有 URL 集合只抓新出现的内容。如果每次全量抓数据量一大去重和清洗都会变成灾难。异常隔离单条新闻解析失败要记录日志然后继续下一条。不要因为一个页面结构变化就导致整个采集任务中断。日志完整每个字段是否解析成功、请求是否超时、重试了几次都要有日志。日志是后面对抗改版和反爬的核心依据。频率可控爬虫要像一个礼貌的访客而不是一个暴力扫描器。随机延时、并发数限制、失败重试次数都要设置合理值。在毕设项目里你不需要追求实时采集。我建议设置一个“手动触发”或“每天定时一次”的采集任务把最近几百条新闻抓下来清洗后存成分好类的数据文件。这样既满足功能要求又不会给自己的开发带来太多运维负担。4. Hadoop 存储与分析让海量新闻数据“接得住、算得动”到了 Hadoop 这一层很多同学会突然停滞因为环境配置和思想转换都比较陌生。你需要从“关系型数据库”切换到“分布式文件系统 离线计算”这套思维方式。4.1 数据怎么进 HDFS爬虫清洗后的数据最简单的落地格式是 JSON 或 CSV。每条新闻一行字段统一。然后使用 HDFS 命令上传到 HDFS 指定目录。常见命令示例hdfs dfs -mkdir -p /news/raw hdfs dfs -put ./news_2025.json /news/raw/ hdfs dfs -ls /news/raw/如果你用的是本地 Hadoop 伪分布式以上命令需要在 Hadoop 环境配置完成后执行。如果不想在命令行里操作也可以写一个小的 Python 脚本调用 HDFS 命令行接口但毕设阶段直接敲命令展示效果更直观。这里建议把 HDFS 目录分成几层/news/raw存放爬虫导出的原始清洗文件/news/analysis存放分析任务产生的结果文件/news/tmp存放临时中间文件。目录结构清晰后续写文档时也更容易描述。4.2 用 MapReduce 或 Hive 做什么分析Hadoop 层面的核心价值是批量分析。回到新闻场景最经典的分析任务有三个统计每个新闻来源站点的新闻数量按小时/天统计新闻发布时间分布对新闻标题或正文做中文分词统计高频热词。第一个任务最简单MapReduce 的 Map 阶段把来源字段作为 key输出 1Reduce 阶段把相同 key 的值加起来得到统计结果。第二个任务思路类似只是 key 变成时间字段。第三个任务稍微复杂需要引入中文分词库但如果用 Hive 配合自定义 UDF 也能做。如果选用 Hive还可以直接用 SQL 完成统计SELECT source, COUNT(*) AS cnt FROM news_table GROUP BY source ORDER BY cnt DESC;这是我更推荐的方式因为 Hive 的 SQL 表达门槛比手写 MapReduce 低很多而且讲解起来也更方便。当然如果你的课程要求必须用 MapReduce那手写一个 WordCount 或 SourceCount 也是可以的代码量不大。4.3 不要把 Hadoop 变成“多余的中间层”这里要讲一个非常重要的判断Hadoop 不是摆在那里就够的它必须和你的数据、分析任务产生实际连接。如果你的数据量只有 100 条Hadoop 的分布式优势完全体现不出来这在答辩时很容易被追问。因此你要主动想清楚并准备好回答“为什么这个场景适合 Hadoop”新闻数据会持续增长未来可能有多个来源、每天几十万条大量历史新闻需要离线批量统计适合 MapReduce 这种“计算移动到数据”的模型使用 HDFS 可以把采集到的原始文件统一保存后续可以再跑新的分析任务而不需要重新爬取数据。这并不意味着 Hadoop 比 MySQL 快。它更适合的是“大规模、离线、批处理”的场景。如果你的项目只要展示“今天有哪些新闻”MySQL 就够了但如果你想做“过去一年所有新闻来源的趋势分析”Hadoop 就有说服力了。所以设计分析任务时尽量做一个“不可能用几条数据完成”的统计比如跨多天、多站点的聚合这样 Hadoop 的存在感才会更自然。如果你觉得伪分布式 Hadoop 内存压力太大也可以换一种实现方式只在 Docker 容器里跑 HDFS用命令行展示上传和下载再用 Hive 跑一个查询。这样既能讲清流程又避免本地环境做太多复杂配置。5. Django 展示端把离线结果变成用户能看的新闻聚合页Django 是这个项目里离用户最近的一层也是最终呈现成果的地方。它本身不难难的是如何把前面几层的数据结果统一整合到页面上。5.1 Django 项目结构怎么设计在动手写模型之前建议先把 Django 项目按职责分成几个 app。一个典型的划分方式是这样的collector负责采集任务的触发、查看采集日志news负责新闻数据模型和列表页、详情页analysis负责展示分析结果比如热词排行、来源统计。这种划分不是为了“看起来专业”而是为了让代码逻辑不纠缠在一起。采集任务属于后台逻辑新闻展示属于前台逻辑分析结果属于统计逻辑三个 app 各管各的后续维护也好定位问题。一个简化版新闻模型可以写成这样from django.db import models class News(models.Model): title models.CharField(max_length255) url models.URLField(uniqueTrue) source models.CharField(max_length100) pub_time models.DateTimeField() summary models.TextField(blankTrue) content models.TextField(blankTrue) created_at models.DateTimeField(auto_now_addTrue) def __str__(self): return self.title这个模型的url字段设置成uniqueTrue可以用数据库层去重。但你也要留意如果爬虫数据量非常大数据库层的 unique 约束会造成插入冲突所以实际编码时通常先用 URL 查一次再插入或者用update_or_create。毕设的数据量通常不会太大直接在逻辑里去重即可。5.2 数据展示的核心页面Django 端需要实现的页面不必太花哨但要把核心功能做完整首页展示最新新闻列表分页显示分类/来源页按来源或分类筛选新闻搜索页按标题或正文关键词搜索热榜页展示来源统计、热词排行、发布时间趋势。如果你希望页面更好看可以直接用 Bootstrap 或简单的前端模板。不要在这一层浪费时间做复杂交互重点是演示数据流。关于热词统计结果我建议在 Hadoop 分析完成后把结果导出到一个 MySQL 结果表Django 再读取这张表。这样 Django 端不用直接访问 HDFS实现起来简单稳定。5.3 部署和演示时的几个注意点本地开发时python manage.py runserver就能启动但你要提前确认以下事项数据库是否已经完成migrate采集任务产生的数据文件路径是否和中间层脚本一致如果部署到服务器需要处理ALLOWED_HOSTS、静态文件收集、数据库备份等问题如果你用宝塔面板部署 Django注意 Python 版本和虚拟环境路径。演示之前最好准备一份“演示流程卡”大约长这样打开爬虫脚本抓取最近 100 条新闻检查清洗结果 JSON 文件把文件上传到 HDFS运行统计任务输出各来源数量把分析结果导入 MySQL刷新 Django 页面看到最新数据和榜单。按照这个顺序演示评委能很快理解你做了什么而不是看到一堆报错和“手动补数据”。6. 从演示到答辩必须提前排查的 5 类环境与工程问题毕设项目最怕的不是代码丑而是演示现场起不来。下面这 5 类问题建议你提前排查一遍。6.1 Hadoop 环境类问题Hadoop 伪分布式配置的核心文件是core-site.xml、hdfs-site.xml、yarn-site.xml。如果你是第一次配置最容易遇到三类问题启动后 NameNode 或 DataNode 进程没有起来通常是因为端口被占用或格式化多次导致数据目录冲突文件上传时报 permission denied常见原因是当前 Linux 用户和 HDFS 的权限不匹配内存不够Java 进程被系统杀掉。建议调小 Hadoop 各进程的内存参数或直接用 Docker 单节点镜像。排查顺序先看jps进程列表再查日志最后检查配置不要盲目重装。6.2 Python 和 Django 版本类问题Django 版本和 Python 版本有对应关系比如 Django 4.x 要求 Python 3.8 以上。如果你在虚拟环境里安装依赖最好固定版本号写成requirements.txt避免换机器后 package 版本不一致。另外Python 爬虫脚本里的requests、beautifulsoup4也需要保持版本一致。不要小看这一点很多项目跑不起来都是因为环境里装的包版本冲突。6.3 数据清洗和中文编码问题新闻数据最容易出问题的是中文乱码和时间格式不统一。抓取响应后要设置正确的编码比如resp.encoding resp.apparent_encoding写入文件时统一用 UTF-8。时间字段要尽量统一成datetime类型或YYYY-MM-DD HH:MM:SS格式否则后续按时间聚合会很痛苦。去重时要注意 URL 可能带参数最好先做归一化处理比如去掉utm_*等跟踪参数。6.4 演示稳定性和性能类问题答辩演示时不要反复跑爬虫。爬虫是有不确定性的网络延迟、目标网站改版、反爬频繁都可能让它失败。更稳妥的做法是提前把数据抓好存成离线文件演示时手动触发一次“从文件到分析结果”的流程而不是现场访问目标网站。如果你确实想演示实时抓取建议提前准备备用站点。一个站点失败立即切换到另一个站点不要让全场观众盯着你的报错日志。并发和性能方面不要在演示机上开太多进程。建议爬虫用单线程或少量线程MapReduce 用默认配置Django 用runserver即可。毕设重点是流程不是性能压测。6.5 答辩时会被追问的问题你至少要能回答以下五类问题为什么选这个选题你的系统解决了什么问题为什么用 Hadoop为什么不用 MySQL 直接存你的爬虫如何应对目标网站改版和反爬你的数据清洗规则是什么如何处理脏数据如果数据量从一千条变成一千万条系统哪里会先成为瓶颈回答这些问题不需要背答案而是要回到你的设计文档和数据流上去解释。只要能说清楚“每一层解决了什么问题换一种方案会有什么不同”就已经足够有说服力了。7. 把毕设做成“能讲清楚”的项目一套可复用的收尾框架最后我想分享一套收尾框架。它不只是给这个新闻聚合平台用的也可以迁移到很多数据类毕设项目上。7.1 从最小闭环到完整链路的四个阶段不要一开始就想做到“采集、分析、展示全部最优”。我建议按下面四个阶段推进第一阶段用 Requests Django SQLite 做出一个最小闭环。手动在数据库里插入 20 条新闻页面能展示出来。第二阶段接入爬虫替换手动数据跑通自动采集到入库的流程。第三阶段接入 Hadoop把清洗后的新闻文件上传 HDFS跑通一个 MapReduce 或 Hive 统计任务并把结果导回 MySQL。第四阶段补做日志、异常处理、去重、文档报告和演示流程。每完成一个阶段你都拥有一个可独立演示的成果。即使最后 Hadoop 没能完美跑通你也至少有一个能展示的新闻平台但如果 Hadoop 跑通了你的项目会明显比同组同学多一个层次。7.2 评判毕设质量的四个标准做完之后你可以用四个问题来检查自己数据流是否完整一条新闻数据能不能从目标网站一路走到前端页面中间每一跳都是真实流转而不是写死的手工数据代码是否可讲每个模块的核心逻辑你是否都能画出输入输出说清为什么这样设计异常是否可控万一爬虫失败、HDFS 没启动、数据库连不上你是否能通过日志快速定位问题文档是否可复现换一台电脑别人能否按你的文档把项目跑起来这比代码本身更能反映你的工程能力。7.3 最后再说一句这个项目做完之后你能收获的最有价值的东西不是“我会用 Scrapy 了”或“我配好了 Hadoop”而是你经历过一次“把一个复杂问题拆成采集、存储、计算、展示四层然后逐层打通”的完整过程。以后不管是做数据开发、后端开发还是继续做更复杂的大数据项目这种分层拆解和链路联调的能力都会持续起作用。所以写代码的时候不要急环境出问题也不要慌。把每个模块的输入和输出想清楚把每一次报错当作一次排查练习你就能把一个题目从“能跑”做成“能讲清楚”。如果现在的你正准备开始这个题我的建议只有一条先不要管 Hadoop也不要管 Django先写一个爬虫抓 10 条新闻打印到屏幕上。等这 10 条数据变成你想要的格式再一步一步往下走。新闻聚合平台的起点永远是那条最不起眼、但真实存在的数据。
基于爬虫与Hadoop的新闻聚合平台毕设实战指南
1. 毕设选这个题目的真正理由不是爬虫而是完整数据链路如果你在毕业设计或课程设计里看到“基于爬虫技术的新闻聚合平台”这个题目第一反应很可能是先写一个爬虫把新闻抓下来再用 Django 做个页面展示最后交给老师。这个思路不能说错但很容易踩进一个隐藏陷阱——做完之后发现爬虫是爬虫Django 是 DjangoHadoop 是 Hadoop三个模块之间没有任何关系。我见过不少类似的毕设项目爬虫能跑网页也能看但数据量只有几十条Hadoop 只是装了个伪分布式环境最后答辩时老师问“你项目里 Hadoop 起了什么作用”回答变成“存了爬下来的新闻”。如果只是这样那这个项目本质上还是一个“带数据库的爬虫展示页”和「基于爬虫技术的新闻聚合平台」这个题目的预期差了很远。这个题目真正值得做的地方不是“爬虫”而是“完整数据链路”。一条新闻从目标网站的 HTML 页面到被爬虫提取成结构化字段到存入 HDFS再到被离线分析任务统计成热点结果最后通过 Django 渲染成浏览器里可读的新闻聚合页面——这条链路完整跑通才是这个毕设的核心价值。为什么它适合做毕设因为新闻数据天然适合练习数据处理公开、结构半结构化、时效性强、天然有来源、时间、标题、正文、热度等多个维度。你可以从零开始完成一套“采集—清洗—存储—分析—展示”的工程流程每一层都有明确产出也都有话可讲。但也要先说清楚边界这个题目不是给“只想快速出个页面”的人准备的。它的前置门槛包括 Python 基础、Django 项目经验、Linux 常用命令以及愿意在 Hadoop 伪分布式环境上折腾几天的耐心。如果前面这些你还不熟建议先把它当作课程设计级别的练习项目而不是一上来就追求生产级架构。相反如果你已经有一定 Python 基础并且想通过毕设系统接触一次“大数据处理流程”那这个题目会比单纯做“新闻发布管理系统”有价值得多。1.1 为什么新闻聚合平台能同时覆盖爬虫、大数据和 Web 开发这个选题最大的优势是技术栈覆盖面足够广但每一层又没有复杂到完全失控。从业务场景看新闻聚合平台需要做的几件事非常明确从多个新闻网站采集公开信息把网页里的标题、发布时间、来源、正文摘录等字段提取出来将清洗后的数据保存下来形成可供查询和分析的基础数据集统计来源分布、发布时间趋势、关键词热度等信息在 Web 端展示新闻列表、分类、搜索和热点排行。你会发现这天然就是一套数据管道。它不像“电商系统”那样要处理复杂的业务规则也不像“算法模型”那样依赖训练数据和调参经验。它的每一步都有标准答案可循但又不至于幼稚到“一个 CRUD 就能交差”。更重要的是这个选题允许你按自己的进度拆层次先做单机小数据量版本再逐步加 Hadoop 伪分布式先跑通一条新闻再扩展成批量化采集先展示简单列表再叠加统计图表。这种递进式开发非常适合毕设节奏也适合在文档报告里写清楚“我做了哪几步为什么这么做结果是什么”。1.2 Hadoop 在这个题目里到底是为了什么很多人会把 Hadoop 当成一个“简历关键词”放进去仿佛不引入 Hadoop 就显得项目不够高级。但如果你不能在答辩时解释清楚“为什么非用它”那就等于给自己埋了一颗雷。从工程角度看新闻数据有几条特点数量持续增长、来源非常多、格式五花八门、需要批量统计。这恰恰是 HDFS 和 MapReduce 的经典场景。HDFS 负责把大量原始新闻文件分布式存起来MapReduce 负责离线批量统计比如按来源站点统计新闻数量、按时间窗口统计发布趋势、对正文做简单的关键词频次统计。当然如果你的毕设数据量只有几百条Django 直接读 MySQL 反而更简单。但引入 Hadoop 的意义不在于“当前这个演示数据量必须用它”而在于“你把一套面向大数据量的处理流程模拟了出来”。所以在实际项目中更稳妥的做法是让爬虫产出的数据既导入 MySQL 用于 Web 端快速查询也以文件形式放到 HDFS 上用于离线分析再把分析结果导回 MySQL。这样 Hadoop 就不是一个摆设而是真正参与了数据链路。在单机环境里Hadoop 伪分布式模式足够做毕设演示。它可以跑 HDFS 文件上传下载也可以运行 MapReduce 任务或 Hive 查询。缺点是内存开销比较大启动时如果电脑只有 8G 内存会比较吃力。因此建议先在最小配置下启动确认日志正常再逐步加数据。1.3 这个题目适合哪些人不适合哪些人我把它拆成一个比较直白的判断标准适合你想通过一次完整的项目实践理解“爬虫到数据仓库再到前端展示”到底是怎么串起来的你有耐心处理环境问题你愿意花时间做数据清洗和日志排错。不适合你只想尽快出一个能演示的网页不想折腾 Hadoop你对 Python 基础语法还不太熟你不准备写文档只想把代码跑起来。如果从就业角度看这组技术栈也很有意思。Python 爬虫对应数据采集岗位的基础技能Hadoop 对应大数据入门Django 对应 Web 后端。虽然它不等于“精通大数据”但能证明你有过从零搭建完整数据管道的经验这在面试初级数据开发或 Python 后端岗位时是能讲出细节的。2. 整体架构怎么搭从新闻网页到前端展示的数据流向在设计一个毕设项目时最忌讳的是一上来就写代码。正确的顺序是先画数据流再确定每一层的输入和输出然后再动手实现。哪怕你的架构图只是一个简单的框图也能帮你避免“写到一半发现各模块接不上”的尴尬。2.1 系统分层与数据流向这个项目可以分成五层每一层都只和上下游交换特定格式的数据。层核心职责常用技术选型采集层从新闻网站抓取 HTML 或 API 数据Requests / Scrapy / BeautifulSoup清洗层提取字段、去重、格式化Python 脚本文本处理存储层保存原始数据和分析结果HDFS、MySQL、SQLite可选项分析层统计来源分布、热词、时间趋势MapReduce / Hive展示层新闻列表、搜索、热榜、管理后台Django、HTML CSS JavaScript整体数据流向是这样的爬虫请求目标新闻网站获取页面内容解析页面提取标题、链接、发布时间、来源等字段做基本清洗去掉重复 URL、残缺字段和无效内容将清洗后的数据以结构化格式保存比如 JSON / CSV / 数据库把文件导入 HDFS启动 MapReduce 或 Hive 任务做离线统计将统计结果导出回 MySQLDjango 读取 MySQL 渲染新闻页面。在这个流程里最关键的设计决策是不要让爬虫直接往 Django 的数据库里写数据而是先落到一个“中间态”。这样做的原因很实际爬虫抓到的数据需要检查、清洗、去重直接写入最终表会让 Web 端数据和统计逻辑混在一起出了问题很难排查。2.2 为什么中间要加“清洗”和“暂时存储”很多同学会问“我能不能爬虫直接入库Django 直接读”答案是可以但那会把项目变成一个“展示爬虫抓取内容的站点”而不是“新闻聚合平台”。真正的新闻聚合平台必须有数据从采集到分析的过程而不是简单搬运网页。加一层“暂时存储”的好处有三个第一你可以不依赖目标网站当前状态来做演示。爬虫可能会因为目标网站改版、网络波动、反爬策略而临时失效但只要你把最近一次成功采集的数据留在中间层页面展示就有数据可用。这能避免答辩现场突然拿不出内容的尴尬。第二数据清洗可以独立调试。你可以先跑一个页面打印出解析出来的字段确认标题、时间、正文是否提取正确再决定是否发起批量抓取。如果直接入库调试成本会高很多。第三Hadoop 需要的是文件而不是数据库记录。你最终要把数据导入 HDFS清洗后的 JSON 或 CSV 文件是最自然的中间格式。如果你坚持“爬虫直接写 MySQL”再去 MySQL 导出文件到 HDFS反而多了一道转换过程。2.3 环境准备建议如果你准备按完整链路落地我建议先用一台 Linux 虚拟机或自己的电脑完成以下准备Python 3.8 以上建议使用venv或conda创建独立虚拟环境Django 3.2 或 4.x根据你自己熟悉的版本选一个不要追新Hadoop 3.x 伪分布式或者用 Docker 镜像跑一个单节点 Hadoop降低环境配置成本MySQL 开启用于最终展示数据如果用 Scrapy还需要安装 Scrapy 及相关依赖。这里最大的坑是版本匹配。Hadoop 依赖 Java 环境Java 版本和 Hadoop 版本有对应关系Django 又依赖 Python 版本。如果这些版本不匹配你会浪费大量时间在启动报错上。建议不要在自己不熟悉的环境上直接追求“全分布式”。毕设场景下Hadoop 伪分布式已经完全够用。你要证明的是你对架构的理解而不是真的搭了一个几十台机器的大数据集群。3. 爬虫模块先跑通目标站点再谈稳定采集爬虫是新闻聚合平台的第一入口也是最容易出问题的模块。很多人的毕设失败不是因为 Hadoop 没配好而是爬虫在演示前一天突然失效了。原因往往是前期太依赖“能跑一次”忽略了后面几个关键点。3.1 用什么框架写爬虫常见的选择有两个Requests BeautifulSoup或者 Scrapy。Requests BeautifulSoup 更轻量可以按自己的思路一步一步写对新手友好也容易在答辩时讲清逻辑。缺点是要自己处理并发、重试、去重等细节。Scrapy 更像一个工程化框架自带调度器、下载中间件、去重和 Item Pipeline适合做批量采集。缺点是在开始之前需要学框架概念初期上手成本稍高。我个人的建议是如果你只是做毕设并且不打算以后深入爬虫开发用 Requests BeautifulSoup 就够了。它代码逻辑直观每一条请求和解析你都能讲明白。如果你已经熟悉 Scrapy那就直接用 Scrapy它工程化程度更高给人感觉也更“完整”。无论选哪一种这里最关键的不是框架本身而是你是否知道“数据从哪里来要提取哪些字段怎么验证提取结果”。3.2 抓取目标站点前先想清三个问题在写任何代码前先回答三个问题你要抓哪几个站点建议不要超过 3 到 5 个并且优先选择结构稳定、更新频率正常的公开新闻站。你需要的字段是什么标题、URL、发布时间、来源、正文摘要这是最基础的一组。如果你想做热词分析还需要至少保存正文或正文摘要。你如何判断一条新闻是“新的”简单做法是记录 URL 的 MD5 值或直接用 URL 字段查重。更稳妥的做法是保存新闻发布时间并设置采集的时间窗口。这里特别提醒爬虫过程中一定要遵守 robots 协议控制访问频率不要对目标站点造成访问压力。毕设代码里尽量加一个下载延迟比如time.sleep(random.uniform(1, 3))。这样既显得专业也能减少触发反爬机制的概率。3.3 一个最小可用的解析示例如果用 Requests BeautifulSoup常见的伪代码结构是这样的import requests from bs4 import BeautifulSoup url https://example.com/news headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } resp requests.get(url, headersheaders, timeout10) resp.encoding resp.apparent_encoding soup BeautifulSoup(resp.text, html.parser) for item in soup.select(div.news-item): title item.select_one(h2 a).get_text(stripTrue) link item.select_one(h2 a).get(href) pub_time item.select_one(span.time).get_text(stripTrue) print(title, link, pub_time)这只是一个示例结构不同站点的页面结构差异非常大。实际开发时你需要先用浏览器开发者工具查看目标页面的 HTML确认标题、链接、时间对应的选择器再写解析逻辑。这里最容易踩的坑是你以为页面里有某个字段但某些文章没有配图、没有摘要、没有时间导致None值异常。因此解析后一定要做字段校验缺失字段的新闻可以跳过或标记为“待补全”不要直接崩掉整个任务。3.4 从“能爬一次”到“能稳定爬”的四个关键点增量爬取每次抓取前先查询已有 URL 集合只抓新出现的内容。如果每次全量抓数据量一大去重和清洗都会变成灾难。异常隔离单条新闻解析失败要记录日志然后继续下一条。不要因为一个页面结构变化就导致整个采集任务中断。日志完整每个字段是否解析成功、请求是否超时、重试了几次都要有日志。日志是后面对抗改版和反爬的核心依据。频率可控爬虫要像一个礼貌的访客而不是一个暴力扫描器。随机延时、并发数限制、失败重试次数都要设置合理值。在毕设项目里你不需要追求实时采集。我建议设置一个“手动触发”或“每天定时一次”的采集任务把最近几百条新闻抓下来清洗后存成分好类的数据文件。这样既满足功能要求又不会给自己的开发带来太多运维负担。4. Hadoop 存储与分析让海量新闻数据“接得住、算得动”到了 Hadoop 这一层很多同学会突然停滞因为环境配置和思想转换都比较陌生。你需要从“关系型数据库”切换到“分布式文件系统 离线计算”这套思维方式。4.1 数据怎么进 HDFS爬虫清洗后的数据最简单的落地格式是 JSON 或 CSV。每条新闻一行字段统一。然后使用 HDFS 命令上传到 HDFS 指定目录。常见命令示例hdfs dfs -mkdir -p /news/raw hdfs dfs -put ./news_2025.json /news/raw/ hdfs dfs -ls /news/raw/如果你用的是本地 Hadoop 伪分布式以上命令需要在 Hadoop 环境配置完成后执行。如果不想在命令行里操作也可以写一个小的 Python 脚本调用 HDFS 命令行接口但毕设阶段直接敲命令展示效果更直观。这里建议把 HDFS 目录分成几层/news/raw存放爬虫导出的原始清洗文件/news/analysis存放分析任务产生的结果文件/news/tmp存放临时中间文件。目录结构清晰后续写文档时也更容易描述。4.2 用 MapReduce 或 Hive 做什么分析Hadoop 层面的核心价值是批量分析。回到新闻场景最经典的分析任务有三个统计每个新闻来源站点的新闻数量按小时/天统计新闻发布时间分布对新闻标题或正文做中文分词统计高频热词。第一个任务最简单MapReduce 的 Map 阶段把来源字段作为 key输出 1Reduce 阶段把相同 key 的值加起来得到统计结果。第二个任务思路类似只是 key 变成时间字段。第三个任务稍微复杂需要引入中文分词库但如果用 Hive 配合自定义 UDF 也能做。如果选用 Hive还可以直接用 SQL 完成统计SELECT source, COUNT(*) AS cnt FROM news_table GROUP BY source ORDER BY cnt DESC;这是我更推荐的方式因为 Hive 的 SQL 表达门槛比手写 MapReduce 低很多而且讲解起来也更方便。当然如果你的课程要求必须用 MapReduce那手写一个 WordCount 或 SourceCount 也是可以的代码量不大。4.3 不要把 Hadoop 变成“多余的中间层”这里要讲一个非常重要的判断Hadoop 不是摆在那里就够的它必须和你的数据、分析任务产生实际连接。如果你的数据量只有 100 条Hadoop 的分布式优势完全体现不出来这在答辩时很容易被追问。因此你要主动想清楚并准备好回答“为什么这个场景适合 Hadoop”新闻数据会持续增长未来可能有多个来源、每天几十万条大量历史新闻需要离线批量统计适合 MapReduce 这种“计算移动到数据”的模型使用 HDFS 可以把采集到的原始文件统一保存后续可以再跑新的分析任务而不需要重新爬取数据。这并不意味着 Hadoop 比 MySQL 快。它更适合的是“大规模、离线、批处理”的场景。如果你的项目只要展示“今天有哪些新闻”MySQL 就够了但如果你想做“过去一年所有新闻来源的趋势分析”Hadoop 就有说服力了。所以设计分析任务时尽量做一个“不可能用几条数据完成”的统计比如跨多天、多站点的聚合这样 Hadoop 的存在感才会更自然。如果你觉得伪分布式 Hadoop 内存压力太大也可以换一种实现方式只在 Docker 容器里跑 HDFS用命令行展示上传和下载再用 Hive 跑一个查询。这样既能讲清流程又避免本地环境做太多复杂配置。5. Django 展示端把离线结果变成用户能看的新闻聚合页Django 是这个项目里离用户最近的一层也是最终呈现成果的地方。它本身不难难的是如何把前面几层的数据结果统一整合到页面上。5.1 Django 项目结构怎么设计在动手写模型之前建议先把 Django 项目按职责分成几个 app。一个典型的划分方式是这样的collector负责采集任务的触发、查看采集日志news负责新闻数据模型和列表页、详情页analysis负责展示分析结果比如热词排行、来源统计。这种划分不是为了“看起来专业”而是为了让代码逻辑不纠缠在一起。采集任务属于后台逻辑新闻展示属于前台逻辑分析结果属于统计逻辑三个 app 各管各的后续维护也好定位问题。一个简化版新闻模型可以写成这样from django.db import models class News(models.Model): title models.CharField(max_length255) url models.URLField(uniqueTrue) source models.CharField(max_length100) pub_time models.DateTimeField() summary models.TextField(blankTrue) content models.TextField(blankTrue) created_at models.DateTimeField(auto_now_addTrue) def __str__(self): return self.title这个模型的url字段设置成uniqueTrue可以用数据库层去重。但你也要留意如果爬虫数据量非常大数据库层的 unique 约束会造成插入冲突所以实际编码时通常先用 URL 查一次再插入或者用update_or_create。毕设的数据量通常不会太大直接在逻辑里去重即可。5.2 数据展示的核心页面Django 端需要实现的页面不必太花哨但要把核心功能做完整首页展示最新新闻列表分页显示分类/来源页按来源或分类筛选新闻搜索页按标题或正文关键词搜索热榜页展示来源统计、热词排行、发布时间趋势。如果你希望页面更好看可以直接用 Bootstrap 或简单的前端模板。不要在这一层浪费时间做复杂交互重点是演示数据流。关于热词统计结果我建议在 Hadoop 分析完成后把结果导出到一个 MySQL 结果表Django 再读取这张表。这样 Django 端不用直接访问 HDFS实现起来简单稳定。5.3 部署和演示时的几个注意点本地开发时python manage.py runserver就能启动但你要提前确认以下事项数据库是否已经完成migrate采集任务产生的数据文件路径是否和中间层脚本一致如果部署到服务器需要处理ALLOWED_HOSTS、静态文件收集、数据库备份等问题如果你用宝塔面板部署 Django注意 Python 版本和虚拟环境路径。演示之前最好准备一份“演示流程卡”大约长这样打开爬虫脚本抓取最近 100 条新闻检查清洗结果 JSON 文件把文件上传到 HDFS运行统计任务输出各来源数量把分析结果导入 MySQL刷新 Django 页面看到最新数据和榜单。按照这个顺序演示评委能很快理解你做了什么而不是看到一堆报错和“手动补数据”。6. 从演示到答辩必须提前排查的 5 类环境与工程问题毕设项目最怕的不是代码丑而是演示现场起不来。下面这 5 类问题建议你提前排查一遍。6.1 Hadoop 环境类问题Hadoop 伪分布式配置的核心文件是core-site.xml、hdfs-site.xml、yarn-site.xml。如果你是第一次配置最容易遇到三类问题启动后 NameNode 或 DataNode 进程没有起来通常是因为端口被占用或格式化多次导致数据目录冲突文件上传时报 permission denied常见原因是当前 Linux 用户和 HDFS 的权限不匹配内存不够Java 进程被系统杀掉。建议调小 Hadoop 各进程的内存参数或直接用 Docker 单节点镜像。排查顺序先看jps进程列表再查日志最后检查配置不要盲目重装。6.2 Python 和 Django 版本类问题Django 版本和 Python 版本有对应关系比如 Django 4.x 要求 Python 3.8 以上。如果你在虚拟环境里安装依赖最好固定版本号写成requirements.txt避免换机器后 package 版本不一致。另外Python 爬虫脚本里的requests、beautifulsoup4也需要保持版本一致。不要小看这一点很多项目跑不起来都是因为环境里装的包版本冲突。6.3 数据清洗和中文编码问题新闻数据最容易出问题的是中文乱码和时间格式不统一。抓取响应后要设置正确的编码比如resp.encoding resp.apparent_encoding写入文件时统一用 UTF-8。时间字段要尽量统一成datetime类型或YYYY-MM-DD HH:MM:SS格式否则后续按时间聚合会很痛苦。去重时要注意 URL 可能带参数最好先做归一化处理比如去掉utm_*等跟踪参数。6.4 演示稳定性和性能类问题答辩演示时不要反复跑爬虫。爬虫是有不确定性的网络延迟、目标网站改版、反爬频繁都可能让它失败。更稳妥的做法是提前把数据抓好存成离线文件演示时手动触发一次“从文件到分析结果”的流程而不是现场访问目标网站。如果你确实想演示实时抓取建议提前准备备用站点。一个站点失败立即切换到另一个站点不要让全场观众盯着你的报错日志。并发和性能方面不要在演示机上开太多进程。建议爬虫用单线程或少量线程MapReduce 用默认配置Django 用runserver即可。毕设重点是流程不是性能压测。6.5 答辩时会被追问的问题你至少要能回答以下五类问题为什么选这个选题你的系统解决了什么问题为什么用 Hadoop为什么不用 MySQL 直接存你的爬虫如何应对目标网站改版和反爬你的数据清洗规则是什么如何处理脏数据如果数据量从一千条变成一千万条系统哪里会先成为瓶颈回答这些问题不需要背答案而是要回到你的设计文档和数据流上去解释。只要能说清楚“每一层解决了什么问题换一种方案会有什么不同”就已经足够有说服力了。7. 把毕设做成“能讲清楚”的项目一套可复用的收尾框架最后我想分享一套收尾框架。它不只是给这个新闻聚合平台用的也可以迁移到很多数据类毕设项目上。7.1 从最小闭环到完整链路的四个阶段不要一开始就想做到“采集、分析、展示全部最优”。我建议按下面四个阶段推进第一阶段用 Requests Django SQLite 做出一个最小闭环。手动在数据库里插入 20 条新闻页面能展示出来。第二阶段接入爬虫替换手动数据跑通自动采集到入库的流程。第三阶段接入 Hadoop把清洗后的新闻文件上传 HDFS跑通一个 MapReduce 或 Hive 统计任务并把结果导回 MySQL。第四阶段补做日志、异常处理、去重、文档报告和演示流程。每完成一个阶段你都拥有一个可独立演示的成果。即使最后 Hadoop 没能完美跑通你也至少有一个能展示的新闻平台但如果 Hadoop 跑通了你的项目会明显比同组同学多一个层次。7.2 评判毕设质量的四个标准做完之后你可以用四个问题来检查自己数据流是否完整一条新闻数据能不能从目标网站一路走到前端页面中间每一跳都是真实流转而不是写死的手工数据代码是否可讲每个模块的核心逻辑你是否都能画出输入输出说清为什么这样设计异常是否可控万一爬虫失败、HDFS 没启动、数据库连不上你是否能通过日志快速定位问题文档是否可复现换一台电脑别人能否按你的文档把项目跑起来这比代码本身更能反映你的工程能力。7.3 最后再说一句这个项目做完之后你能收获的最有价值的东西不是“我会用 Scrapy 了”或“我配好了 Hadoop”而是你经历过一次“把一个复杂问题拆成采集、存储、计算、展示四层然后逐层打通”的完整过程。以后不管是做数据开发、后端开发还是继续做更复杂的大数据项目这种分层拆解和链路联调的能力都会持续起作用。所以写代码的时候不要急环境出问题也不要慌。把每个模块的输入和输出想清楚把每一次报错当作一次排查练习你就能把一个题目从“能跑”做成“能讲清楚”。如果现在的你正准备开始这个题我的建议只有一条先不要管 Hadoop也不要管 Django先写一个爬虫抓 10 条新闻打印到屏幕上。等这 10 条数据变成你想要的格式再一步一步往下走。新闻聚合平台的起点永远是那条最不起眼、但真实存在的数据。
