每年到毕设季总能收到类似基于 Hadoop 和 Spring Boot 的某城市旅游推荐周边商城这样的题目。很多人第一反应就是电商套了个大数据的壳然后卡在第一个问题Hadoop 到底在这个项目里干什么我用实际帮同学调过的一个澜港市旅游推荐周边商城项目把这个问题彻底讲清楚——Spring Boot 管在线服务和商城交易Hadoop 负责用户行为日志的批量存储与离线计算两者通过一张推荐结果表衔接形成行为采集→离线统计→推荐回写→在线展示的完整闭环。这篇文章从需求拆解、架构设计、数据流、Hadoop 侧 SQL、推荐算法简化落地、Spring Boot 接口实现到环境排错和答辩文档把整条路走一遍。适合准备大数据方向毕设的同学也适合想快速搭一个有大数据含量全栈项目的新人。1. 先拆题目Hadoop 和 Spring Boot 在项目里各管哪一段1.1 表层题目背后藏着三层需求这个题目看起来只提了 Hadoop 和 Spring Boot但实际操作时你会发现它至少包含三个独立系统在线商城用户注册登录、商品浏览、搜索、购物车、下单、模拟支付、收藏、个人中心这是常规电商能力。管理后台商品上下架、分类维护、库存修改、订单处理、用户管理以及基于统计数据的数据报表图表。大数据处理模块用户行为采集、日志入 HDFS、离线 ETL 清洗、热门商品统计、个性化推荐计算、结果回写。如果只做了商城和管理后台那这就是一个普通的 SSMVue 项目如果只写了几个 Hive SQL 但没有业务系统承接那又撑不起实现与设计这个题目要求的完整度。这个毕设真正的难点和得分点都集中在第三条如何让大数据处理的结果反过来影响商城首页的推荐展示形成一个可演示、可解释的业务闭环。1.2 为什么是这个组合不是缝合是分工我先说一下选型逻辑这个在答辩时基本必问。Hadoop 生态是绝大多数学校大数据课程的核心内容HDFS 提供分布式存储Hive 提供 SQL 化的大数据离线分析。毕设题目里必须出现 Hadoop本质上是要验证你对课程体系的掌握程度。Spring Boot 是 Java 方向的 Web 主流框架用来实现用户端和管理端最稳妥资料多、招人面广、评阅老师也熟悉。真正容易想歪的地方是要不要再加组件。我见过不少同学上来就堆 Flume、Kafka、Spark、Flink、ZooKeeper结果一个组件启动失败就能耗掉一周。我给的建议是存储用 HDFS离线分析用 Hive结果导出用 Sqoop业务库用 MySQL缓存用 Redis在线服务用 Spring Boot一套 Hadoop 生态内的最小闭环就够了。组件越少串联问题越少答辩时你也能把每一个环节为什么这么选讲清楚。1.3 大数据含量到底体现在哪几个可感知的点评判一个毕设是不是大数据项目看的不是代码量而是下面几方面有没有被真正卷入链路海量日志的存储方案用户行为不是直接写业务表就完事而是按天落地成 HDFS 上的分区数据。数仓分层处理ODS、DWD、DWS、ADS 各层的职责划分这是大数据课里最看重的工程思想。离线计算结果反哺在线系统通过 Sqoop 把统计结果导出到 MySQL再让 Spring Boot 读出来展示。推荐算法建在历史行为上个性化推荐的依据来自离线统计出来的物品相似度或用户偏好。为了让这些点看得出来我通常会造 10 万条以上的模拟用户行为数据。没有充足数据热门榜只有几条记录推荐相似度矩阵稀疏得没法看演示效果和论文截图都会很空洞。这一点在后面演示提示部分会再展开。2. 数据怎么流从一次点击到推荐结果回写首页2.1 前端行为埋点与日志落地的两种方式整个数据链条的起点是用户行为采集。前端在商品详情页、首页曝光、加购、下单、收藏等关键动作发生时都调用一个统一的上报接口例如 POST /api/log/behavior参数包含 userId、goodsId、behaviorType、sourcePage、eventTime。后端收到这个请求后做双写一条写入 MySQL 的 t_user_behavior 行为表方便在线查最近行为另一条按一定格式追加写入本地的 JSON/TSV 日志文件例如 /data/log/behavior/2025-01-12.log每行一条字段之间用制表符分隔和 Hive 表的默认分隔符对齐。这里有个关键决策为什么不直接往 HDFS 写因为在线接口的响应时间要求很高HDFS 是批式写入不适合高频小文件的实时追加而且并发高时会拖垮 NameNode 元数据操作。毕设里最稳妥的做法是凌晨跑一个脚本把前一天的日志文件用 hdfs dfs -put 上传到 HDFS 的按日期目录下再用 Hive 的 LOAD DATA 加载到分区表。如果你学有余力可以加 Flume 监听日志目录自动采集到 HDFS但这不是必须项手动上传反而更直白答辩时你这一步做了什么一句话就能答清楚。2.2 离线加工与在线读服务的边界我给这个项目做过一张分工表每次讲解都先讲这张表读者也最容易建立起整体感数据阶段存储位置谁来操作产出结果用户行为原始日志本地日志文件商城后端 Logback 追加写入按天命名的行为日志日志归档HDFS 分区目录Shell 脚本上传ODS 层原始表分区离线清洗与统计Hive 数仓各层表定时 Hive SQL 任务DWD/DWS/ADS 数据结果回写MySQL 业务库Sqoop 导出任务推荐结果表、热门商品表在线推荐读取Redis / MySQLSpring Boot 服务商城首页接口返回这条边界意识很重要Hadoop 侧的活全部在离线窗口期完成也就是每天凌晨那段时间用户白天访问商城时所有请求只打 MySQL 和 Redis绝不直接查 HDFS。这样在线响应快离线计算也不干扰业务。2.3 一次完整数据闭环的具体例子我搭演示数据的时候设计过这样一个场景用户小张前一天晚上浏览了澜港海岛公园门票加入购物车最后下单成功。当天凌晨的批处理任务跑完后日志经历了 ODS 原始加载、DWD 清洗、DWS 用户-商品聚合、ADS 商品共现和相似度计算最终产生了一条类似购买海岛公园门票的用户也购买过海鲜干货礼盒的关联记录通过 Sqoop 导出到了 MySQL 的推荐结果表。第二天小张打开商城首页请求打到 Spring Boot 的推荐接口接口先从 Redis 命中缓存如果没有再从 MySQL 按 userId 查离线结果最终首页猜你喜欢区域出现了海鲜干货礼盒推荐理由标签显示与你在看的商品相似。这个例子在演示视频里只要 30 秒就能讲完但它把埋点、HDFS、Hive、Sqoop、MySQL、Redis、Spring Boot 全部串起来了比单纯展示一张商品列表有说服力得多。你还要能主动说一句这里的推荐是 T1 的因为依赖离线日志的全量计算这句话能提前消掉答辩老师一半的追问。3. Hadoop 侧实现HDFS 目录、Hive 数仓和离线 SQL3.1 HDFS 目录和分区表怎么设计HDFS 目录设计直接决定后面 Hive 建表是否顺手。我习惯按数仓分层建立顶层目录/warehouse/tourism/ods/ -- 原始数据层 /warehouse/tourism/dwd/ -- 明细清洗层 /warehouse/tourism/dws/ -- 汇总服务层 /warehouse/tourism/ads/ -- 应用数据层每一层下面再按业务子目录分比如 ODS 下放行为日志、订单明细等原始数据。Hive 表用外部表加上按天分区是最适合毕设的做法因为数据文件已经放在 HDFS 上了外部表删表不删数据演示和调试都安全。建表语句大致长这样CREATE EXTERNAL TABLE ods_behavior_log ( user_id BIGINT, goods_id BIGINT, behavior_type STRING, -- view / favorite / cart / order event_time STRING, -- yyyy-MM-dd HH:mm:ss source_page STRING ) PARTITIONED BY (dt STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY \t LOCATION /warehouse/tourism/ods/behavior_log;日志文件上传完成后执行 LOAD 命令把数据灌进对应分区LOAD DATA LOCAL INPATH /data/log/behavior/2025-01-12.log INTO TABLE ods_behavior_log PARTITION (dt2025-01-12);注意如果是本地文件就用 LOCAL 关键字HDFS 上的文件则不能加 LOCAL这个差异我见过太多同学在这里栽跟头后面排错部分会再提。3.2 数仓四层在小项目里怎么各自干活不敢说我的划分是标准答案但对毕设来说这个映射关系非常好讲ODS 层原封不动承接业务日志尽量不加工只做格式规范化。DWD 层把 ODS 里的脏数据洗掉比如过滤掉 behaviorType 不在枚举里的记录、去掉 userId 或 goodsId 为空的脏行同时把时间字段规范成标准格式。DWS 层按用户-商品维度做聚合统计每个用户对每个商品看过几次、收藏过几次、加购过几次、下单过几次这是后面推荐算法的输入源。ADS 层面向应用产出两张核心表一是全站热门商品榜二是给用户的个性化推荐候选集可选产出物品相似度表。DWD 层清洗逻辑的典型 SQLINSERT OVERWRITE TABLE dwd_behavior PARTITION(dt2025-01-12) SELECT user_id, goods_id, behavior_type, from_unixtime(unix_timestamp(event_time, yyyy-MM-dd HH:mm:ss)) AS event_time, source_page FROM ods_behavior_log WHERE dt2025-01-12 AND behavior_type IN (view,favorite,cart,order) AND user_id IS NOT NULL AND goods_id IS NOT NULL;DWS 层继续聚合这一步的结果能直接支撑用户 x 商品的行为权重矩阵INSERT OVERWRITE TABLE dws_user_goods PARTITION(dt2025-01-12) SELECT user_id, goods_id, SUM(IF(behavior_typeview,1,0)) AS view_cnt, SUM(IF(behavior_typefavorite,1,0)) AS fav_cnt, SUM(IF(behavior_typecart,1,0)) AS cart_cnt, SUM(IF(behavior_typeorder,1,0)) AS order_cnt, MAX(event_time) AS last_ts FROM dwd_behavior WHERE dt2025-01-12 GROUP BY user_id, goods_id;关于为什么要分层而不直接一个 SQL 查完答辩时可以说分层是为了隔离脏数据、复用中间结果、降低任务耦合这是大数据开发岗位面试都会问的考点放在毕设里就是加分项。3.3 热门商品统计与 Sqoop 结果导出热门榜是最容易出效果的部分。按商品订单数统计 Top 榜或者按分类维度做热门排行Hive SQL 几行就能出来INSERT OVERWRITE TABLE ads_goods_hot PARTITION(dt2025-01-12) SELECT goods_id, COUNT(*) AS order_cnt FROM dwd_behavior WHERE dt2025-01-12 AND behavior_typeorder GROUP BY goods_id ORDER BY order_cnt DESC LIMIT 50;算出结果后Hive 表还在 HDFS 上Spring Boot 查不了。导出动作我推荐用 Sqoop命令示例sqoop export \ --connect jdbc:mysql://localhost:3306/tourism_db \ --username root --password 你的密码 \ --table t_hot_goods \ --export-dir /warehouse/tourism/ads/goods_hot \ --input-fields-terminated-by \t \ --columns goods_id,order_cnt导出的前提是 MySQL 表结构先建好字段类型对齐。这里要提醒一句建议把 Sqoop 导出放在定时脚本里和 Hive 任务一起串成一条批处理链。毕设的调度用最简单的方式就行——写一个 shell 脚本按顺序执行Hive 任务、Sqoop 导出、Redis 缓存刷新交给 Linux 的 crontab 每天凌晨跑。别急着上工作流引擎那不是这个题目的重点。4. 推荐算法怎么落地物品协同过滤的简化版4.1 为什么选物品协同过滤而不是用户协同过滤商城里的商品数量是远小于用户数量的。澜港这种旅游城市的周边商城商品撑死也就几百上千个而注册用户可以有几十万用物品 x 物品的相似度矩阵比用户 x 用户矩阵小得多计算量可控结果也稳定。再加上商品协同过滤的解释性非常好——系统告诉我因为你看过海角灯塔门票所以推荐你古镇联票用户和答辩老师都能一眼看懂。深度学习算法不是不能提而是性价比太低你需要大量训练时间、特征工程和调参效果还不一定比简单的协同过滤好。作为毕设把经典的物品协同过滤实现规范、解释清楚已经超出大多数同学的工作量了。4.2 相似度计算的核心思路与简化实现物品协同过滤的基本假设是对商品 A 和 B 都产生过行为的用户越多AB 就越相似。最常用的余弦相似度公式长这样sim(i, j) |N(i) ∩ N(j)| / ( sqrt(|N(i)|) * sqrt(|N(j)|) )|N(i)| 表示对商品 i 产生过行为的用户集合大小分子是两个商品共同被行为的用户数。为了体现不同行为的权重我在计算时把行为做了加权转换下单记 5 分加购记 3 分收藏记 2 分浏览记 1 分这样用户只看不买的噪声能适当被压制。计算共现关系我习惯用 Spark 做因为可以用 DataFrame 一句话完成自关联比手写 MapReduce 快太多。伪代码如下from pyspark.sql import functions as F df spark.sql(SELECT user_id, goods_id FROM dws_user_goods WHERE dt2025-01-12) # 同一个用户行为过的商品两两配对 item_pair df.alias(a).join(df.alias(b), user_id) \ .filter(F.col(a.goods_id) F.col(b.goods_id)) \ .groupBy(a.goods_id, b.goods_id) \ .agg(F.countDistinct(user_id).alias(co_cnt))拿到 co_cnt 之后再结合每个商品被行为过的用户总数就能算出所有商品对的相似度取每件商品相似度最高的前 50 个作为邻居写入 t_item_sim 表。这里需要说明如果你不想引入 Spark用 Hive SQL 也可以做同样的自关联和聚合只是写起来啰嗦一些。毕设的取舍原则永远是能解决问题、自己能讲清楚工具排第二。4.3 在线推荐列表的生成逻辑与冷启动处理离线算好的相似度表只回答了一个问题与某商品相似的商品有哪些。在线推荐要把用户最近的行为串起来。Spring Boot 接口里做的逻辑大概是从 t_user_behavior 表里取该用户最近 20 条正向行为对应的 goodsId。用这些 goodsId 去 t_item_sim 表查相似商品候选集。对候选商品加权求和权重来自用户行为类型的分数和时间衰减。去掉用户已经买过的商品按总分排序取前 20 个作为推荐结果。给每条推荐结果打一个 reasonTag比如similar表示相似推荐。在线端取候选的 SQL 大概是这样的SELECT sim_goods_id, SUM(score) AS total_score FROM t_item_sim WHERE goods_id IN (:recentGoods) GROUP BY sim_goods_id ORDER BY total_score DESC LIMIT 20;冷启动分两种情况处理新用户没有任何行为直接返回全站热门榜新商品还没有积累足够行为放到同品类热门里保底。这样一来无论数据多稀疏推荐接口永远有返回演示不会出现空白页。把冷启动策略写进代码并画进文档是很能体现工程思维的一个细节。5. Spring Boot 侧商城核心模块与推荐接口实现5.1 模块划分与核心表结构Spring Boot 侧我分了四个大模块用户模块注册、登录、JWT 鉴权、地址管理。商城模块商品列表、分类检索、商品详情、购物车、订单、模拟支付、收藏。推荐模块首页推荐接口、热门榜、推荐结果查询、行为上报接口。管理后台模块商品管理、分类管理、订单管理、用户管理、统计报表。核心表就七张评审老师最喜欢看表结构和它们之间的关系表名作用关键字段t_user用户信息user_id, nickname, avatar, cityt_category商品分类category_id, category_name, parent_idt_goods商品goods_id, goods_name, category_id, price, stock, cover_url, scene_tagt_cart购物车cart_id, user_id, goods_id, num, checkedt_order / t_order_item订单主表与明细order_id, user_id, total_price, statust_user_behavior用户行为user_id, goods_id, behavior_type, event_timet_recommend_result推荐结果user_id, goods_id, score, reason_tag, rec_datet_item_sim物品相似度goods_id, sim_goods_id, score几个字段设计上的小讲究金额一律用 DECIMAL(10,2)不要用 float订单要有状态机比如待支付、已支付、已发货、已完成、已取消t_user_behavior 表给 userId 和 goodsId 建联合索引在线取最近行为时效率差别很大所有表都加 create_time 和 update_time管理后台排序筛选全指望它们。5.2 推荐接口的读取顺序与兜底策略推荐接口是整个项目最核心的在线入口我设计的读取顺序是Redis 缓存优先其次 MySQL 离线结果最后走规则兜底Redis key 设计为 rec:home:{userId}:{yyyyMMdd}缓存离线计算好的推荐列表。命中缓存直接返回未命中查 t_recommend_result 表。MySQL 也没有该用户的离线结果时走冷启动规则返回热门榜加同品类热销。Controller 的骨架大致是这样RestController RequestMapping(/api/recommend) public class RecommendController { Resource private RecommendService recommendService; GetMapping(/home) public ResultListGoodsVO home(RequestParam(required false) Long userId) { ListGoodsVO list recommendService.getHomeRecommend(userId); return Result.ok(list); } }Service 内部就是那套缓存的判断逻辑。注意接口要同时支持未登录用户未登录时直接返回热门榜因为前端首页不能让未登录用户看到空白。统一用 Result 包装返回体也是评审老师会留意的地方建议定义 ResultCode 枚举把成功、参数错误、无权限、系统异常统一管理。5.3 商城交易链路和容易漏掉的小细节交易链路看起来是常规电商功能但三个点必须处理好否则演示时出问题会很尴尬下单事务创建订单、扣减库存、清空购物车三个操作必须放在同一个事务方法里用 Transactional 管理。扣减库存建议用 UPDATE t_goods SET stock stock - #{num} WHERE goods_id #{id} AND stock #{num} 这种原子条件更新防止超卖。模拟支付不要真的接外部支付通道做一个模拟支付接口传入订单号就把订单状态从待支付更新为已支付前后端把状态流转演示清楚即可。答辩如果问为什么不接入真实支付就说演示环境不具备商户资质用模拟通道验证状态机。统一异常处理写一个 RestControllerAdvice 全局异常处理器业务异常返回业务码未知异常返回兜底文案并打印日志。这属于平时没人提、但代码评审一眼就能看出差距的细节。6. 环境搭建与联调的完整排错笔记6.1 从零开始的环境清单与启动顺序如果你的电脑内存足够推荐在虚拟机里装一套 CentOS 环境配置给到 8G 内存、4 核。Hadoop 用单机伪分布式模式就够了毕设不需要真集群但启动脚本、界面端口这些东西和集群一致。整套环境清单如下JDK 8Hadoop 3.xHive 3.xHive 元数据库建议一开始就配置成 MySQL别用默认的 DerbyDerby 在高并发和异常退出时容易锁库MySQL 8.x 业务库Redis 6.xSqoop 1.4.7用于 Hive 到 MySQL 的导出后端 Maven Spring Boot 2.7前端 Vue Element UI 这类常规组合即可启动顺序建议固定先 start-dfs.sh再 start-yarn.sh确认 HDFS 的 9870 端口和 YARN 的 8088 端口能打开然后启动 MySQL 和 Redis最后启动 Hive 服务。把启动步骤写成一个脚本每次演示前一键拉起能省掉大量现场救火的时间。6.2 一次典型故障的完整排查链路首页推荐接口 500讲一个我实际遇到过、很多同学也会遇到的排查过程。现象是白天接口还能返回推荐列表第二天早上突然首页全部报 500。这个过程完整走一遍比直接给一百条避坑总结都有用。第一步看后端日志。控制台报错指向 Jackson 反序列化异常说什么 LocalDateTime 无法解析。这说明问题出在 Redis 缓存的读取上。第二步顺着异常去 Redis 里看实际存的什么。用 redis-cli 的 GET 命令把 key 的值打印出来发现里面是一大段带 \xAC\xED 开头的二进制内容根本不是可读的 JSON。第三步根因浮出水面项目里有人用 RedisTemplate 的默认序列化器写入缓存有人用 StringRedisTemplate 写入 JSON两边读写不一致。默认的 JdkSerializationRedisSerializer 写出来的二进制JSON 那边根本解析不了再加上 Jdk8 的 LocalDateTime 没有默认无参构造Jackson 处理时间是另一层坑。第四步修复方案统一 RedisTemplate 序列化配置key 用 StringRedisSerializervalue 用配置了 JavaTimeModule 的 Jackson 序列化器同时约定所有时间字段统一用字符串yyyy-MM-dd HH:mm:ss传递。修完清掉脏缓存 key重新触发一次离线导出和缓存刷新接口恢复。这个案例最有价值的教训是数据格式和序列化方式必须在项目第一天就定好分布式系统里最贵的从来不是功能开发而是协作规范不一致造成的隐性故障。6.3 其他高频坑和演示前必做的几件事再把其他常见问题列成一张表都是我实际踩过或者看别人踩过的现象原因解决Hive 查询中文乱码表字段字符集和客户端不一致metastore 连接串加 characterEncodingUTF-8表字段用 utf8Sqoop 导出主键冲突导出的目标表没有幂等清理导出前先 TRUNCATE 当天分区对应的表数据Hadoop 启动后 DataNode 起不来多次格式化 NameNode 导致 clusterID 不一致收敛一次后删除 tmp 目录重新格式化分区表查询无数据LOAD 时加了 LOCAL 而文件已在 HDFS记住本地文件用 LOAD DATA LOCALHDFS 文件不能用 LOCALSpring Boot 连 MySQL 报时区错误连接串缺 serverTimezone连接串加 serverTimezoneAsia/Shanghai推荐接口偶发超时未预热 Redis 缓存直接查大结果表离线批处理后主动刷新缓存演示前有三件事必须做一是把离线批处理提前手动跑完让 Redis 缓存处于热状态不要把现场等批处理跑 15 分钟当成演示环节二是造足数据量10 万到 20 万条用户行为让热门榜、用户画像、推荐结果都长得有说服力三是准备一份业务演示脚本先讲普通用户购物再讲管理员上架商品最后重点讲推荐结果的变化整套流程控制在十分钟以内。7. 文档、答辩和这个项目的下一次进化7.1 毕设文档怎么组织最能体现工作量文档的重要性不亚于代码因为很多评审老师不一定细看代码但一定会翻文档。建议按下面大纲组织绪论选题背景、国内外研究现状、项目意义。相关技术介绍Hadoop、Hive、Sqoop、Spring Boot、MySQL、Redis每个技术写清为什么用。需求分析功能性需求、非功能性需求用用例图辅助说明。总体设计系统架构图、模块划分、HDFS 目录结构、数据流图。详细设计数据库表结构、核心类设计、接口设计、关键流程图。系统实现每个模块的界面截图和核心代码讲解。系统测试功能测试用例表、性能测试结果。总结与展望完成情况、不足、后续改进方向。画图工具不用挑能导出 PNG 就行。架构图必须有一张完整的用户→商城→MySQL→批处理→Hadoop→Sqoop→Redis→首页的链路图这张图是全篇文档的灵魂答辩 PPT 里也要放。7.2 答辩高频追问和应答思路我总结评审老师最爱问的五个问题以及可以提前准备好的回答思路为什么用 Hadoop不用单机 MySQL 直接算回答重点Hadoop 解决海量日志的存储和分布式计算问题单机 MySQL 无法承载 TB 级行为数据本项目虽然演示数据是十万级但架构具备水平扩展能力。为什么推荐算法选物品协同过滤回答重点商品数远小于用户数物品相似度矩阵稳定、可解释性强冷启动策略完备。你的推荐效果怎么验证回答重点可以从行为覆盖率、推荐位点击率统计、热门兜底比例三个指标说明虽然做不到线上 A/B 测试但设计了统计埋点。集群节点挂了怎么办回答重点NameNode 和 DataNode 的副本机制、Hive 任务的重跑机制、MySQL 定时备份。数据量再大十倍有哪些瓶颈回答重点Hive 任务耗时会变长需要引入调度系统、分区策略优化、加 Spark 加速这就是后续展望。回答的基本原则是承认项目是简化实现但从架构到算法都能说出取舍理由评审老师更看重思路而不是功能是否齐全。7.3 如果再往前走一步往哪几个方向扩展对这个项目最自然的三个扩展方向分别是实时化、画像化、算法升级。实时化可以引入 Kafka 加 Flink把 T1 推荐改成分钟级更新但这已经是另一个毕设的量级了画像化可以在 Hive 里增加用户标签计算比如价格敏感度、品类偏好、旅游场景亲子、情侣、老年团标签结果直接进推荐接口作为权重算法升级可以用 Spark MLlib 的 ALS 矩阵分解替代共现矩阵把隐式反馈问题建模成矩阵补全。我的建议是这三个方向只挑一个写进总结与展望作为加分表述就好不要真在毕设阶段全部实现。项目最重要的是完整闭环和自洽逻辑而不是组件数量。最后说点个人体会。网上这个题目的源码包很多但拿到手就导入运行、改个城市名交差的做法最终坑的是自己。答辩时老师让你现场讲一下 Hive 里哪张表存相似度、哪个脚本做导出答不上来反而更难堪。我建议你拿到参考代码后至少亲手做三件事把 Hive SQL 从头写一遍跑通把推荐接口的缓存逻辑自己重构一次把模拟数据的生成脚本看懂并改造成自己的场景。做完这三步这个项目才真正属于你。