Spark与协同过滤小说推荐平台实战：从环境搭建到答辩全攻略

每年三四月份，总有一批计算机专业的学生在毕设和答辩之间反复横跳。如果你拿到的题目是"基于Spark与协同过滤的小说推荐平台"这种，八成已经被三座大山压得喘不过气：第一座是Hadoop生态的环境搭建，第二座是协同过滤算法的数学推导，第三座是Django加前端把所有东西串起来。这篇文章就是把这套完整链路从头到尾梳理一遍，会直接给出我当时做类似项目时的环境版本、踩坑记录、核心代码思路，以及答辩时老师真正会问的问题。适合正在做大数据方向毕设、或者想用Spark练手一个完整项目的同学参考，不是泛泛讲概念，而是能直接照着落地的实战经验。

先说清楚一件事情：这个项目表面上是"推荐系统"，实际上是典型的"大数据全流程"项目。从数据采集、数据清洗、特征加工，到算法训练、模型评估，再到Web展示、可视化大屏，每一步都有对应的技术组件，这才是它适合做毕设的原因——覆盖的知识点足够多，每一层都能写出内容。但知识点多也意味着坑多，尤其是环境搭建环节，我见过太多同学在Hadoop集群上耗了两周最后项目只跑了三天，所以这篇文章会花比较大的篇幅讲环境问题和排错思路。

如果你正准备开题，或者已经卡在半路，希望这篇东西能帮你把整个项目的骨架立起来。后面我会按照我自己做这个项目的顺序来写，从技术选型开始，一路推到答辩准备，中间穿插大量真实出现的报错和处理办法。

1. 为什么这套技术栈是大数据毕设的稳妥组合

很多人一上来就纠结"我要不要用Flink""要不要换成ClickHouse""是不是用MySQL就够了"。作为过来人，我劝你先想清楚一个问题：毕设的核心目标是让评委老师一眼看出你掌握了大数据处理的全链路，而不是单纯追求技术最前沿。Spark加Hadoop加Hive加Django这套组合，恰好能在不过度复杂的前提下覆盖完整的大数据项目生命周期。

1.1 项目定位：一个小说推荐平台需要哪几个层次

拆开来看，这个平台至少要包含四层：

• 数据存储层：小说信息、用户信息、用户行为记录（评分、点击、收藏）都需要落盘存储。这里有两类存储并存：HDFS作为大数据底座，MySQL作为业务库（给Django用）。
• 数据处理层：原始日志和用户行为数据往往是脏的、冗余的，需要清洗和特征提取。Hive负责做离线的数据加工，把明细数据聚合成算法可用的宽表。
• 算法层：协同过滤推荐引擎，基于用户的历史行为计算相似度，生成Top-N推荐列表。Spark负责跑分布式计算，把推荐结果批量产出。
• 应用展示层：Django搭建Web平台，展示小说列表、推荐结果、用户评分操作，同时用ECharts做可视化大屏，把数据统计结果直观呈现。

这个架构和一线互联网公司的推荐系统主干是类似的，只是规模缩小了而已。毕设答辩的时候，老师问"你的项目架构是什么"，你把这个分层讲清楚，技术分数的基本盘就稳了。

1.2 每个组件在架构里的真实分工

很多人把Hadoop、Spark、Hive当成三个孤立的东西背概念，实际上它们在项目里是协作关系：

• Hadoop：提供HDFS分布式文件系统和Yarn资源调度。所有原始数据文件上传后存在HDFS上，Spark和Hive跑任务时从HDFS读写数据。
• Spark：负责计算密集型的算法任务，主要是协同过滤模型的训练和推荐结果的生成。它比MapReduce快得多，Debug也容易，而且有MLlib库可以直接调ALS算法。
• Hive：做数据仓库的ETL工作，把原始日志转化成结构化的表。Hive的SQL写起来简单，适合做数据统计分析（评分分布、热度排行、用户活跃度等），产出物供可视化和推荐算法使用。
• Django：面向用户的Web服务。用户在前端注册登录、浏览小说、打分，这些数据写回MySQL；推荐结果从Hive或Spark产出的结果表里读取，渲染到页面上。

一句话总结：Hadoop管存储，Hive管数仓加工，Spark管算法计算，Django管业务展示。各司其职，这正是毕设论文里"系统架构设计"章节最好的素材。

1.3 环境版本怎么选：不要自己想当然，直接抄作业

版本兼容性是环境搭建阶段最大的坑。我在GitHub上帮人看过太多报错，最后定位基本都是版本冲突。给你一份我实测稳定的组合：

强调一点：Hadoop的hadoop-3.3.6.tar.gz要和Spark的spark-3.3.4-bin-hadoop3.tgz配套。如果你下载错了Spark的版本（比如下成hadoop2.7编译版），运行时会各种找不到类。另外JDK一定要先配好JAVA_HOME，再装Hadoop。顺序反了会出现JAVA_HOME is not set的报错，虽然不是致命问题，但特别影响心态。

2. 环境搭建的高频问题：把最常见的坑先排干净

这个项目的环境搭建能劝退一半人。为了不让读者在开局就崩溃，我把当时遇到的高频问题和排查思路完整写出来。如果你已经搭建完成，可以直接跳到第三节；如果还没开始，这一节能帮你少走两天弯路。

2.1 Hadoop伪分布式还是完全分布式：毕设场景怎么选

技术选型上第一个争论就是：搭建单机伪分布式还是三节点完全分布式。

我的建议是：如果你的笔记本内存小于16G，老老实实做伪分布式。原因很简单，三节点集群跑起来光是Java进程就要吃掉很多内存，NameNode、DataNode、ResourceManager、NodeManager再加上Spark的进程，内存不够会频繁OOM，查起来极其痛苦。而伪分布式模式下所有进程运行在同一台机器上，完全可以验证HDFS读写、MapReduce提交、Spark on Yarn的完整流程，对毕设来说已经足够了。

但如果你的毕设题目明确要求"搭建分布式集群"，或者导师希望看到多节点效果，那可以用三台虚拟机（每台分配4G内存）做完全分布式。注意这三点：

• 配置/etc/hosts，三台机器的主机名解析必须写好，不要用IP直连
• SSH免密登录要配置好，ssh localhost也必须能免密，否则启动时反复要密码
• core-site.xml和hdfs-site.xml里的路径要提前建好，手动mkdir -p，不要依赖脚本自动创建

无论哪种模式，格式化NameNode的命令是hdfs namenode -format，只需要执行一次。如果你重复执行格式化，会出现集群元数据不一致的问题，DataNode可能起不来。

2.2 Spark部署模式：local、Standalone、Yarn三选一

Spark有三种常见部署模式，很多同学分不清区别，直接上来用local模式写完代码就交差，其实这样会让你失去最重要的"分布式计算"展示点。

• local模式：不需要任何集群，Spark跑在本地线程里。适合写代码调试和快速验证逻辑，但是体现不了Spark的优势。
• Standalone模式：Spark自带的资源调度。需要启动Master和Worker进程，配置简单，但每次提交代码前要手动保证集群状态正常。
• Yarn模式：把资源调度交给Hadoop的Yarn，Spark只负责计算。这是生产环境最常用的方式，也是毕设答辩时最容易被加分的地方，因为展示了Spark和Hadoop的整合能力。

我强烈建议你至少在Yarn模式下提交一次推荐算法任务，哪怕数据量很小。这一操作会让答辩老师认为你真正理解了Spark的分布式计算流程，而不是只会在本地跑跑函数。

2.3 Hive的安装与MySQL元数据库配置：必坑清单

Hive启动时依赖Metastore，默认使用内置的Derby数据库，但Derby不支持多会话同时操作，非常难用。所以一定要配置成MySQL存储元数据。

在Hive的conf/hive-site.xml里，核心配置如下：

<property> <name>javax.jdo.option.ConnectionURL</name> <value>jdbc:mysql://localhost:3306/hive_metastore?createDatabaseIfNotExist=true</value> </property> <property> <name>javax.jdo.option.ConnectionDriverName</name> <value>com.mysql.cj.jdbc.Driver</value> </property> <property> <name>javax.jdo.option.ConnectionUserName</name> <value>hive</value> </property> <property> <name>javax.jdo.option.ConnectionPassword</name> <value>你的密码</value> </property>

这里有一个容易踩的坑：新版MySQL驱动类名从com.mysql.jdbc.Driver改成了com.mysql.cj.jdbc.Driver，如果你拷贝的文章是老版本配置，启动Hive时会报ClassNotFoundException。另外，检查hive-site.xml里是否配置了hive.metastore.schema.verification=false，很多教程漏掉了这一项，导致Metastore schema version is not supported异常。

2.4 热搜里的三个高频报错：现场排查思路

场景一：hadoop启动格式化失败

很多同学第一次格式化NameNode，报错信息中带有Cannot lock storage或NameNode is already formatted。原因是格式化需要清空dfs.namenode.name.dir指向的目录。假设你的name.dir配置为/usr/local/hadoop/tmp/dfs/name，正确的格式化流程是：

# 停止所有Hadoop进程 stop-all.sh # 清空临时数据和元数据目录 rm -rf /usr/local/hadoop/tmp/dfs/name/* rm -rf /usr/local/hadoop/tmp/dfs/data/* # 重新格式化 hdfs namenode -format

格式化完成后，日志里会出现successfully formatted字样，不用管那些WARN输出，直接执行start-dfs.sh再看进程状态。

场景二：spark on yarn cpu只能用1个

这个问题刷新过很多人的认知。明明Spark程序里设置了spark.executor.cores=4，但观察Yarn资源页面发现每个Executor还是只用了1个vCores。原因有两个：

第一个原因是Yarn容器最小分配粒度。在yarn-site.xml中有一个参数yarn.scheduler.minimum-allocation-vcores，默认值是1。即使你请求4个核，调度器会按最小粒度逐个分配，最终效果是4个容器，每个1核。

第二个原因更隐蔽：Spark请求的是逻辑核，而Yarn上的yarn.nodemanager.resource.cpu-vcores默认没有开启物理核映射。如果你配置不对，程序认为获得了4个核，但实际只有1个在干活。排查方法是去Yarn的资源管理器页面看Active Nodes信息，确认每个NodeManager上报的VCores Total数量。

在Standalone模式下可能还有另一层问题，JVM默认只识别物理CPU，需要设置SPARK_WORKER_CORES或提交时指定--total-executor-cores。生产上还会涉及绑核的问题，但毕设场景你只需要理解：资源请求是分层传递的，你写在Spark代码里的配置并不代表最终实际分配结果。

场景三：Hive insert cannot recognize input near

这个报错我见到的案例非常多，但每次原因都不一样。常见的有三种：

1. SQL语法位置错误，比如INSERT INTO没写在SELECT前面，建议把SQL在MySQL或Navicat里先跑通再搬到Hive中。
2. 字段类型不匹配，比如目标表定义的是DECIMAL(10,2)，你插入的数据里有abc字符串。
3. 使用了未注册的自定义函数（UDF），Hive不识别这个方法名。

排查这类报错的关键是仔细看堆栈信息的at line X部分，它会明确指向SQL中出错的位置。下次遇到不要急着改SQL，先定位是语法问题、类型问题还是函数问题。

3. 数据获取与数仓建模：推荐系统好不好用，七成看数据

环境搭好之后，最让人头大的就是：数据从哪里来。

3.1 数据来源方案对比：爬虫、公开数据集还是手工造数

我见过三种做法，各有优劣：

方案一：爬虫抓取真实小说数据

有人会去小说网站抓取书名、分类、简介、评论数等信息，再模拟用户产生评分行为。这种做法最真实，但也有风险，网站的反爬机制和robots协议都要考虑。另外毕设论文里写"爬取XX网站数据"可能会引起评审对合规性的关注，所以不推荐大规模爬取。

方案二：使用公开数据集

比如Book-Crossing数据集（国外图书评分数据）、MovieLens数据集（虽然是电影，但结构和图书几乎一样）。这些数据完整性好、字段清晰，适合做算法训练。缺点是没有中文小说数据，如果导师要求"中文效果"，可能需要额外做一层映射。

方案三：结合规则手工造数

准备1000本小说，规则化生成1万条模拟的用户评分记录。这样做的好处是数据可控，评分的分布能人为设计，推荐算法训练出来的效果更"好看"，适合演示。缺点是你需要写一段随机数据生成脚本。

我当时的做法是组合方式，用MovieLens的结构做参考，自己构造了小说数据集（800本小说，3200个用户，约9万条评分记录），既保证了数据规模能支撑分布式计算演示，又完全可控。

3.2 数仓表设计：从原始数据到算法宽表

在Hive中建几张核心表，几乎任何推荐项目都能沿用这个模型。

第一张是小说信息表ods_novel_info，敏感字段主要在源数据，不需要额外处理，字段包括：

CREATE TABLE ods_novel_info ( novel_id INT, novel_name STRING, author STRING, category STRING, status STRING COMMENT '连载/完结', word_count INT, rating DOUBLE ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS TEXTFILE;

在真实数据处理里，一般会先把数据放到TEXTFILE格式的ODS层，后续再转成PARQUET或ORC列式存储。这里也建议你顺手加一张dw_novel_info表，使用ORC格式存储，并设置合理的分桶，比如按novel_id分10个桶，这样后续查询统计的效率明显提升：

CREATE TABLE dw_novel_info ( novel_id INT, novel_name STRING, author STRING, category STRING, status STRING, word_count INT, rating DOUBLE ) CLUSTERED BY (novel_id) INTO 10 BUCKETS STORED AS ORC;

第二张是用户行为表ods_user_rating，核心字段包括用户ID、小说ID、评分（1-5分）、时间戳。注意一点，如果你想体现Hive的完整性，可以加入分区字段dt，按天分区存储，即使数据量很小，也能展示你掌握了分区表的思想。这点在答辩上值得讲一讲。

3.3 一张表说清Hive三兄弟：partition by、distribute by、sort by

热搜词里那么多人在查这三个关键词的区别，说明面试官和答辩老师都爱问。很多人把partition by理解成"分区表"，把distribute by理解成"排序"，其实不然。

• partition by是用于建表时的分区列，决定数据在HDFS目录上的存储划分方式，比如按dt='2024-05-01'形成一个子目录。它的核心作用是查询裁剪。
• distribute by是控制MapReduce阶段数据如何分发到Reducer，决定的是数据分发的键，值相同的行会进同一个Reducer。
• sort by是Reducer内部的排序，它只保证每个Reducer内部有序，不保证全局有序。

举个例子，你要把评分数据按小说ID分发到多个Reducer，在每个Reducer内部按评分降序排，可以这样写：

SELECT novel_id, user_id, rating FROM ods_user_rating DISTRIBUTE BY novel_id SORT BY rating DESC;

而全局排序则用ORDER BY。这组概念不搞清楚，写优化SQL时很容易踩坑。

3.4 离线特征计算：写几个真正用得上的统计SQL

建好表之后，用Hive做几类简单的统计，产出后面可视化和算法都要用到的数据。

统计每本小说的热度（平均分、评分人数）：

INSERT OVERWRITE TABLE dw_novel_stats SELECT novel_id, COUNT(*) AS rating_cnt, AVG(rating) AS avg_rating, PERCENTILE(CAST(rating AS INT), 0.5) AS median_rating FROM ods_user_rating WHERE dt = '2024-05-01' GROUP BY novel_id;

这里用PERCENTILE计算中位数，比单纯平均值更能反映评分分布，答辩时也可以说这是为了减少极端评分的影响。

统计每个用户的活跃度（评分次数、平均分）：

SELECT user_id, COUNT(*) AS rating_cnt, AVG(rating) AS avg_rating FROM ods_user_rating GROUP BY user_id HAVING COUNT(*) >= 5;

为什么要过滤掉评分次数少于5的用户？因为协同过滤的基石是用户行为的充分性——一个只给过1次评分的用户，根本无法和其他用户计算有意义的相似度。这个思路一定要写进你的论文里，能体现你对推荐系统基本假设的理解。

4. 协同过滤推荐引擎：从数学原理到Spark MLlib实现

环境稳定、数据就位，接下来是整个项目最核心的部分——推荐算法。

4.1 基于用户的协同过滤还是基于物品的协同过滤

协同过滤（Collaborative Filtering）的核心思想是：你喜欢的物品，和你相似的人也会喜欢；或者，和你看过的小说相似的小说，你可能也爱看。

**基于用户的协同过滤（UserCF）**首先计算用户之间的相似度，找到目标用户的K个最相似邻居，再把邻居们喜欢但目标用户没看过的书推荐给他。这种算法适合用户数量不是特别庞大的场景，因为用户相似度矩阵的规模是用户数乘用户数。

**基于物品的协同过滤（ItemCF）**计算物品之间的相似度，给用户推荐和他历史评分高的物品最相似的物品。这种算法在电商场景中更常见，因为它能解释"看了又看"，而且物品数量相对稳定，相似度矩阵可以离线定时更新。

对于小说推荐平台，我的建议是优先实现ItemCF，理由有两点：小说的数量（千级别）远小于用户数量（万级别），计算物品相似度矩阵的代价更低；而且推荐结果更容易做业务解释——"因为你喜欢《三体》，所以推荐《球状闪电》"，这一句话在答辩演示时比冷冰冰的"计算相似度"直观得多。

如果你想做得更深入一点，可以同时实现两种算法，让用户在前端切换"为我推荐"和"相似小说"，但核心逻辑建议以ItemCF为主。

4.2 相似度计算的数学原理：不要只会掉包

面试官和答辩老师很喜欢让你手写相似度公式。三个最常用的相似度算法必须了然于心：

余弦相似度先计算两个向量夹角的余弦值，公式是：

cos(θ) = (A · B) / (||A|| ||B||)

比如用户A给5本小说的评分为[5, 0, 3, 0, 1]，用户B给评分为[4, 0, 5, 0, 2]，分子是5×4+0×0+3×5+0×0+1×2 = 37，分母是两个向量的模的乘积，约等于5.92×6.71，最后相似度约为0.93。这个值越接近1，代表两个用户越相似。

皮尔逊相关系数对评分的绝对值不敏感，它把每个用户减去自己的平均分再计算相似度。公式是：

Pearson(A, B) = Σ(Ai - Ā)(Bi - B̄) / sqrt(Σ(Ai - Ā)^2) * sqrt(Σ(Bi - B̄)^2)

举个例子，一个用户习惯打低分（平均分2分），另一个用户习惯打高分（平均分4分），如果他们都觉得某本书不错，直接用余弦计算相似度会偏低，但用皮尔逊会把这种评分尺度的差异消除掉。

Jaccard相似度用于二值化数据，只关心用户是否对物品产生过行为，不关心分值：

J(A, B) = |A∩B| / |A∪B|

比如用户A点了10本书，用户B点了8本书，其中有5本交集，那Jaccard相似度就是 5/(10+8-5)=5/13≈0.38。

在Spark MLlib的ALS实现中，你不需要手动写这些公式，但理解它们能帮助你在答辩时解释为什么参数要这么选。

4.3 Spark MLlib中的ALS算法实现：完整可跑的代码

ALS（Alternating Least Squares，交替最小二乘）是Spark中做协同过滤的标准实现。它的原理是：把用户-物品评分矩阵分解成两个低维矩阵的乘积（用户因子矩阵和物品因子矩阵），通过迭代优化使预测误差最小化。代码实现非常简洁。

先用pyspark跑通，下面是核心代码：

from pyspark.sql import SparkSession from pyspark.ml.recommendation import ALS from pyspark.ml.evaluation import RegressionEvaluator spark = SparkSession.builder \ .appName("NovelRecommendALS") \ .config("spark.executor.memory", "2g") \ .config("spark.driver.memory", "2g") \ .getOrCreate() # 读取Hive中的评分数据 rating_df = spark.sql(""" SELECT user_id, novel_id, rating FROM dw_user_rating WHERE dt = '2024-05-01' """) # 划分训练集和测试集 train_df, test_df = rating_df.randomSplit([0.8, 0.2], seed=42) # ALS模型：显式反馈 als = ALS( userCol="user_id", itemCol="novel_id", ratingCol="rating", rank=10, # 隐因子数量 maxIter=10, # 最大迭代次数 regParam=0.1, # 正则化参数，防止过拟合 coldStartStrategy="drop", nonnegative=True ) model = als.fit(train_df) # 在测试集上进行预测 predictions = model.transform(test_df) # 评估：RMSE (均方根误差) evaluator = RegressionEvaluator( metricName="rmse", labelCol="rating", predictionCol="prediction" ) rmse = evaluator.evaluate(predictions) print(f"Root Mean Squared Error = {rmse}") # 为每个用户生成Top10推荐 user_recs = model.recommendForAllUsers(10) # 保存到Hive或临时表 user_recs.write.mode("overwrite").saveAsTable("dw_user_rec_top10")

这段代码有三个关键点：

1. coldStartStrategy="drop"会在预测时过滤掉训练集中没出现过的新用户或新物品，避免产生NaN预测值。
2. rank值代表隐因子的维度。太小欠拟合，太大容易过拟合还拖慢训练速度，毕设场景取10到20之间比较合适。
3. ALS默认假设评分是连续数值，如果你的评分是1-5的整数，需要把rating列转成FloatType，否则会遇到类型转换报错。

4.4 模型评估：用RMSE、MAE、Precision、Recall四个指标让评委无话可说

推荐模型的评估分两类，一类是评分的预测误差，一类是推荐列表的质量。

评分预测误差用RMSE和MAE，Spark代码里可以直接算：

from pyspark.ml.evaluation import RegressionEvaluator rmse_evaluator = RegressionEvaluator( metricName="rmse", labelCol="rating", predictionCol="prediction" ) mae_evaluator = RegressionEvaluator( metricName="mae", labelCol="rating", predictionCol="prediction" ) rmse = rmse_evaluator.evaluate(predictions) mae = mae_evaluator.evaluate(predictions) print(f"RMSE = {rmse:.4f}, MAE = {mae:.4f}")

推荐列表质量常用Precision@K和Recall@K，衡量推荐结果中有多少是用户真实喜欢的。这里有个实用技巧：把实际评分大于等于4分的物品视为"正样本"，然后和推荐列表做交集。

def precision_recall_at_k(predictions, k=10, threshold=4.0): # 取出每个用户真实高分的小说ID集合 real_positives = predictions.filter(predictions.rating >= threshold) \ .groupBy("user_id") \ .agg(F.collect_set("novel_id").alias("real_items")) # 取出每个用户预测的TopK推荐 top_k = predictions \ .orderBy(["user_id", "prediction"], ascending=[True, False]) \ .groupBy("user_id") \ .agg(F.collect_list("novel_id").alias("rec_items")) \ .withColumn("rec_items", F.slice("rec_items", 1, k)) joined = real_positives.join(top_k, "user_id") # 计算每个用户的精确率和召回率，再求平均 ...

需要提醒一句，在真实项目中往往是"召回+排序"两阶段推荐，先用协同过滤粗粒度召回候选集，再用CTR模型精排。毕设不需要做到这步，但可以在论文"不足与展望"里提一句，显得你有视野。

4.5 冷启动问题的三种处理办法

协同过滤天然有个死穴：新用户没有行为记录，新书没有评分数据，推荐结果为空。如果你的平台是真实上线的，这个问题必须解决。

常用处理方案有三种：

1. 热门推荐兜底：对新用户直接推荐全站热度Top10（按评分人数、平均分、阅读量加权排序）。代码实现很简单，从dw_novel_stats表里取avg_rating和rating_cnt排序即可。
2. 基于内容推荐辅助：抽取小说的分类、标签、作者等特征，新书上架时直接推荐同分类下的热门小说。这需要用到TF-IDF或Word2Vec做文本向量化，工作量稍大。
3. 混合策略：平时用协同过滤，遇到用户行为记录少于5条时切换到热门排名推荐。这种"算法开关"在工程上叫做策略降级，是一种很实用的兜底手段。

在Django接口设计中，冷启动的逻辑应该写到视图层，当user_rating_count < 5时走备用SQL，否则走推荐结果表。

5. Django后端：把推荐结果变成一个个可以访问的页面

算法产出了推荐列表，接下来要靠Django把结果变成Web页面。这一节不讲基础的Django教程，只讲和这个项目强相关的设计决策和代码实现。

5.1 Django项目结构设计：合理分层，别把所有代码堆在views.py

很多毕设代码的典型问题是一个views.py文件几千行，所有功能逻辑全写在里面。作为软件工程的基本素养，建议按下面方式组织：

novel_reco/ ├── manage.py ├── config/ # 项目配置（settings、urls、wsgi） ├── apps/ │ ├── users/ # 用户注册、登录、个人信息 │ ├── novels/ # 小说列表、小说详情、搜索 │ ├── ratings/ # 评分接口 │ ├── recommendations/ # 推荐接口 │ └── dashboard/ # 可视化大屏页面 ├── static/ ├── templates/ └── scripts/ ├── etl_hive.sql ├── train_als.py └── generate_rating_data.py

按业务模块拆分成多个app，不要Django项目默认只有一个app。评委老师看你项目结构的时候，这种分层的组织方式会直接加分。

5.2 数据模型设计：MySQL中至少要有三张核心表

Django的ORM模型对应MySQL的业务表，设计如下：

from django.db import models class User(models.Model): username = models.CharField(max_length=50, unique=True) password_hash = models.CharField(max_length=128) created_at = models.DateTimeField(auto_now_add=True) class Novel(models.Model): novel_id = models.IntegerField(unique=True) title = models.CharField(max_length=200) author = models.CharField(max_length=100) category = models.CharField(max_length=50) status = models.CharField(max_length=20) word_count = models.IntegerField() rating = models.FloatField() description = models.TextField() class Rating(models.Model): user = models.ForeignKey(User, on_delete=models.CASCADE) novel = models.ForeignKey(Novel, on_delete=models.CASCADE) score = models.IntegerField(choices=[(i, i) for i in range(1, 6)]) created_at = models.DateTimeField(auto_now_add=True) class Meta: unique_together = ('user', 'novel')

这里有一个经常被忽视的点：Rating表一定要加unique_together约束，确保同一个用户对同一本小说只能有一条评分记录。否则用户在前端手滑点两次评分，就会产生两条数据，导致协同过滤的数据质量出现混乱。

5.3 推荐接口的两种实现方式：实算和预计算

推荐结果的查询方式有两种思路：

方式一：实时计算

用户请求推荐接口时，Django实时调用Spark任务或读取算法模型结果，计算Top-N列表。这种方式的实时性好，但需要维护Spark服务常驻，响应时间可能较长，对毕设演示不友好。

方式二：离线预计算+在线读取

Spark每天定时计算好每个用户的Top-N推荐列表，写入MySQL的recommendation表，用户在页面上请求时直接查表返回。这种思路更贴近生产环境"离线计算、在线服务"的架构，适合毕设。我强烈推荐这种方式。

对应的模型设计：

class Recommendation(models.Model): user = models.ForeignKey(User, on_delete=models.CASCADE) novel = models.ForeignKey(Novel, on_delete=models.CASCADE) rank = models.IntegerField() # 推荐排序 score = models.FloatField() # 推荐分数 reason = models.CharField(max_length=200, blank=True) # 推荐理由 created_at = models.DateTimeField(auto_now_add=True) class Meta: ordering = ['user', 'rank']

这里推荐加上reason字段。比如"因为你看过《三体》，推荐《球状闪电》"，推荐理由能让用户感知到推荐系统的存在。业务解释性也是推荐系统的重要指标。

5.4 从Spark结果到Django：数据衔接的关键一步

Spark产出的推荐结果在HDFS或Hive表中，Django不能直接查询Hive（性能太差）。衔接方案是：Spark把结果导出到MySQL表，Django再从MySQL中读取。用Spark写MySQL的代码片段如下：

user_recs.write \ .format("jdbc") \ .option("url", "jdbc:mysql://localhost:3306/novel_reco") \ .option("dbtable", "recommendation") \ .option("user", "root") \ .option("password", "你的密码") \ .option("driver", "com.mysql.cj.jdbc.Driver") \ .mode("overwrite") \ .save()

Django视图层的处理非常简洁：

def recommend_view(request): user = request.user recs = Recommendation.objects.select_related('novel').filter(user=user) novels = [rec.novel for rec in recs] return render(request, 'recommendations.html', {'novels': novels})

6. 可视化大屏：用ECharts把数据讲明白

毕设答辩能不能吸引眼球，可视化占了非常大的比重。无论你的算法多复杂，如果页面展示是一个"白底黑字"列表，说服力会大打折扣。一个好看的可视化大屏，能在3分钟内让老师理解你做了什么。

6.1 可视化面板的指标设计：不要堆图表，要有逻辑

我建议大屏上放以下几类图表，逻辑上层层递进：

• 顶部全局KPI卡片：总小说数、总用户数、总评分记录数、日均评分次数
• 中部左侧：小说分类占比（饼图）；小说评分分布（柱状图）
• 中部中间：热门小说Top10（横向条形图）；用户活跃度折线图（按时间）
• 中部右侧：基于用户协同的Top10推荐名单表
• 底部：最近评分动态（滚动列表）

有一个关键取舍需要说清楚：大屏是用来支持决策和展示"数据洞察"的，不是用来堆花哨动效的。每一个图表必须对应一个业务问题。比如"评分分布"回答的是"平台评分是否虚高"，"分类占比"回答的是"平台哪类书最受欢迎"。

6.2 Django配合ECharts的数据接口写法

ECharts本身是一个前端图表库，数据源来自Django接口。最方便的方法是写一个只返回JSON的接口：

import json from django.http import JsonResponse from django.db.models import Count, Avg from .models import Novel, Rating def api_category_stats(request): stats = Novel.objects.values('category') \ .annotate(cnt=Count('id')) \ .order_by('-cnt') data = { "categories": [item['category'] for item in stats], "counts": [item['cnt'] for item in stats] } return JsonResponse(data)

前端ECharts初始化时通过fetch或axios调这个接口，把返回的数组塞进option.series.data即可。记住一点：接口返回的JSON结构要稳定，前后端约定清晰，不要频繁改字段名。

6.3 图表组件代码参考：评分分布柱状图

一个可以直接抄的示例，评分分布柱状图的配置项：

fetch('/api/rating_distribution') .then(res => res.json()) .then(data => { var chart = echarts.init(document.getElementById('ratingChart')); chart.setOption({ title: { text: '评分分布', left: 'center' }, tooltip: { trigger: 'axis' }, xAxis: { type: 'category', data: data.scores }, yAxis: { type: 'value' }, series: [{ type: 'bar', data: data.counts, itemStyle: { color: function(params) { var colors = ['#5470c6', '#91cc75', '#fac858', '#ee6666', '#73c0de']; return colors[params.dataIndex % colors.length]; } } }] }); });

评分分布用柱状图，5个柱子对应1-5分的评分人数。这个图能直观展示你的评分数据是否大致符合正态分布或者偏态分布，也方便在答辩时解释数据的合理性。

6.4 大数据组件监控可视化：另一个加分思路

如果你搭建的是真实的三节点集群，还可以额外做一个"集群状态监控面板"，通过读取jps命令的输出和HDFS的报告，展示HDFS存储使用情况、DataNode存活状态、Spark任务的运行情况。实现方式可以考虑用Django定时读取hdfs dfsadmin -report和yarn application -list的输出来实现。

这个面板不涉及算法，但它能让评委直观感受到"集群在运行"，比纯页面展示更贴近"大数据平台"的概念。有能力的同学值得一试。

7. 论文写作、答辩展示与面试延伸：让努力变成分数

很多人大意地以为项目做完就等于毕设做完了，但实际上论文和答辩的表现对最终成绩影响很大。别辛辛苦苦干活，最后栽在表达上。

7.1 论文的章节结构建议：标题目录直接照抄

一篇大数据毕设论文的正常结构如下：

• 第一章 绪论（背景、意义、国内外研究现状、论文结构）
• 第二章 相关技术介绍（Hadoop、Spark、Hive、Django、协同过滤算法原理）
• 第三章 系统需求分析（功能性需求、非功能性需求、用例图、流程图）
• 第四章 系统设计（总体架构设计、模块设计、数据库设计）
• 第五章 系统实现（环境部署、核心算法实现、各模块界面截图和代码说明）
• 第六章 系统测试（功能测试、性能测试、推荐效果分析）
• 第七章 总结与展望

有一个经常被忽视的点：第二章的相关技术介绍不要写成百科词条。技术介绍要和你后续用的功能强相关，比如介绍Spark时侧重MLlib，介绍Hive时侧重分区表和窗口函数，介绍Django时侧重ORM和MVT架构。这样整篇论文才有逻辑闭环。

7.2 答辩演示清单：把最稳的状态留给评委

根据我几次参加毕业答辩的经验，给你一份演示前的检查清单：

• 确认虚拟机和Hadoop、Spark、Hive相关进程全部启动正常，jps能看到NameNode、DataNode、ResourceManager、NodeManager等进程
• 确认MySQL服务已启动，Django项目能正常运行
• 提前在推荐结果里准备好一个有丰富历史行为的演示账号，避免演示时因为冷启动而推荐列表为空
• 提前准备好300个用户以上的行为数据，让大屏图表显得丰满
• 准备一张故障清单（比如"如果Spark任务无法提交，我会怎么办"）
• 控制演示时间在8到10分钟以内，重点流程是：打开平台主页→登录演示账号→展示个性推荐页→展示可视化大屏→展示Hive统计分析结果→展示Spark任务日志

7.3 答辩老师最常追问的问题清单

答辩时间有限，老师一般会围绕两个方向问：项目是不是你做的，以及你对底层原理是否理解。我被问到过的高频问题如下：

1. 推荐系统冷启动问题怎么解决？（考察对推荐系统业务的理解）
2. ALS中隐因子数rank选10和选50的区别是什么？（考察对模型超参数的理解）
3. Hive和MySQL有什么区别？（宏观架构理解）
4. Spark为什么比MapReduce快？（考察Spark核心原理：内存计算、DAG优化、数据本地性）
5. HDFS读写流程是怎样的？（大数据基础）
6. 你的推荐结果是怎么存到MySQL的？（考察对整个数据流的理解）

逐一来说，第1问可以直接用我前面写的冷启动策略回答；第2问可以说rank代表找多少个隐藏特征（比如小说的风格、主题、文笔等），过小会欠拟合，过大则容易学到噪声；第3问围绕"一个是数仓一个业务库"展开；第4问是重中之重，重点答"基于内存、DAG有向无环图、懒执行、无需落盘"；第5问答"客户端请求NameNode、NameNode返回DataNode列表、客户端与DataNode交互传输数据"的流程即可。

7.4 延伸一下：如果面试被问到怎么把这个项目讲出彩

这个项目写进简历的价值不止于毕设本身。去面大数据开发或者后端开发岗位时，这是非常好的项目经历。你可以在自我介绍环节讲成这样一个故事：构建了包含Hadoop、Spark、Hive、Django在内的大数据推荐系统，处理了数万条用户行为数据，使用ALS协同过滤算法实现小说Top-N推荐，并基于ECharts完成了数据可视化平台。

如果面试官问"你在项目中遇到过最大的挑战是什么"，一个真实的回答是："Spark on Yarn模式下Executor资源分配不符合预期，通过查看Yarn资源管理页面逐步定位到是vcore配置和最小分配粒度的问题"。这类真实的排错经验，比任何华丽的项目描述都更能打动人。

如果你还想增加亮点，可以在GitHub上把代码开源，README写好环境部署步骤和项目演示视频链接。这一份材料就是最好的作品证明。

写在最后：几个我实际操作中沉淀下来的心得

这个项目做完，我自己最大的体会是：大数据毕设的核心不在于算法的花哨程度，而在于全流程的完整度。你可以把算法换成最简单的ItemCF，甚至用Spark SQL直接算相似度，只要架构完整、数据链路通顺、页面展示清晰，成绩就不会差。真正让评委皱眉头的是那种只跑了一个local模式的脚本、连Hive都没配好、页面输出是空白的项目。

另外再分享一个实用的小技巧——做演示前一定要把Hadoop的dfs.replication设为1。因为很多同学在伪分布式下生产环境默认是3副本，当磁盘空间不足时DataNode会自动停止，导致HDFS进入安全模式，这时所有的读写操作都会报错。hdfs dfsadmin -safemode leave只能临时解决，最靠谱的方式是在hdfs-site.xml中把副本数直接改为1，并且格式化完NameNode后先验证一下hdfs dfs -ls /能正常返回。

这类问题往往不会出现在教程中，但只要被你踩过一次，整个排查思路就通了。希望这篇内容能帮你少走这些弯路，把更多时间留给真正重要的算法调优和论文打磨。