基于Hadoop的网络小说数据分析系统：Python全链路设计与实现

这次我们来看一个 Python 计算机毕业设计项目：基于 Hadoop 的网络小说数据分析系统。它的看点是技术链路完整，不是某个算法有多难：先写 Python 爬虫采集网络小说榜单和详情数据，把数据落到 Hadoop HDFS 上做分布式存储，再用离线分析计算分类趋势、作者排行、字数分布等指标，接着用推荐算法生成“喜欢这本书的人还喜欢”的结果，最后通过可视化大屏展示分析结论。爬虫、大数据框架、推荐算法、可视化四种能力全都有，正因为链路完整，这类项目在本科毕设答辩时反而比单点功能更容易讲清楚。

先回答一个很多人会关心的问题：这项目值不值得选，或者拿到配套源码后该怎么下手。从工程角度看，核心难点不在 Python 爬虫和 ECharts，而在 Hadoop 环境的搭建和验证。只要能把 Hadoop 伪分布式跑起来，数据写入 HDFS、执行分析 SQL、导出结果给 Web 层，后续工作基本都是“调用服务 + 拼装数据 + 渲染图表”的组合。本文会从项目结构出发，拆清楚数据流和各模块设计，再给出本地环境准备、部署、测试、排错的完整思路，适合准备大数据方向毕设、想要系统化梳理“Python + Hadoop + 推荐算法 + 可视化”套路的读者。

如果把项目拆成几个关键特点，可以这样看：一是数据闭环完整，采集、存储、计算、推荐、展示都有对应模块；二是技术栈主流，Python 负责数据处理和接口，Hadoop/HDFS 承担分布式存储和离线分析；三是可视化成果直观，分析出的榜单和分布能直接放在答辩 PPT 里；四是交付物结构比较全，标题里已经写了包含源码、文档报告和代码讲解，拿来对照学习或二次开发都会省去不少搭框架的时间。下面的步骤不会假定机器是 64G 内存集群，单机伪分布式就足够把整条链路跑通。

1. 核心能力速览

这里有一个需要说明的地方：Hadoop 分析具体采用 HiveSQL 还是手写 MapReduce，可视化后端用的是 Flask 还是 Django，要看手上源码的实际实现。上面表格描述的是这类毕设项目最常见的落地轮廓，代码讲解视频里一般也会先介绍这个顶层结构。

2. 适用场景与使用边界

这个项目更适合下面几类人：Python 和 SQL 有基础，想把 Hadoop 放进简历或毕业设计里的同学；需要一个“数据从采集到展示”完整演示的项目，而不是只写一个爬虫或只画几张图的读者；以及正在搭建大数据综合课程设计，想参考模块划分的人。项目中很多地方体现的是工程思维，比如数据清洗要处理缺失值和重复数据，CSV 直接分隔会因为小说简介里的逗号把字段拆坏，Hive 表需要设计合适的分隔符，这些都值得实际跑一遍。

它的边界也非常清楚。第一，脱胎于毕设场景，不等于生产级小说数据分析平台，数据量通常只有几万条，性能方向不是重点。第二，如果老师要求必须让“Hadoop”体现在重量级计算上，那爬虫和数据可视化只是辅助，核心得分点在于 HiveSQL 或 MapReduce 完成的分析任务，不能把 Hadoop 当成普通文件存储来用。第三，推荐算法带教学属性，核心要讲清楚输入是什么、相似度怎么算、结果如何解释，不能用“上线效果很好”这类无法验证的话。

合规方面必须提醒一句：网络小说正文通常有版权，毕设项目尽量只处理榜单、书名、作者、分类、字数、评分等元数据，不建议把全文内容采集进 HDFS。爬虫调用的站点要遵守 robots 协议和服务条款，不绕过登录态、不暴力请求；最稳妥的测试方式是本地构造一个 HTML 页面，或者使用允许公开抓取的样例站点，先验证解析逻辑，再考虑扩大采集范围。演示和提交代码前，也要去掉可能暴露隐私或涉及侵权的内容。

3. 整体架构与技术选型

从数据流方向看，系统可以分为六个层次。

一条完整的数据流转大概是这样的：爬虫脚本先抓取页面并输出 JSON 或者 CSV，然后数据预处理阶段清洗字段，生成方便 Hive 读取的文本文件；数据文件被上传到 HDFS 之后，通过外部表让 Hive 能直接查询；分析 SQL 跑完的结果落到 HDFS 的某个结果目录，再导出到项目目录；推荐模块读取这部分结果，结合用户行为或小说属性和相似度算法生成推荐列表；最终 Web 接口把分类统计、排行榜、推荐结果组合成 JSON，前端用 ECharts 渲染大屏。

这样的分层有一个优点：每个模块都能被单独验证。爬虫可以离线路测，清洗可以单独跑，Hive 分析结果可以抽样核对，可视化页面也能先用假数据调试。毕设调试时最忌讳把所有逻辑写在一个大 Python 文件里，一旦 Hadoop 服务异常，整个流程都定位不了问题。

4. 核心功能模块设计

4.1 爬虫采集模块

爬虫模块的目的是把网页变成结构化数据。如果使用 Requests + BeautifulSoup，代码骨架一般长这样：

import json import time import requests from bs4 import BeautifulSoup def parse_novel_list(html_text): soup = BeautifulSoup(html_text, "html.parser") rows = [] # 下面是通用写法，最终选择器要根据目标页面结构调整 for item in soup.select(".book-item"): title = item.select_one(".title") author = item.select_one(".author") if not title or not author: continue rows.append({ "title": title.get_text(strip=True), "author": author.get_text(strip=True), "category": item.select_one(".category").get_text(strip=True), "intro": item.select_one(".intro").get_text(strip=True), }) return rows def main(): headers = {"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"} all_rows = [] for page in range(1, 11): # 页数需要控制，避免给目标站点造成压力 url = "https://example.com/novel/list?page=" + str(page) resp = requests.get(url, headers=headers, timeout=10) if resp.status_code != 200: continue all_rows.extend(parse_novel_list(resp.text)) time.sleep(1) # 频率控制 with open("novels.json", "w", encoding="utf-8") as f: json.dump(all_rows, f, ensure_ascii=False, indent=2) print("collected:", len(all_rows)) if __name__ == "__main__": main()

这里要解释清楚“双重合规”的必要性。第一层是法律合规，没有站长授权就不要持续高频抓取，更不要把抓下来的内容再公开传播；第二层是工程合规，很多流量稍微大一点的站点都会做频率限制和 User-Agent 校验，如果一上来就跑几十个线程，结果往往不是数据抓到了，而是 IP 被临时限制，随后代码可能什么也解析不出来。

有些同学跑爬虫时会遇到一个很典型的现象：程序执行结束，显示 process finished with exit code 0，但控制台没有任何输出。这不一定代表爬虫失败，而是说明请求或解析环节静默地返回了空结果。比如目标页面改版后选择器没有命中，又或者页面里根本没有.book-item这样的类名。调试时先打印状态码和 HTML 长度，再检查解析结果条数，比盲改选择器有效率得多。

4.2 数据清洗与字段标准化

爬虫原始结果里通常有大量问题：同一本小说被重复采集、分类字段为空、简介里有换行符和多余空格、字数写成“123.4万字”而不是纯数字。如果不统一清洗，后续上传 HDFS 和写 HiveSQL 都会踩坑。

网络小说分析需要的典型字段包括：

清洗代码可以按这样的思路组织：

import pandas as pd df = pd.read_json("novels.json", encoding="utf-8") # 去除重复小说 df = df.drop_duplicates(subset=["title", "author"]) # 去掉关键字段为空的行 df = df.dropna(subset=["title", "author", "category"]) # 把“123.4万字”转成纯数字，转换规则要按实际数据格式调整 df["word_count"] = df["word_count"].astype(str).str.replace("万字", "").astype(float) * 10000 # 使用 \x01 作为 Hive 文本表分隔符，避免小说简介里的逗号破坏列结构 df.to_csv("novel_clean.dat", sep="\x01", index=False, encoding="utf-8") print(df.shape)

清洗后的数据要不要做中文分词，取决于后续推荐算法是否使用简介关键词。如果只用分类做内容推荐，分词不是必须的；如果要做 TF-IDF 相似度，则可以用 jieba 对intro分词，把关键词结果存入单独的推荐特征文件。

4.3 HDFS 存储与文件导入

Hadoop 伪分布式环境准备好之后，第一步不是急着写 MapReduce，而是先把数据文件放进 HDFS，确认读写过程没有异常。常用的操作是：

# 在 HDFS 上创建目录，/user 下的实际路径以系统配置为准 hdfs dfs -mkdir -p /novel/ods # 上传清洗后的文本文件 hdfs dfs -put novel_clean.dat /novel/ods/ # 查看文件是否上传成功 hdfs dfs -ls /novel/ods/ # 如果 DataNode 容量或健康状态异常，用这个命令检查 hdfs dfsadmin -report

文件放进 HDFS 后，可以在终端用hdfs dfs -cat查看内容，确认是否为\001分隔。有经验的开发者会建议不在这一层直接建依赖文件夹结构的复杂目录，而是先用一个/novel/ods目录跑通。因为伪分布式调试阶段最怕路径写错，到后面再根据时间分区或来源网站扩展目录也不迟。

4.4 Hive 建表与离线分析

基于 Hadoop 的分析系统要想在答辩时站得住，不能只把文件放到 HDFS 后就用 pandas 统计，最好把核心指标计算放到 Hadoop 生态中。如果项目里使用了 Hive，可以建一张外部表指向 HDFS 目录：

CREATE EXTERNAL TABLE IF NOT EXISTS novel_ods ( novel_id STRING, title STRING, author STRING, category STRING, word_count BIGINT, click_count BIGINT, recommend_count BIGINT, rating DOUBLE, intro STRING ) COMMENT '网络小说元数据外部表' ROW FORMAT DELIMITED FIELDS TERMINATED BY '\001' STORED AS TEXTFILE LOCATION '/novel/ods';

建表字段必须和清洗文件列一一对应。这里有个常见错误：文件里字段顺序是novel_id,title,author,category,word_count,click_count,recommend_count,rating,intro，Hive 表却漏了某个字段，结果查询出来的数据整体错位，看起来像“中文乱码”或“全 NULL”。先SELECT * FROM novel_ods LIMIT 10;确认前几行，再执行聚合 SQL。

下面是一条典型的分组统计 SQL，计算每个分类的小说数量、平均字数和平均评分：

SET hive.cli.print.header=true; SELECT category, COUNT(*) AS cnt, ROUND(AVG(word_count)) AS avg_word_count, ROUND(AVG(rating), 2) AS avg_rating FROM novel_ods GROUP BY category ORDER BY cnt DESC LIMIT 20;

这段 SQL 结果是可视化大屏中“分类分布”的数据来源。还可以继续扩展作者排行、字数区间、评分 Top 榜等 SQL，但建议控制在一屏能展示的 6 到 10 个指标内，避免报告越写越长。

运行 HiveSQL 时命令行过程比较长，可以把一段时间内重复执行的查询存成.hql文件统一管理：

hive -f hql/category_stats.hql > logs/category_stats.log 2>&1

如果源码没有引入 Hive，而是直接使用 Java MapReduce，那么推荐用一个自定义 Mapper 做分类统计，Reducer 做累加，流程更绕但“分布式计算”的答辩说服力更强。具体实现要看项目配套代码，这里不再展开伪代码，因为 Hive 方案已经覆盖了同样效果。

4.5 推荐算法模块

推荐算法是该项目比较加分的点，但也是容易被老师追问的部分。网络小说场景下最适合的教学级算法有两种：一种是基于分类和简介关键词的内容相似度，不需要用户行为，适合“匿名浏览到详情页推荐相似书”；另一种是基于用户收藏或评分数据的 ItemCF，适合有模拟用户行为数据的系统。

如果采用 ItemCF，把用户对小说的行为看成一个评分矩阵，先计算物品之间的相似度，再根据用户看过的小说找到最相似的未看小说。下面是一个简化版本：

# 教学级 Item-Based Collaborative Filtering 简化示例 # 这里只是为了讲清楚算法逻辑，实际数据应从用户行为表读取 ratings = { "userA": {"novel1": 5, "novel2": 3}, "userB": {"novel1": 4, "novel3": 5}, "userC": {"novel2": 3, "novel3": 4}, } def jaccard_similarity(items_a, items_b): union = set(items_a) | set(items_b) if not union: return 0.0 inter = set(items_a) & set(items_b) return len(inter) / len(union) def recommend(user_id, top_n=3): user_items = set(ratings[user_id].keys()) item_scores = {} for other_user, other_items in ratings.items(): if other_user == user_id: continue sim = jaccard_similarity(user_items, other_items.keys()) if sim <= 0: continue for item, score in other_items.items(): if item in user_items: continue item_scores[item] = item_scores.get(item, 0) + sim * score ranked = sorted(item_scores.items(), key=lambda x: x[1], reverse=True) return ranked[:top_n] if __name__ ==