Mr pretty毕设选“Hadoop+Hive+PySpark”这套大数据技术栈来做小说推荐系统，很多同学第一反应是“这得搭多少环境啊”，第二反应是“推荐算法会不会很难”。实际上我做完一轮下来，最深的感受是：这个题目的难点不在算法原理，而在数据链路的完整性——从爬虫采集、清洗入仓、离线训练，到结果落地和可视化，每一步都有活儿干，而且每一步都能在答辩时讲出东西。哪怕你只把这条链路走通，就已经超过一半的毕设了。
先说说这套系统到底做了什么：用Python爬虫抓取小说站点的书籍信息和用户评论数据，通过HDFS做分布式存储，用Hive做数据清洗和特征提取，再交给PySpark跑ALS协同过滤算法训练推荐模型，最后把推荐结果和统计指标通过一个可视化看板展示出来。整个项目覆盖了“数据采集→数据存储→数据处理→算法建模→结果展示”的全流程，这也是它能同时吸引答辩老师和招聘面试官的原因——它不是一个单点功能，而是一套完整的大数据应用闭环。
这篇文章我会按照实际开发顺序，把每个环节的设计思路、实现细节和踩坑记录都过一遍。你在做的时候不需要完全照搬，但每条经验基本都能对号入座。
1. 项目整体拆解：一个毕设做了四件事
1.1 核心需求与功能模块盘点
小说推荐系统听起来是个推荐算法项目，但拆解下来其实是四条线并行：
- 数据采集线：从小说平台抓取小说基本信息（书名、作者、分类、简介、字数、状态）和用户行为数据（评分、评论、阅读记录）。
- 数据存储线：爬虫产出的结构化数据落到HDFS，再用Hive建立数据仓库表，支撑后续的统计分析和特征提取。
- 数据处理线：PySpark负责清洗、过滤、格式转换，包括去重、缺失值填充、时间戳规范化、用户ID和小说ID的统一编码。
- 推荐与展示线：ALS算法训练用户-小说隐语义模型，输出TopN推荐列表，再配合排行榜、分类统计、评分分布等图表做成可视化看板。
这四个模块相对独立，又可以串成一条完整链路。独立的好处是每一块都能单独拿出来讲，“数据采集用了什么框架”“Hive分区表怎么设计的”“ALS参数怎么调的”，每个点都能展开两三页PPT。串起来的好处是系统完整性一目了然，评委随便问一个环节你都能接住。
1.2 技术栈选型背后的逻辑
很多同学纠结为什么不用Spring Boot加MySQL一把梭，这个质疑在毕业设计答辩中其实经常出现。我的理解是，选题为“XX推荐系统”的毕设，核心考察点其实是“你是不是真的理解了大数据组件各自的位置和边界”。
Hadoop HDFS的定位是分布式文件系统，解决的是“数据量大到单机存不下”的存储问题。在演示环境里你可能只有几万条数据，但架构上要有这个抽象。Hive的定位是把SQL翻译成MapReduce/Spark任务，适合批量离线分析，比如统计每个分类的小说数量、计算用户平均评分这类操作。PySpark则承担了更复杂的清洗逻辑和算法训练，它比写MapReduce Java代码的效率高了一个数量级，这也是现在很多公司实际在用的组合——数据入Hive，计算跑Spark。
再往深一层，这套组合能让你在毕设里同时展示三样东西：会SQL做数据分析、会Python写数据处理脚本、会调参跑推荐算法。这三样单拿出任何一样都不稀奇，但组合在一个项目里，就容易给评委留下“这个学生真的会干活”的印象。
1.3 架构设计的三个关键决策
我在动手之前做了三个关键决策，很大程度上决定了后面的开发节奏。
第一，环境用伪分布式而不是完全分布式。毕设的核心是验证流程，不是搭建生产集群。我就用一台8G内存的虚拟机完成了Hadoop、Hive、Spark的全部部署，三台机器的集群在演示时反而容易因为资源不足出问题。但注意，HDFS的目录设计、Hive的库表设计、Spark的提交参数，仍然要按照分布式集群的标准来配置，这样答辩被问“扩容一台节点要改什么”时你才能答得上。
第二，爬虫数据先落地成JSON文件，再通过HDFS命令批量入库，而不是直接调用Hive API写入。这个决定让爬虫模块和数据仓库模块彻底解耦。爬虫挂了不影响后续流程，数据不满意可以随时重新抓取，重新上传就能覆盖。
第三，推荐算法用ALS协同过滤，不做基于内容的推荐。原因很简单：协作过滤只需要用户-小说评分矩阵，特征工程工作量小，解释起来也直观——“和你口味相似的用户也喜欢这本书”。基于内容的方案需要给每本书构建内容特征向量，爬虫阶段拿到的简介和标签数据量又不足以支撑训练，很容易做成一堆垃圾特征。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 小说爬虫设计：先把数据拿到手再说推荐
2.1 目标站点与字段规划
爬虫的第一步不是写代码，而是确定“要什么字段”。这个决定直接影响后续Hive建表和数据清洗的复杂度。
我当时规划的字段分两类。小说基本信息：小说ID、书名、作者、分类、简介、字数、连载状态、评分、封面图URL。用户行为数据：用户ID、小说ID、评分、评论内容、评论时间。为了缩小爬取范围，我只爬取了固定分类下的Top N本小说（比如玄幻、都市、历史各取200本），再针对每本小说爬取最近的热门评论。这种方式比全站爬取可控得多，既满足了数据量需求，也避免了对目标站点造成太大压力。
这里有一个容易被忽视的坑：小说ID和用户ID必须在全站范围内统一。如果爬A分类时给小说编号1，爬B分类时又遇见了另一个编号1，后面Hive里做JOIN就会乱套。最好直接使用目标站点的真实ID，比如详情页URL里的那串数字，既保证唯一性，又方便后续断点续爬。
2.2 请求策略与解析方案
技术上我采用的是requests加BeautifulSoup4的组合，而不是Scrapy。原因很实际：Scrapy的学习成本和项目初期调试成本稍高，而requests配合xpath或CSS选择器在快速原型阶段效率更高。不过工程上还是补了一个简单的请求重试机制，避免单次请求失败导致整批数据丢失。
请求策略上主要规避两点：高频请求被限流，以及请求头被识别为脚本。实测下来，每两次请求之间随机sleep 1到3秒，加上一个随机的User-Agent池，基本能稳定跑完全量爬取。如果目标网站有登录墙，可能需要加Cookie模拟登录，这个就看你选的站点了。
解析阶段的核心是提取“结构化信息”。评论时间字段建议用统一的时间戳格式（YYYY-MM-DD HH:MM:SS）保存，后续PySpark处理时会省很多事。如果源站的时间格式五花八门，就在爬虫阶段做一次轻量处理，统一格式，别把脏活留给后面的清洗环节。
2.3 数据落盘与断点续爬
数据落地到本地之后，按类型分成两个目录：novel_info/和novel_comment/，每个目录下按批次生成JSON文件，比如novel_info_batch_001.json。文件命名带批次号的好处是方便增量上传到HDFS，后续出了问题也容易定位是哪个批次的数据有误。
断点续爬的核心是记录“已爬取的小说ID集合”。每爬完一本小说，就把它的ID追加写入一个本地文件done_ids.txt，下次启动时先加载这个集合，跳过已完成的ID。这个方法简单却非常有效，因为小说详情页的爬取是天然可并行的，断点续爬让中途挂掉变成一件不用太担心的事。
实际爬取完，数据量大概是这样的：小说基本信息1500条，评论数据两万多条。这个体量对推荐算法来说不算充裕，但足以支撑一个毕设的完整流程演示。如果你需要更丰富的训练数据，有两种扩展思路：一是增加分类数量，二是对每本书爬取更多页评论。后者提升效果更明显，因为评分数据量直接决定了ALS训练的效果。
3. 数据入仓：从HDFS到Hive到PySpark
3.1 HDFS目录设计与文件上传
爬虫数据在本地是JSON文件，下一步就是进入HDFS。建立HDFS目录时，我按数据源分了两层：
code复制/user/hadoop/novel/raw/novel_info/
/user/hadoop/novel/raw/novel_comment/
上传命令就是一条hdfs dfs -put，但有一点必须注意：如果之前已经有数据，再用-put上传会报“文件已存在”的错误，这时需要用-appendToFile或者先删除旧目录再上传。考虑到毕设阶段频繁调整爬虫逻辑很正常，我习惯用-rm -r清空再重新上传的方式，保证HDFS里的数据始终是当前爬虫输出的最新版本。
上传完成后，用hdfs dfs -ls检查一下文件数和大小，确认没有0字节的空文件。这一步看似多余，但能帮你尽早发现爬虫解析失败、导致整批次数据空转的问题。
3.2 Hive建表设计：外部表与分区策略
Hive表的创建是这个项目的第二个关键点。我的做法是建外部表，数据文件直接指向HDFS目录，而不是把数据“拷进”Hive的仓库目录。外部表的好处在于：如果后续清洗逻辑有问题需要重新处理数据，直接替换HDFS文件即可，表结构几乎不用动。
表结构上，小说信息表和评论表都按照源JSON的字段逐个映射。特别注意几个坑：
- JSON里的嵌套结构（比如评论JSON里带user_info子对象）在Hive中要拆开来存，用普通字段代替嵌套结构，避免后续查询麻烦。
- 字符串字段统一用STRING，避免因长度不够导致数据截断。
- 日期字段如果用于后续分组统计，建议设计成分区字段，比如
dt分区。虽然毕设数据量不大，但带上分区字段能展示你对Hive分区优化的理解，答辩时提到“按日期分区可以避免全表扫描”就很加分。
建表SQL的一个参考模板（以小说评论表为例）：
sql复制CREATE EXTERNAL TABLE novel_comment (
uid BIGINT,
novel_id BIGINT,
rating DOUBLE,
comment STRING,
comment_time TIMESTAMP
)
PARTITIONED BY (dt STRING)
ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe'
STORED AS TEXTFILE
LOCATION '/user/hadoop/novel/raw/novel_comment';
建完表后需要执行MSCK REPAIR TABLE novel_comment;刷新分区信息，否则新上传的分区数据查不到。这是我第一次用分区表时踩过的坑，也是复习时容易遗漏的点。
3.3 PySpark数据清洗三步走
Hive负责了基本的数据定义和存储，但真正灵活的数据清洗在PySpark中完成。我用了三个关键步骤。
第一步是数据去重。评论表里同一个人对同一本书的重复评分会直接影响ALS的训练效果。做法是保底逻辑：按uid + novel_id分组，取comment_time最新的一条。用PySpark的dropDuplicates加排序配合Window函数实现。
第二步是过滤异常数据。评分字段的值域是1到5，如果爬虫解析出错出现0分、10分这类数据，直接过滤掉。评论为空但评分为正常值的记录可以保留，但评论内容为空的记录建议过滤，因为后续可视化统计会用到评论数。
第三步是用户和小说ID的重新编码。爬虫拿到的用户ID可能是字符串，也可能跨度很大，直接灌给ALS并不方便。我把用户ID映射成从0开始的连续整数，小说ID同样处理。这一步用StringIndexer就能搞定，输出两列映射关系，后面推荐结果还要用这个映射关系还原成真实ID。
清洗完成后，把结果写回Hive的另外一张宽表（或者直接以Parquet格式存储）。Parquet格式在Spark读取效率上比TEXTFILE高不少，推荐使用。HDFS上的目录结构就变成了：
code复制/user/hadoop/novel/cleaned/novel_rating.parquet
这一步做完，数据准备工作基本结束，后面就是推荐算法的主场。
4. 推荐引擎：为什么选ALS，以及完整训练链路
4.1 协同过滤与ALS原理
推荐系统的经典分支是协同过滤，核心思想是“物以类聚，人以群分”。ALS（交替最小二乘法）是协同过滤中矩阵分解的一种实现方式。它的目标是把用户对小说的评分矩阵R（维度是用户数x小说数）分解成两个低维矩阵U和V的乘积，使得U x V尽量接近R。
这个矩阵非常稀疏，因为绝大多数用户只对极少数小说有过评分。ALS的做法是：固定U，用最小二乘求解V，再固定V，用最小二乘求解U，如此交替迭代直到收敛。每个用户最终得到一个低维向量表示，每本小说也同样得到一个向量。推荐时，计算某个用户向量与所有小说向量的点积，得分最高的前N本就是推荐结果。
我在实际训练的时候，把评分数据切分成了训练集和测试集，用测试集的RMSE来评估模型效果。虽然毕设阶段不需要极高的准确率，但这个评估过程体现了你对模型泛化能力的理解，答辩时非常加分类。
4.2 基于PySpark ALS的训练代码
PySpark的MLlib对ALS有封装，核心代码量并不多：
python复制from pyspark.sql import SparkSession
from pyspark.ml.recommendation import ALS
from pyspark.ml.evaluation import RegressionEvaluator
spark = SparkSession.builder.appName("novel_als").getOrCreate()
rating_df = spark.read.parquet("/user/hadoop/novel/cleaned/novel_rating.parquet")
train, test = rating_df.randomSplit([0.8, 0.2], seed=42)
als = ALS(
userCol="user_id_new",
itemCol="novel_id_new",
ratingCol="rating",
rank=10,
maxIter=10,
regParam=0.1,
coldStartStrategy="drop"
)
model = als.fit(train)
evaluator = RegressionEvaluator(
metricName="rmse",
labelCol="rating",
predictionCol="prediction"
)
rmse = evaluator.evaluate(model.transform(test))
print(f"RMSE: {rmse}")
这里有几个参数值得展开：
rank是隐语义向量的维度。10到20之间是常见选择，过大会导致过拟合和更大的存储开销，过小则表达能力不够。regParam是正则化系数。控制防止过拟合的强度，0.05到0.2都是合理的搜索区间。可以先跑几组值对比RMSE再定。coldStartStrategy非常关键。它决定了对没有评分记录的新用户或新书如何处理，设成drop会在预测时跳过冷启动物品，避免结果为空或NaN。推荐列表生成的时候再单独处理冷启场景。
4.3 推荐结果生成与存储
训练完了就要产出“看得见”的推荐结果。我用模型对每个用户生成Top10的小说推荐，方法是取所有用户向量集合与所有小说向量集合做批量预测，然后按用户分组取TopN。代码上是用model.recommendForAllUsers(10)一行搞定，但内部机制值得在答辩时说清楚：它是算每对用户-小说的预测评分，然后取最高分的前N个。
结果回写到本地MySQL或者HBase都可以。毕设阶段用MySQL最省事，因为可视化后端可以直接查询，但如果你想展示更偏大数据的存储方案，HBase也是很合理的选择。我是用了MySQL，建了recommend_result表，字段包括：user_id_new、novel_id_new、prediction、rank。这样可视化模块的接口只需要读这张表就能拼出推荐列表。
这里还有一个小小的加分项：做一个“针对冷启动用户”的兜底推荐。如果一个用户没有评分历史，直接返回全站热销榜Top10。代码写起来很简单，但答辩时提到这点，评委就知道你思考过推荐系统的实际问题，而不仅仅是调了个包。
5. 可视化与系统闭环：让数据“讲人话”
5.1 可视化技术选择
可视化模块我选择了Flask后端加上ECharts前端。Flask起来快，和PySpark服务的通信也方便；ECharts则内置了足够多的图表类型，对展示类项目的覆盖度非常好。如果你对前端框架不熟，完全没有必要上React或者Vue，一个HTML页面加几个JS文件就能完成全部展示需求。
页面布局上我分了三个区域：顶部是整体数据概览（总小说数、总用户数、总评论数），中部分别是分类分布饼图、评分分布柱状图、热门小说排行列表，底部是推荐结果展示区。用户可以在推荐区输入或者选择一个用户ID，页面异步请求后端接口，返回该用户的Top10推荐小说并渲染成卡片列表。
接口设计上，后端提供两个主要API：
/api/statistics：返回整体统计数据和图表数据，供首页渲染。/api/recommend/<user_id>：根据用户ID返回推荐结果。
5.2 图表数据的SQL查询逻辑
图表的背后几乎都是SQL统计，这正是Hive和Spark拿手的地方。几个典型查询：
- 分类分布：
SELECT category, COUNT(*) AS cnt FROM novel_info GROUP BY category ORDER BY cnt DESC。 - 评分分布：
SELECT rating, COUNT(*) AS cnt FROM novel_comment GROUP BY rating ORDER BY rating。 - 热门小说：按评论数降序取前20本，再关联小说信息表补全书名和作者。
这些统计结果在演示前可以预先算好存入MySQL的统计表，前端接口直接查询，避免演示现场去跑Spark任务等半天。但答辩时可以现场演示一遍“实时跑SQL出统计”的过程，展示你确实知道这些图表的数据是从哪来的。
5.3 前后端联调的常见问题
联调阶段遇到最多的问题是中文乱码。统一使用UTF-8编码基本能解决，但要确保三处都设置正确：爬虫阶段写入JSON文件时指定UTF-8、MySQL建库时指定utf8mb4字符集、Flask的JSON响应中设置ensure_ascii=False并声明Content-Type带charset=utf-8。
另一个问题是日期和数值的格式统一。前端展示评分时保留一位小数就好，预测评分这种原始浮点值直接显示会很奇怪。我在后端做了一层DTO格式化，把字段规整成前端展示友好型的数据结构，避免前端写一堆格式化逻辑。
6. 遇到的高频问题与排查手册
做这套系统的过程中，大多数时间其实不是在写新功能，而是在解决环境、路径、依赖之类的基础问题。以下几个问题几乎每个搭这套技术栈的人都会遇到，我按频率排个序。
6.1 环境与部署问题
| 问题现象 | 排查思路 | 解决办法 |
|---|---|---|
| start-dfs.sh启动后NameNode起不来 | 检查日志，多半是格式化问题或端口占用 | 重新格式化前必须删除HDFS的临时目录（默认在/tmp），并确认50070端口未被占用 |
| Hive查询一直卡在MapReduce阶段 | 资源不足，或未启用Spark执行引擎 | 改用set hive.execution.engine=spark;，或调整YARN内存分配 |
| Hive表查询显示“Class not found JsonSerDe” | 缺少hcatalog相关jar包 | 在hive-site.xml中添加HCatalog的auxlib路径，或把jar包复制到$HIVE_HOME/lib |
| PySpark连接Hive时报元数据错误 | Hive和Spark的版本不兼容，或metastore配置不一致 | 统一Hive和Spark的Scala版本，启动Spark SQL时显式指定--jars包含mysql-connector |
| Spark任务提交时报“jar does not exist” | 路径或环境变量问题 | 检查SPARK_HOME和HADOOP_HOME是否配置正确，确认相关jar包存在于指定目录 |
这里我想多说一句：伪分布式环境下搭Hadoop+Hive+Spark，最容易翻车的点其实是系统内存。如果虚拟机只给2G内存，ZooKeeper、NameNode、DataNode、ResourceManager、Spark Driver一启动，机器基本就卡死了。建议至少4G，8G最稳妥，内存不够时优先杀掉无用的进程，比如关掉防火墙、关闭图形界面服务。
6.2 爬虫与数据清洗问题
爬虫阶段遇到的最经典问题是“curl或者requests访问返回403”。这种情况要从请求头、Cookie、访问频率三个方面逐一排查。先带上完整的浏览器请求头，如果还不行就加Cookie，最后再降频率。实测一个通行的思路：先模拟浏览器直接访问详情页，确认能拿到HTML后再写循环逻辑，不要一上来就全量跑。
数据清洗阶段比较隐蔽的问题是ID映射错位。用StringIndexer时，如果训练前没有对数据重新分区，可能出现同一个真实ID映射成不同整数ID的情况。我建议在编码前先dropDuplicates确保每个真实ID只有一行，然后再做编码，最后把编码映射表单独保存一份，方便之后还原。
6.3 推荐结果异常问题
ALS训练完成后如果发现推荐结果全是同一本书，多半是评分数值区间出了问题。当评分数值都相同，比如所有评分都是5.0，矩阵分解无法学到差异信息，推荐结果自然没有区分度。
另一个常见问题是预测评分为NaN。这通常是因为coldStartStrategy没有设置，或者测试集中出现了训练集没有出现过的用户/小说。我在代码里设置了coldStartStrategy="drop"，但我在进行model.transform(test)之后还做了一次过滤，把预测值不为空的结果单独拿出来评估。这个习惯让我在实际调试中少走了很多弯路。
7. 交付材料编写与答辩准备建议
毕设最后提交的是源码加文档加PPT加讲解，每一份材料都有它存在的意义，不能厚此薄彼。
7.1 文档怎么写得让人以为你做了很久
毕设文档的核心是“完整性和可复现性”。完整性指项目背景、需求分析、系统设计、功能实现、测试结果这个逻辑链不能断。可复现性指别人按照文档步骤能否重建整套系统。写文档时注意不要只贴代码，关键设计决策必须写清楚“为什么”。
我写文档时的结构是：第一章介绍选题背景与技术选型；第二章画系统架构图和模块划分；第三章按四个核心模块展开详细设计，每个模块包含功能逻辑、关键代码、界面截图；第四章写测试情况，包括环境配置、数据集规模、ALS实验参数对比和RMSE表现；最后一章总结，再加一个“系统局限与改进方向”。
7.2 PPT怎么排版才能让评委不困
PPT的定位是“导图”而不是“文档”，一页一个主题，控制在12到15页。我的PPT顺序是：项目背景与意义一页→系统架构图一页→各模块详细介绍四到五页→推荐算法部分专门一页讲原理和参数→可视化效果展示两页→测试结果和数据一页→总结与展望一页。
推荐算法那页是评委最喜欢提问的地方，提前准备好解释：ALS算法的目标函数是什么，矩阵分解的物理意义是什么。
7.3 高频答辩题与应对思路
整理了几个高频答辩问题，大家可以提前准备：
- 为什么选Hadoop不用MySQL？回答要说明数据量的假设，HDFS扩展性的价值，以及Hive SQL做离线分析的优势。
- 推荐算法是什么？为什么能用来推荐？讲清协同过滤的直觉和ALS的迭代思想，提到评分矩阵的稀疏性。
- 爬虫数据有多少，合规性怎么考虑？如实回答数据规模，同时强调只爬取公开信息、控制请求频率、不涉及个人隐私数据，体现你的责任意识。
- 模型效果怎么样？怎么评估的？提RMSE，提训练集测试集划分，还可以说实际观察推荐结果的人工评估。
- 如果数据量再大十倍，系统会不会崩？哪里是瓶颈？建议说HDFS存储没有问题，瓶颈在Hive查询和Spark训练的资源规模，可以通过增加节点、改用Spark SQL、引入Kafka实时管道来扩展。
这套题答下来，基本就能覆盖评委的主要关注点。
8. 从毕设到简历：这套项目还能怎么延伸
做完这个毕设之后，我建议你花一点时间做“项目包装”，不是编造数据，而是把工作梳理成简历上可量化的项目经历。
一个比较标准的表述方式是：“基于Hadoop+Hive+PySpark构建小说推荐系统，实现海量小说数据的采集、清洗、分析及个性化推荐，覆盖数据仓库构建、ETL处理和ALS协同过滤算法的完整链路；使用Python爬虫采集小说及评论数据超过2万条，通过Hive完成分类统计与数据探查，使用PySpark MLlib训练ALS模型并优化rank与regParam参数，RMSE降至0.86；基于Flask+ECharts实现可视化看板，支持推荐结果与多维统计展示。”
这段描述里提到的“数据采集量”“RMSE指标”“完整链路”“可视化看板”都是真实可考的出题点。面试官如果顺着这几点追问，你都能展开一两分钟的细节叙述，这个项目就真正成为了你的经验沉淀，而不仅仅是毕设分数的一部分。
最后再说一个小技巧：完整的项目源码、文档和PPT在做完后，建议打包上传到自己的代码仓库并写好README，包括部署步骤和运行截图。这样做一是防止本地文件丢失，二是未来找实习或投简历时可以直接甩链接，节省来回解释的成本。
一个项目做下来，最值钱的其实不是评分，而是你对“从0到1完成数据产品”这个流程的亲身体感。这套链路跑通之后，再看公司的招聘信息里“熟悉Hadoop生态”“了解推荐系统”“会Python”这些词，你会发现它们不再是简历上的几个字，而是自己真正做过的事。