简介面向高校计算机相关专业的毕设与课设场景这是一套基于Hadoop的好友推荐系统完整项目包含设计与实现源码、部署文档及全部配套资料可直接作为毕业设计、课程设计、作业或入门进阶项目尤其适合毕设初期立项演示与后期扩展。压缩包共2000个文件约79.5MB其中java源码与class编译产物对应核心逻辑jsp与css/js构成前端展示png/gif为界面或流程截图另含jar依赖库、xml/properties配置及md说明文档整体结构清晰便于按模块定位学习。项目代码经测试运行成功答辩评审分达95分涵盖Hadoop数据分析、距离度量、聚类计算等核心环节能够帮助读者理解推荐系统从数据处理到结果输出的工程实现掌握Hadoop生态在实际项目中的落地方法。目前已有162人学习下载可直接使用或在此基础上二次扩展显著降低从零搭建Hadoop项目的门槛尤其适合时间紧张但需要完整参考的开发者。1. 基于Hadoop的好友推荐系统先想清楚推荐逻辑再动集群很多人第一次看到“好友推荐系统”这个标题会下意识以为要训练一个协同过滤模型。实际上在Hadoop生态里做这件事最经典的落地方式是用MapReduce计算“共同好友数”你和用户B的共同好友越多B就越值得推荐给你。这套逻辑在真实社交产品里被验证过无数次它不需要复杂的机器学习框架却能把离线推荐跑得很稳。这个项目的完整交付通常包括三部分推荐算法设计与MapReduce实现、伪分布式或集群部署、以及一份可以让别人照着重新部署的文档。对做Hadoop课程设计或毕业设计的人来说难点从来不在算法本身而在“怎么把一份好友关系数据变成推荐结果”的完整链路——数据进HDFS、作业跑起来、日志能排查、结果能回写。对工程师来说这套系统也是一次不错的Hadoop全家桶演练HDFS、YARN、MapReduce、ZooKeeper高可用全都会碰到。下面按“数据建模 → 算法实现 → 部署验证 → 结果上线”的顺序把这条链路拆开。每一步都会给出能直接抄走的命令和参数你不需要有一份现成项目源码就能复现这套方案。2. 好友推荐的数据模型与推荐逻辑设计共同好友打分的三层依据2.1 好友关系怎么建模无向边与邻接表好友关系在数学上是一张无向图。用户A是B的好友那么B也必然是A的好友。但实际数据落盘时很多业务系统只存了一条单向记录比如A关注了B或者A把B加为好友时只写了一条流水。所以第一步要做的不是算推荐而是把数据洗干净。常见做法是把输入统一成两列TSV格式# friends.tsv字段之间用Tab分隔 1001 1002 1001 1003 1002 1003 1002 1004每一行表示“前者与后者存在好友关系”。数据清洗阶段需要检查的事情有三个去重同一对好友出现多次、反向补全只有1001 1002时补一条1002 1001、过滤自环1001 1001无效。这一步可以在MapReduce里做也可以在上传HDFS之前用脚本预处理。清洗后的数据最终建议以SequenceFile格式存入推荐专用目录而不是每次直接扫描原始业务表。原因在于SequenceFile支持块级压缩在HDFS上占用的块更少MapReduce读取时的I/O开销更低。对课程设计这种规模的数据来说压缩收益不明显但养成这个习惯会让你在真实集群上少踩坑。2.2 推荐候选集生成二度好友才是真正候选好友推荐有个容易被忽略的前提不能推荐已经是好友的人。判断“是否已经是好友”需要连接原关系数据做排除更常见的做法是算法层面天然规避——只计算“二度好友”也就是“我好友的好友”因为一度好友已经在关系表里了。举个例子用户A的好友列表是 {B, C}用户C的好友列表是 {A, D}那么D就是A的二度好友因为C同时是A和D的好友这里的核心计算就是把每个用户的好友列表拿到手再对列表中所有好友两两配对统计“谁和谁共同出现在多少个用户的列表里”。这个操作在SQL里就是一个自连接但在Hadoop里需要写成两轮MapReduce否则数据无法在一次Shuffle里完成“列表展开→两两配对→统计”的全过程。两轮作业的划分逻辑很清晰作业输入输出做的事Job1好友关系对用户 → 好友列表按用户聚合所有好友Job2用户 → 好友列表好友对 → 共同好友数两两配对并统计次数2.3 打分逻辑共同好友数、亲密度权重与冷启动兜底推荐排序不能只看共同好友数量。两个用户有20个共同好友但其中15个是系统推荐时产生的弱关系另一个用户有5个共同好友但全是高频互动好友后者往往更值得推荐。所以在设计MapReduce输出的时候就应该预留权重字段。打分公式可以写成score(u, v) Σ(common_friend_i 的权重)权重怎么来最简单的是给每条好友关系加上一个交互频次字段每个月互动超过10次记2分1到10次记1分否则记0.5分。常见做法是把权重直接追加到输入数据第三列这样Mapper端读入时可以顺便把权重读出来。但这会带来一个新问题Job2只统计了数量没统计权重和。解决办法是让Job2的Mapper输出“好友对”作为key输出“共同好友的权重”作为valueReducer里累加。原样照搬数量统计的逻辑会丢掉权重信息这是很多课程设计代码里“看起来能跑但推荐结果不合理”的重要原因。冷启动用户没有好友关系的新用户没有二度好友可推荐。常见做法是在Job2输出之外单独准备一份“热门用户表”按粉丝数或活跃度降序取前50遇到冷启动用户直接用热门列表填充。这个兜底逻辑不需要写进MapReduce主流程最后合并结果时补上即可。2.4 为什么这个设计适合Hadoop而不是Spark Streaming好友推荐的数据计算特征是“全量重算”每天凌晨把全量好友关系重新扫一遍生成第二天的推荐结果。它不是一个流式计算场景不需要秒级响应也没有持续到达的数据流。这正好落在Hadoop MapReduce的舒适区。MapReduce的Shuffle机制天然适合“按key聚合”这类计算。Job1按用户聚合好友列表Job2按好友对聚合共同好友来源两次Shuffle都是典型的分组聚合场景。相比SparkMapReduce没有内存计算的性能优势但它的资源管理和容器隔离在部署时更简单——你只需要保证YARN的NodeManager资源充足不需要关心executor内存和core的配比关系。这里不是否定Spark而是说明技术选型要和标题里的Hadoop对齐。如果面试或答辩被问“为什么不用Spark”可以这样回答推荐结果的实时性要求不高MapReduce的吞吐量已满足每日全量计算且集群硬件配置有限MapReduce对内存的要求低于Spark部署和运维更省心。3. 用MapReduce实现好友推荐的两个Stage与3个必调参数3.1 Stage1把单向关系展开成邻接表第一个作业的核心目的是把关系表变成用户到好友列表的映射。输入的一行是1001 1002Mapper输出两行1001 → 1002和1002 → 1001。这样无论原始数据是否双向Reducer里都能拿到完整的邻居集合。代码如下public static class FriendRelationMapper extends MapperObject, Text, Text, Text { public void map(Object key, Text value, Context context) throws IOException, InterruptedException { String[] tokens value.toString().split(\\t); if (tokens.length 2) { return; } String user tokens[0].trim(); String friend tokens[1].trim(); if (user.equals(friend)) { return; // 过滤自环 } context.write(new Text(user), new Text(friend)); context.write(new Text(friend), new Text(user)); } }Reducer把同一个用户的所有好友汇总成列表输出为用户 → 好友1,好友2,好友3public static class FriendListReducer extends ReducerText, Text, Text, Text { public void reduce(Text key, IterableText values, Context context) throws IOException, InterruptedException { SetString friendSet new HashSetString(); for (Text val : values) { friendSet.add(val.toString()); } String friendList String.join(,, friendSet); context.write(key, new Text(friendList)); } }这里使用HashSet而不直接拼接字符串是因为同一个用户的好友在双向展开后会出现重复记录直接拼接会造成后续配对时的重复计算。去重放在Reducer里也有代价——所有好友集合都在内存里如果某个用户有几十万好友会触发堆内存溢出。遇到这种极端用户后续需要用“切割好友列表”的方式处理这个坑放在第4章讲。3.2 Stage2把邻接表拆成好友对并统计共同好友第二个作业的输入是用户 → 好友列表。Mapper拿到一个用户的全部好友后对好友列表做两两配对每对输出一次。这样如果用户X同时是A和B的好友X的列表里就会同时出现A和B从而输出A,B这对key。public static class PairMapper extends MapperObject, Text, Text, Text { public void map(Object key, Text value, Context context) throws IOException, InterruptedException { String[] parts value.toString().split(\\t); if (parts.length 2) { return; } String[] friends parts[1].split(,); for (int i 0; i friends.length; i) { for (int j i 1; j friends.length; j) { String left friends[i]; String right friends[j]; // 保证pair有序避免(A,B)和(B,A)当成两对 if (left.compareTo(right) 0) { String tmp left; left right; right tmp; } context.write(new Text(left , right), new Text(parts[0])); } } } }Reducer统计value的个数就是这两个用户之间的共同好友数public static class CommonFriendReducer extends ReducerText, Text, Text, Text { public void reduce(Text key, IterableText values, Context context) throws IOException, InterruptedException { int count 0; for (Text val : values) { count; } context.write(key, new Text(String.valueOf(count))); } }为什么要让Reducer输出的是“好友对 → 共同好友数”而不是“用户A → 推荐用户列表”因为排序和截取TopN在MapReduce里做比较麻烦把明细结果落盘后后续用Hive或脚本再排序更灵活。输出格式保持简单也方便做结果校验。3.3 3个必调参数Reduce数量、Combiner与内存上限作业能跑通和跑得好是两回事。部署文档里通常只会写启动命令不会写参数调整经验这里给出一份适用的调参清单。参数默认值建议值作用mapreduce.job.reduces1按数据量设为4~16提高Reduce端并行度避免单点瓶颈mapreduce.reduce.memory.mb10242048或3072防止Reducer在聚合大列表时OOMmapreduce.map.combine.minspills3保持默认控制Combiner触发的Spill次数第一项参数最容易忽略。默认Reduce数是1所有Map输出都会集中到同一个Reduce任务上数据量大时直接变成“单机计算”集群的其他资源都在闲着。推荐值根据输入文件大小估算1GB输入配8个Reduce比较合理5GB以上配16个。Combiner能否使用取决于Reducer的逻辑是否为“交换律和结合律”。CommonFriendReducer里统计的是value个数Combiner可以先做一次局部去重计数再把计数结果传给Reducer。注意如果Reducer里计算的是“共同好友去重后的权重和”Combiner就不能简单复用Reducer逻辑需要单独写一个Combiner类。内存参数是第二个高频坑。好友列表聚合时如果某个用户的邻居数达到百万级HashSet会占用上GB内存。这时候单纯调大mapreduce.reduce.memory.mb不够还要确保YARN的yarn.nodemanager.resource.memory-mb给容器留了足够空间。伪分布式部署时机器内存只有8GB建议把mapreduce.reduce.java.opts的最大堆设为-Xmx2048m给系统留出余量。3.4 本地跑通的最小命令两份代码编译打包后在Hadoop集群上执行的最少命令只有三行hadoop jar friend-recommend-1.0.jar \ com.example.FriendRecommend \ /input/friends.tsv \ /output/job1 \ /output/job2作业提交后在YARN的ResourceManager界面能看到两个Application依次运行。Job1跑完Job2才开始。如果写的是“一个Driver类里串行提交两个Job”的模式就是这种效果。如果两个Job没有依赖关系却串行会造成资源浪费这里的Job2依赖Job1的输出路径所以必须等待。跑完以后从HDFS上拉结果检查hdfs dfs -cat /output/job2/part-r-00000 | sort -k2 -nr | head -20输出格式是好友对Tab共同好友数按共同好友数降序取前20。看到这个结果就说明推荐主流程已经通了。4. Hadoop伪分布式到集群的部署与作业提交环境搭不好一切白算4.1 伪分布式搭建的关键配置core-site.xml与hdfs-site.xml好友推荐系统的部署文档核心内容是Hadoop环境的搭建。课程设计环境和生产集群一样都需要先准备好JDK和SSH免密登录然后再配置Hadoop。JDK版本与Hadoop版本要匹配配置JAVA_HOME时建议写成绝对路径不要依赖/etc/profile里的全局变量——因为hadoop-env.sh里的配置在部分环境变量加载顺序下会失效这个坑很隐蔽。伪分布式模式下只需要配置两个文件!-- core-site.xml -- configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/home/hadoop/data/tmp/value /property /configuration!-- hdfs-site.xml -- configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name value/home/hadoop/data/namenode/value /property property namedfs.datanode.data.dir/name value/home/hadoop/data/datanode/value /property /configuration伪分布式只有一个DataNode副本数必须设为1否则HDFS会一直处于UNDER_REPLICATED状态。hadoop.tmp.dir决定NameNode和DataNode的数据存放目录建议改成独立路径不要用默认的/tmp因为系统重启会清理/tmp导致NameNode元数据丢失启动时报NameNode is not formatted。启动顺序有讲究hdfs namenode -format # 只在第一次部署时执行 start-dfs.sh start-yarn.sh格式化NameNode的命令执行一次即可反复格式化会导致Cluster ID不一致DataNode注册不上。验证启动是否成功jps能看到NameNode、DataNode、ResourceManager、NodeManager四个进程环境就基本就绪了。Web界面分别监听9870HDFS和8088YARN确认两个Web UI都能打开再往里传数据。4.2 从伪分布式到三节点集群角色分配与启动顺序伪分布式验证通过后可以扩展成三节点集群。标题里的“部署文档”通常会覆盖这部分。常见的角色分配方式如下节点NameNodeDataNodeResourceManagerNodeManagermaster是否是否slave1否是否是slave2否是否是集群模式下core-site.xml里的fs.defaultFS要从localhost改成master节点的主机名dfs.replication改成2。还需要配置workers文件把slave1和slave2的主机名逐行写入。启动顺序从master节点执行hdfs namenode -format start-dfs.sh start-yarn.shstart-dfs.sh会通过SSH自动跳到slave节点启动DataNode所以配置SSH免密登录是前置条件。集群模式下经常出的问题有两个slave节点上没有同步Hadoop安装目录start-dfs.sh找不到命令。JAVA_HOME在slave节点上配置不一致DataNode进程启动失败。这两个问题在部署文档里必须写明“所有节点统一路径、统一环境变量”。我验收过不少方案一大半失败案例都出在这上面。4.3 提交作业后的三个验证点HTTP界面、Counter与YARN日志作业提交后不要只盯着终端看进度。YARN提供的验证手段有三个由浅入深# 1. 查看作业列表和状态 yarn application -list # 2. 查看job历史日志需要拿到applicationId yarn logs -applicationId application_1690000000000_0001 # 3. 从HDFS检查输出 hdfs dfs -ls /output/job2/HTTP界面在http://master:8088/cluster/apps可以看到每个Application的Map完成比例、Reduce完成比例、启动时间、资源占用。如果Reduce卡在100%不动通常是Reducer在做大列表聚合时内存溢出去yarn logs里查OutOfMemoryError即可确认。MapReduce自带的Counter也能提供关键信息File System Counters里的HDFS_BYTES_READ能判断输入是否倾斜Map-Reduce Framework里的Shuffle Errors能定位网络或序列化异常。查看Counter的命令hadoop job -counter job_id \ org.apache.hadoop.mapreduce.TaskCounter \ MAP_INPUT_RECORDS这里有个实战经验如果Job2的Map输出记录数远大于预期往往是Job1的Reducer没有先排序导致好友列表内部顺序混乱两两配对时产生了重复对。解决办法是在PairMapper里先对friends数组排序再配对。4.4 数据倾斜时怎么定位从Input Split到Reduce好友关系数据天然倾斜——明星用户的边数比普通用户多几个数量级。一个拥有千万好友的用户会让某个Reduce任务处理的数据量是其他人的几十倍。定位方法很简单YARN页面上看Reduce任务的耗时分布如果某个Reduce耗时是其他的3倍以上基本可以判定倾斜。处理倾斜有三个可选方案按实施难度排序增加Reduce数量让每个Reduce处理更少的数据。对超大好友列表做“前缀拆分”把列表切成多个块分别配对。使用TotalOrderPartitioner配合采样器让数据量大的key分散到不同Reduce。第三种方案实现成本最高通常需要自定义Partitioner。对好友推荐系统来说第一条方案加上“将超过阈值的好友列表单独处理”就能覆盖绝大多数场景。具体阈值设为多少取决于单条记录的最大长度——建议把超过10万好友的用户单独抽出来走一个独立的Job不与普通用户混跑。5. 部署后的验证方法与推荐结果上线的两个技巧整个系统跑通后不能只拿head -20看一眼就收工至少要做一次量的验证。把结果表按“共同好友数”降序排列后随机抽三四十个用户逐个检查推荐的好友是否满足“这些人是该用户好友的好友而不是该用户当前好友”。这个验证逻辑虽然朴素但能发现一个很隐蔽的错误Job2输出的pair没有过滤掉真实好友。原因是Job1做了双向展开用户A和B如果本来就是好友那么A的好友列表里有BB的好友列表里有A在某个共同好友的列表里A和B依然可能同时出现。严格的做法是在Job2之后接一个“排除已知好友”的过滤Job或者在输入关系表时把已存在的对标记出来在最终结果里过滤。答辩时主动说出这个坑比说自己跑通了多少数据更有说服力。两个上线技巧值得写进部署文档第一个技巧是结果回写业务库。MapReduce算出的是全量TopN但线上接口不能直接查HDFS。我一般会在Job2跑完后把结果拉取到本地再批量写入MySQL。数据量在百万级以内时直接用LOAD DATA LOCAL INFILE即可每天定时执行一次线上服务只读MySQL。LOAD DATA LOCAL INFILE /data/recommend_result.tsv INTO TABLE friend_recommend FIELDS TERMINATED BY \t (user_id, recommend_id, score);第二个技巧是给共同好友数加时间衰减。把“近30天有互动”的共同好友权重提升到“半年以上无互动”的好友的3倍可以让推荐结果更贴近用户现状。具体做法是在Job1阶段输出的好友列表里带上权重Job2的Reducer由计数改为累加权重和。改造量很小但效果提升明显。推荐系统的部署不是跑完Job就结束还要考虑每天的数据更新。HDFS上建议保留最近7天的快照目录每天的全量计算从当天目录读取输入输出写到带日期后缀的结果目录这样回滚时只需要切回前一天的输出不需要重新计算。这个目录规划放进部署文档里会让整个项目看起来更像一个可持续运行的系统而不是一次性作业。本文还有配套的精品资源点击获取