基于Hadoop的电影推荐系统实战：从爬虫到SpringBoot接口的完整实现

简介：面向毕业设计、课程设计与工程实训场景，这是一份基于Hadoop大数据技术的电影推荐系统完整项目包。系统采用SpringBoot作为后端框架，Vue实现前端页面，MySQL 5.7存储业务数据，并通过Scrapy爬虫采集电影信息，配合Hadoop完成海量用户行为数据的存储与分析；用户端支持历史记录、收藏与管理个人偏好，管理员端提供电影信息维护、论坛交流以及评分、导演、类型、地区等统计看板。包体共642个文件，整体大小约26MB，主要包含Java后端源码、Vue前端页面、JavaScript逻辑、SQL数据库脚本、XML与CSS配置文件、SVG和PNG图标素材，以及Python爬虫脚本与安装运行批处理。项目已具备可运行源码、SQL文件和LW文档，并附带启动、构建脚本，便于快速部署调试。目前已有94人学习下载，适合需要完整参考大数据推荐流程的进阶学习者，也适合用作毕业设计或课程设计的真实项目底板，可从爬虫采集、Hadoop分析、推荐逻辑到前端可视化获得一套闭环方案。

1. 用Hadoop做电影推荐系统，先回答这三个问题

很多人拿到“基于Hadoop大数据技术的电影推荐系统”这道题，第一反应是埋头啃推荐算法，最后却都卡在Hadoop伪分布式搭建和spider数据采集上。这个题目本质不是让你发明新算法，而是把一条完整链路走通：spider抓取电影评分数据，HDFS存放原始文件，MapReduce算出电影相似度，SpringBoot把结果暴露成HTTP接口。它解决的是离线推荐系统怎么从数据到服务完整落地的问题，也是大数据方向里少有的“算法、存储、后端全覆盖”的题目。适合正在做课程设计或毕业设计的同学，也适合准备大数据岗位面试、想拿一个完整项目讲清楚的人。有三个问题建议先想明白：数据从哪来、相似度怎么算、接口怎么出。把这三个问题理清再动手，一星期就能跑通。

2. 系统架构与数据流转：spider、HDFS、ItemCF、SpringBoot怎么串成一条线

整个项目的难点不在某一个单点，而在模块之间的衔接。很多人把爬虫写好了，却发现HDFS里读不到；MapReduce算完了，SpringBoot又不知道去哪拿结果。所以先把架构和数据流固定下来，再动手写代码，是这套项目里最值得花时间的环节。

2.1 为什么这套架构里Hadoop不可替代：单机算不了共现矩阵

先说句实话：只爬几百部电影、几千条评分，单机MySQL完全扛得住，甚至用Python Pandas几秒就能算完相似度。那为什么还要用Hadoop？一是题目要求，二是这类项目真正想训练的是离线计算的架构思维。电影推荐里最核心的计算是物品共现矩阵：对每个用户看过的电影两两配对，统计“看过A的人有多少也看过B”。这个操作在SQL里就是一张大表自己join自己，数据量到百万级评分时，单机内存和IO都会成为瓶颈，而MapReduce天然适合这种“先分组、再聚合”的并行任务。所以选Hadoop不是因为它比单机快，而是它把计算模型标准化了，数据量变大时不用重写业务逻辑，只需要加节点。

如果你还没搭好环境，建议先按Hadoop伪分布式搭建的步骤把NameNode和DataNode跑起来，再回来读这一章。伪分布式虽然只有一台机器，但提交作业、查日志、调参数的路径和集群完全一致，后面踩的坑在集群里一样会踩。

2.2 四层架构职责拆分：采集、存储、计算、服务各管一段

这套系统按数据流向拆成四层，每一层只干一件事，边界清晰才能独立调试。采集层用Python写spider，产出结构化CSV；存储层用HDFS存放原始文件，Hive负责查询和清洗；计算层用MapReduce实现ItemCF推荐算法，产出每个用户的推荐列表；服务层用SpringBoot读取结果文件，对外提供REST接口。

数据流转上，spider抓下来的CSV先通过hdfs dfs -put上传到HDFS的raw目录，再用Hive做清洗，把脏数据、空值、重复记录去掉，下一步MapReduce直接读清洗后的评分表。计算层的结果写回HDFS的output目录，SpringBoot在启动时把结果加载到内存Map里，用户请求过来直接查Map返回。这里要理解一个关键点：电影评分数据不需要实时更新，每天跑一次离线任务完全够用，所以SpringBoot不直接连HDFS，只在启动和刷新时读一次结果文件，这样接口层和计算层彻底解耦。这也是面试时值得展开讲的设计决策。

2.3 HDFS目录设计：从raw到cleaned再到output的三级目录

HDFS目录设计看着简单，却直接影响后续所有命令的路径参数，建议一开始就定成三级目录：原始数据、清洗数据、计算结果。不要把所有文件堆在/movie下面，否则后续跑MapReduce时很容易分不清输入输出路径，甚至不小心把输出目录建到输入目录里导致任务失败。

# 1. 创建三级目录 hdfs dfs -mkdir -p /movie/raw hdfs dfs -mkdir -p /movie/cleaned hdfs dfs -mkdir -p /movie/output # 2. 上传spider产出的CSV文件到raw目录 hdfs dfs -put movies.csv /movie/raw/ hdfs dfs -put ratings.csv /movie/raw/ # 3. 确认文件真的落盘了 hdfs dfs -ls /movie/raw/

这段命令里，-mkdir -p会自动创建父目录，第一次执行时会把/movie/raw三层一次性建好，省去逐层创建的麻烦。-put是上传文件的常用命令，如果文件很大，它会按块大小自动切成多个block，伪分布式环境下默认块大小是128MB，建议调成64MB，方便在日志里直观看到分块效果。还有一个容易被忽略的参数：伪分布式集群副本数默认是3，但只有一台DataNode，副本数为3只会造成磁盘浪费，建议在hdfs-site.xml里把dfs.replication设为1。

图片1：HDFS三级目录结构示意图（文本描述：raw存放原始爬虫数据，cleaned存放清洗后数据，output存放推荐结果）
图片2：数据流架构示意图（文本描述：spider → HDFS raw → Hive cleaned → MapReduce output → SpringBoot API）

3. spider采集到HDFS：抓取、去重、落盘的完整链路

爬虫是整套系统的数据入口，但很多人的爬虫写得很随意，抓到什么存什么，结果到算法阶段才发现字段对不上。这一章从字段设计开始，到去重和增量更新结束，目标是让爬虫产出的CSV能直接被Hive和MapReduce消费，而不是后期再花大量时间清洗。

3.1 先定字段再写爬虫：这四个字段决定推荐质量

推荐算法吃的不是原始网页，而是结构化字段。字段设计的原则是“宁少勿多”，够用就行。基于ItemCF算法，核心必须有两类数据：电影本身的元数据和用户对电影的评分。电影表至少要有movieId、title、genres三个字段，genres是电影类型，后面做冷启动和结果解释时会用到；评分表至少要有userId、movieId、rating、timestamp四个字段，其中timestamp虽然算法阶段不直接用，但做增量更新和数据集划分时非常关键。

有些教程会建议再爬演员、导演、标签，这在教学项目里其实没必要。字段越多，爬虫越容易被反爬机制干扰，清洗时处理空值的成本也越高。你爬下来的数据将来要进Hive表，每个字段都要有明确类型，比如rating必须能转成FLOAT，timestamp必须能转成BIGINT，否则Hive建表后查询直接报错。建议在爬虫里就把类型转换做掉，不要在Hive阶段才发现几千条数据里混入了脏字符。

3.2 爬虫代码骨架：requests加BeautifulSoup的最小实现

以抓取豆瓣电影Top250为例，这是一个非常经典的入门目标，页面结构稳定、分页规律，适合做课程设计演示。下面的代码用requests请求页面，BeautifulSoup解析HTML，最后用Pandas输出CSV。

import requests from bs4 import BeautifulSoup import pandas as pd import time HEADERS = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)", "Accept-Language": "zh-CN,zh;q=0.9" } def fetch_page(start): url = f"https://movie.douban.com/top250?start={start}" resp = requests.get(url, headers=HEADERS, timeout=10) resp.raise_for_status() soup = BeautifulSoup(resp.text, "html.parser") movies = [] for item in soup.select(".item"): title = item.select_one(".title").get_text(strip=True) rating = item.select_one(".rating_num").get_text(strip=True) quote = item.select_one(".inq") movies.append({ "movieId": f"mv_{start}_" + title[:6], # 简单生成ID，真实项目用数据库自增ID "title": title, "rating": float(rating), "quote": quote.get_text(strip=True) if quote else "" }) return movies def main(): all_movies = [] for start in range(0, 250, 25): # Top250每页25条，共10页 all_movies.extend(fetch_page(start)) time.sleep(1) # 基础限速，防止被反爬机制识别 df = pd.DataFrame(all_movies) df.to_csv("movies.csv", index=False, encoding="utf-8-sig") print(f"抓取完成，共 {len(df)} 条记录") if __name__ == "__main__": main()

这段代码里，HEADERS中的User-Agent是模拟浏览器请求的必要参数，不带它很多网站直接返回403。time.sleep(1)是限速，每抓一页停一秒，既降低对方服务器压力，也避免IP被临时封禁。encoding="utf-8-sig"写出来的CSV带BOM头，Excel直接打开不会出现中文乱码，这个细节在后面Hive阶段也很重要。quote字段不是算法必需的，但可以放到SpringBoot接口的返回结果里做展示，让推荐结果更有人味。爬虫抓完之后别急着写下一段，先打开CSV确认一下字段类型，再进下一节。

3.3 去重与增量更新：不能每次全量抓

爬虫跑一次简单，但项目调试过程中你会反复重跑爬虫，如果不做去重，同一个电影会反复出现在CSV里。最直接的去重方案是用Pandas按标题或ID去重，但更稳健的做法是把已抓取的movieId存一份清单，每次抓取前先加载已有ID集合，抓取时跳过重复项。

import os def load_existing_ids(path="movie_ids.txt"): if not os.path.exists(path): return set() with open(path, "r", encoding="utf-8") as f: return set(line.strip() for line in f if line.strip()) def save_new_ids(movies, path="movie_ids.txt", existing=None): if existing is None: existing = set() new_ids = set(m["movieId"] for m in movies) - existing with open(path, "a", encoding="utf-8") as f: for mid in new_ids: f.write(mid + "\n") return len(new_ids)

这段代码的增量思路是：已抓取ID文件只追加不重写，即使爬虫中途崩溃，下次运行也能从上次的进度继续，不需要重新抓全量数据。new_ids的计算用的是集合减法，省去了遍历列表判断的写法。实际项目中如果评分数据每天都有新记录，可以按timestamp字段做时间增量，只抓最近一天的新评分。

这里要提一个注意点：爬虫只应该采集公开、合法的数据，并且控制请求频率，不要用高并发去抓，更不要把数据用于商业用途。课程设计场景里抓几百条数据做演示完全够，模拟真实场景时自己构造数据也是常见做法。爬虫的产出是CSV，下一步就用hdfs dfs -put把它上传到/movie/raw目录，进入存储阶段。

4. 推荐算法落地：ItemCF的MapReduce三步计算

这是整套系统的算法核心，也是最容易写成一团浆糊的部分。很多人想把相似度计算、排序、过滤全塞进一个MapReduce里，结果Reducer逻辑复杂到根本调不通。ItemCF的标准做法是拆成三个MapReduce任务，前一个的输出就是后一个的输入，每一步都可以独立验证，出了问题能快速定位。

4.1 为什么选ItemCF而不是UserCF：矩阵规模与冷启动的权衡

协同过滤有两条路线：UserCF找相似用户，ItemCF找相似电影。电影推荐场景里用户数量远大于电影数量，UserCF要在每次计算时比较所有用户两两之间的相似度，矩阵规模随用户数平方增长；ItemCF只需要维护电影之间的共现关系，电影数量相对稳定，算一次可以复用很久。另一个实际原因是可解释性：给用户推荐“和你之前看过的某部电影相似”的电影，远比“和你相似的用户看过的电影”更容易让人信服。

ItemCF也有自己的坑：新电影由于没有评分记录，共现矩阵里它和其他电影的相似度都是0，这就是冷启动问题。常见的做法是维护一份热门榜单，新电影和没有任何行为的新用户一律先推热门榜，等积累了一定评分后再进入个性化推荐。理解这个取舍之后，下面三步计算会顺理成章。

4.2 第一步：按用户分组，输出“用户-电影列表”

MapReduce的第一步是把评分表按用户分组，得到每个用户看过的电影列表。输入是Hive清洗后的CSV文件，每行格式是userId,movieId,rating,timestamp，输出是userId movie1,movie2,movie3这样一行一条用户记录。Mapper负责把每行拆出userId和movieId，真正做分组聚合的在Reducer。

public class UserMovieMapper extends Mapper<Object, Text, Text, Text> { private Text userId = new Text(); private Text movieId = new Text(); @Override protected void map(Object key, Text value, Context context) throws IOException, InterruptedException { // 输入行格式：userId,movieId,rating,timestamp String[] fields = value.toString().split(","); if (fields.length < 3) return; // 脏数据直接丢弃 userId.set(fields[0].trim()); movieId.set(fields[1].trim()); context.write(userId, movieId); } }

public class UserMovieReducer extends Reducer<Text, Text, Text, Text> { private Text result = new Text(); @Override protected void reduce(Text key, Iterable<Text> values, Context context) throws IOException, InterruptedException { StringBuilder sb = new StringBuilder(); for (Text v : values) { if (sb.length() > 0) sb.append(","); sb.append(v.toString()); } result.set(sb.toString()); context.write(key, result); } }

Mapper里context.write(userId, movieId)把同一个用户的所有电影发给同一个Reducer，这是Hadoop shuffle阶段自动完成的。Reducer里把迭代器里的电影ID用逗号拼成一个字符串，注意不要用+=拼，数据量大时会产生大量临时对象。粗心的同学会在Mapper里判断rating < 3.0就丢弃，这是不对的，评分低的电影也是用户行为的一部分，只有真正想过滤低质量行为时才需要这样的条件，在基础ItemCF里保留所有评分即可。

这个任务的输出要仔细检查：hdfs dfs -cat /movie/output/users_movies/part-r-00000，看是不是每行一个用户、多部电影、以逗号分隔。如果Reducer输出出结果了，再继续下一步。

4.3 第二步：计算共现矩阵与相似度

第二步的输入是第一步的输出，目标是把同一用户看过的电影两两配对，统计任意两部电影同时被多少用户看过。这个数值叫共现次数，是相似度的基础。Mapper把userId,movie1,movie2这一行拆开后，对电影列表做笛卡尔积，每对电影输出一次计数1；Reducer对同一个电影对求和，得到共现矩阵。

public class CoOccurrenceMapper extends Mapper<Object, Text, Text, IntWritable> { private Text pair = new Text(); private IntWritable one = new IntWritable(1); @Override protected void map(Object key, Text value, Context context) throws IOException, InterruptedException { // 输入格式：userId \t movie1,movie2,movie3 String[] parts = value.toString().split("\t"); if (parts.length != 2) return; String[] movies = parts[1].split(","); for (int i = 0; i < movies.length; i++) { for (int j = 0; j < movies.length; j++) { if (i != j) { // 排除自己和自己的配对 pair.set(movies[i] + ":" + movies[j]); context.write(pair, one); } } } } }

这段代码里movies[i] + ":" + movies[j]用冒号做电影对之间的分隔符，因为电影ID里可能包含逗号或空格，用冒号能避免后续解析时混淆。排除i == j的配对是必须的，电影和自己的共现次数没有意义。输出形如mv_001:mv_002 1，Reducer直接对相同key的value求和。这里“:分隔符”属于内部格式，只要Map和Reduce约定一致就行，后续如果要用Hive查这个中间结果，就把冒号替换成_或/`，因为Hive底层的分隔符配置非常容易在这种地方出问题。

共现次数本身可以直接当相似度用，但更好的做法是加一层归一化，用余弦相似度：count(A,B) / sqrt(count(A) * count(B))，这样可以削弱热门电影对整个推荐结果的影响。这一步可以在共现矩阵输出后再跑一个简单的MapReduce任务，也可以在第三步Reducer里实时计算。课程设计为了展示完整流程，建议单独写成第三个任务，以便在文档里把每个阶段的输入输出讲清楚。

4.4 第三步：生成TopN推荐结果

第三步要做三件事：对每个用户，把他看过的每部电影的相关电影找出来；用“物品相似度 × 用户评分”累加出候选电影得分；过滤掉已经看过的，按得分降序取Top10。这一步的Mapper输入是用户电影列表和共现矩阵两个文件，需要在Driver里设置多个输入路径。

public class RecommendReducer extends Reducer<Text, Text, Text, Text> { private Text result = new Text(); @Override protected void reduce(Text key, Iterable<Text> values, Context context) throws IOException, InterruptedException { // key 是 movieId，values 是相似电影及其相似度 // 实际项目中在这里读取用户已看列表，计算候选得分 Map<String, Double> scoreMap = new HashMap<>(); for (Text v : values) { String[] parts = v.toString().split(":"); if (parts.length < 2) continue; String simMovie = parts[0]; double simScore = Double.parseDouble(parts[1]); scoreMap.merge(simMovie, simScore, Double::sum); } // 按得分排序取前10，过滤已看电影后输出 List<Map.Entry<String, Double>> sorted = scoreMap.entrySet().stream() .sorted((a, b) -> Double.compare(b.getValue(), a.getValue())) .limit(10) .collect(Collectors.toList()); result.set(sorted.toString()); context.write(key, result); } }

上面的代码省略了已看列表的加载逻辑，实际实现中这一步通常会用MultipleInputs把用户电影列表和共现矩阵同时输入，在Reducer里用value的标签区分数据来源。得分累加用的是Map.merge，避免自己写判断key是否存在的逻辑。排序用流式操作，取limit(10)得到Top10。输出格式建议和SpringBoot约定为：userId \t movieId1,movieId2,movieId3，一行一个用户，后面接口层直接按\t分隔读取，解析成本最低。

4.5 三个任务的Driver装配与参数设置

三个MapReduce任务需要分别写Driver类，核心参数完全一样，只有输入输出路径不同。一个常见错误是三个任务共用一个输出目录，第二次运行会提示Output directory already exists，Hadoop不允许任务覆盖已有输出目录。

# 第一个任务：用户电影列表 hadoop jar movie-recommend.jar UserMovieDriver /movie/cleaned/ratings.csv /movie/output/users_movies # 第二个任务：共现矩阵 hadoop jar movie-recommend.jar CoOccurrenceDriver /movie/output/users_movies /movie/output/co_matrix # 第三个任务：TopN推荐 hadoop jar movie-recommend.jar RecommendDriver /movie/output/users_movies /movie/output/co_matrix /movie/output/recommend # 查看最终结果 hdfs dfs -cat /movie/output/recommend/part-r-00000

每个任务的输出目录都要用新路径，/movie/output/recommend就是最终结果，后面SpringBoot会用到。跑任务前先确认输入文件存在，用hdfs dfs -ls逐级检查路径，很多“任务成功但结果为空”的问题都出在输入路径写错。参数上，伪分布式环境里建议给每个Map和Reduce容器都分配至少1GB内存，否则数据量稍微大一点就会触发容器被杀，这个在下一章避坑部分详细说。

5. Hadoop伪分布式环境与SpringBoot对接的5个常见坑

这一章是整套系统的血泪经验总结。下面的坑从环境搭建到最终接口对接，每个都是我见过不止一次翻车的场景，按“现象、原因、解决”三段式列出，方便你直接对着排查。

5.1 NameNode起不来：格式化与数据目录的因果关系

现象：执行start-dfs.sh后，用jps看不到NameNode，日志里报Cannot lock storage或者Inconsistent clusterID。原因：伪分布式环境下，有人第一次启动失败后反复执行hdfs namenode -format，每次格式化都会生成新的clusterID，但DataNode的数据目录里还是旧clusterID，两边对不上就启动失败。解决：先执行stop-all.sh停掉所有进程，然后删除Hadoop临时目录rm -rf /tmp/hadoop-*，再重新执行hdfs namenode -format并输入Y确认，最后start-dfs.sh。记住：格式化操作会清空HDFS里的全部数据，只在数据不要了或者clusterID冲突时才做。

5.2 MapReduce卡在Running Job：YARN内存参数没调

现象：作业提交后一直显示Running job，进度卡在0%或map 100%但reduce 0%，日志里有Container killed或GC overhead limit exceeded。原因：伪分布式默认给YARN分配的资源很少，虚拟机的内存又不一定够用，Map或Reduce容器在运行中被NodeManager杀死。解决：改动yarn-site.xml，把yarn.nodemanager.resource.memory-mb设为4096，yarn.scheduler.maximum-allocation-mb设为4096，再在mapred-site.xml里把mapreduce.map.memory.mb和mapreduce.reduce.memory.mb都设为1024。改完一定要重启YARN，stop-yarn.sh再start-yarn.sh，否则配置不生效。

5.3 中文乱码：CSV、Hive、控制台三层都要统一UTF-8

现象：Hive里查出来的中文是问号，SpringBoot返回的JSON里中文变成乱码，Excel打开CSV直接乱。原因：每一层都有默认编码，任何一层不统一UTF-8就会出问题。解决：CSV写入时用encoding="utf-8-sig"，Hive建表语句里加ROW FORMAT DELIMITED FIELDS TERMINATED BY ','，并在客户端执行SET NAMES utf8。检查文件编码用命令file -i movies.csv，如果显示的不是charset=utf-8，就要重新生成数据。还要注意SpringBoot的application.yml里设置一下server.servlet.encoding.force=true，防止HTTP响应头里丢失编码声明。

5.4 任务成功但输出文件是空的

现象：日志显示Job job_xxx completed successfully，但hdfs dfs -cat输出目录时发现只有_SUCCESS文件，part文件是空的。原因：最常见的是Mapper输入路径写错了。比如清洗后的数据在/movie/cleaned/ratings.csv，Driver里却配成了/movie/raw/ratings.csv，而raw目录里的文件格式可能不符合Mapper的解析逻辑，所有行都被当脏数据丢弃。解决：先用hdfs dfs -cat /movie/cleaned/ratings.csv | head -5确认输入文件里有数据且格式正确，再去Driver里核对输入输出路径。还有一种情况是Mapper和Reducer的输出key类型不匹配，Hadoop不会报错，但结果会被静默丢弃，这也是黑匣子问题的典型来源。

5.5 SpringBoot连不上HDFS：权限和依赖双关

现象：SpringBoot项目里用FileSystem.get(conf)读HDFS文件，报Permission denied: user=Administrator或者No FileSystem for scheme "hdfs"。原因：第一个是Windows下启动SpringBoot的本地用户名和Hadoop集群的Linux用户不一致；第二个是项目缺少Hadoop客户端依赖或者core-site.xml没放到classpath里。解决：在SpringBoot的resources目录下放一份core-site.xml，里面指定hdfs://localhost:9000，并配置fs.defaultFS。权限问题可以在启动参数里加-DHADOOP_USER_NAME=root，或者在代码里设System.setProperty("HADOOP_USER_NAME", "root")。Windows环境下还需要把winutils.exe放到Hadoop安装目录的bin里，否则本地调试时HDFS的权限检查会直接抛异常。这个坑在Windows下使用IDEA搭建Hadoop开发环境时几乎是必现的，提前配好可以省半天时间。

6. SpringBoot接口与推荐结果验证：让离线结果变成在线推荐

6.1 接口设计：一个HTTP接口拉通推荐结果

算法算出的推荐结果存在HDFS里，但用户不会去读HDFS，需要一个SpringBoot应用把结果暴露成接口。常见的做法是在应用启动时一次性加载推荐结果到内存Map里，而不是每次请求都去访问HDFS。离线推荐系统的特点是结果不会秒级变化，启动时加载一次完全够用，也避免了对Hadoop客户端的频繁依赖。

@RestController @RequestMapping("/api") public class RecommendController { private final Map<String, List<String>> recommendMap = new HashMap<>(); @PostConstruct public void loadResult() throws IOException { // 演示环境从classpath读取，生产环境从HDFS读取 Path path = Paths.get("recommend_result.csv"); Files.lines(path, StandardCharsets.UTF_8).forEach(line -> { String[] kv = line.split("\t"); recommendMap.put(kv[0], Arrays.asList(kv[1].split(","))); }); } @GetMapping("/recommend") public List<String> recommend(@RequestParam String userId) { return recommendMap.getOrDefault(userId, hotMovieList()); } private List<String> hotMovieList() { // 冷启动兜底：返回热门电影榜单 return Arrays.asList("mv_001", "mv_002", "mv_003"); } }

代码里loadResult用@PostConstruct保证在SpringBoot启动完成后、接口对外提供服务前加载完数据。recommendMap的key是userId，value是推荐电影ID列表，查询接口只做一次Map查找，性能足够。冷启动场景下用户不在Map里时用热门榜单兜底，这是上一章说过的冷启动策略。接口层的参数校验要记得加：userId为空时返回400，数字型userId越界时也要处理，这些边界情况在答辩时会被考官问，提前处理掉显得更专业。

6.2 离线评估：用留出集验证推荐有没有用

接口跑通之后，还要回答一个问题：推荐结果到底好不好。离线推荐系统最常用的验证方法是把评分数据集按时间切分：前80%作为训练集，后20%作为测试集。拿训练集跑完推荐流程后，检查测试集里用户实际看过的电影有多少出现在推荐列表里，就能算出准确率和召回率。

这个评估方案不要求额外写MapReduce，用Spark或者Python Pandas都行。实际教学中，哪怕只是按Precision@10算出30%左右，都已经足以说明推荐链路是通的。如果结果非常差，先怀疑输入数据：评分数量太少会导致共现矩阵极度稀疏，相似度计算出来的数字全是零。

我当初在这套项目上翻过最狠的车，是先写了三天算法代码，最后发现伪分布式环境没搭好，MapReduce根本跑不起来。后来养成一个习惯：先跑通一条最小数据链路，也就是拿十条评分数据从爬虫一路走到SpringBoot接口，再回头填完整数据。这个习惯帮我省下大量时间，希望帮到你。

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