企业官网建设流程全解析

如果你正好在纠结大数据方向的毕设选题，又不想去做那种千篇一律的电商分析、股票预测，我强烈推荐一条我自己走通的路：做一个小说推荐系统，技术栈直接用 Hadoop + Hive + PySpark，外加一个小说爬虫负责喂数据，最后用可视化把成果展示出来。这个组合的妙处在于，它不是单纯调一个推荐模型，而是把大数据处理的全链路都覆盖了——数据采集、分布式存储、离线数仓、分布式计算、模型训练、结果展示，每一步都有明确的产出和可讲的故事，无论是写论文还是答辩，都有非常扎实的素材。

这篇文章我会把整个项目怎么做、为什么这么做、会遇到哪些坑，全部按我当时的实践过程讲一遍。源码、文档、PPT这些具体的工程文件不做搬运，但我下面写的内容，足够你自己从零搭出一套完整可用的系统，并且能在答辩时把每一个技术点讲清楚。

1. 为什么选"小说推荐"做大数据毕设：选题逻辑与三件套的分工

先说选题。毕业设计最怕的不是难，而是"做完说不清"。很多同学选课题时喜欢奔着"高精尖"去，比如深度学习、知识图谱，结果数据搞不到，模型跑不动，论文写出来自己都看不懂。小说推荐系统这个方向，刚好卡在一个非常好的位置——业务场景人人能懂，技术栈又是大数据课设和校招面试的高频考纲，属于投入产出比很高的一类题目。

1.1 小说推荐场景的数据优势

从数据角度讲，推荐系统需要三类数据：物品信息、用户信息、用户和物品的交互记录。放在小说场景下，物品就是书的基本信息和内容标签，交互记录就是用户的收藏、推荐票、评分、评论。这三类数据有两个很好的特点：第一，结构相对规整，不像自然语言文本那么难清洗；第二，可以在公开的小说站合法采集一部分，不需要去申请那种很难拿到的商业数据集。我当时的目标数据量很简单：爬 5000 本左右的小说基础信息和 30 万条左右的评分/推荐记录，跑在单机伪分布式环境下，Spark 任务几分钟就能出结果，演示效果也能保证。

1.2 Hadoop、Hive、PySpark 各自的角色

很多同学分不清这三个组件到底各干什么，我这里用一句话总结：Hadoop 负责存原始文件和中间结果，Hive 负责把存储在 HDFS 上的半结构化数据映射成二维表并用 SQL 做清洗聚合，PySpark 负责跑真正的分布式推荐算法。

具体到数据流是这样一个链条：

1. 爬虫抓取数据后，把 CSV/JSON 文件上传到 HDFS；
2. Hive 建外部表把 HDFS 上的文件映射成表，然后通过写 HQL 做清洗、去重、类型转换，再写 HQL 做各类聚合统计，比如分类热度、评分分布；
3. PySpark 通过 SparkSession 直接查 Hive 表，拿到清洗后的评分数据，跑 ALS 协同过滤模型，输出每个用户的 Top-N 推荐结果；
4. 推荐结果、聚合统计结果同步到 MySQL，供后端和可视化页面查询展示。

这个链路里每一步都用了实在的技术，而且每一步产出的东西都能在论文里单开一节去写，工作量非常饱满。

1.3 为什么不用纯 Spark 或纯 Hive

这里有个我调研时踩过的小弯：既然 PySpark 也能做数据清洗，为什么还要单独搞一套 Hive 数仓？答案是，数仓分层的思想本身就是课程考核点，也是面试官爱问的点。在论文里你完全可以写"采用 ODS-DWD-ADS 三层数仓结构"，给原始数据、明细数据、应用统计数据各建一层表，逻辑清晰，体现的不是简单会调 API，而是具备工程化数据处理思维。PySpark 的重心放在算法部分，Hive 的重心放在数据管理部分，两个组件都"有事干"，比你只用一个框架完成所有事情要好讲得多。

2. 小说爬虫的落地实践：选站策略、字段设计与异常处理

标题里放了"小说爬虫"三个字，就说明这是整个项目的数据入口，做好了后面的环节才有东西可处理。

2.1 目标站点怎么选，采集策略怎么定

我当时的做法是，不选那种很复杂的动态渲染站，而是找一个服务端直接返回 HTML 的公开小说站，它的分类页、小说详情页结构比较规整。采集策略分三步走：

• 第一步，跑分类页，拿到每个分类下的书籍列表，提取每本书的详情页链接；
• 第二步，逐个访问详情页，解析书名、作者、分类、简介、字数、状态、评分、封面图链接等基础信息；
• 第三步，访问书评区或评分列表页，尽可能采集多页的用户评分和短评内容。

这里我不建议去碰需要登录、有严格反爬机制的站点，主要原因是毕设精力有限，反爬会消耗大量时间。我自己当时写了一个基于 requests + BeautifulSoup 的多线程爬虫，线程数控制在 8 个，加上随机延时，跑了一晚上把数据抓完，整个过程没有触发对方的封禁机制。爬虫的代码框架其实不复杂，核心是解析逻辑要写得稳。

import requests import threading import queue from bs4 import BeautifulSoup import time import random import csv class NovelSpider: def __init__(self, base_url): self.base_url = base_url self.queue = queue.Queue() self.session = requests.Session() self.session.headers.update({ "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" }) self.results = [] def crawl_detail(self, book_url): # 这里省略常规请求和bs4解析代码 # 重点：每条数据解析成功后，写入统一的dict字段 pass def worker(self): while True: try: url = self.queue.get(timeout=3) except queue.Empty: return # 加入随机延时，控制在 1 ~ 3 秒 time.sleep(random.uniform(1, 3)) try: data = self.crawl_detail(url) if data: self.results.append(data) except Exception as e: # 记录失败 url 到日志，方便断点续爬 with open("failed_urls.txt", "a", encoding="utf-8") as f: f.write(url + "\n") finally: self.queue.task_done()

2.2 核心字段设计与建表思路

爬虫到的数据最终要落成结构化文件，我设计了四个实体：小说表、作者表、分类表、评分记录表。小说表的主键是小说 ID，外键关联作者 ID 和分类 ID，评分记录表是最关键的一张表，字段包括用户 ID、小说 ID、评分分数、评分时间。这里有个容易忽略的细节：用户 ID 从哪来。

公开展示的评分数据一般不会暴露真实用户 ID，我当时是做了脱敏抽象，用"用户编号 + 小说编号 + 评分分数"三级信息组成一条记录，同时为了模拟真实场景，在保持分布形态的前提下随机生成了一部分补充评分数据。这个做法在论文里一定要写清楚是模拟生成的，属于实验数据增强，不能误导读者。

采集完成后，所有数据以 UTF-8 编码写成 CSV 文件。这一步必须注意统一编码，不然传到 Hive 后中文全变乱码，后边会非常痛苦。我在踩坑章节会详细讲这个问题。

2.3 爬虫的稳定性，或者说"看起来不专业的问题"

爬虫最容易翻车的地方不是解析写不出来，而是跑着跑着就崩了。我的处理方案有三层：第一，每条数据封装成独立函数，单条失败不影响整体；第二，维护一个失败 URL 列表，跑完后重新执行一次补偿爬取；第三，所有写入操作只在内存统一攒批，最后一次性写文件，避免频繁 I/O 导致文件锁问题。实测下来，这套方案爬到 5000 多本详情数据，漏失率不到 1%。

还有一点合规上的提醒：爬虫部分只用于课程设计和学习演示，需要遵守目标网站的 robots 协议，控制请求频率，不碰用户隐私数据。

3. 数仓建设不能省：HDFS 存储设计、Hive 建表与 ETL 清洗细节

数据抓下来只是第一步，真正体现大数据工程能力的是把数据"接进"数仓。

3.1 HDFS 目录怎么规划最合理

我一开始图省事把 CSV 一股脑丢在 /data 目录，后来发现表多了以后根本分不清。重新整理后的目录结构是这样的：

/user/hive/warehouse/novel.db/origin_data/novel_info.csv /user/hive/warehouse/novel.db/origin_data/rating_info.csv /user/hive/warehouse/novel.db/ods/novel_info/ /user/hive/warehouse/novel.db/ods/rating_info/ /user/hive/warehouse/novel.db/dwd/novel_detail/ /user/hive/warehouse/novel.db/ads/category_hot/

简单来说：原始文件单独放 origin_data，ODS 层是原样导入的原始表，DWD 层是清洗后的明细表，ADS 层是聚合统计结果。这样分区规划之后，答辩时画一张架构图，导师一眼就能看出你理解数仓分层。

3.2 Hive 建表语句里最容易忽略的两个参数

建表时我用的是外部表，原因是外部表删除时不会动 HDFS 里的原始文件，对实验场景来说更安全。这里分享两段我实际跑过的建表语句：

CREATE EXTERNAL TABLE IF NOT EXISTS ods_novel_info( novel_id STRING, novel_name STRING, author_id STRING, category_id STRING, intro STRING, book_status STRING, word_count BIGINT, score DECIMAL(3,2), update_time STRING ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS TEXTFILE LOCATION '/user/hive/warehouse/novel.db/ods/novel_info/';

CREATE EXTERNAL TABLE IF NOT EXISTS ods_rating( user_id STRING, novel_id STRING, rating INT, rate_time STRING ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS TEXTFILE LOCATION '/user/hive/warehouse/novel.db/ods/rating_info/';

第一，ROW FORMAT DELIMITED FIELDS TERMINATED BY ','必须和 CSV 文件里的分隔符完全一致，包括是不是有引号包裹，都要仔细看。第二，中文数据一定用STORED AS TEXTFILE加上表内 UTF-8 编码，同时在 Hive 连接串上显式指定编码参数。

3.3 清洗逻辑：不是一把梭的去重

数仓清洗阶段不能只会 DISTINCT。我当时写了完整的清洗流程，按这个顺序处理：

• 过滤空值和异常值：评分为空、评分不在 1~10 区间的直接丢弃；
• 去重：以"用户 ID + 小说 ID"为唯一键，保留最新一条评分记录；
• 类型转换：把 word_count、rating 字段转成正确的数值类型；
• 关联补全：把大量无效的 author_id、category_id 通过字典表补全；
• 时间字段规范化：统一转成yyyy-MM-dd格式，方便后续做时间维度统计。

清洗完的数据写入 DWD 层，我用一条简单的聚合 SQL 就能证明数据可用，比如统计评分大于 8 分的小说有多少本。这样在答辩时，随便抛一条 SQL 上去都能跑出有说服力的图表数据。

这里放一条我当时经常用的 DWD 层构建语句，清洗逻辑很直白：

INSERT OVERWRITE TABLE dwd_novel_detail SELECT novel_id, novel_name, author_id, category_id, intro, book_status, CAST(word_count AS BIGINT) AS word_count, CAST(score AS DECIMAL(3,2)) AS score, update_time FROM ods_novel_info WHERE novel_id IS NOT NULL AND score BETWEEN 0 AND 10 AND word_count > 0;

3.4 ADS 层聚合指标怎么设计

ADS 层是给可视化直接提供数据的，我当时做了四张表：分类热度统计表、评分分布统计表、字数区间统计表、时间维度热度统计表。每个统计需求对应一条 HQL，写起来没有难度，但是要有意识地对结果数量做限制，比如分类热度就取 Top 15，后端接口才不会卡顿。Hive 跑聚合还有一个优势：多个聚合可以共用同一张 DWD 表，只扫一遍数据，效率比直接读 CSV 高得多。

4. PySpark 推荐引擎：ALS 协同过滤的完整实现与调参思路

推荐算法是整个项目的技术核心，也是答辩最容易深挖的部分。我的策略是牢牢抓住 ALS（交替最小二乘法），它和 PySpark 的 ML 库配合得非常好，代码量不大，原理又足够撑起论文里的一个完整章节。

4.1 为什么选 ALS 而不是基于物品的余弦相似度

开题的时候我也考虑过用 ItemCF，就是通过计算物品间的相似度来做推荐。但后来发现两个问题：一是毕设场景数据量不大但维度已经不小，ItemCF 用余弦相似度是 O(n^2) 的复杂度，在单机伪分布式上跑起来很慢；二是 ALS 的分布式实现是 Spark MLlib 自带的，训练过程能真正跑在 Spark 集群上，更贴合"大数据"这个主题。而且 ALS 背后的矩阵分解思想非常好理解：把用户-物品评分矩阵拆成用户因子矩阵和物品因子矩阵，用低秩近似还原缺失评分。

用一张生活化的图景来解释：你有一张"用户 × 书"的大表格，表格里大部分格子是空的，ALS 就是想用两个小表格的乘积把空格子填上。小表格里的每一行/每一列是一串隐藏因子，比如"喜欢玄幻"、"偏爱短篇"、"对悬疑无感"——算法不告诉我们这些因子具体叫什么，但它能帮我们还原出最有解释力的数字。

4.2 从 Hive 取数到模型训练的完整代码

PySpark 读取 Hive 表有两种做法，一种是通过 SparkSession 的 sql 方法直接查询，另一种是用spark.read.table。我当时环境里 Hive 和 Spark 的集成已经配好，所以直接用第一种：

from pyspark.sql import SparkSession spark = SparkSession.builder \ .appName("NovelRecommendation") \ .config("spark.sql.warehouse.dir", "hdfs://localhost:9000/user/hive/warehouse") \ .enableHiveSupport() \ .getOrCreate() # 读取清洗后的评分数据 rating_df = spark.sql("SELECT user_id, novel_id, rating FROM dwd_rating_final") # ALS 要求 rating 字段必须是数值类型且有列名 from pyspark.sql.functions import col rating_df = rating_df.select( col("user_id").cast("int").alias("userId"), col("novel_id").cast("int").alias("itemId"), col("rating").cast("float").alias("rating") ) # 划分训练集和测试集 train_data, test_data = rating_df.randomSplit([0.8, 0.2], seed=42) from pyspark.ml.recommendation import ALS from pyspark.ml.evaluation import RegressionEvaluator als = ALS( maxIter=15, regParam=0.1, rank=20, userCol="userId", itemCol="itemId", ratingCol="rating", coldStartStrategy="drop" ) model = als.fit(train_data) # 评估 RMSE predictions = model.transform(test_data) evaluator = RegressionEvaluator( metricName="rmse", labelCol="rating", predictionCol="prediction" ) rmse = evaluator.evaluate(predictions) print(f"Root-mean-square error = {rmse}")

几个参数我解释得非常直白：

• rank：隐因子的数量。太小拟合不好，太大容易过拟合，我调参后在 20 左右效果最好。
• regParam：正则化系数，控制模型复杂度，防止过拟合。0.1 是一个相对稳的起点。
• maxIter：ALS 的迭代次数，15 次足够收敛，再大收敛收益很小。
• coldStartStrategy="drop"：这条必须有，否则测试集里出现新用户/新书时预测会得到 NaN，评估直接崩掉。

训练完成后，给每个用户生成推荐列表的代码也很简单：

# 给所有用户推荐 TopN=10 本书 user_recs = model.recommendForAllUsers(10) # 如果只想看某个用户 single_user = spark.createDataFrame([(1,)], ["userId"]) single_recs = model.recommendForUserSubset(single_user, 10)

4.3 评分稀疏和冷启动问题的实用处理

ALS 最怕的就是评分矩阵太稀疏。我当时爬虫爬到 30 万条评分，看起来很多，但分配到几千个用户头上，每人也就几十条。解决方案有两个方向：一是降低矩阵规模，对评分数量少于 5 条的用户做过滤，保证每个用户都有足够多的行为；二是用隐式反馈，把"有没有评过分"当成 0/1 标签喂给 ALS，这个做法对稀疏数据非常友好，在论文里也有足够的理论深度可以讨论。

冷启动问题我是这样解决的：新用户没有历史行为时，直接推荐全站热度最高的 Top-20 小说，这里"热度"用综合评分和评分人数加权算出来；新书没有评分时，加入同分类下热度最高的书里。这个策略逻辑简单，但在演示时特别有用——演示阶段新注册账号也能看到推荐结果，不会出现空白页面。

5. 可视化模块：从 Hive 查询结果到 ECharts 图表的全流程

很多同学做完推荐算法以为项目就结束了，其实可视化才是让整个系统"显得完整"的关键。标题里既然写了"小说可视化"，那这一块就绝对不是随便画几个柱状图那么简单。

5.1 可视化指标怎么设计，才能既好看又有说服力

我最后选了四个维度：

1. 小说分类热度排行榜：横向柱状图，展示玄幻、都市、历史等类型的作品数量和平均评分；
2. 评分分布直方图：验证数据分布是否符合常理，通常应该是一个集中在中间段的正态偏态分布；
3. 小说字数分布散点图/箱线图：挖掘"多长篇幅的书更受好评"这类关系；
4. 个人推荐页：展示给指定用户推荐的 Top-10 书籍列表和推荐理由。

这四个维度分别对应 ADS 层的四张表，后端接口直接查询即可。比较讨巧的地方是第四个维度——把推荐结果做成可视化接口，就把推荐算法和可视化串联在一起了，答辩时可以现场演示：输入用户 ID，前端立即展示出该用户的个性化书单，整个链路一目了然。

5.2 前端图表选型和后端接口设计

我用的前端是 Vue + ECharts，后端是 Flask。技术上不复杂，但有一个很重要的架构决策：展示用的聚合数据先由 Hive 算好，结果同步到 MySQL，后端接口从 MySQL 查，而不是每次请求都去跑 Spark 或者查 Hive。

原因是 Hive 的查询延迟太高，尤其是任务一多，几百毫秒甚至几秒的响应时间在演示时非常尴尬。离线计算和在线查询分离，是大数据系统里非常经典的设计思路，能写进论文里作为"实时/离线解耦"方案。

前端的关键代码其实很普通，但接口返回字段设计好后，图表渲染就很顺：

// 这是 Vue 组件里的核心部分：用 ECharts 画分类热度柱状图 const chart = echarts.init(document.getElementById('categoryHot')); fetch('/api/category_hot') .then(res => res.json()) .then(data => { chart.setOption({ title: { text: '小说分类热度 TOP15' }, xAxis: { type: 'category', data: data.map(item => item.category_name) }, yAxis: { type: 'value' }, series: [{ type: 'bar', data: data.map(item => item.book_count), itemStyle: { color: '#5470c6' } }] }); });

6. 部署与运行阶段必须绕开的五个坑：内存、编码、数据倾斜和版本兼容

这一章是全文最值得反复看的实战部分。我当时在部署阶段被坑了一周，几乎每个问题都在网上搜不到现成答案，最终靠查日志一步步解决。我把它们全部总结出来，希望能帮你省掉这部分时间。

6.1 伪分布式环境下，内存配置不够怎么办

用单机跑 Hadoop + Spark 最大的问题就是内存。默认配置下，NameNode、DataNode、ResourceManager、NodeManager、Spark Executor 全部挤在一台机器上，稍微大一点的数据集就能让系统直接卡死。

我的解决思路是做减法：HDFS 和 YARN 的内存参数手动写死，不给系统"自动分配"的机会。具体是在hadoop-env.sh里设置HADOOP_HEAPSIZE=512，在spark-defaults.conf里设置：

spark.driver.memory 2g spark.executor.memory 3g spark.executor.cores 2 spark.memory.offHeap.enabled false

一个关键心得：Spark 任务跑不动时，优先看是不是 Executor 拿不到内存，而不是怀疑代码写错。日志里出现Container is running beyond physical memory limits时，第一件事就是调大yarn.nodemanager.vmem-pmem-ratio，把虚拟内存比例从默认的 2.1 提高到 2.8 或更高。这个参数报错信息里经常不直接提示，非常容易卡住新手。

6.2 中文乱码，一个出现在三个环节的经典问题

中文乱码在 Hadoop、Hive、MySQL 三个环节都可能出现，每换一个环节，解决方式还不一样。

• 文件上传到 HDFS 之前，CSV 必须是 UTF-8 编码，Windows 下用记事本另存为 UTF-8 会带 BOM，这个 BOM 会让 Hive 表第一列字段名变成一个奇怪的字符；
• Hive 建表时建议显式指定TBLPROPERTIES('serialization.encoding'='UTF-8')；
• MySQL 这边建库时统一用CHARACTER SET utf8mb4，否则插入中文推荐结果时会报Incorrect string value错误。

这三个点我每一个都踩过。最隐蔽的是 BOM 那个，当时查了很久才发现第一列字段名user_id前面挂了一个不可见字符，导致按列名查数永远查不出来。

6.3 数据倾斜：热门书籍让某几个节点累死

推荐系统场景天然存在数据倾斜——热门小说的评分记录数量可能是冷门小说的几千倍。具体表现是：Spark 任务最后几个 Stage 卡住不动，日志里某几个 Executor 的 Shuffle 读取量远高于其他 Executor。

轻量级的处理是过滤掉评分数量过少的冷门书，我把评分少于 10 条的书直接丢出训练集，这其实也是提高推荐质量的操作。如果倾斜仍然严重，可以给 key 加盐再拆分，或者说加一个随机前缀，把热点 key 打散到多个分区去。论文里写这个优化点时导师通常都很认可，说明你踩过并发场景的真实问题。

6.4 PySpark 环境的版本兼容矩阵

PySpark 和 Hadoop 的版本兼容问题可能是整个项目里最劝退新手的点。我当时用的是 PySpark 3.x 搭配 Hadoop 3.x，整体顺利，但如果用旧教程搭 PySpark 2.x 配 Hadoop 2.x 就会遇到一堆javax.servlet冲突和Guava版本冲突。

一个特别实用的建议：不要在不了解版本关系的情况下，直接从 Maven 仓库拉最新版。去查阅官方文档上的 Compatibility Matrix，把 Hadoop、Hive、Spark、Java 四者的版本统一到一个已验证过的排列组合。我在本地用 Java 8 + Hadoop 3.2 + Hive 3.1 + Spark 3.1 组合跑通了全流程，这个组合网上教程多、资料全，比较适合作为参考基线。

6.5 在 Windows 上跑 Spark 时的一个隐藏问题

如果你在 Windows 上本地跑 PySpark，大概率会遇到Failed to locate the winutils binary in the hadoop home directory这样的报错。这是 Spark 在 Windows 上需要访问 Hadoop 的本地工具。解决办法有两个：一个是在项目里放一个 winutils.exe 并设置环境变量HADOOP_HOME，另一个更省事的方法是直接用 Docker 起一个 Linux 环境，把整个 Hadoop 集群跑在容器里。我当时为了省时间选择了本地配置 winutils，如果你图省心，更推荐直接用容器方案。

7. 论文、PPT 与答辩准备：把工程量讲成亮点

最后一章分享一些关于毕业设计"包装"的经验。项目做得再好，讲不出来等于白做。

7.1 论文结构怎么安排最合理

我的论文目录大致是这样的：绪论（背景、意义、研究现状）、相关技术介绍（Hadoop、Hive、PySpark、推荐算法原理）、需求分析（功能需求、非功能需求）、系统设计（总体架构、数仓设计、功能模块设计）、系统实现（爬虫、数仓、推荐、可视化各一章）、系统测试（功能测试、性能测试）、总结与展望。

这里有一个非常关键的写作技巧：把"技术选型的原因"单独写一个小节，不要只列技术栈。比如写"为什么使用 Hive 而不直接使用 Spark SQL"，这个分析过程会让论文看起来有思想，而不是简单的工具罗列。论文里的图片尤其重要——架构图最好亲自画清楚，数仓分层图、推荐流程图、可视化页面截图，这些是答辩评委最会盯的内容。

7.2 PPT 讲解的顺序和主次

答辩 PPT 不要按论文章节的顺序平铺，要用"项目演示驱动"的顺序来讲：

1. 开场直接亮出可视化页面，用一个具体的用户推荐结果吸引注意力；
2. 再讲整体架构图，说明 Hadoop + Hive + PySpark 各自负责什么；
3. 然后讲数据来源和爬虫，让评委知道数据是真实采集的，不是捏造的；
4. 接着讲数仓建设和清洗逻辑，强调 ODS、DWD、ADS 三层结构；
5. 最后重点讲 ALS 推荐模型、参数调优和评估结果。

这样的顺序让评委先看到了完整效果，再听技术细节，理解成本低很多。那些"爬虫被反爬、中文乱码、数据倾斜"的踩坑经历，非常适合放在技术细节里作为"项目亮点"来讲，不要藏着掖着，真实的问题处理过程会让答辩更有说服力。

7.3 决赛圈高频答辩问题清单

我把自己被问到的问题和被朋友问过的问题整理成一个清单，你提前对着练一遍：

• ALS 的原理是什么？矩阵分解的目标函数怎么写？
• 为什么用 ALS 而不用其他协同过滤算法？
• 你的训练集、测试集怎么划分？RMSE 是多少？
• 数据量这么小，为什么还要用 Hadoop？
• Spark 任务内存溢出怎么排查？
• 新用户没有评分数据，系统怎么推荐？
• 整条数据链路如果某一步失败了，怎么处理？

对于第一个问题，建议把 ALS 的目标损失函数大概写出来，不需要完整推导，但要让评委看到你能解释正则项和隐因子的含义。第二个问题的核心点在于稀疏矩阵下 ALS 的并行化优势。

最后分享一个我个人的体会：毕设项目做到后面，真正值钱的不是你用了多高深的算法，而是你把整个数据链条、工程链路做得有多完整、多自洽。一个能跑通、能演示、能讲清楚自己每一步决策原因的完整项目，远远比一个"模型分数好看但部署不上"的半成品更有说服力。这套小说推荐系统做完之后，不但让我顺利通过了答辩，还在秋招面试时成为我讲大数据项目经历的核心素材。如果你也正在为选题头疼，不妨照这个方案试一次，有任何问题随时可以再来交流。