很多同学在选大数据毕业设计题目的时候，第一反应都是“推荐系统”，原因很简单——这个方向既有算法内容可以写，又有可视化可以展示，还能和“大数据”这个关键词牢牢挂钩。但真正动手做的时候，才发现坑比想象中多得多。尤其是题目里一旦带上“基于Hadoop”，很多人就开始纠结：推荐系统到底跟Hadoop有什么关系？Hadoop在项目里到底承担什么角色？是做协同过滤算法，还是只用来存数据？如果只是把数据丢进HDFS，那跟普通的关系型数据库方案有什么区别？
这篇博文就以“基于Hadoop的宠物用品推荐系统”为例，把整个设计思路、技术选型、实现路径和踩坑记录完整拆一遍。不管你是准备开题、正在写代码，还是已经到写论文阶段，这篇文章都能帮你把“Hadoop + 推荐系统”这条线的逻辑捋顺。
1. 内容整体设计与思路拆解
1.1 为什么选Hadoop做推荐系统，而不是一台普通服务器
先说一个很多同学没想清楚的问题：推荐系统本身并不需要Hadoop。一个跑在单机上的Python脚本，用协同过滤算法处理几千条用户行为数据，完全够用。那为什么毕业设计还要硬塞一个Hadoop进去？
因为毕业设计的核心考察点不是“推荐准不准”，而是“你对大数据技术栈的理解和应用能力”。Hadoop在这里承担的是分布式存储与分布式计算的底座角色。你要展示的不是“我会调一个surprise库”，而是“我能把海量日志数据存储到HDFS，用MapReduce或Spark完成离线计算，再通过推荐算法产出结果”。换句话说，Hadoop是舞台，推荐算法是演员，你得先搭好舞台，演出才能成立。
针对宠物用品这个场景，数据特点也很典型：宠物主人在电商平台上的浏览、收藏、加购、购买行为，会产生大量半结构化或非结构化的日志数据。这些数据如果存在MySQL里，单表几百万条之后查询就会明显变慢，而且要做复杂的用户行为序列分析，SQL写起来非常痛苦。把这些原始日志导入HDFS，再用Hive做数据清洗和特征提取，用MapReduce或Spark跑推荐模型，最后把推荐结果同步回MySQL供Web端展示——这条链路才是“基于Hadoop”的真正含义。
1.2 宠物用品推荐系统的功能边界划分
在设计系统时，建议把功能边界划成三个模块，这样写论文时逻辑也清晰：数据采集与存储模块、推荐计算模块、结果展示模块。
数据采集模块负责生成或收集用户行为数据。毕业设计通常没有真实用户，所以需要写一个模拟数据生成器。别小看这个部分，模拟数据的质量直接决定推荐效果。比如用户ID要有分布规律、商品类别要符合宠物用品的实际分类（猫粮、狗粮、猫砂、玩具、洗护用品等）、行为类型要有时间先后顺序。如果你随机生成数据，每个用户的行为都是均匀随机分布，那推荐结果必然是一团糟。
推荐计算模块是整个系统的技术核心。离线部分用Hadoop的MapReduce或者Spark做用户行为统计、物品共现矩阵计算，然后用协同过滤算法生成推荐候选集。在线部分用一个轻量级的相似度查询服务，从Redis或MySQL中读取预计算好的推荐结果。这样的设计思路是“离线计算、在线查询”，避免在线实时计算的高延迟问题。
结果展示模块就是一个Web应用。宠物用品推荐系统的界面，建议包含三个核心页面：热门商品推荐页、基于用户的协同过滤推荐页、基于物品的协同过滤推荐页。这样你在论文里可以做对比分析，评估两种算法在宠物用品数据上的表现差异。
1.3 为什么推荐系统适合用协同过滤而不是深度学习
很多同学的误区是一上来就要用深度学习，什么Wide and Deep、DIN、Graph Embedding。说实话，本科生毕业设计用这些模型，容易给自己挖坑。一方面，深度学习需要大量训练数据，你模拟生成的数据量根本喂不饱模型；另一方面，Hadoop生态对你的支持主要体现在离线批处理上，深度学习训练框架跟Hadoop的整合，写起来非常繁琐，答辩时也很难讲清楚。
协同过滤就不一样。它逻辑直观，实现难度适中，而且天生适合Hadoop分布式计算。比如基于物品的协同过滤，核心是计算物品之间的相似度矩阵。这个过程可以拆成MapReduce的多个阶段：第一个MapReduce统计用户对物品的评分或行为权重，第二个MapReduce计算两两物品的共现次数，第三个MapReduce归一化得到相似度矩阵。每一步都清清楚楚，论文里可以画流程图、贴核心代码、分析运行日志，内容非常充实。
2. 核心细节解析与实操要点
2.1 Hadoop集群规模的取舍：伪分布式还是真实集群
先把这个最实际的问题解决掉。据我观察，大部分毕设同学面临的情况是：笔记本电脑8G或16G内存，跑Windows或Ubuntu虚拟机。这种情况下，搭建一个三节点的完全分布式Hadoop集群会很吃力，不说别的，三台虚拟机光内存就得占掉6G以上，再跑MapReduce任务，电脑基本就卡死了。
我的建议是：如果不是学校提供了服务器资源，就用伪分布式模式。伪分布式的本质是，所有守护进程（NameNode、DataNode、ResourceManager、NodeManager）都运行在同一台机器上，但配置的是分布式参数。这样做的好处是，你可以在论文里写“本系统采用Hadoop伪分布式模式构建，完整模拟了分布式文件系统和分布式计算框架的运行机制”，同时又不至于让电脑崩溃。
但有一点要注意：你需要在论文里明确说明，生产环境会扩展到多节点的集群。最好在实验章节加一个“集群扩展方案”，简单描述一下如果增加节点，需要在哪些配置文件中修改、NameNode和DataNode之间的关系如何变化。这样答辩老师就知道你理解分布式架构，而不只是会跟着教程敲命令。
2.2 宠物用品推荐的核心算法流程与MapReduce实现思路
基于物品的协同过滤（ItemCF）是这里最推荐的核心算法，它比基于用户的协同过滤更适合电商类场景。原因很简单：用户数量通常远大于物品数量，宠物用品SKU一般在几百到几千，而用户可能是几万甚至几十万。计算物品相似度矩阵的规模远小于计算用户相似度矩阵，而且物品相似度相对稳定，不需要频繁更新。
ItemCF的算法核心分三步：
第一步，构建“用户-物品”行为矩阵。把用户行为日志转成用户对物品的评分。这里要注意，不同行为类型的权重不同，我的经验值是：购买5.0、加购3.0、收藏2.0、浏览1.0。这个权重不是拍脑袋定的，你在论文里要说明，购买行为代表强偏好，浏览行为代表弱偏好，赋不同权重能减少噪声数据的影响。
第二步，计算物品间的相似度。公式是余弦相似度或者共现相似度。所谓共现，就是两个物品被同一个用户同时行为过的次数。用公式表示就是：
sim(i, j) = 同时喜欢物品i和物品j的用户数 / 喜欢物品i的用户数这个公式用MapReduce实现时，要把“喜欢某个物品的用户列表”作为中间输出，然后在Reduce阶段两两配对统计共现次数。
第三步，生成推荐列表。对于目标用户，找出他行为过的物品集合，遍历这些物品的相似物品，排除用户已经行为过的物品，按相似度加权求和排序，取Top-N。
这里我贴一段简化版代码，展示Map阶段如何输出用户-物品对和物品-物品共现对：
public static class ItemCooccurrenceMapper extends Mapper<Object, Text, Text, Text> { @Override protected void map(Object key, Text value, Context context) throws IOException, InterruptedException { // 输入格式: 用户ID, 物品ID, 行为权重 String[] tokens = value.toString().split(","); String userId = tokens[0]; String itemId = tokens[1]; String weight = tokens[2]; // 输出: 用户ID -> (物品ID:权重) context.write(new Text(userId), new Text(itemId + ":" + weight)); } }在写MapReduce的时候，有一个新手经常犯的错：认为每个MapReduce任务要一口气解决所有计算。实际上一个完整的ItemCF至少需要三个MapReduce作业串联。第一个做数据清洗和格式化，第二个计算物品共现矩阵，第三个做归一化和推荐度计算。如果你用Hive来写，可以用几条SQL搞定类似逻辑，但用原生MapReduce写，论文的“核心算法实现”章节会饱满很多。
2.3 数据采集层：模拟数据生成器的关键细节
获取模拟数据这一步，很多同学直接用Python的random库随机拼几条数据就结束了，结果导致推荐结果毫无可解释性。要让推荐系统看起来“有用”，必须让数据带有人为设计的偏好模式。
我的做法是：先生成用户类型，比如“猫主人”和“狗主人”，猫主人大概率浏览猫粮、猫砂、猫玩具，狗主人大概率浏览狗粮、牵引绳、咬胶。再生成商品类别映射表，确保物品ID和类别强关联。最后生成行为序列，每个用户按照“搜索→浏览→收藏→购买”的顺序产生行为，行为时间用泊松分布模拟，而不是用均匀分布。
一个可复现的参数配置是这样的：
- 用户总数：1000
- 商品总数：200
- 行为日志条数：30000~50000条
- 用户行为稀疏度：70%的用户只对不到20个物品产生行为
- 热门物品：随机选择10个商品作为爆款，60%的用户都会产生行为
这样造出来的数据有几个好处。首先，它符合真实世界的长尾分布；其次，因为数据中存在天然的偏好聚类，协同过滤算法能算出有意义的相似度；最后，热门物品和非热门物品的推荐结果差异明显，你评估推荐效果时就有话可说，比如“头部商品覆盖率”“推荐结果多样性”都能作为评价指标。
2.4 Web展示层与推荐结果缓存的配合
展示层建议直接用Spring Boot写一个简洁的Web应用，或者更轻量的方案是Flask + ECharts。推荐结果不要实时算，因为MapReduce任务跑完需要时间，用户不可能等几十秒。正确做法是：定时调度推荐任务（比如每晚跑一次），把结果写入MySQL中的推荐结果表，Web应用查询这张表做展示。
MySQL表结构可以这样设计：
CREATE TABLE recommend_result ( user_id INT NOT NULL, item_id INT NOT NULL, score DOUBLE NOT NULL, algorithm VARCHAR(20) NOT NULL, create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (user_id, item_id, algorithm) );这里设计一个算法标识字段很有必要。同一用户，基于用户协同过滤和基于物品协同过滤会生成两套推荐结果。展示页面上可以做Tab切换，对比两种算法的差异。这个对比过程不仅是加分项，也是你论文里实验分析的素材。
3. 实操过程与核心环节实现
3.1 Hadoop环境搭建的关键步骤与验证方法
这部分我只挑最容易出问题的环节讲，详细的安装命令网上教程多得是，但很少有人告诉你装完之后如何验证系统真的没问题。
我建议的安装步骤是：先装JDK8，再配置SSH免密登录，然后解压Hadoop安装包，修改hadoop-env.sh、core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml这五个文件，最后格式化NameNode。
这里有一个很重要的顺序问题：格式化NameNode必须放在所有配置完成之后，并且只能执行一次。如果你改了hdfs-site.xml里的dfs.replication或者dfs.namenode.name.dir参数，需要删除/tmp/hadoop-*目录下的数据，重新格式化。否则会出现NameNode和DataNode的集群ID不一致问题，现象就是jps能看到进程，但HDFS的Web界面显示DataNode数量为0。
验证Hadoop是否就绪，不要只看能启动进程，还要实际跑一个测试任务。推荐用Hadoop自带的WordCount示例，它虽然简单，但涉及完整的MapReduce生命周期。当你在YARN的8088端口看到Application状态变为SUCCEEDED，才说明集群真的没问题。
3.2 创建模拟宠物用品数据的完整脚本
用Python生成模拟数据是效率最高的方式。我这里给出一份可以直接使用的核心代码框架，读者可以按自己的需要扩展：
import random import datetime users = range(1, 1001) # 1000个用户 items = range(1, 201) # 200个商品 # 商品类别映射：1-100为猫类用品, 101-200为狗类用品 def get_category(item_id): return "cat" if item_id <= 100 else "dog" # 用户偏好映射 user_prefs = {} for u in users: user_prefs[u] = "cat" if random.random() < 0.5 else "dog" # 行为生成 behavior_weights = {"view": 1.0, "fav": 2.0, "cart": 3.0, "buy": 5.0} with open("user_behavior.csv", "w") as f: f.write("user_id,item_id,behavior,weight,ts\n") for u in users: pref = user_prefs[u] # 每个用户产生30~60条行为 for _ in range(random.randint(30, 60)): if random.random() < 0.8: # 80%概率选择偏好类目下的商品 item = random.choice([i for i in items if get_category(i) == pref]) else: # 20%概率选择其他类目，模拟跨类目浏览 item = random.choice([i for i in items if get_category(i) != pref]) behavior = random.choice(["view", "view", "view", "fav", "cart", "buy"]) weight = behavior_weights[behavior] ts = datetime.datetime(2024, 1, 1) + datetime.timedelta( minutes=random.randint(0, 365*24*60)) f.write(f"{u},{item},{behavior},{weight},{ts}\n")这段代码生成的CSV就是HDFS上的原始数据。有一点要记住：写进HDFS之前，一定要确认文件编码是UTF-8，且换行符是\n。Windows环境下用记事本编辑过的CSV可能有\r\n，会导致MapReduce读入时出现空行，进而引发解析错误。
3.3 从HDFS到Hive的数据导入与特征表构建
原始CSV直接放在HDFS上可以，但做数据分析时不如用Hive建表方便。你可以把Hive理解为“给HDFS上的文件加一层SQL视图”，不需要额外存储数据，查询时底层还是走MapReduce或Tez。
宠物用品推荐系统的数据表建议建四层：
第一层是原始行为表ods_user_behavior，字段跟CSV对齐。第二层是清洗后的明细表dwd_user_behavior_clean，主要做去重、过滤异常值。第三层是特征聚合表dws_user_item_score，按用户和物品聚合出评分。第四层是应用层ads_item_similarity，存放计算出的物品相似度结果。
Hive建表语句可以用分区表来控制数据规模。比如按日期分区，每天一个分区，这样模拟数据时可以生成多天的数据，体现大数据量的积累过程。
一个建表示例：
CREATE EXTERNAL TABLE ods_user_behavior ( user_id INT, item_id INT, behavior STRING, weight DOUBLE, ts STRING ) PARTITIONED BY (dt STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS TEXTFILE LOCATION '/user/hadoop/ods/user_behavior';这里用EXTERNAL TABLE有一个好处：如果Hive表删了，HDFS上的数据文件还在，不至于让之前导入的数据全部丢失。对毕设这种反复调试的场景，这是很实用的保护措施。
3.4 推荐结果的生成与存储
推荐结果生成后，怎么回到MySQL是关键的一步。思路是：把Hive或MapReduce算出的相似度矩阵和推荐候选集输出成CSV，再通过Sqoop或其他工具导出到MySQL。
Sqoop是Hadoop生态里专门做关系型数据库和HDFS之间数据迁移的工具。如果搭建Sqoop比较费劲，也可以用一个更笨但更可控的方法：直接用Hive的INSERT OVERWRITE LOCAL DIRECTORY把结果导出成本地文件，然后写一个Java或Python脚本解析文件并写入MySQL。
我建议导出的结果格式是这样的：
user_id,item_id,score,algorithm其中algorithm字段标记该结果来自ItemCF还是UserCF。Web端查询时，通过这个字段区分不同的推荐策略。
3.5 离线推荐任务调度的最佳实践
毕业设计里需要展示系统“自动化”的能力，这里用任务调度把整个流程串起来：模拟数据生成→上传HDFS→Hive清洗→MapReduce计算相似度→结果导出MySQL。
在实验中，我直接用Linux的crontab做定时调度，每天晚上2点跑一次全流程。你可能会说，每次生成的数据都是一样的，推荐结果不会变啊。没错，所以我把模拟数据生成脚本做成了“增量生成”模式——每天生成当天的新行为数据，追加到HDFS上的对应日期分区。这样每次调度跑出来的推荐结果都会有变化，系统看起来就“活”了。
调度脚本的核心逻辑用一个Shell文件串起来：
#!/bin/bash # 1. 生成当天模拟数据 python3 generate_daily_data.py $(date +%F) # 2. 上传到HDFS hdfs dfs -put /data/behavior_$(date +%F).csv /user/hadoop/ods/user_behavior/dt=$(date +%F)/ # 3. 执行Hive清洗 hive -f clean.sql -hiveconf dt=$(date +%F) # 4. 运行MapReduce推荐任务 hadoop jar recommend.jar ItemCFDriver /user/hadoop/dws/score /user/hadoop/ads/similarity # 5. 导出到MySQL python3 export_to_mysql.py这个脚本看起来简单，但它的价值在于把Hadoop生态的各种工具串成了一条完整的数据流水线。论文里写“系统实现了离线推荐任务的自动化调度”，配一段这个脚本，说服力拉满。
4. 常见问题与排查技巧实录
4.1 NameNode和DataNode集群ID不一致
这是最经典的问题。现象是start-dfs.sh执行后，NameNode进程正常，但DataNode启动后立刻退出或无法连接，Web UI上显示Live Nodes为0。
原因几乎都是因为多次格式化NameNode导致的。NameNode格式化时会在dfs.namenode.name.dir目录下生成一个current/VERSION文件，里面有clusterID。DataNode在第一次连接NameNode时会把clusterID记录到自己本地的VERSION文件里。如果集群ID对不上，DataNode就会拒绝连接。
解决办法分两步。第一步，在hdfs-site.xml中找到dfs.namenode.name.dir和dfs.datanode.data.dir配置的路径。第二步，停掉所有Hadoop进程，删除这两个路径下的所有目录和文件，然后重新格式化NameNode。注意，只删DataNode的数据目录不行，必须NameNode和DataNode的一起删，否则还是会不一致。
也可以不删数据，手动去各自路径下的current/VERSION文件，把clusterID改成一样，然后重启。这个方法对线上环境更友好，毕设场景折腾得起，直接删了重来更干净。
注意：不要在集群运行状态下执行格式化和删除操作，必须完全停掉所有Java进程后再操作，否则会出现文件锁和写入中断。
4.2 MapReduce任务卡在ACCEPTED状态
提交任务后，在YARN界面看到状态一直是ACCEPTED，不进入RUNNING。这通常不是代码问题，而是YARN的资源调度配置问题。
最常见的原因是yarn-site.xml中的yarn.nodemanager.resource.memory-mb参数设置得过小。如果你的机器内存是8G，给YARN分配2G或3G是可以的，但如果设置成512MB，Container可能连启动Java虚拟机的内存都不够，任务就永远等不到资源。另一个相关参数是yarn.scheduler.minimum-allocation-mb，这个值默认是1024，意味着每个Container申请的最小内存是1G。
调试时建议先看一下ResourceManager的日志，它会明确打印“requested resource exceeds the available resource”之类的提示。如果日志没给出有效信息，用yarn application -status <application-id>查看详细诊断信息。
4.3 Hive查询时出现SemanticException
Hive报错里最让人头疼的就是各种SemanticException。常见的原因是分区字段类型不匹配，或者表结构和文件元数据对不上。
比如你建表时定义ts是STRING，但CSV里的时间戳字段写成2024-01-01 12:30:00，这没问题。但如果你在Hive里用了from_unixtime(unix_timestamp(ts))做转换，而ts字段里混入了空值，UDF处理空值时会直接报错。
调试技巧是用hive --hiveconf mapred.job.name=test这种模式在前台运行Hive查询，不要用hive -f后台执行，这样错误堆栈会完整显示出来。另外，养成先SELECT * FROM table LIMIT 10看数据的习惯，确认数据格式和预期一致后再跑复杂的聚合SQL。
4.4 模拟数据看得到，推荐结果却没有量
这是很多人的真实经历：HDFS上数据一大堆，Hive表也能查到数据，但推荐结果表一片空白。排查的思路是，先确认数据分布是否合理。
协同过滤有一个“冷启动”问题。如果大部分用户行为数很少，用户间的共同行为项不足，相似度矩阵会极其稀疏。比如1000个用户对200个商品产生20000条行为，看起来平均每个用户有20条行为，但如果行为集中在少数热门商品上，大多数“尾部”商品就没有任何共现数据，推荐结果自然很空。
一种简单有效的验证方法是：统计每个商品被用户行为过的数量。如果超过一半的商品只有不到5个用户行为过，那数据质量就不行，需要调整模拟数据生成逻辑。把行为分布做成长尾分布，并且把热门商品数量控制在10~20个，其余商品平均分配行为量。
另外，在写推荐结果时，我建议增加一个兜底策略：对于没有行为数据的新用户，直接推荐热门商品Top-N。这既是业界的常规做法，也能保证你的Web页面永远有内容展示，不会出现空白页。
5. 效果评估与论文素材准备
5.1 评估推荐质量的三个核心指标
毕业设计里不能只贴几个截图说“效果不错”，要有量化指标。我在实践中用的三个指标是：准确率、召回率、覆盖率。
准确率的计算方式是，在测试集中取出用户真正产生行为的商品，看推荐列表里有多少是用户真正感兴趣的。召回率衡量的是推荐列表覆盖了多少用户所有感兴趣的商品。覆盖率计算的是推荐列表中不同商品占总商品的比例，用于判断推荐是否过于集中在热门物品上。
具体计算时，在实验章节你需要说明数据划分方式。我把原始行为数据按时间切分，前80%作为训练集，后20%作为测试集。训练集用来计算物品相似度，测试集用来评估推荐命中情况。
一个简单的评估代码示例，用Python实现：
def precision_recall(recommended_items, test_items): hit = len(set(recommended_items) & set(test_items)) precision = hit / len(recommended_items) if recommended_items else 0 recall = hit / len(test_items) if test_items else 0 return precision, recall如果ItemCF的准确率在5%~10%之间，这个数值不要觉得低。推荐系统本身就是精确率和覆盖率之间的权衡，淘宝这种级别的系统精确率也就在个位数水平，你能让数据落在合理区间就好。
5.2 对比实验：ItemCF和UserCF到底哪个好
论文里的对比实验不需要太复杂，但一定要有意义。基于我之前造的数据，实验结果通常是ItemCF的准确率和覆盖率明显优于UserCF。原因是宠物用品的数据特点：用户数量（1000）远大于商品数量（200），UserCF需要构建1000x1000的用户相似度矩阵，数据稀疏度极高，推荐效果被稀释。而ItemCF只需要计算200x200的物品相似度矩阵，稠密度高得多。
你可以把这两条曲线用ECharts折线图画出来，放一张对比表格，再配一段分析文字：“基于物品的协同过滤算法在该数据集上表现更优，其原因在于物品数量远小于用户数量，物品间相似度计算更为稠密和稳定。”这段话放在论文里，是典型的高质量分析，不是堆词。
5.3 常见指标解读误区
有一点需要特别提醒：不要在你的毕设论文里夸大推荐系统效果。比如不要写“本系统推荐准确率达95%”，这在答辩时会被老师质疑到体无完肤。推荐系统没有一个固定的“正确标准”，你的评估只能说明在特定数据集和特定指标下的表现，你要强调的是“对比实验验证了算法选择的合理性”，而不是“模型性能卓越”。
在写论文时，你还需要把评估过程的局限性写清楚。比如“本实验使用模拟数据进行验证，与真实平台的数据分布存在差异，后续工作将接入真实电商日志数据进行进一步验证”。这种诚实的表述反而会提高论文的学术可信度。
6. 个人经验补充与扩展方向
项目做到这里，基础功能就算完整了。但我最后想多说几点经验，这几条是踩过坑之后得来的心得，希望后来者能少走弯路。
第一，代码仓库一定要用Git管理，每个关键节点都要提交。我见过太多人做到一半代码崩了，回退都没法回退，只能从头重写。毕业设计的时间本来就不宽裕，不要在这个环节浪费时间。
第二，Hadoop生态的日志是排查问题最重要的线索，但新手很容易忽略。NameNode日志在$HADOOP_HOME/logs/hadoop-hadoop-namenode-*.log，DataNode日志在类似命名的文件中，YARN日志在$HADOOP_HOME/logs/userlogs目录下。遇到问题先看日志，不要盲目改配置。
第三，这个项目还有很大的扩展空间。如果时间和精力允许，可以尝试把推荐算法从协同过滤升级为ALS矩阵分解，用Spark MLlib实现，这就把Spark技术栈也纳入进来了。或者还可以加入基于内容的推荐，利用宠物用品的类目属性和标题关键词做文本相似度计算。这些扩展方向都可以作为论文里的“展望”章节，让指导老师看到你思考的深度。
我个人的建议是，优先把基于Hadoop的主流程做得干净利落，再考虑扩展。很多同学一开始雄心勃勃，想在毕设里同时用上Hadoop、Spark、Flink、Kafka，最后每个组件都只搭了皮毛，论文里全是粘贴的配置代码，没有任何深度分析。与其这样，不如把一个完整的流程从头到尾吃透，每一步都讲清楚为什么要这么做，答辩时才能胸有成竹。
说到底，基于Hadoop的宠物用品推荐系统，考察的核心不是推荐算法的新颖性，而是你能否把Hadoop生态的多项技术有机地串起来，形成一个自洽的大数据应用系统。把这个逻辑吃透了，换什么商品领域、换什么推荐算法，思路都是一样的。
