Hadoop好友推荐系统毕设源码解析：从MapReduce到伪分布式部署-育师

简介：这是一份基于Hadoop的好友推荐系统完整项目源码，面向计算机、人工智能、通信工程等专业的在校学生与教师，可用于毕业设计、课程设计、作业提交或项目初期立项演示，也适合希望进阶学习大数据推荐算法的开发者。压缩包共约2000个文件，整体79.5MB，以1260个png界面截图、403个css样式、88个jar依赖包、73个java源码及55个class文件为主，另含jsp页面、xml配置、js脚本与properties配置等，覆盖前端展示、后端逻辑与Hadoop集群计算模块。项目已通过导师指导与答辩评审，获得95分成绩，代码均经测试运行成功，功能完整可直接使用。内容涉及距离计算、聚类数据映射、初始化距离矩阵等推荐算法核心类，配合部署文档可帮助读者理解Hadoop环境下好友推荐的实现思路与工程结构。目前已有162人学习关注，适合在此基础上二次开发或作为学习大数据推荐系统的实践参考。

1. 从一份 95 分毕设说起：Hadoop 好友推荐系统到底解决了什么问题

社交平台里「你可能认识的人」这个模块，背后其实是一道典型的二度好友推理题。这份基于 Hadoop 的好友推荐系统源码包，把这道题拆成了离线计算链路：用 MapReduce 在 HDFS 上跑关系数据，算出用户之间的共同好友数，再按亲密度排序输出推荐列表。它不是一个玩具 Demo，而是带完整部署文档、DAO 层、工具类、绘图类的可运行工程，答辩评审分 95 分，说明业务闭环和代码结构都经得起追问。

适合谁？计算机相关专业的毕设、课设、作业场景，尤其是选题卡在「大数据方向但不知道做什么」的同学。你拿到的不只是几个 class 文件，而是一条从数据入库、集群计算到结果可视化的完整链路。下面我按「资源里有什么 → 怎么跑起来 → 参数怎么调 → 哪里容易翻车」的顺序拆一遍，能直接抄作业的地方我都标了。

2. 拆开源码包：HUtils、DBService 与那几个 Mapper 各管什么

2.1 从 class 清单反推系统分层

项目正文给出的 class 列表信息量很大，先按职责归类，这决定了你改代码时该动哪一层：

类名	所属层	职责
HUtils	工具层	Hadoop 配置加载、Job 提交封装
DBService	服务层	数据库连接与业务查询入口
Utils	工具层	通用字符串、日期、路径处理
DrawPic	展示层	推荐结果绘图输出
BaseDAOImpl	持久层	DAO 基类，封装 JDBC 增删改查
ClusterDataMapper	MapReduce	聚类/分组阶段映射
DeltaDistanceMapper	MapReduce	增量距离计算映射
CalDistanceMapper	MapReduce	距离计算映射
FindInitDCMapper	MapReduce	初始中心点查找映射

这张表是理解整个工程的钥匙。工具层和持久层是脚手架，真正决定推荐质量的是四个 Mapper。它们不是随便命名的，DeltaDistance 和 CalDistance 同时出现，说明系统用了「初始中心 + 增量更新」的思路来算用户间距离，而不是每次全量重算。FindInitDCMapper 负责找初始聚类中心，ClusterDataMapper 负责把用户按距离归簇，这套组合在好友推荐里对应的是「先把兴趣相近的人聚在一起，再在簇内算共同好友」。

2.2 推荐算法的核心逻辑

好友推荐最朴素的算法是共同好友数：A 和 B 的共同好友越多，越可能认识。但纯共同好友数有个问题——大 V 用户好友多，跟谁都有一堆共同好友，推荐会失真。所以工程上一般会做归一化，常见做法是 Jaccard 相似度或余弦相似度。

这份源码用距离计算 Mapper 来实现相似度。CalDistanceMapper 算的是全量距离矩阵，DeltaDistanceMapper 算的是增量部分。为什么要拆成两个？因为社交关系是动态的，每天都有新好友关系产生，如果每次都全量重算，集群开销扛不住。增量 Mapper 只处理变化的那部分数据，这是工程化的关键设计，也是答辩时能加分的点。

FindInitDCMapper 里的 DC 大概率指 Distance Center 或 Density Center。聚类算法对初始中心敏感，K-Means 随机选中心容易陷入局部最优，所以单独写一个 Mapper 来找初始中心，通常用密度峰值或最远点采样。你在改算法时，如果想换聚类策略，优先动这个类。

2.3 本地跑通最小链路

在碰集群之前，先在本地把单机模式跑通，确认代码逻辑没问题。Hadoop 支持 LocalJobRunner，不需要真集群也能跑 MapReduce。

# 确认 JDK 和 Hadoop 环境变量 java -version echo $HADOOP_HOME # 本地模式提交 Job，不走 YARN export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop hadoop jar friend-recommend.jar com.xxx.FriendRecommendDriver \ -D mapreduce.framework.name=local \ -D fs.defaultFS=file:/// \ /input/relations.txt /output/rec

第一行确认 JDK 版本，Hadoop 2.x 和 3.x 对 JDK 要求不同，2.x 用 JDK7/8，3.x 用 JDK8。第二行确认 HADOOP_HOME 指向正确，很多「命令找不到」的问题都出在这里。第三行是核心，mapreduce.framework.name=local强制走本地模式，fs.defaultFS=file:///让文件系统走本地而不是 HDFS。这样你不需要启动任何守护进程就能验证 Mapper 逻辑。

提示：本地模式跑通后再上伪分布式，能省掉大量「到底是代码错还是集群错」的排查时间。

3. 伪分布式搭建与部署文档落地：从 HDFS 到 Job 提交

3.1 伪分布式环境准备

热搜里 hadoop 伪分布式搭建是高频词，这份部署文档大概率也是按伪分布式写的。伪分布式就是所有守护进程跑在一台机器上，但走完整的 RPC 和 HDFS，适合毕设演示。

# 1. 配置 core-site.xml cat >> $HADOOP_HOME/etc/hadoop/core-site.xml << 'EOF' <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> </configuration> EOF # 2. 配置 hdfs-site.xml，副本数设为 1 cat >> $HADOOP_HOME/etc/hadoop/hdfs-site.xml << 'EOF' <configuration> <property> <name>dfs.replication</name> <value>1</value> </property> </configuration> EOF # 3. 格式化并启动 hdfs namenode -format start-dfs.sh jps

第一段配置fs.defaultFS指向hdfs://localhost:9000，这是 NameNode 的 RPC 地址。第二段把副本数设为 1，伪分布式只有一台机器，设 3 会一直报副本不足。第三段hdfs namenode -format只在第一次启动前执行，重复格式化会导致 clusterID 不一致，DataNode 起不来，这是血泪经验。jps应该看到 NameNode、DataNode、SecondaryNameNode 三个进程。

3.2 数据入库与目录规划

推荐系统的输入是用户好友关系对，格式一般是userA,userB每行一对。上传到 HDFS 前先在本地确认编码和分隔符。

# 创建 HDFS 目录 hdfs dfs -mkdir -p /friend/input hdfs dfs -mkdir -p /friend/output # 上传关系数据 hdfs dfs -put relations.txt /friend/input/ # 验证 hdfs dfs -ls /friend/input/ hdfs dfs -cat /friend/input/relations.txt | head -5

-mkdir -p支持多级创建，-put上传本地文件。上传后一定用-cat | head抽查前几行，确认没有 BOM 头、没有多余空行。分隔符如果是逗号，Mapper 里 split 就要用逗号；如果数据里混了制表符，解析会静默失败，输出空结果，这种问题最难查。

3.3 提交 Job 与参数调优

hadoop jar friend-recommend.jar com.xxx.FriendRecommendDriver \ /friend/input /friend/output \ -D mapreduce.job.reduces=2 \ -D mapreduce.task.timeout=600000

mapreduce.job.reduces=2控制 Reduce 任务数，伪分布式下设 1 到 2 就够，设太多反而因为资源竞争变慢。mapreduce.task.timeout默认 600000 毫秒即 10 分钟，如果你的数据量大、单任务超过 10 分钟没心跳，TaskTracker 会杀掉任务，适当调大能避免「任务莫名被杀」。这两个参数是部署文档里最该关注的地方，很多人跑失败就是超时导致的。

注意：Reduce 数不是越多越好，它等于输出文件数。设成 2 会生成两个 part 文件，后续合并结果时要一起读。

4. 避坑与排查：那些让任务跑不起来的常见问题

4.1 现象：DataNode 启动后立刻消失

原因：重复执行了hdfs namenode -format，NameNode 的 clusterID 和 DataNode 的 clusterID 不匹配，DataNode 拒绝注册。

解决：停掉集群，删除$HADOOP_HOME/data下所有数据目录，重新格式化一次，之后不要再格式化。如果数据不能丢，就去 NameNode 的 VERSION 文件里把 clusterID 抄到 DataNode 的 VERSION 文件里。

4.2 现象：Job 卡在 map 0% reduce 0% 不动

原因：YARN 资源不够，或者yarn-site.xml里yarn.nodemanager.resource.memory-mb设得比机器实际内存还大，NodeManager 起不来。

解决：检查jps是否有 ResourceManager 和 NodeManager，把内存参数调到机器实际内存的 70% 左右。伪分布式下yarn.nodemanager.resource.memory-mb设 2048 通常够用。

4.3 现象：输出结果为空，但任务显示成功

原因：Mapper 里 split 分隔符和数据实际分隔符不一致，或者输入路径下有空文件。MapReduce 对解析失败是静默跳过的，不会报错。

解决：在 Mapper 的 map 方法里加一行日志打印原始行，用hdfs dfs -cat确认数据格式。常见做法是先用小样本数据跑一遍，确认输出非空再上全量。

4.4 现象：中文乱码

原因：源码文件编码是 GBK，而集群默认 UTF-8，或者数据文件本身是 GBK。

解决：统一用 UTF-8。IDE 里把文件编码设为 UTF-8，数据文件用iconv -f GBK -t UTF-8转换后再上传。DrawPic 输出的图片如果中文乱码，是字体问题，指定一个支持中文的字体文件即可。

4.5 现象：ClassNotFoundException 或 NoClassDefFoundError

原因：第三方依赖没打进 jar 包，或者HADOOP_CLASSPATH没配。

解决：用 Maven 的 shade 插件打 fat jar，把所有依赖打进去。如果依赖是 Hadoop 自带的，用providedscope，避免版本冲突。提交时确认hadoop jar后面跟的是 fat jar 而不是原始 jar。

5. 进阶玩法：把推荐结果接上可视化与增量更新

5.1 用 DrawPic 输出可展示的推荐图

答辩现场光有文本结果不够直观，DrawPic 这个类就是干这个的。它大概率基于 Java 的绘图库把推荐关系画成图。你可以把 Reduce 输出的userA -> [推荐列表]读进来，转成邻接表再渲染。

# 读取 Reduce 输出，生成可视化用的边列表 import re edges = [] with open('part-r-00000', 'r', encoding='utf-8') as f: for line in f: user, recs = line.strip().split('\t') # recs 形如 "B:3,C:2"，冒号后是共同好友数 for item in recs.split(','): friend, score = item.split(':') edges.append((user, friend, int(score))) # 按分数过滤，只保留强推荐 strong = [e for e in edges if e[2] >= 2] print(f'总边数 {len(edges)}，强推荐边数 {len(strong)}')

这段脚本把 Reduce 输出解析成边列表，score是共同好友数。过滤阈值>= 2是经验值，低于 2 的推荐基本是噪声。拿到边列表后可以喂给 Gephi 或 ECharts 做力导向图，答辩时比表格好看得多。

5.2 增量更新：DeltaDistanceMapper 的正确用法

社交数据每天在变，全量重算不现实。DeltaDistanceMapper 的设计意图就是只处理新增关系。常见做法是维护一个时间戳，每次只把timestamp > last_run的关系对喂给增量 Job，然后和上一次的全量结果做合并。

# 增量 Job：只处理新增关系 hadoop jar friend-recommend.jar com.xxx.DeltaDriver \ /friend/input/new_relations.txt \ /friend/delta_output \ -D last.run.timestamp=1700000000 # 合并全量结果和增量结果 hadoop jar friend-recommend.jar com.xxx.MergeDriver \ /friend/output /friend/delta_output /friend/final_output

last.run.timestamp是自定义参数，需要在 Driver 里读取并传给 Mapper 做过滤。合并阶段用 MergeDriver 把历史推荐和新增推荐去重合并。这套流程跑通后，你的系统就从「一次性计算」升级成「可持续更新」，答辩时是明显的加分项。

5.3 验证推荐质量的一个笨办法

推荐系统没有绝对的对错，但可以验证合理性。我一般会抽几个用户，人工看他们的好友关系，再对比系统推荐。如果推荐的人里超过一半是「好友的好友」，说明共同好友逻辑生效了；如果推荐的全是陌生人，大概率是距离计算或聚类环节出了问题。

-- 从数据库抽查：某用户的二度好友 SELECT DISTINCT f2.friend_id FROM friend f1 JOIN friend f2 ON f1.friend_id = f2.user_id WHERE f1.user_id = 'target_user' AND f2.friend_id != 'target_user';

这条 SQL 查出目标用户的二度好友集合，和系统推荐列表做交集。交集占比高说明推荐准确，占比低就要回头查 CalDistanceMapper 的权重设置。这个笨办法不依赖任何评估框架，但能快速定位问题出在算法还是数据。

从那以后我每次拿到这类 Hadoop 项目，都强制先跑本地模式验证逻辑，再上伪分布式，最后才碰集群参数。顺序反了，排查成本会翻好几倍。希望帮到你。

本文还有配套的精品资源，点击获取