Spark音乐推荐系统毕设实战：从ALS离线模型到实时推荐全流程

说实话计算机毕设选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 系统功能模块与数据流设计整个系统我拆成了五个模块分工很清晰模块核心职责关键技术点数据采集与存储接收用户行为日志保存原始数据Kafka、HDFS、MySQL离线处理层周期性清洗日志统计用户听歌偏好Spark SQL、DataFrame离线推荐引擎训练协同过滤模型生成每日推荐列表ALS矩阵分解、Top-N实时处理层监听用户实时行为动态调整推荐Spark Streaming / Structured Streaming展示与查询层前端页面展示推荐结果和统计报表Spring Boot、Vue、ECharts数据流大概是这样的用户在前端产生的行为播放、收藏、跳转、完整收听会先写入一个消息队列然后分两条路走。一条路进离线批处理每天凌晨用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的readStreamwriteStream模型相比老的DStream API它能直接用DataFrame的API操作流写起来和批处理几乎一样理解成本低很多。存储层的分工是用户行为原始日志放HDFS清洗后的结构化数据放MySQL推荐结果也落MySQL供后端查询。Redis在中间用来缓存热点用户的实时推荐结果。其实毕设级别的数据量不用HDFS也能跑但加上HDFS能体现分布式存储的完整链条。2. 环境搭建与数据集准备踩平地基才能起楼2.1 Spark环境从本地模拟到Standalone集群环境这一步是劝退很多人的地方但踩过之后回头看核心就是几个版本一定要对齐。我用的组合是JDK 1.8注意别装高版本JDKSpark 3.1对JDK17的支持有问题Scala 2.12.10仅编译期需要跑任务时用Spark自带的ScalaSpark 3.1.2选不带Hadoop版本的包自己配Hadoop 3.2的PATHHadoop 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.jar2.2 数据集来源与格式设计我用的是Last.fm的公开听歌记录数据集包含约36万用户的近2000万条听歌行为量级对毕设来说非常合适既能体现Spark处理大数据的能力又不至于让训练时间长得离谱。同时用Million Song Dataset中歌曲元数据的一个子集来补充歌曲的歌手、专辑、流派、时长信息。如果你不想一开始就处理几千万条数据可以先抽样出5万用户和100万条行为做开发测试等流程全部跑通了再上全量数据。原始数据只是三列user_id、artist_id、song_id格式类似TSV。显然直接拿来做推荐还不够所以我设计了两个核心表用户行为表user_behaviorCREATE 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_infoCREATE 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 );这两个表的设计贯穿整个项目清洗后的数据落MySQLALS训练用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可以设置implicitPrefstrue来处理隐式反馈但它在参数调优上更敏感。我最终采用的是自己构造显式评分rating 0.4*播放次数权重 0.3*收藏 0.2*下载 0.1*完整收听这样语义更清楚实现上也不复杂答辩时还能多讲一层隐式反馈如何转显式评分的设计考量。3.2 模型训练参数与评估ALS模型训练的核心参数有四个rank隐藏特征维度、maxIter最大迭代次数、regParam正则化系数、alpha置信度参数只在隐式反馈模式下用。参数选择我做了几组对比实验rankmaxIterregParam验证集RMSE训练时长10100.10.9822分30秒20100.10.9414分10秒30100.10.9237分20秒20150.010.9355分50秒20100.50.9614分20秒最终选了rank20、maxIter10、regParam0.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(srecent:${row.getString(1)}, row.getSeq[String](2).mkString(,)) } } .outputMode(update) .start()写流作业时有个体会毕设里能不加的复杂度就不要加。比如窗口大小我固定为2小时没有做动态调整事件时间和处理时间的乱序问题只用了watermark来处理没有再上复杂的延迟数据重放机制。这些扩展点可以放在项目展望里讲但不建议在开发阶段都做全否则任何一个环节出问题都会把整体节奏拖垮。4.3 离线结果与实时结果的合并策略实时修正和离线推荐怎么合并是一个值得细想的问题。我最后采用的策略是从Redis按用户取出最近2小时的实时候选歌曲列表如果实时列表不为空把这些歌按以下规则加权完整收听权重最高、收藏次之、普通播放最低把加权后的实时歌曲插入离线Top20列表前列最多插入5首如果实时列表为空直接返回离线推荐结果。这个最多插入5首的限制很关键。如果允许实时列表无限制插队离线的个性化结果会被实时行为淹没系统会退化成热门歌推荐但完全不插队实时模块就没有存在感。5首是我试了几次后觉得比较均衡的值既不破坏离线模型的长远刻画又能让用户明显感知到系统懂我最近在听什么。合并逻辑写在后端服务的推荐查询接口里没有放在Spark里做因为实时结果已经在Redis了用Java代码合并比再触发一次Spark作业轻量得多。这也算一个架构上的心得Spark负责算Redis负责存后端负责拼——各司其职。5. 毕设实战中掉过的坑Spark SQL日期处理、广播变量与OOM5.1 日期加减与格式转换的几个坑日期处理是Spark作业里最常见的低级错误来源。先说日期加减。如果日期是标准字符串yyyy-MM-dd可以直接用date_add和date_subimport 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会什么都不报错但结果完全错。我的做法是先统一清洗成标准格式再做日期计算。原始格式转换方式20240701to_date(col(dt), yyyyMMdd)2024-07-01 08:30:00to_date(col(dt))Spark会自动识别Unix秒级时间戳from_unixtime(col(ts))Unix毫秒级时间戳from_unixtime(col(ts) / 1000)另一个常见的需求是按月分组统计。如果要统计最近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默认的autoBroadcastJoinThreshold10MB应该自动广播但由于没有开启相关优化实际执行计划走了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 性能指标与优化前后对比答辩时老师很容易问你这个系统到底有多快、能撑多大并发。我了列一组优化前后的数据指标优化前优化后离线清洗作业33分钟9分钟数据倾斜处理分区调整ALS模型训练7分钟4分钟rank20epoch10Top-N推荐生成12分钟3分钟候选集裁剪推荐接口响应时间1.2秒首次180msRedis命中实时行为生效延迟无实时平均40秒入库生效这一张表基本就能把一个普通项目和中上水平的项目区分开。做毕设不要只写完成了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或者引入图神经网络做歌曲表示学习有机会可以往这个方向继续深入下去。