简介：该资源是一套面向大数据与推荐系统方向学习者、毕业设计学生及算法入门者的电影推荐系统完整资料，围绕 Spark 技术栈展开，帮助读者理解从需求分析到系统测试的完整开发链路。包内仅有 1 个 docx 文件，压缩包约 7.46MB，内容以论文正文为主体，涵盖绪论、开发技术、系统分析与设计、系统实现、系统测试等章节，并附摘要、目录、参考文献与致谢，结构完整、层次清晰。论文重点讲解了基于人口统计学、基于内容与协同过滤三类推荐算法的原理与设计思路，并给出 Spark、MongoDB 与 Web 前端相结合的开发方案，实现用户登录注册、个性化推荐、电影搜索与用户评分等功能模块，同时包含功能测试与性能测试环节。已有 207 人学习，适合作为毕业设计写作范式参考，也可据此梳理推荐算法选型、系统模块划分与测试用例设计的整体框架。

1. 冷启动悖论：为什么推荐越准的系统，越怕遇到新用户

很多人以为推荐系统的难点是算法精度不够，实际做过一遍就会发现，最先让人翻车的是矩阵里那些空位。一个刚注册的用户没有任何评分记录，协同过滤算不出相似邻居；一部刚上架的电影没人看过，评分矩阵里它整行空白。Spark 加上协同过滤能解决的是「数据够多之后算得快不快」，解决不了「数据不够时该推什么」。这套电影推荐系统真正值得看的地方，是它把基于人口统计学的统计推荐、基于内容的标签相似、基于协同过滤的隐因子模型放在同一条链路上，用离线、实时、详情页三种触发时机各管一段，让大数据场景下的空结果有兜底、有过渡、有精细化。搞懂这个分工，比背下算法公式有用得多。

2. Spark 的内存账本：RDD 血缘为什么比磁盘落地更快

先给结论：Spark 快，主要不是快在「内存比磁盘快」这种物理常识上，而是快在它把一次作业拆成 DAG 之后，能在同一个 stage 内把多次 map/filter 串成流水线，中间不落盘；以及在迭代计算里，把反复使用的那份数据缓存下来，省掉重复读取和重复解析。理解这两点，才知道哪些场景缓存有用、哪些场景缓存纯属浪费内存。

2.1 惰性求值与血缘链：一次 count 之前什么都没发生

RDD（弹性分布式数据集）本质是一份「计算说明书」，不是数据本身。它记着五件事：分区列表、每个分区的计算函数、依赖的父 RDD、分区器（如果是 key-value 类型）、以及首选位置。前四件事合起来就是血缘（lineage）。所有 transformation 只是往血缘链上追加一个节点，一个字节的数据都不会被读进来；只有 action 到来，DAG 才会被提交成 Job，切成 stage，下发到 executor 上真正跑。

// 每一步都只是构造血缘，没有发生任何计算 val raw = sc.textFile("hdfs:///movie/ratings.csv") // map + filter 是窄依赖，会被压进同一个 stage 的流水线里 val parsed = raw.map(_.split(",")).filter(_.length == 4) // 转成 (userId, movieId, score) 三元组 val triples = parsed.map(a => (a(0).toInt, a(1).toInt, a(2).toDouble)) // 只保留 3.5 分以上的正反馈 val positive = triples.filter(_._3 >= 3.5) // 直到 action 出现，前面四步才被一次性调度执行 println(positive.count())

textFile的第二个参数可以指定最小分区数，默认按 HDFS 块大小切；filter之后分区数不变，数据量却可能掉一半，这也是后面要提的数据倾斜伏笔。这段代码里最值钱的一句不是count()，而是「什么都没发生」这件事本身：正因为惰性，Spark 才有机会在提交前做整体优化，把连续的窄依赖合并成一个 stage，把多次函数调用合并成一次对分区迭代器的遍历。

血缘的第二个作用是容错。某个 executor 挂了，丢失的分区不需要整作业重跑，只要顺着血缘从最近的可用父 RDD 重算那一个分区就行。代价是血缘链太长时重算成本高，所以长链路场景要主动checkpoint截断，或者persist一份物化结果。常见的实现思路是：迭代型算法（比如后面要讲的 ALS 训练）在第三次迭代左右缓存，一次性作业不缓存。

2.2 宽依赖与 shuffle：内存加速真正被吃掉的地方

窄依赖指一个父分区只对应一个子分区，map、filter、union、mapPartitions都是。宽依赖指一个父分区的数据要被打散到多个子分区，groupByKey、reduceByKey、join、distinct、repartition都是。宽依赖必然触发 shuffle：数据按 key 重新分区、写磁盘、走网络、再读回来。这一步是磁盘 IO 加序列化，内存再大也躲不开。

所以「Spark 比 MapReduce 快」这个说法要加限定条件。两者都要 shuffle，差别在于：MapReduce 每个 Map/Reduce 阶段结束都把结果落盘，链式作业之间只能通过 HDFS 交接；Spark 在 stage 内部做流水线，stage 之间的 shuffle 文件也不一定立刻落盘。真正拉开差距的是迭代场景——同一个数据集被反复扫描几十次时，MapReduce 每轮都要从磁盘重读，Spark 可以只读一次。

// cache 只在第一次 action 时真正物化，之后常驻 executor 内存 val ratings = sc.textFile("hdfs:///movie/ratings.csv") .map(_.split(",")) .map(a => Rating(a(0).toInt, a(1).toInt, a(2).toDouble)) .cache() // ALS 的每一轮迭代都要完整扫一遍 ratings，缓存直接省掉九次磁盘读取和解析 val model = new ALS() .setRank(20) // 隐因子维度，越大表达力越强、越容易过拟合 .setIterations(10) // 交替最小二乘的轮数，通常 10~20 够用 .setLambda(0.01) // 正则系数，抑制因子数值膨胀 .setSeed(42L) // 固定随机种子，保证结果可复现 .fit(ratings)

cache()和persist()的区别只在存储级别：前者等价于MEMORY_AND_DISK，内存不够时溢写到磁盘。这里有个容易忽略的细节——cache()是惰性的，不写后面那句fit它永远不会生效，很多人在这一步被「缓存好像没起作用」骗过。判断缓存是否命中，看 Spark UI 的 Storage 页，看 Fraction Cached 是不是 100%，而不是凭感觉。

rank和lambda是一对相互拉扯的参数：rank调大，模型能拟合更细的偏好，但每个因子能分到的样本变少，方差变大；lambda调大能压住方差，但压过头会把真实信号也正则掉。工程上的经验是先固定rank=20、iterations=10，用一小部分评分做留出验证，只调lambda，因为lambda对结果的影响更平滑，网格搜索的代价更低。

2.3 一个 Master 三个 Worker：伪分布式里的进程与线程模型

教学和自测环境通常没有真集群，只能在一台物理机上开虚拟机，搭一个 Master 加三个 Worker 的 Standalone 伪分布式。搭法本身不难，值得讲的是它背后的进程模型，因为这决定了资源参数怎么配。

Spark 的调度单位是「应用」。每个应用有独立的 Driver 进程和一组 Executor 进程，应用之间互不共享内存，也就互不干扰。Executor 内部用多线程跑 task，线程数等于分到的 core 数。对比 Hadoop 的 MRv1，每个 task 起一个 JVM 进程，启动开销和 GC 压力都在那摆着；Spark 的线程复用省掉了这部分，代价是同一个 Executor 上的 task 共享堆内存，一个 task 把内存打爆会连累同屋的其他 task。

# Master 节点上启动整个 Standalone 集群 $SPARK_HOME/sbin/start-all.sh # 提交作业：资源参数要和伪分布式的实际规格对齐 $SPARK_HOME/bin/spark-submit \ --master spark://node01:7077 \ --executor-memory 1g \ --total-executor-cores 3 \ --class com.demo.OfflineRecommender \ movie-recommender.jar

--executor-memory在三个 Worker 的伪集群上不能照抄生产值。一台物理机被切成四台虚拟机，每台可用内存本来就有限，给每个 Executor 分 1G 是稳妥起点；分 4G 的结果多半是 executor 被系统 OOM killer 干掉，日志里只剩一句Container killed by YARN for exceeding memory limits或者 Worker 端的Executor lost。--total-executor-cores决定并行 task 上限，3 个 core 意味着同一时刻最多 3 个 task 在跑，分区数设成 30 就会分成 10 批顺序执行，分区数设成 2 又会浪费一半并发。默认分区数一般取 core 数的 2~3 倍，让批次之间能填补长尾 task 留下的空档。

还有一个容易被忽略的点是序列化。Spark 默认用 Java 序列化，每个对象都带完整的类描述，体积大、速度慢。把spark.serializer换成 Kryo，并把自定义的样例类注册进去，shuffle 数据量和缓存占用的内存都能明显下降。在评分矩阵这种「大量小对象」的场景里，这个改动带来的收益比调rank更直接。

3. 离线统计推荐：一条 Spark SQL 怎么算出四张推荐底表

离线链路是整个系统的地基。它每天（或者每次全量重算时）用 Spark SQL 扫一遍评分表和电影表，产出四类结果写进文档数据库，前端打开首页时直接查结果，不做任何实时计算。这条链路的价值在于「确定性」：结果可复现、口径可解释、出错可回滚，用户看到的「历史热门」「高分榜」都是能对上数的。

3.1 四张底表的分工：热门、近期热门、平均分、分类 Top10

四个统计口径对应四种不同的「兜底逻辑」，各自的聚合键和排序依据都不一样。

四张表的计算难度都不高，难点全在口径。比如「近期热门」的「近期」怎么定义，直接决定了结果的时效性。原文的做法是按评分时间戳切出最近一个月，再统计这一个月内的评分数；更稳妥的做法是给时间窗口加一个可配置参数，让窗口长度变成配置项而不是硬编码，A/B 对比时只改配置不重新发版。

平均分这张表要特别注意样本量。一部只有 1 个人打了 5 分的电影，平均分 5.0，排在全站第一，这是典型的「小样本高分污染」。常见的修正思路是用贝叶斯平均：给每部电影预置一个先验均分和先验票数，实际得分是（先验票数 × 先验均分 + 真实评分总和）/（先验票数 + 真实评分数）。票数越少，结果越向先验均分靠拢；票数上来了，真实数据自然接管。这个改动很小，但口碑榜的可信度会明显不一样。

// 历史热门：按电影聚合评分数，取前 N val rateMore = spark.sql( """ |SELECT mid, count(1) AS count |FROM ratings |GROUP BY mid |ORDER BY count DESC |LIMIT 100 """.stripMargin) // 平均分：只在有评分的电影上计算，避免除零 val average = spark.sql( """ |SELECT mid, avg(score) AS avg |FROM ratings |GROUP BY mid """.stripMargin)

count(1)和count(*)在这个场景下没有性能差异，count(具体列)才会跳过空值。ORDER BY count DESC后面如果只跟LIMIT 100，全局排序会把所有数据 shuffle 到一个分区再排，数据量大时要改成先DISTRIBUTE BY再局部排序，或者用窗口函数ROW_NUMBER() OVER (ORDER BY count DESC)在分区内先筛后合。

3.2 genres 字段拆解：UDF + 笛卡尔积过滤的写法与代价

电影表里genres存的是竖线分隔的字符串，比如Action|Adventure|Sci-Fi。要按单个类别分组统计，第一步是把它拆开。原文用的方式是注册 UDF 做切分，再用类别集合和电影表做笛卡尔积、按「电影类别串里是否包含该类别」过滤，最终得到「电影 - 类别」的展开形态。

// 注册 UDF：把竖线分隔的类别串切成数组 val splitGenres = udf((genres: String) => genres.split("\\|").toSeq) // 取出全站所有出现过的类别，去重后作为「类别字典」 val allGenres = movies.select(splitGenres(col("genres")).as("gs")) .select(explode(col("gs")).as("genre")) .distinct() // 假设就只有 Action / Comedy / Sci-Fi 这几十个 // 笛卡尔积：每部电影 × 每个类别，再用 contains 过滤出真实归属 val exploded = movies.crossJoin(allGenres) .filter(array_contains(splitGenres(col("genres")), col("genre"))) .select(col("mid"), col("genre"), col("score"))

这段代码的关键在crossJoin。假设有 5000 部电影、20 个类别，笛卡尔积会产生 10 万行中间结果，再过滤掉大约三分之二。10 万行不算什么，但这一步的本质是一次全量 shuffle，电影数乘类别数才是它的真实成本。类别从 20 涨到 200，中间结果就变成 100 万行，伪分布式环境直接卡住。

更省的做法是用explode把数组直接炸成多行，一次select就完成展开，不需要类别字典，也不需要笛卡尔积：

// 等价写法：直接把类别数组展开成多行，避免了 crossJoin 的全量乘积 val exploded = movies .select(col("mid"), explode(splitGenres(col("genres"))).as("genre"))

之所以原文选择了笛卡尔积，通常是因为项目要演示 UDF、array_contains和 join 的组合用法，教学价值大于执行效率。理解了「展开」这个语义之后，两种写法可以互换，实际系统里没有理由选成本更高的那个。选型判断很简单：只要展开逻辑不依赖外部字典，就用explode；只有当归属规则来自另一张表（比如人工维护的类别映射）时，join 才是必要的。

展开之后按类别分组、组内按平均分降序取前十，这一步用窗口函数最省事：

// 每个类别内部打分排序，取前 10 部 val ranked = exploded .withColumn("rn", row_number().over( Window.partitionBy("genre").orderBy(col("score").desc))) .filter(col("rn") <= 10) .drop("rn")

partitionBy决定分组键，orderBy决定组内排名依据。这里用row_number而不是rank，是因为评分相同的电影用rank会并列，导致某个类别返回超过 10 条，前端分页会错位。

3.3 结果落库：连接器写入与表结构约定

算完的结果要能被子系统读，最直接的做法是写进文档数据库，前端按集合名直接查。写入时的幂等性比写入速度更重要：离线任务每天重跑一次，如果每次都追加，集合会越滚越大，前端查到的第一页全是历史脏数据。

// overwrite 保证每次全量重算后集合内容被整体替换，天然幂等 genresTop10.write .format("com.mongodb.spark.sql.DefaultSource") .option("uri", mongoUri) // 连接串，含库名 .option("collection", "GenresTopMovies") // 目标集合 .mode("overwrite") .save()

mode有三个常用值：append追加、overwrite覆盖、ignore存在就跳过。离线统计场景一律用overwrite，原因很简单——这类结果是可以从原始数据完全重算的派生数据，覆盖不会丢信息，还能顺带清理掉上一版结构不兼容的字段。反过来，用户表、评分表这种原始数据绝对不能用overwrite，那是真的后悔药都没得吃。

集合的字段名要和后端实体类对齐，mid、count、avg这类缩写字段在校验时容易出问题。建议在离线任务末尾加一步 schema 断言，字段名和类型对不上直接抛异常，而不是让脏数据静默流到前端。这类断言写起来只有几行，但能省掉「页面上一片空白、日志里没有任何报错」这种排查半天的情况。

4. 三路推荐的分工：内容相似度、协同过滤与实时链路的边界

一个系统用三种算法，不是因为算法多显得完整，而是因为三种算法分别在补对方的短板。基于人口统计学和统计口径的推荐没有个性化，但永远不会返回空；基于内容的推荐依赖标签质量，但不需要用户历史；协同过滤精度最高，但依赖足够密的评分矩阵。把它们的触发时机拆开，每种算法只在自己擅长的场景里出场，是这套设计里最值得抄的部分。

4.1 基于内容：标签向量与余弦相似度怎么算

基于内容的推荐把电影变成向量，把「相似」变成向量夹角。特征来源就是电影元数据：类别标签、导演、主演、年代。类别做 one-hot，导演和主演可以按出现频次做 TF-IDF 加权——一个演过 50 部片的演员，区分度远低于只演过 3 部的演员，TF-IDF 正好压住这种高频项。

// 余弦相似度：点积除以两个向量模长的乘积，结果落在 [-1, 1] def cosine(a: Array[Double], b: Array[Double]): Double = { var dot = 0.0 var normA = 0.0 var normB = 0.0 var i = 0 while (i < a.length) { dot += a(i) * b(i) normA += a(i) * a(i) normB += b(i) * b(i) i += 1 } // 任一向量为零向量时直接返回 0，避免除零 if (normA == 0.0 || normB == 0.0) 0.0 else dot / (math.sqrt(normA) * math.sqrt(normB)) }

三个累加量分别对应点积和两个模长的平方。返回 0 的那个分支很重要：一部没有任何标签的电影，在向量空间里是零向量，夹角没有定义，如果这里抛异常，整个详情页的推荐模块都会挂。工程上宁可返回 0 让这条候选被排到最后，也不要让一次脏数据中断整批计算。

这个函数在详情页链路里被调用 N 次（N 等于候选电影数），在实时链路里被调用 N×K 次（K 等于用户最近看过的高分电影数）。纯手写循环在 Scala 里比zip.map.sum快，因为避免了中间集合的分配；但真正的瓶颈从来不是这个循环，而是候选集的规模。如果每次请求都拿目标电影和全库几十万部电影算一遍，延迟立刻爆炸。实际做法是先用倒排索引粗排：按类别、按主演建索引，只取共享至少一个标签的候选，再对这几百部精排。粗排召回、精排打分的两段式结构，在内容推荐里比在协同过滤里更必要。

详情页和实时推荐用的是同一套相似度，区别在输入。详情页的输入是「用户点开的这一部电影」，输出是「和它像的若干部」；实时推荐的输入是「用户最近打过高分的若干部电影」，输出是「和这些电影都像、但用户还没看过的」。后者要多做一步合并去重，还要过滤掉已看过的，否则用户会反复看到自己刚评完分的片子——这是最常见的体验问题之一。

4.2 协同过滤：稀疏矩阵与隐因子的取舍

协同过滤有两种主流形态。基于邻域的（UserCF / ItemCF）先算用户之间或物品之间的相似度，再按邻居的偏好加权；基于模型的（矩阵分解）把用户-物品评分矩阵拆成两个低维矩阵的乘积，用隐因子表示用户口味和物品属性。这套系统用的是后者，也就是交替最小二乘。

先看稀疏这件事有多严重。假设 2000 个用户、5000 部电影，矩阵有 1000 万个格子；如果实际评分记录只有 5 万条，密度就是 0.5%。也就是说 99.5% 的格子里没有值。UserCF 在这种矩阵上算用户相似度，两个用户共同评过分的电影可能只有一两部，相似度要么是 0 要么极不稳定，这就是数据稀疏性带来的直接后果。ItemCF 稍微好一点，因为热门电影的评分人数多，但长尾电影依然算不出可靠邻居。

ALS 绕开了这个问题：它不要求两个用户有共同评分，而是把整个矩阵当作一个带缺失值的优化问题，用已知评分去拟合隐因子，缺失位置的值由模型预测。目标函数是最小化已知评分上的平方误差加正则项：

min Σ(r_ui − p_u·q_i)² + λ(‖p_u‖² + ‖q_i‖²)

「交替」的意思是：先固定所有物品因子 q，把每个用户的因子 p 解成一个线性方程组（有闭式解）；再固定 p，解 q；来回交替。每一轮都能让目标函数单调下降，轮数够了就收敛。这个性质是 ALS 比 SGD 更好工程化的原因——每轮只需求解独立的线性系统，天然适合分布式并行，不需要像 SGD 那样控制更新顺序。

// 训练集/测试集切分：固定种子保证每次划分一致 val Array(train, test) = ratings.randomSplit(Array(0.8, 0.2), seed = 42L) val als = new ALS() .setRank(50) // 隐因子维度：用户口味和电影属性的表达空间 .setIterations(10) // 交替轮数，太少不收敛，太多收益递减 .setLambda(0.1) // 正则系数，稀疏数据上要适当放大 .setNonnegative(true) // 评分非负，约束因子非负可提升可解释性 .setImplicitPrefs(false) // 显式评分用 false，隐式反馈（点击/观看时长）用 true val model = als.fit(train) // 为每个用户生成 Top20 推荐，写回结果集供离线查询 val recs = model.recommendForAllUsers(20)

setNonnegative(true)是个容易被忽略但收益明显的开关。评分都是正数，理论上因子可以为负，但负因子在业务上无法解释，还会让预测值超出评分区间。加上非负约束后，预测值天然落在合理范围，也减少了「预测出 7.3 分但评分上限是 5 分」这类需要额外裁剪的情况。

setImplicitPrefs是选型分水岭。显式评分（用户主动打星）适合false；如果系统里主要信号是「看了但没有评分」，就该用true，此时数值的含义从「评分」变成「置信度」，模型会按偏好强度而非绝对分值来拟合。两套模型的参数不能互换，lambda在隐式模式下通常要更大。

评估环节不能用 RMSE 一条路走到黑。评分预测误差小，不代表推荐列表好——模型可能把用户已经看过的高分片排在最前面，RMSE 很漂亮，实际体验没有任何新意。更贴近业务的做法是留出法加排序指标：把每个用户最近的一部分正反馈藏起来，看 Top-N 列表里召回了多少。这套系统面向演示，用 RMSE 已经够用，但只要往生产走一步，排序指标就必须补上。

4.3 离线、实时、详情页：三条链路的触发时机与数据流

三条链路的分工，本质是按「数据新鲜度要求」切分，而不是按算法切分。

离线链路的产出是「用户推荐表」，每个用户一行，存着 Top-N 的电影 ID 列表。前端加载首页时直接按用户 ID 查一行，不需要等任何计算。这份结果的时效性由批跑频率决定，昨天新评的分今天才进模型，这在大多数场景下是可接受的——用户的口味不会一夜之间变。

实时链路补的是「刚发生的兴趣」。用户刚给一部科幻片打了 5 分，等他刷新首页时，离线结果里还没有这条信号。流式处理的做法是消费评分事件，取出该用户最近若干条高分记录作为种子，用内容相似度算出候选，去重、过滤已看、按相似度加权排序，写进缓存并设置过期时间。这里用内容相似度而不是协同过滤，是因为单条新评分不足以更新矩阵分解模型，但足以支撑一次标签层面的相似召回。

详情页链路最轻，也最容易被低估。用户点开一部电影的瞬间，系统要给出「相似影片」，这个请求必须在一百毫秒量级返回。每次现算全库相似度不可能，两种做法：一是离线预计算相似度矩阵，只存每部电影的前 K 个近邻，查询就是一次 key-value 读；二是把电影元数据同步到搜索引擎，用它的相似文档检索能力在线算。前者存储成本高但延迟极低，后者存储省但依赖检索引擎的相关性调参。中小规模用后者更划算，电影量到百万级再考虑前者。

三条链路之间要有明确的降级顺序。离线结果为空（新用户）走热门兜底；实时结果为空（没有新评分）直接用离线结果；详情页结果为空（电影标签缺失）回落到同类别的高分片。缺了这套降级，任何一个环节返回空集合，前端就是一个白块。

5. 避坑清单：从冷启动空结果到序列化异常的五次翻车

下面这五条都是这套架构里真实会撞上的问题，按「现象 → 原因 → 解决」记，比看十页文档管用。

5.1 新用户推荐为空与稀疏矩阵的零相似度

现象一：新注册用户登录后首页推荐区域完全空白，控制台没有异常。原因很直接：ALS 只对训练时出现过的用户 ID 输出结果，新用户不在recommendForAllUsers的返回集合里，查询自然空。解决方式是在读取离线结果时做一次判断，命中为空就回落到「历史热门」加「分类 Top10」，并把这次回落记进日志，用于观察新用户占比。更主动的做法是在用户注册时按填写的偏好标签做一次人口统计学推荐，先给出一版初始结果，等评分攒到阈值再切到协同过滤。

现象二：老用户推荐列表里反复出现同几部电影，换了模型参数也没变化。原因往往不是模型没训练，而是评分矩阵太稀疏，用户和绝大多数电影之间相似度都是 0，排序退化成按电影热度排。解决办法有两个方向：一是引入隐式反馈，把浏览、收藏、播放时长都折算成置信度，把矩阵填密；二是对相似度做惩罚，把热门电影的相似度按热度倒数加权，压住「什么都推热门」的倾向。这两种改动的效果差异要看具体数据，建议先做隐式反馈，因为它的信号量级通常比显式评分大一个数量级。

5.2 集群任务失败：序列化与依赖冲突

现象三：本地模式跑得好好的作业，提交到集群就抛Task not serializable。原因是闭包里捕获了不可序列化的对象，最典型的是把SparkSession、数据库连接、或者某个带状态的工具类直接写进了map的匿名函数里。Spark 需要把闭包序列化后发到 executor，这些对象过不去。解决办法是把依赖抽成方法参数或者用broadcast分发只读数据，不要在闭包里引用 Driver 端的重型对象；如果确实需要外部资源，用mapPartitions在每个分区内初始化一次，而不是每行初始化一次。

现象四：提交时提示找不到类或版本冲突，本地 IDE 里却能编译。这是依赖打包的经典坑。spark-submit时执行环境已经自带了一套 Spark 相关 jar，用户的 fat jar 里如果再打进去一份不同版本，类加载顺序不同就会出各种诡异错误。解决办法是把 Spark 相关依赖在打包配置里设成provided，只打进业务代码和第三方库；提交时用--jars单独指定额外依赖。排查这类问题最有效的手段是看 executor 端的完整堆栈，而不是只看 Driver 返回的那一句概括性错误。

5.3 写入与缓存：覆盖、主键冲突与缓存键设计

现象五：离线任务重跑后，前端推荐列表出现重复项，越跑越多。原因是写入模式用了append，派生数据每跑一次就追加一份。解决办法是把所有「可从原始数据完全重算」的结果集统一改成overwrite，让每次批跑的结果是一个完整快照。如果因为数据量太大不能全量覆盖，那就得改成按日期分区写入，查询时只读最新分区，同时加一个清理任务删除过期分区——用分区替代覆盖，是同一件事的另一种实现。

现象六：实时推荐的缓存里 key 越积越多，内存缓慢上涨直到被打满。原因是写入缓存时没有设置过期时间，用户量涨上来之后每个用户都留着一份永远不会被读的推荐列表。解决办法是给每个 key 设一个合理的 TTL，长度取「推荐结果的有效期」，比如一天；同时把 key 的设计收敛，避免同一用户因为不同入口产生多份重复缓存。这个问题在测试环境永远暴露不出来，因为测试用户太少，只有上了量才会显现，属于典型的「上线后才炸」类型。

6. 混合推荐的取舍：为什么没有一种算法能通吃

把三种算法放在一张表里对比，取舍关系就清楚了。

这张表解释了一个常见误解：不是「三种算法混合所以效果更好」，而是「三种算法各自覆盖一段用户生命周期」。新用户进来，统计推荐兜底；用户点开某部片，内容相似度补位；用户攒够评分，协同过滤接管主推荐位。它们不是同时投票，而是在不同条件下各自出场。真正的混合策略（加权融合、切换式混合、级联）要考虑的是「什么条件下用哪个」，而不是「各占多少权重」。

这也带来一个必须接受的代价：链路变长，故障面变大。离线批跑失败、实时流断掉、缓存穿透、检索引擎不可用，任何一个环节出问题都会在页面上表现为「推荐不准」或者「推荐为空」，而这三类现象在监控上的表现几乎一样。我一般的做法是给每条链路单独埋一个健康指标：离线看结果集行数和最新更新时间，实时看消费延迟和写入条数，详情页看平均响应时间和空结果率。四个指标都正常，才敢说推荐是「正常」的，而不是「没报错」。

还有一个取舍是「先做厚哪一段」。如果时间有限，我建议先把离线统计做扎实，再补内容相似度，最后上协同过滤。理由不是难度递增，而是收益递增的顺序反过来——统计推荐能覆盖 100% 的用户，内容推荐能覆盖有标签的电影，协同过滤只对评分充足的活跃用户有效。按覆盖率排序投入，比按算法先进性排序投入更划算。

从那以后我每次搭推荐链路，都会强制先跑一遍「空用户」的完整路径：注册一个没有任何行为的账号，从登录到首页到详情页全走一遍，看每一步是不是都能拿到结果、降级是不是真的生效。这个动作花不了十分钟，但能提前暴露掉大部分上线后才会被用户撞见的问题。希望帮到你。

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