Maggie H每年三四月份，总会有不少大四学生拿着“Hadoop+Spark新闻推荐系统”这类题目来找我调 bug。说实话，这个题目标题党很多：源码从网上能下载好几份，文档也有现成的，可是真要在本地把 HDFS、Yarn、Spark 和前端页面串起来跑通，再讲清楚“新闻标题自动分类、新闻推荐、新闻可视化”这整套逻辑，已经能淘汰一半人。很多人卡住的点根本不是算法不会，而是不懂一条数据处理链路应该如何组织，也不明白哪些部分必须用大数据组件，哪些部分其实可以用普通后端完成。
这篇内容就是把我自己做完这个题之后沉淀的拆解思路写出来。适合正在做大数据方向毕业设计的学生、准备相关岗位面试的人，以及想把“Hadoop+Spark新闻推荐系统”做成一个能演示、能答辩、能讲清楚的项目而不是只交一份 PDF 的同学。我尽量不堆术语，把整条数据流从采集、存储、清洗、分类、训练、推荐到可视化一层层剥开，顺便解释为什么这么设计、哪些环节容易翻车。
1. 就业与答辩视角下，新闻推荐系统为什么是一个合适的大数据题目
1.1 表面上是个“推荐算法题”，本质是个“平台工程题”
不少同学选这个题，是奔着“推荐算法”来的，觉得给用户推荐新闻很有趣。但仔细想想，如果你只是想实现推荐，用一台笔记本跑个 sklearn 的最近邻模型就够了，根本不需要 Hadoop。这个题目的巧妙之处在于，它把真实互联网产品的数据流程压缩成了一个可演示的系统：新闻有文本、有发布时间、有分类；用户会不断产生点击、浏览、收藏，甚至后续可以模拟出实时到达的新数据。要处理这些数据，你可以名正言顺地把 HDFS、Spark SQL、Spark MLlib、Kafka、Redis、可视化大屏都纳进来，每个组件都有自己不可替代的位置。
在面试和答辩时，这种做法得分很高。因为老师或面试官真正想看的不是你去掉第三方后端、独自从头写一个夸克推荐引擎，而是你有没有能力把一个需求拆解成多个模块，再合理分配资源：哪些用离线批处理，哪些放内存，哪些需要保存到关系型数据库供网页查询。新闻推荐系统恰好覆盖了“数据采集—数据处理—数据建模—结果展示—反馈回流”的完整闭环。哪怕每个环节实现的深度不高，链路是通的，答辩时就“有故事可讲”。
1.2 题目虽常见，为什么年年有人挂在同一个地方
同一个题目年年有人选，能拿优秀的人却很少，原因往往不是模型精度不够高，而是以下这几个问题没有处理好：
- 只在一台电脑上跑通了 Python 脚本，但没有真正经过 HDFS 存储和 Spark 任务调度，老师一问“你的 Spark 到底做了什么”，场面就非常尴尬。
- 把新闻爬下来后直接塞进了 MySQL，没有做数据清洗和文本预处理，导致后面分类模块的效果非常差，各种新闻标题都被分到“娱乐”类别里。
- 演示时靠手动点在网页上点出几张图表，点击量、分类准确率这些指标没有任何日志支撑。视频或现场答辩只能不停切换页面，说服力很弱。
- 文档里写满了 HDFS、Spark、推荐算法的概念，但实际代码仓库结构混乱，自己写完一个月后都找不到入口文件在哪，更别说让别人复现。
这四类问题本质上是同一个：只做了局部功能，没有站在系统集成视角去看项目。下面的章节，我会按照我自己推荐的“5 层架构 + 4 条主链路”来逐步还原一套可交付的 Hadoop+Spark 新闻推荐系统应该长什么样。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 新闻推荐系统的整体架构设计与技术选型逻辑
2.1 五模块分离：采集、平台、计算、服务、展示
我一般会把项目分成五个模块，而不是按“张三负责推荐、李四负责前端”这种按页面拆法。模块一旦按数据流划分，代码的边界就特别清楚：
| 模块 | 主要职责 | 常用组件 |
|---|---|---|
| 数据采集模块 | 抓取新闻标题、正文、发布时间、来源；采集用户模拟点击日志 | Scrapy / Requests、Flask 模拟日志接口 |
| 数据平台模块 | 存放原始数据与清洗后数据，形成统一的表结构 | HDFS、Hive、MySQL |
| 离线计算模块 | 每日定时跑新闻数据清洗、标题分类、ALS 用户推荐、统计报表 | Spark SQL、Spark MLlib、PySpark |
| 服务接口模块 | 给前端 Web 页面提供新闻列表、推荐列表、分类结果查询、图表数据接口 | Flask / FastAPI |
| 展示模块 | 网页端展示新闻内容、推荐反馈、可视化统计 | HTML + Vue/原生 JS + ECharts |
为什么要把 MySQL 放进去？这个问题值得细讲。HDFS 适合存储超大文件，但是不适合让 Web 后端用 SQL 去高频查询单条记录，也不适合快速响应推荐接口的 Top N 查询。所以标准做法是让 Spark 完成大规模计算后，把维度表和结果表写回 MySQL。前端打开的每个列表页、每个图表，都只和 MySQL 或 Redis 交互。这个架构在真实工业场景里很普遍，也是面试时最能体现工程经验的细节。
2.2 Spark 与 Hadoop 各自承担什么角色
很多同学把“Hadoop 和 Spark”理解成一个增强版的“大数据全家桶”，认为只要用到了这两个单词，题目就完成了。实际项目中，两者有明确分工：
- Hadoop HDFS 负责原始新闻、点击日志的分布式存储。在答辩环境中可以只搭一个伪分布式集群，但你需要说明白真实环境下为什么不能都塞进单机数据库。
- Hadoop Yarn 负责资源调度，给 Spark Application 分配内存与 CPU 资源。
- Spark 负责大规模数据清洗与特征处理。例如从 20GB 点击日志中提取每个用户的点击序列，Spark 比单机脚本快得多，代码也更流畅。
- Spark MLlib 提供的 ALS 算法可以直接训练协同过滤模型，这是推荐系统里极其经典的应用。
架构确定以后，还有一个容易忽略的“调度”问题。我建议不要在 Web 主线程里用代码触发 Spark 任务，这不是一个合格的数据平台设计。更好的方式是预留一个 Spark 任务入口脚本，用 Linux 的 crontab 或类似工具，每天凌晨以批处理方式执行分类和推荐任务。在演示时，如果你想让老师看到实时跑任务的效果，可以在后台再单独点击执行。把离线任务、在线服务分开，整个系统才不容易出现“接口被一个 Spark 任务拖死”的尴尬场景。