简介：一套基于JavaWeb与Hadoop的图书推荐系统大作业项目，源码、数据库脚本和设计报告齐备，面向计算机专业正在准备课程设计或期末大作业的学生，也适合需要大数据实战练习的学习者。整套资源共78个文件，涵盖Java源码与编译后的class文件、Hadoop相关配置（XML、properties）、SQL数据库脚本以及实验手册与项目说明文档（doc/docx），压缩包整体约20.19MB，目录结构清晰，便于导入IDE进行二次开发。项目采用Apriori关联规则算法完成图书推荐，涉及数据预处理、频繁项集挖掘和推荐结果展示等完整流程，配合实验手册可帮助读者理解推荐系统原理及工程落地方式。已有208人学习下载，是一份可直接参考的高分大作业方案，能有效节省选题和搭建框架的时间。
1. 基于 JavaWeb + Hadoop 的图书推荐系统，最难的不是算法
拿到这个题目，多数人第一反应是去啃协同过滤公式。实际把项目做完一遍你会认同一个反直觉的结论：推荐算法本身压缩到几十行代码就能跑通，真正让期末大作业卡壳的是两件事——Hadoop 伪分布式环境搭建时配置文件改错一项导致 NameNode 起不来，以及 MapReduce 算完的结果怎么落进 MySQL 让 JavaWeb 页面查出来。这套系统的本质是一条数据管道：Hadoop 负责离线算“该推荐什么”，JavaWeb 负责把结果变成用户能点的页面，数据库夹在中间当仓库。适合谁做？手里有 JavaWeb 基础、想在一周内交出一份能跑通、能讲清原理、报告有图有表的课程设计的同学。下面按我自己会做的方案，把环境、算法、联调、报告拆开讲。
2. 表结构设计与 Hadoop 伪分布式环境准备
2.1 先定数据模型：四张 MySQL 表 + 两份 HDFS 文件
图书推荐系统的数据面很简单，核心业务表四张就够：用户表、图书表、评分表、推荐结果表。前两张是基础数据，评分表是推荐算法的输入，推荐结果表是 MapReduce 的输出落点，JavaWeb 只查这最后一张表。
-- 用户表 CREATE TABLE `t_user` ( `id` int NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL, `password` varchar(100) NOT NULL, PRIMARY KEY (`id`) ); -- 图书表 CREATE TABLE `t_book` ( `id` int NOT NULL AUTO_INCREMENT, `title` varchar(200) NOT NULL, `author` varchar(100) DEFAULT NULL, `category` varchar(50) DEFAULT NULL, `cover_url` varchar(500) DEFAULT NULL, PRIMARY KEY (`id`) ); -- 评分表（推荐算法输入） CREATE TABLE `t_rating` ( `user_id` int NOT NULL, `book_id` int NOT NULL, `score` int NOT NULL, `create_time` datetime DEFAULT NULL, PRIMARY KEY (`user_id`, `book_id`) ); -- 推荐结果表（MapReduce 输出） CREATE TABLE `t_recommend` ( `user_id` int NOT NULL, `rec_book_ids` varchar(500) NOT NULL, `update_time` datetime DEFAULT NULL, PRIMARY KEY (`user_id`) );推荐结果表只存每个用户对应的图书 ID 列表，用逗号分隔。这样设计是为了让 MapReduce 输出按行写入时足够简单，JavaWeb 端查询时再做拆分关联。
提示：评分数据不要手工一条条往 MySQL 里插，先把数据维护成两份纯文本文件放在 Linux 上，后面直接喂给 HDFS。一份是图书信息 books.txt，字段为 book_id、title、category；一份是评分数据 ratings.txt，字段为 user_id、book_id、score。
2.2 Hadoop 伪分布式搭建：最容易翻车的三个配置
课程设计阶段不建议上集群，伪分布式足够。整个流程是：JDK 1.8 + Hadoop 安装包解压 → 改四个配置文件 → 免密登录 → 格式化 NameNode → 启动。用 tar 包解压后放在/usr/local/hadoop，JDK 放在/usr/local/java。
core-site.xml 指定 NameNode 地址：
<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/usr/local/hadoop/tmp</value> </property> </configuration>hdfs-site.xml 设置副本数为 1，伪分布式只有单节点，副本数设 3 会造成资源浪费且启动时可能报块副本不足的警告：
<configuration> <property> <name>dfs.replication</name> <value>1</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/usr/local/hadoop/tmp/name</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/usr/local/hadoop/tmp/data</value> </property> </configuration>yarn-site.xml 需要指定资源管理器和节点管理器地址，否则后面跑 MapReduce 任务时容易报「ApplicationMaster 无法连接」的错误：
<configuration> <property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value> </property> <property> <name>yarn.nodemanager.aux-services.mapreduce_shuffle.class</name> <value>org.apache.hadoop.mapred.ShuffleHandler</value> </property> </configuration>mapred-site.xml 指定用 YARN 来调度 MapReduce 任务：
<configuration> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> </configuration>改完配置后依次执行：
ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys cd /usr/local/hadoop bin/hdfs namenode -format sbin/start-dfs.sh sbin/start-yarn.sh格式化 NameNode 在首次安装时只执行一次，之后如果反复格式化，必须把 tmp 目录清掉，否则 NameNode 和 DataNode 的集群 ID 不一致，DataNode 进程会不停闪退。启动后用jps能看到 NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager 五个进程，JavaWeb 侧联调时依赖 HDFS 的 9000 端口和 YARN 的 8088 端口，注意云服务器的安全组放行这两个端口。
2.3 数据入库：从本地文件到 HDFS
把两份数据文件放到 /usr/local/hadoop 下，然后建目录上传：
cd /usr/local/hadoop bin/hdfs dfs -mkdir -p /input bin/hdfs dfs -put books.txt /input/ bin/hdfs dfs -put ratings.txt /input/ bin/hdfs dfs -ls /inputHDFS 的名字节点和 Apache Hadoop 数据块默认大小是 128MB，课程设计的数据量通常只有几百 KB，不需要调块大小，也不要因为文件小而担心性能，这里主要验证的是数据通道是否打通。
3. 基于物品的协同过滤：用 MapReduce 把评分数据算成推荐
3.1 为什么是 ItemCF 而不是 UserCF
图书推荐这个场景，用户数量远大于图书数量，而且用户评分矩阵非常稀疏。UserCF 需要先找“口味相似的人”，再找这些人看过的书，但课程设计里注册用户往往只有几十个，相似用户很难算准。ItemCF 的思路反过来：先统计“看过这本书的人还看了什么”，再根据用户历史评分把相似图书按加权分数排序。这个逻辑对图书完全成立——用户的兴趣相对稳定，计算量集中在图书共现矩阵上，数据量小也能跑出合理结果。
3.2 两阶段 MapReduce：共现矩阵与推荐分计算
完整 ItemCF 需要算图书相似度矩阵，再对每个用户做加权。课程设计用 MapReduce 全链路实现太复杂，常见做法是拆成两个 Job：第一个 Job 统计图书之间的共现次数，第二个 Job 对用户评分和共现结果做加权求和。
第一阶段 Mapper 把评分数据转成“用户 -> 图书列表”的结构，Reducer 里对同一个用户下的图书两两配对输出共现对：
public class CoOccurrenceMapper extends Mapper<LongWritable, Text, Text, Text> { @Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { String[] parts = value.toString().split(","); String userId = parts[0]; String bookId = parts[1]; context.write(new Text(userId), new Text(bookId)); } }Reducer 的关键逻辑是构造商品对，key 是“bookA:bookB”，value 记一次共现：
public class CoOccurrenceReducer extends Reducer<Text, Text, Text, IntWritable> { @Override protected void reduce(Text key, Iterable<Text> values, Context context) throws IOException, InterruptedException { List<String> books = new ArrayList<>(); for (Text val : values) { books.add(val.toString()); } // 同一个用户下所有图书两两配对 for (int i = 0; i < books.size(); i++) { for (int j = i + 1; j < books.size(); j++) { context.write(new Text(books.get(i) + ":" + books.get(j)), new IntWritable(1)); context.write(new Text(books.get(j) + ":" + books.get(i)), new IntWritable(1)); } } } }第二阶段 Job 读共现矩阵和原始评分，输入变成bookA:bookB 共现次数以及userId,bookId,score两路数据，Reducer 里算推荐分：用户对某本书的评分 × 这本书与目标书的共现次数加权聚合。
// 输入格式：userId,bookId,score 与 bookA:bookB,count public class RecommendReducer extends Reducer<Text, Text, Text, Text> { @Override protected void reduce(Text key, Iterable<Text> values, Context context) throws IOException, InterruptedException { // key 为目标图书 ID，values 中要么是评分，要么是共现权重 Map<String, Double> scoreMap = new HashMap<>(); Map<String, Double> coMap = new HashMap<>(); for (Text val : values) { String line = val.toString(); String[] parts = line.split(","); if (parts.length == 3) { scoreMap.put(parts[0], Double.parseDouble(parts[2])); } else if (parts.length == 2) { coMap.put(parts[0], Double.parseDouble(parts[1])); } } // 对每个用户计算目标图书的推荐分 for (Map.Entry<String, Double> entry : scoreMap.entrySet()) { double total = 0.0; for (Map.Entry<String, Double> co : coMap.entrySet()) { total += entry.getValue() * co.getValue(); } context.write(new Text(entry.getKey()), new Text(key.toString() + ":" + total)); } } }运行命令：
cd /usr/local/hadoop bin/hadoop jar recommend.jar com.course.RecommendJob /input/ratings.txt /output bin/hdfs dfs -cat /output/part-r-00000/output目录不能提前存在，Hadoop 在任务启动时会检查输出路径，存在就报FileAlreadyExistsException。每次重跑前执行bin/hdfs dfs -rm -r /output清理。
3.3 调参优先级与输出格式
推荐任务里最值得调的三个参数是共现窗口大小、TopN 截断阈值、评分归一化方式。评分归一化在课程设计里常用均值中心化——把每个用户的评分减去自身均值，降低“有的人只打 5 分、有的人只打 2 分”造成的影响。实现上在 Mapper 阶段输出前先做一次均值计算。
输出文件每行格式为：
1 3:7.5,5:6.2,9:4.8 2 1:5.1,7:4.0左侧是用户 ID，右侧是图书 ID 和推荐分。这个文件需要转存成干净的两列数据供后续导入 MySQL。用 HDFS 命令导出到本地再加工：
cd /usr/local/hadoop bin/hdfs dfs -getmerge /output /root/rec_result.txt sed -i 's/\t/,/g' /root/rec_result.txt
getmerge会把输出目录下所有 part 文件合并成一个，比逐文件-cat更省事。注意输出的换行符在 Linux 上是\n，直接导入 MySQL 没问题，不要在 Windows 上用记事本打开另存后再传，容易变成\r\n导致字段错位。
4. JavaWeb 集成推荐结果：把 HDFS 算出的数据做成可点页面
4.1 架构边界：Hadoop 不参与在线请求
在线查询场景下，JavaWeb 直接读 HDFS 是不现实的，正常做法是让 Hadoop 保持离线角色——算完后把结果同步进 MySQL，用户请求只打 MySQL。这也是“基于 JavaWeb + Hadoop”这类题目最合理的结构划分：Hadoop 负责批处理，MySQL 负责在线读。所以集成工作的核心就是两件事：写一个同步脚本把推荐结果灌进 t_recommend 表；再写一套 MVC 代码把推荐列表查出来渲染到页面。
4.2 同步脚本：从 HDFS 结果文件到 MySQL
用 shell 脚本做中转：
#!/bin/bash # sync_recommend.sh # 从本地合并文件读取每行 user_id,rec_ids ,写入 MySQL t_recommend mysql -uroot -p123456 --local-infile=1 <<EOF DELETE FROM t_recommend; LOAD DATA LOCAL INFILE '/root/rec_result.txt' INTO TABLE t_recommend FIELDS TERMINATED BY ',' (user_id, rec_book_ids) SET update_time = NOW(); EOF先清空再导入是为了防止脏数据累积。FIELDS TERMINATED BY ','对应sed处理后的逗号分隔格式。如果 MapReduce 输出里同一用户有多条结果需要合并，可以先把 HDFS 输出在 shell 层用awk按用户 ID 聚合，再灌入表，避免写入时因主键冲突报错。
4.3 SSM 框架下推荐查询链路
项目骨架用 Spring + SpringMVC + MyBatis，Maven 依赖里只需要引入 spring-webmvc、mybatis、mybatis-spring、mysql-connector-java、jackson-databind。Controller 负责接收页面请求，调 Service 查 t_recommend，再拆推荐 ID 列表回查 t_book 详情。
@Controller @RequestMapping("/recommend") public class RecommendController { @Autowired private RecommendService recommendService; @RequestMapping("/list") public String list(@RequestParam(defaultValue = "1") Integer userId, Model model) { // 1. 查推荐表，拿到 "3:7.5,5:6.2" 这种原始字符串 Recommend rec = recommendService.getByUserId(userId); // 2. 按推荐分从高到低截取 TopN List<Integer> bookIds = RecommendUtils.parseAndSort(rec.getRecBookIds(), 10); // 3. 用 bookIds 批量查图书详情 List<Book> books = bookService.listByIds(bookIds); model.addAttribute("books", books); return "recommend_list"; } }Mapper 的 XML 里用动态 SQL 批量查询图书：
<select id="listByIds" resultType="com.course.entity.Book"> SELECT id, title, author, category, cover_url FROM t_book WHERE id IN <foreach collection="list" item="id" open="(" separator="," close=")"> #{id} </foreach> </select>注意：
ParseAndSort工具类要处理 MapReduce 输出里的分数残留，比如3:7.5中的 7.5 只用于排序，不用于展示。核心逻辑是 split 后按分数降序排，再取出前 N 个图书 ID。这是推荐系统展示层最容易被忽略的边角问题——不排序直接塞进页面，推荐效果会显得非常随机。
4.4 页面渲染与回退策略
页面建议直接用 Bootstrap 栅格做卡片流，每张卡片展示封面、书名、作者、分类。推荐列表为空时不能白屏，常见做法是降级为“热门图书”——按 t_rating 表中平均分最高的 8 本兜底：
SELECT book_id, AVG(score) AS avg_score FROM t_rating GROUP BY book_id ORDER BY avg_score DESC LIMIT 8;这条 SQL 在 t_recommend 表没有当前用户数据时执行，保证页面始终有内容。课程设计里老师最在意的点之一就是边界情况处理，空数据页面比报错页面印象好太多。
4.5 联调顺序与日志排错
推荐系统的联调最容易出问题的环节是用户 ID 对齐。HDFS 算出来的用户 ID 是 ratings.txt 里的 ID，MySQL t_user 表里的 ID 如果导入时重新自增过，两边就会错位。解决办法：rating 数据文件生成时直接用 t_user.id 导出，不要手工编。联调阶段在 Controller 里临时打印 userId 和推荐结果，确认数据链路再删掉调试日志。
# 查看 JavaWeb 容器日志中推荐的请求与返回 tail -f /usr/local/tomcat/logs/catalina.out日志里重点看有没有null出现在 rec_book_ids 字段中，这是同步脚本字段顺序错了，通常是user_id和rec_book_ids交换了位置。打开 t_recommend 表刷几行数据，SELECT * FROM t_recommend LIMIT 5;确认数据形态，再回到页面刷新。
5. 期末报告怎么写出区分度：图表、流程与答辩话术
5.1 报告目录结构与图表规范
课程设计报告不需要创新点堆砌，但结构要完整。推荐按这个目录组织：需求分析、系统设计（架构图 + 数据库设计）、环境搭建过程（含伪分布式配置截图）、核心算法实现（ItemCF 原理 + MapReduce 代码 + 运行日志）、系统功能展示（页面截图）、测试与结果分析、总结与展望。
架构图里必须画清三条数据流：原始数据文件 → HDFS → MapReduce 输出、MapReduce 输出 → 同步脚本 → MySQL、前端页面 → Controller → MySQL。这三条链路对应了题目里的 JavaWeb、Hadoop、数据库三个关键词，图比文字直观得多。页面截图要截全浏览器窗口，不要截局部，推荐结果页和登录页必须出现在同一系统下，不要拿别人的页面图来充数。
5.2 答辩前必须能回答的三个问题
问题一：为什么用 ItemCF 不用 UserCF？标准答法是结合数据规模谈：图书场景用户少、物品多，UserCF 的用户相似度矩阵稀疏度高，计算误差大；ItemCF 的推荐结果可解释性强，适合应用层展示。
问题二：K 值怎么选的？TopN 取 10 是经验值，也是展示层权衡——卡片一行 5 个、两行正好 10 个。如果评分数据多，可以对比 K=5、10、20 时推荐列表的覆盖率，选一个在页面里不显得空的数字。
问题三：冷启动图书推不推？报告里一句“对评分量为零的图书做兜底推荐或直接过滤”就能体现思考。实现上在同步脚本里加一个条件，过滤掉没有任何评分的图书 ID，避免推荐一个用户根本没看过的分类。
5.3 加分细节：让演示节奏更顺
把 Hadoop 集群的启动方式和重启命令抄进报告的附录，答辩演示时如果现场环境需要重启，直接按附录操作，会显得项目真正自己跑过。演示顺序统一为：登录 → 热门图书页 → 用户评分页 → 点击“查看推荐” → 展示推荐列表和数据库中的 t_recommend 对应记录。数据库表数据变化要提前截一张“同步前后对照”图放进测试章，这张图能同时证明 MapReduce 算完、同步脚本跑通、JavaWeb 查对，一条链路三个关键点全部覆盖。把这些内容铺满报告，容量自然超过三十页，不用靠复制源码来凑字数。
本文还有配套的精品资源，点击获取
