企业官网建设流程全解析

说实话，计算机毕设选"Spark音乐推荐系统"这个方向的人不少，但真正能把这个题目做得有深度、经得起答辩追问的并不多。不少同学卡在同一个地方：知道要用Spark，也知道大概要做一个推荐系统，但一上手就发现数据不知道怎么来、ALS参数怎么调、实时推荐和离线推荐怎么结合、集群怎么搭，甚至光是环境就能折腾一周。项目编号42921这一版，我前前后后梳理了三周左右，从选题到答辩一路踩坑，最后沉淀出一套完整可跑的源码和设计思路。这篇文章就把这套东西完整拆开，从选题逻辑讲到环境搭建、数据清洗、离线推荐、实时推荐，再到答辩常被追问的点和几个比较典型的坑，帮打算做类似题目的同学少走弯路。

1. 选题动机与系统架构拆解：先想清楚要交什么

1.1 为什么选"Spark + 音乐推荐"这个组合

先说选题逻辑。音乐推荐系统本身是一个很成熟的业务场景，市面上主流的音乐平台都在做，算法从协同过滤到深度学习都有大量公开资料，这意味着你做这个东西不会遇到"没有参考"的困境。而Spark这个技术栈，恰好能覆盖推荐系统里最重要的两个环节：离线大规模数据处理和实时日志流处理。用Spzzark做音乐推荐，本质上就是把你学过的分布式计算、数据清洗、机器学习三个模块全部串起来，答辩时老师想挑毛病都难找出一个大方向上的硬伤。

另外还有一个很现实的原因：数据集好拿。音乐推荐领域的公开数据集比很多领域都规范，Last.fm的听歌记录、百万歌曲数据集（Million Song Dataset）这些都是现成的，字段清晰、体量足够，拿来就能做清洗和建模。这一点在毕设场景里特别关键——很多题目不是难在算法，而是难在找不到一份干净可用的数据，最后只能自己造，反而显得项目不真实。

如果你问我这个题目适合谁，我的判断是：适合有两类基础的同学。第一类是已经把Hadoop/Spark基础看完，但缺乏一个完整项目串联知识点的人；第二类是算法理论懂一些，但想把Spark MLlib从"看过源码"变成"真正跑过训练任务"的人。如果你的基础还停在"写过几个MapReduce单词统计"，那这个题目会有点吃力，建议先把Spark RDD和DataFrame的基本操作过一遍再动手。

1.2 系统功能模块与数据流设计

整个系统我拆成了五个模块，分工很清晰：

数据流大概是这样的：用户在前端产生的行为（播放、收藏、跳转、完整收听）会先写入一个消息队列，然后分两条路走。一条路进离线批处理，每天凌晨用Spark作业清洗全量日志，更新ALS模型并生成新一天的推荐列表；另一条路进实时流处理，用户当天的新行为会被实时捕获，在几秒内更新当前用户的推荐候选集。最终前端拉取推荐结果时，看到的是"昨日离线推荐 + 今日实时修正"的合并结果。

这里设计成Lambda架构思路，一方面是经典，答辩时好讲；另一方面也确实符合音乐推荐的真实业务形态——用户的兴趣是相对稳定的，适合用离线模型刻画，但突然连续听了几首说唱，系统应该快速感知到，这就是实时模块的价值。

1.3 技术栈选型的核心理由

技术栈这一步很多人容易犯迷糊，我按最终定下来的组合逐个说明理由。

版本上我选了Spark 3.1.2 + Scala 2.12 + Java 8。Spark 3.x的Structured Streaming和AQE（自适应查询执行）都成熟了，比用Spark 2.x省心很多；Java 8是最保守的选择，虽然也可以上Java 11，但毕设环境容易遇到各种兼容问题，没必要冒险。部署模式我平时用local[*]调试，正式跑作业的时候用Standalone集群模式，Master节点加两个Worker节点，用三台虚拟机就能模拟，不需要搭Yarn，避免把时间耗在Hadoop生态的复杂配置上。

推荐算法这块用的是Spark MLlib里的ALS（交替最小二乘法）。选它的理由很简单：对音乐推荐这种只有隐式反馈（用户没有显式打分表，只有播放行为）的场景，ALS在处理稀疏矩阵上的效果和易用性都很好，而且MLlib直接提供了现成实现，不需要自己手推矩阵分解数学过程。实时部分用了Structured Streaming的readStream+writeStream模型，相比老的DStream API，它能直接用DataFrame的API操作流，写起来和批处理几乎一样，理解成本低很多。

存储层的分工是：用户行为原始日志放HDFS，清洗后的结构化数据放MySQL，推荐结果也落MySQL供后端查询。Redis在中间用来缓存热点用户的实时推荐结果。其实毕设级别的数据量，不用HDFS也能跑，但加上HDFS能体现分布式存储的完整链条。

2. 环境搭建与数据集准备：踩平地基才能起楼

2.1 Spark环境：从本地模拟到Standalone集群

环境这一步是劝退很多人的地方，但踩过之后回头看，核心就是几个版本一定要对齐。我用的组合是：

• JDK 1.8（注意别装高版本JDK，Spark 3.1对JDK17的支持有问题）
• Scala 2.12.10（仅编译期需要，跑任务时用Spark自带的Scala）
• Spark 3.1.2（选不带Hadoop版本的包，自己配Hadoop 3.2的PATH）
• Hadoop 3.2.2（主要是用HDFS，单机伪分布式就行）
• MySQL 5.7 / 8.0都可以，驱动用mysql-connector-java8.0系列

本地调试阶段，先用local[*]模式把整个代码逻辑跑通，这一步不用配集群，适合验证算法和清洗流程。但如果你准备直接交一个local模式的项目，答辩时大概率会被问"分布式体现在哪"，所以建议代码里对运行模式做一个可配置项：本地调试传local[*]，正式提交流程传spark://master:7077。

Standalone集群的搭法比较直接：三个节点都装好Spark，主节点配置SPARK_MASTER_HOST，然后在salves文件里填Worker的IP；从节点只要保证Spark安装目录一致、SSH免密登录配好就行。一个容易忽略的细节是，Spark作业里如果要用HDFS上的文件，每个节点都要有Hadoop的core-site.xml和hdfs-site.xml配置，并且HADOOP_HOME要指到正确路径，否则提交作业时总是报找不到文件系统的错。

提交命令我习惯用：

spark-submit \ --class com.musicrec.Main \ --master spark://master:7077 \ --executor-memory 4g \ --driver-memory 2g \ --total-executor-cores 4 \ spark-music-recsys.jar

2.2 数据集来源与格式设计

我用的是Last.fm的公开听歌记录数据集，包含约36万用户的近2000万条听歌行为，量级对毕设来说非常合适，既能体现Spark处理大数据的能力，又不至于让训练时间长得离谱。同时用Million Song Dataset中歌曲元数据的一个子集来补充歌曲的歌手、专辑、流派、时长信息。如果你不想一开始就处理几千万条数据，可以先抽样出5万用户和100万条行为做开发测试，等流程全部跑通了再上全量数据。

原始数据只是三列：user_id、artist_id、song_id，格式类似TSV。显然直接拿来做推荐还不够，所以我设计了两个核心表：

用户行为表（user_behavior）：

CREATE TABLE user_behavior ( user_id VARCHAR(32), song_id VARCHAR(32), behavior TINYINT, -- 1播放 2收藏 3下载 4完整收听 ts BIGINT, -- 事件时间戳 duration INT, -- 本次播放时长 is_valid TINYINT -- 清洗后是否有效 );

歌曲信息表（song_info）：

CREATE TABLE song_info ( song_id VARCHAR(32), song_name VARCHAR(128), artist_name VARCHAR(64), album_name VARCHAR(128), genre VARCHAR(32), duration_ms INT );

这两个表的设计贯穿整个项目，清洗后的数据落MySQL，ALS训练用Spark读取MySQL的user_behavior表，映射成Rating三元组（userId、songId、rating）。

2.3 用Spark做行为日志清洗的完整过程

数据清洗是整个项目里最枯燥但也是最容易在答辩中被深挖的部分。我做清洗时一共处理了四类脏数据：重复记录、超短播放、时间异常、用户和歌曲映射缺失。

去重逻辑是这样的：同一个人在同一秒内对同一首歌产生了多次事件，只保留行为类型权重最高的一条。播放权重我定义为：完整收听 > 收藏 > 下载 > 普通播放。超短播放是指播放时长小于30秒的记录，这种大概率是误触或切歌，清洗时直接过滤掉，但要注意阈值不能设得太高，否则会把用户真实的快速探索行为也清没了，我当时对比过30秒和45秒两个阈值，30秒在覆盖率上明显更好。

时间异常的处理比较细：一部分记录的时间戳是Unix秒，有一部分是毫秒，混在一起如果不处理，时间字段完全没法用。我先用最大值的量级判断是秒还是毫秒，再做统一转换。日期上还需要注意时区问题，音乐平台的日志默认是UTC存储，"今天的推荐"必须按北京时间去切分，否则每天凌晨的批次任务会算错日期边界。

清洗代码用DataFrame写起来逻辑很直白：

val rawDF = spark.read.option("delimiter", "\t") .csv("hdfs:///data/music/behavior_raw") val cleanDF = rawDF .filter(col("_c4").cast("int") >= 30) // 过滤超短播放 .filter(col("_c2").isNotNull && col("_c3").isNotNull) .dropDuplicates("_c0", "_c3", "_c1") // 用户+歌曲+时间戳维度去重 .withColumn("ts_sec", normalizeTs(col("_c1"))) .withColumn("dt", from_unixtime(col("ts_sec"), "yyyy-MM-dd"))

清洗完的数据会重新分区写回HDFS的Parquet目录，并同步写入MySQL。这个清理链路最好做成一个独立的Spark作业，用定时调度每天跑一次，而不是在训练作业里顺便清，因为清洗和建模的迭代频率完全不一样。

3. 离线推荐引擎：ALS矩阵分解与Top-N推荐生成

3.1 为什么选择ALS而不是ItemCF/UserCF

在毕设里，推荐算法可以选择的方案至少有三种：基于物品的协同过滤（ItemCF）、基于用户的协同过滤（UserCF）、矩阵分解（ALS）。很多人图省事直接用ItemCF，代码简单也容易讲明白。但ItemCF在Spark里的实现性能一般，需要先计算全量物品相似度矩阵，在千万级行为记录下这个矩阵的规模会非常大，跑起来内存压力很高；而ALS的处理过程是分布式的、矩阵分解迭代时每个worker只需要部分数据，对海量稀疏数据的处理能力是模拟算法比不了的。

ALS的核心思路是：把用户对歌曲的偏好矩阵分解成两个低维矩阵——用户特征矩阵和歌曲特征矩阵，然后通过两个矩阵的内积预测用户对没听过的歌的评分。听起来有点数学味，但可以这么理解：系统用几十个"隐藏特征"来描述每个用户和每首歌，比如"摇滚程度""节奏快慢""歌词浓度""流行度"，用户和歌在这些特征上各有一个向量，越接近就越可能喜欢。ALS在求解时先固定歌曲矩阵优化用户矩阵，再反过来固定用户矩阵优化歌曲矩阵，交替更新直到收敛，整个过程天然适合分布式并行迭代。

另外音乐推荐和电商推荐有个重要区别：用户对音乐行为几乎都是隐式反馈，没有"打了5分"这种显式评分，只有播放、收藏、跳过。如果直接用播放次数当评分，热门歌曲会被严重放大，所有人都会被推荐到同一批热门歌。ALS可以设置implicitPrefs=true来处理隐式反馈，但它在参数调优上更敏感。我最终采用的是自己构造显式评分：rating = 0.4*播放次数权重 + 0.3*收藏 + 0.2*下载 + 0.1*完整收听，这样语义更清楚，实现上也不复杂，答辩时还能多讲一层"隐式反馈如何转显式评分"的设计考量。

3.2 模型训练参数与评估

ALS模型训练的核心参数有四个：rank（隐藏特征维度）、maxIter（最大迭代次数）、regParam（正则化系数）、alpha（置信度参数，只在隐式反馈模式下用）。

参数选择我做了几组对比实验：

最终选了rank=20、maxIter=10、regParam=0.1这个组合，RMSE在0.94左右，训练时长和效果比较均衡。rank继续加大收益有限，但耗时增长明显。这里要注意，RMSE只是评估预测误差，对推荐系统的实际体验来说，精确率和召回率更直观。我额外从原始数据里留出10%的播放记录作为测试集，用"用户最近听的歌是否出现在推荐的Top20里"来定义命中。

训练代码核心部分：

import org.apache.spark.ml.recommendation.ALS val als = new ALS() .setUserCol("user_id") .setItemCol("song_id") .setRatingCol("rating") .setRank(20) .setMaxIter(10) .setRegParam(0.1) .setColdStartStrategy("drop") val model = als.fit(trainingDF)

一个小提示：setColdStartStrategy("drop")这行一定要加。如果不加，ALS对训练集中没出现过的新用户会给出NaN预测，直接影响后续Top-N推荐结果。

3.3 从推荐模型到榜单结果

训练出模型之后，下一步是生成每个用户的Top-N推荐列表。做法是对用户集合和歌曲集合做笛卡尔积预测，然后对每个用户取评分最高的前20首。但全量笛卡尔积的代价非常大，36万用户乘以10万首歌是360亿条打分计算，直接跑会完全撑不住。

一个折中的做法：预测时只取用户最近播放过的歌曲所属歌手/流派下的候选集，加上全站热门歌曲池，这样候选集可以控制在2000首以内，时间开销可以接受。这样做的推荐多样性稍弱，但对毕设展示完全够用，而且业务上也说得通——"在用户熟悉的音乐范围内做深度推荐，同时用热门歌曲补充广度"。

生成推荐列表的代码：

val userDF = cleanDF.select("user_id").distinct() val candidateDF = userDF.crossJoin(popularCandidates) // 自定义热门池 val predictions = model.transform(candidateDF) val topN = predictions .filter(!col("prediction").isNaN) .orderBy(col("user_id"), col("prediction").desc) .groupBy("user_id") .agg(collect_list("song_id").alias("rec_songs"))

每晚定时任务生成的user_id -> [歌曲列表]会写入MySQL的recommend_result表，前端展示直接查这个表。为了提高并发下的响应速度，我还加了一层Redis缓存，热点用户的最新推荐直接从Redis取。

4. 实时推荐：Spark Streaming监听用户行为的实现路径

4.1 实时推荐到底解决什么问题

离线推荐有一个天然缺陷：模型和推荐列表是周期性更新的，用户今天刚听的歌要等到明天凌晨才会影响推荐结果。这在真实场景里是不够的。举个例子，用户上午连续听了五首民谣，按离线推荐逻辑，他明天才会看到更多民谣；但如果他下午突然开始听电音，系统应该尽快感知到并调整候选顺序，这就是实时推荐模块的用武之地。

毕设项目里实时推荐的深度不用做很深，核心是让整个链路"实时"起来：实时消费用户行为、实时更新用户的候选集、实时对外提供修正后的推荐列表。我实现的功能是：用户产生行为后，系统在1分钟之内把该用户"最近2小时听过的高权重歌曲"追加到推荐候选中，并排到列表前几位。说白了就是"你最近听了什么风格的歌，我就多推同类风格给你"。

4.2 实时计算模块的完整实现

我用的是Structured Streaming，数据入口是Kafka。前端行为日志写入Kafka的music_behavior主题，流作业消费这个主题，按事件时间做窗口聚合，再把结果更新到Redis。

val streamDF = spark.readStream .format("kafka") .option("kafka.bootstrap.servers", "localhost:9092") .option("subscribe", "music_behavior") .option("startingOffsets", "latest") .load() .selectExpr("CAST(key AS STRING)", "CAST(value AS STRING)") // 解析JSON并处理 val parsed = streamDF .select(from_json(col("value"), schema).as("data")) .select(col("data.user_id"), col("data.song_id"), col("data.behavior")) val recentHot = parsed .withWatermark("ts", "10 minutes") .groupBy(window(col("ts"), "2 hours"), col("user_id")) .agg(collect_list("song_id").alias("recent_songs")) recentHot.writeStream .foreachBatch { (batchDF, _) => batchDF.collect.foreach { row => redisClient.lpush(s"recent:${row.getString(1)}", row.getSeq[String](2).mkString(",")) } } .outputMode("update") .start()

写流作业时有个体会：毕设里能不加的复杂度就不要加。比如窗口大小我固定为2小时，没有做动态调整；事件时间和处理时间的乱序问题只用了watermark来处理，没有再上复杂的延迟数据重放机制。这些扩展点可以放在"项目展望"里讲，但不建议在开发阶段都做全，否则任何一个环节出问题都会把整体节奏拖垮。

4.3 离线结果与实时结果的合并策略

实时修正和离线推荐怎么合并，是一个值得细想的问题。我最后采用的策略是：

1. 从Redis按用户取出最近2小时的实时候选歌曲列表；
2. 如果实时列表不为空，把这些歌按以下规则加权：完整收听权重最高、收藏次之、普通播放最低；
3. 把加权后的实时歌曲插入离线Top20列表前列，最多插入5首；
4. 如果实时列表为空，直接返回离线推荐结果。

这个"最多插入5首"的限制很关键。如果允许实时列表无限制插队，离线的个性化结果会被实时行为淹没，系统会退化成"热门歌推荐"；但完全不插队，实时模块就没有存在感。5首是我试了几次后觉得比较均衡的值，既不破坏离线模型的长远刻画，又能让用户明显感知到"系统懂我最近在听什么"。

合并逻辑写在后端服务的推荐查询接口里，没有放在Spark里做，因为实时结果已经在Redis了，用Java代码合并比再触发一次Spark作业轻量得多。这也算一个架构上的心得：Spark负责算，Redis负责存，后端负责拼——各司其职。

5. 毕设实战中掉过的坑：Spark SQL日期处理、广播变量与OOM

5.1 日期加减与格式转换的几个坑

日期处理是Spark作业里最常见的低级错误来源。先说日期加减。如果日期是标准字符串yyyy-MM-dd，可以直接用date_add和date_sub：

import org.apache.spark.sql.functions._ // 取7天前 df.withColumn("date_7d_ago", date_sub(current_date(), 7)) // 对字符串日期列加1天 df.withColumn("next_day", date_add(to_date(col("dt"), "yyyy-MM-dd"), 1))

坑在于日期字段经常不是标准格式。比如日志里的分区字段是20240701这种纯数字格式，或者带时间戳的2024-07-01 08:30:00，如果直接date_add会什么都不报错但结果完全错。我的做法是先统一清洗成标准格式再做日期计算。

另一个常见的需求是按月分组统计。如果要统计"最近12个月每月的播放量"，把日期转成月份字符串再groupBy是最直接的：

df.withColumn("month", date_format(to_date(col("dt"), "yyyy-MM-dd"), "yyyy-MM")) .groupBy("month").agg(sum("play_count").alias("month_plays"))

还有一个隐藏坑：date_sub和date_add转换后保留的是date类型，如果直接写回MySQL，驱动会默认映射成java.sql.Date，毫秒精度丢失；如果业务需要精确到秒，建议用timestamp类型或者转成字符串再落库。

5.2 "left outer join只能广播右侧"到底是怎么回事

这个知识点在网上讨论很多，实际做项目时也真的绕不开。先说结论：在Spark的Broadcast Hash Join中，小表只能放在join的右侧，尤其是left outer join的场景，这是由执行机制决定的。

Broadcast Hash Join的原理是：把一张小表广播到所有executor的本地内存里，然后大表逐行去小表的哈希表中探测匹配。对于left outer join，左表的每一行都必须保留在结果里，所以左表必须是"逐行探测"的那一侧，也就是probe侧；而右表会被加载到内存做哈希查找的build侧。如果把小表放在左侧，左侧的数百万行都会被广播到每个executor，不仅浪费大量内存，而且语义上也说不通——left join的行为定义决定了右表才可能被全量加载。

实际项目里踩到的坑是这样的：清理后的用户行为表和歌曲维度表做关联时，歌曲维度表只有5万行，按Spark默认的autoBroadcastJoinThreshold（10MB）应该自动广播，但由于没有开启相关优化，实际执行计划走了SortMergeJoin，结果任务跑了十几分钟才出结果。加上broadcast提示之后，几秒钟就完成。

import org.apache.spark.sql.functions.broadcast val result = behaviorDF.join(broadcast(songInfoDF), Seq("song_id"), "left")

这里值得多说一句：如果你的两张大表做left join，那就别想着广播了，老老实实走SortMergeJoin，同时注意左表的关联键有没有数据倾斜。我在做用户和歌曲关联时就碰到过少数热门歌曲占据极大比例数据的情况，加broadcast只能解决小表问题，解决不了倾斜问题，那种场景需要给关联键加盐或者调整分区数。

5.3 内存溢出与数据倾斜的排查思路

OOM几乎是Spark项目跑大数据量时的必经之路。我遇到的第一个OOM是在ALS训练时，executor内存报错。排查后发现不是内存不够，而是默认并行度太低，每个task要处理的数据量太大。解决方式是把spark.sql.shuffle.partitions从默认的200调到400，同时加大executor内存到4g，问题就消失了。

数据倾斜是更隐蔽的问题。清洗后的行为日志里，某几个头部歌手的播放记录可能是普通歌曲的几十倍，这部分数据在groupBy或join时会集中在少数几个task上，导致有的task内存爆掉、有的task闲置。我处理倾斜的办法是在关联键上做"热点探测"：先用SQL统计关联键的出现频次，超过阈值视为热点，给热点key加一个随机前缀打散，再和广播维度表做二次join。

// 热点key加盐 val saltedDF = behaviorDF .filter(isHotKey(col("song_id"))) .withColumn("song_id_salt", concat(col("song_id"), lit("_"), rand() % 10)) val resultDF = saltedDF .join(broadcast(songInfoDF), col("song_id_salt") === col("song_id"))

这里需要注意加盐之后关联键变了，join完还要还原真实歌曲ID。处理完倾斜后，作业总运行时间从33分钟降到9分钟，效果非常明显。如果拿这个点写进论文的"性能优化"章节，用量化的前后对比数据说话，会非常加分。

5.4 开发过程中其他值得记录的小问题

除了上面三个大坑，还有几个容易忽视的细节值得提醒。

第一个是MySQL驱动类加载问题。Spark作业写MySQL时，需要在spark-submit命令里通过--driver-class-path和--jars显式指定mysql-connector-java的jar包位置，否则作业提交后NoClassDefFoundError非常常见。

第二个是Spark UI的监控使用。排查耗时作业时，我习惯先到Driver的4040端口看两个指标：每个stage的shuffle read大小和task的耗时分布。只要这两个指标正常，基本上不需要靠猜来定位问题，直接按数据量估算和实际耗时对比，很快能锁定额外瓶颈。

第三个是本地IDE跑Spark作业时的内存设置。IDEA里直接跑spark-submit不是不行，但默认的JVM堆大小只有512MB，加载大数据集时容易在驱动端就内存不足。在Run Configuration里把VM options加上-Xmx2g，能省掉很多莫名其妙的报错。

6. 系统落地与答辩准备：让毕设"能看也能讲"

6.1 前端展示与后端接口组织

推荐系统如果只跑出结果，没有可视化界面，答辩效果会大打折扣。我的展示层结构是：后端用Spring Boot提供REST接口，前端用Vue加ECharts画图。页面分了四个视图：首页展示"为你推荐"列表；用户页面展示个人听歌历史；统计页展示每小时的播放量分布、Top10歌手榜、歌曲风格占比；实时页展示最近5分钟用户的播放动态和实时推荐更新日志。

后端接口的核心是推荐聚合接口，返回的JSON结构大概是：

{ "code": 0, "data": { "user_id": "u_102938", "recommend_list": [ {"song_id": "s_00231", "song_name": "...", "reason": "基于昨日播放历史"}, {"song_id": "s_00911", "song_name": "...", "reason": "实时更新：近期常听风格"} ] } }

reason字段是个小加分项，它让用户能直观知道"为什么推荐这首歌"，这在答辩时特别好讲——它连接了后端逻辑和用户可感知的产品功能，体现了你从产品角度考虑过系统设计。

6.2 性能指标与优化前后对比

答辩时老师很容易问"你这个系统到底有多快、能撑多大并发"。我了列一组优化前后的数据：

这一张表基本就能把一个普通项目和中上水平的项目区分开。做毕设不要只写"完成了XXX功能"，一定要记录"完成这个功能之前是多少、之后是多少"，这种量化的过程数据比任何修饰都更有说服力。

6.3 答辩高频问题与回答方向

在最终答辩时，老师对这个题的关注点集中在原理层和可行性上。我把被问过的问题和准备方向整理了一下：

• "ALS的损失函数是什么？" 建议掌握最小化平方误差的基本形式，并解释交替优化步骤，不用背公式，但要能说出思路。
• "用户没有行为记录时怎么办？" 回答冷启动方案：注册偏好选择 + 热门兜底 + 歌手流派相似推荐。
• "你和抖音推荐有什么区别？" 坦诚说明：我的是基于协同过滤的候选生成 + 简单规则排序，没有引入深度学习和多目标排序，这是受毕设周期限制，但架构上预留了替换排序模型的接口。
• "数据量大了怎么办？" 从水平扩展Worker节点、增加分区数、引入Kafka削峰这三个方向回答，说明系统具备可扩展性。

答辩的核心其实是"诚实 + 深度"。老师知道毕设不可能做到工业级，你只要把自己做过的每个决定都能讲出理由，再承认几个已知的不足，并给出改进方向，效果远好于夸大其词。

6.4 源码结构与复现说明

最后说一下项目源码的结构，方便拿到项目编号42921对应源码包的同学快速找到关键代码：

spark-music-recsys/ ├── data_process/ │ ├── CleanBehaviorJob.scala // 行为日志清洗作业 │ └── GenerateRating.scala // 隐式反馈转显式评分 ├── offline_recommend/ │ ├── TrainALSModel.scala // ALS模型训练 │ └── GenerateTopN.scala // 生成每日推荐列表 ├── realtime_recommend/ │ └── RealtimeListener.scala // Structured Streaming实时监听 ├── backend/ │ └── ... // Spring Boot接口服务 ├── frontend/ │ └── ... // Vue + ECharts页面 └── sql/ └── init.sql // 建表语句

复现时建议按这个顺序跑：先执行sql/init.sql建表，然后跑GenerateRating生成训练评分数据，再跑TrainALSModel得到模型和推荐列表，最后启动后端和前端做展示。实时模块需要先起Kafka，再把模拟行为写入music_behavior主题。

最后说点实际的体会。这个题目最容易被低估的地方不是算法，而是"把各个模块串成一个完整系统"的整合能力。单独写一个ALS模型训练脚本不难，单独写一个Spark清洗作业也不难，但要让清洗结果喂给模型、模型产出推荐、推荐结果被后端读取、实时行为又反过来修正推荐，整个链条每一步都没有断点，这才是真正的工程量所在。如果你正在做这个方向，我的建议是先把数据流跑通，再回头优化算法细节；不要一上来就盯着RMSE调到天昏地暗，系统跑不通的时候，再好看的指标也都只是纸上谈兵。另外我给项目的后续发展留了一个很自然的扩展口子：把排序阶段换成LambdaMART或者引入图神经网络做歌曲表示学习，有机会可以往这个方向继续深入下去。