Hadoop+Spark游戏推荐系统：从数据清洗到可视化大屏实战-平芜编程栈

1. 毕业设计选题：为什么是“Hadoop+Spark游戏推荐系统”

1.1 这个项目到底在做什么

先说人话：这是一个典型的大数据方向毕业设计项目，核心目标是搭一套能够根据用户行为自动推荐游戏的系统。它不是简单地写个推荐算法跑通就完事，而是要求你把“数据采集、分布式存储、分布式计算、算法建模、结果可视化”这一整条大数据链路全部打通。

游戏推荐系统和大数据技术天然契合：游戏平台的用户行为数据量级大（登录、试玩、评分、购买、在线时长）、维度多（用户属性、游戏属性、时间属性）、实时性要求参差不齐。正好可以拿Hadoop扛存储、拿Spark扛计算，再用可视化把结果直观地展示出来。对毕业设计来说，这个题目最大的优势是技术覆盖面广——评审老师一眼就能看出你掌握了HDFS、YARN、Spark RDD/DataFrame、MLlib、Web开发、可视化等一整套技能栈。

我接触过不少做这个题目的同学，能拉开差距的从来不是“跑通了官方Demo”，而是你能不能讲清楚：数据从哪来、为什么存在HDFS里、ALS算法为什么能算相似度、大屏上的图表底层查的是什么表。这篇文章就把这些环节全部拆开讲一遍，适合准备做大数据方向毕设、或者想做项目练手但不知道怎么下手的同学参考。

1.2 为什么选这个题目而不是单纯的推荐系统

很多人会纠结：既然核心是推荐，直接写一个Python协同过滤脚本不就行了吗？为什么要引入Hadoop和Spark？

这个问题的答案就是你这个题目拿高分的关键。单纯推荐算法属于“机器学习”范畴，边界很窄，做完主线也就几千行代码。而“Hadoop+Spark+推荐+可视化”的题目，本质上是把算法放进了大数据工程框架里：

数据的量级假设不再是本地CSV，而是海量日志，这逼着你用HDFS做分布式存储；
数据处理不能再靠Pandas单机跑，这逼着你用Spark做分布式计算；
推荐结果不能只输出一个列表，这逼着你设计可视化大屏，让用户画像、游戏热度、推荐命中率一目了然。

换句话说，这个题目同时覆盖了“存储”、“计算”、“算法”、“展示”四个层面，任何一层你都能写出实实在在的工作量。对毕设而言，工作量就意味着分数。而且这四个层面之间的耦合度不高，哪一层出问题都能单独排错，非常适合一个人从头到尾完成。

1.3 技术选型背后的取舍

我在指导类似项目时，最常被问到的一个问题是：Hadoop用不用装集群？Spark用Scala还是Python写？可视化用ECharts还是Tableau？

这套组合我建议按“够用、能讲、好排错”的标准来选：

Hadoop：如果你不是实验室有现成集群，老老实实装伪分布式模式。单机InnoDB撑不下的数据量，伪分布式HDFS完全够演示。伪分布式的最大好处是你可以在笔记本上完成全部调试，不依赖网络和机房。
Spark：强烈推荐用PySpark，而不是Scala。原因不是Scala不好，而是对大多数字生来说，Python的调试效率高一个量级，而且Spark MLlib的ALS算法在PySpark里直接调API就能用，文档也多。你完全可以用Python完成RDD/DataFrame操作和模型训练，用Scala只是徒增编译负担。
可视化：前端大屏用ECharts就够了，理由后面细说。不要一上来就上Tableau、PowerBI那种商业工具，毕设答辩现场评委更想看到你自己写代码控制每一个图表，而不是拖拽出一个面板。
存储组合：HDFS存原始日志和中间结果，MySQL存业务表（用户表、游戏表、推荐结果表），Redis可选，做实时热门榜时用。

这套选型方案我踩过不少坑之后才稳定下来，下面每一章都会把关键细节和为什么这么干讲清楚。

2. 整体架构设计与数据流转

2.1 四层架构：从日志到推荐结果的完整链路

整个系统的架构可以划分成四层，每一层职责单一，画架构图也好看，答辩讲起来逻辑非常顺：

层级	组件	职责
数据采集层	Python脚本 + Flume（可选）	模拟/采集用户行为日志，写入HDFS
存储层	HDFS + MySQL	原始日志、清洗结果、业务表存储
计算层	Spark Core / Spark SQL / MLlib	数据清洗、统计计算、ALS模型训练
应用展示层	Spring Boot + Vue + ECharts	提供推荐接口，渲染可视化大屏

不建议把Flume、Kafka这类消息队列加进初次版本。很多同学一上来就堆Kafka + Flume + HBase + 各种组件，结果光调环境就耗掉三周，最后推荐算法反而没时间做。毕业设计讲的是“链路完整、逻辑自洽”，不是组件越多越好。先把四层跑通，有余力再往上加消息队列做实时推荐，属于锦上添花。

2.2 数据流：一条数据从产生到展示经历了什么

以我常用的一套模拟数据生成方式为例，完整链路是这样的：

一个Python脚本模拟1000个用户对300款游戏产生评分和试玩行为，生成带时间戳的日志文件；
日志文件通过hdfs dfs -put上传到HDFS的/data/game_log/目录；
Spark读取HDFS中的原始日志，用DataFrame做清洗（去重、过滤异常字段、格式统一），结果写回HDFS/data/game_clean/；
Spark SQL按“用户-游戏-评分”的格式生成ALS训练集，调用MLlib的ALS算法训练推荐模型；
把模型输出的TopN推荐结果写入MySQL的recommend_result表；
Spring Boot后端查询MySQL推荐结果和统计数据，暴露JSON接口；
Vue前端调用接口，ECharts绘制游戏热度排行榜、用户评分分布、推荐命中率等图表。

这条链路每一步都有明确的输入和输出，做的时候不容易迷路。我见过很多同学卡在原地，原因就是数据流没理清楚，一会儿在HDFS里找不到数据，一会儿MySQL表是空的，根本不知道问题出在第几环。我的建议是：先把每条数据的流向画出来，再动手写代码。

2.3 离线优先：为什么不做实时推荐

游戏推荐系统确实有实时推荐场景（比如用户刚玩完一款游戏，立刻推荐同类型），但毕业设计我不建议你死磕实时链路。原因很现实：

实时推荐需要流式计算框架（Spark Streaming / Flink）和消息队列（Kafka），环境维护成本成倍增加；
演示现场网络和机器性能都不可控，实时链路一旦延迟或断流，演示效果会翻车；
离线推荐的评估指标（准确率、召回率、覆盖率）更容易量化，答辩时能拿出具体数字，比“看起来实时”更有说服力。

我带的项目中，80%的学生最终做的都是离线推荐 + 准实时刷新的方案：每10分钟用Spark任务重跑一次推荐结果，写入MySQL。这个方案兼顾了效果和稳定性，演示时你可以手动触发批次任务，看着数据更新，评委也能直观感受到Spark的处理能力。

3. 环境搭建与集群配置实操

3.1 Hadoop伪分布式搭建的核心步骤

Hadoop装不好，后面全部白搭。伪分布式模式虽然只需要一台机器，但配置细节一个都不能少。我给出一个稳定版本（Hadoop 3.3.x）的实操要点：

# 1. 配置Java环境，Hadoop 3.x 要求 JDK 8 或 11 export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 export PATH=$PATH:$JAVA_HOME/bin # 2. 下载解压Hadoop到 /opt/hadoop tar -zxvf hadoop-3.3.6.tar.gz -C /opt/ mv /opt/hadoop-3.3.6 /opt/hadoop

然后修改四个核心配置文件：

core-site.xml：设置NameNode地址和临时目录
hdfs-site.xml：设置副本数为1（伪分布式只有一台机器，副本数为3会一直报错）
mapred-site.xml：指定YARN调度器
yarn-site.xml：配置ResourceManager和NodeManager

<!-- core-site.xml --> <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> </configuration> <!-- hdfs-site.xml --> <configuration> <property> <name>dfs.replication</name> <value>1</value> </property> </configuration>

这里有两个初学者必踩的坑。第一，dfs.replication不改成1的话，伪分布式只有一台DataNode，但默认副本数是3，多余的副本永远分配不出去，集群会一直处于Under replicated状态，影响后续读写。第二，NameNode格式化一定要在配置全部改完之后执行，否则格式化的配置和实际生效的配置不一致，启动时各种诡异报错。

格式化命令：

hdfs namenode -format

格式化只是初始化元数据目录，不会清空你的数据。但如果你改了配置文件又重新格式化，之前上传到HDFS的数据就全没了，这一点务必记住。

启动HDFS的经典命令是start-dfs.sh，启动后建议用jps检查进程是否齐全：

jps

正常应该看到NameNode、DataNode、SecondaryNameNode三个进程。少任何一个都说明配置有问题，这时候先看日志/opt/hadoop/logs/hadoop-*.log，别瞎猜。

3.2 Spark安装与配置：本地模式起步，集群模式加分

Spark的安装比Hadoop简单得多。对毕业设计而言，你前期跑通模型用Local模式就完全够用，甚至不依赖Hadoop也能跑。但为了演示“大数据处理链路”，最终要把Spark和HDFS打通。

# 下载Spark（注意选择与Hadoop匹配的预编译版本） tar -zxvf spark-3.5.0-bin-hadoop3.tgz -C /opt/ mv /opt/spark-3.5.0-bin-hadoop3 /opt/spark # 配置环境变量 export SPARK_HOME=/opt/spark export PYSPARK_PYTHON=python3 export PATH=$PATH:$SPARK_HOME/bin

PySpark使用中最容易踩的坑是Python版本和依赖不一致。Spark自带的Python执行器会去找bin/python3，如果你机器上有多个Python版本，可能在Driver端用的是Anaconda的Python，Executor端却找到了系统自带的Python，两者版本或包不一致就会报各种奇奇怪怪的序列化错误。我的建议是：

# 在spark-env.sh中显式指定Python路径 export PYSPARK_PYTHON=/home/user/anaconda3/bin/python3 export PYSPARK_DRIVER_PYTHON=/home/user/anaconda3/bin/python3

这样能避免90%的PySpark环境问题。

3.3 内存参数调优：别让Spark撑爆你的笔记本

笔记本跑Spark最头疼的问题就是内存不够。默认配置下Spark Executor会尽可能占用内存，如果你的数据稍大一点，直接OOM，甚至把机器卡死不夸张。

我常用的三招：

第一，限制Executor内存。提交任务时用参数约束：

spark-submit \ --master local[2] \ --driver-memory 2g \ --executor-memory 2g \ recommend.py

local[2]表示使用2个CPU核心。不建议写成local[*]，那会让Spark吃满所有核，你连浏览器都打不开，可视化大屏就没法演示了。

第二，给 ALS 模型设置合理的rank和maxIter。我这边的经验是rank=10、maxIter=10、regParam=0.1起步，效果好再加。rank不是越大越好，rank太大模型参数膨胀，小数据集上反而会过拟合。

第三，把中间结果及时cache()或persist()，避免重复计算。ALS训练过程中会多次读取训练数据，如果不缓存，每次都要重新从HDFS拉数据，又慢又费内存。

内存调优这块你在答辩时候往深讲，老师是会高看一眼的，因为这属于“不只是能跑，还能讲出为什么这么跑”的层次。

4. 数据准备与预处理：好数据是推荐系统的地基

4.1 数据集怎么来：模拟生成与开源选择

游戏推荐系统需要的数据核心是三张表：用户表、游戏表、评分行为表。如果你没有真实平台数据，有两个可行路径：

一是用公开的推荐系统数据集改编，比如MovieLens的评分数据结构改成“游戏”语义字段。很多Game Recommendation的学术数据集也长得很像。我在实际操作中就把MovieLens的movies.csv和ratings.csv字段直接映射成游戏ID、游戏名、游戏类型、评分时间，这样数据集天然有上百万条规模，演示时更有说服力。

二是自己写脚本生成模拟数据。用Python的random和uuid，按正态分布模拟1000个用户对300款游戏的评分行为，再混入少量异常值（重复记录、空值、越界评分），方便后面展示清洗效果。

数据规模这块多说一句：别用太少的数据，比如只有几十条评分，那ALS训练出来的模型毫无意义，评委一眼就能看出来是玩具项目。至少要5万条以上评分记录，最好能到20万条以上，Spark处理起来才看得出分布式计算的必要性。

4.2 Spark清洗流程：从原始日志到规整DataFrame

清洗环节是展示你Spark基本功的地方。原始日志长这样：

user_1001|game_2077|rating=4.5|action=play|timestamp=1735689600 user_1002|game_1024|rating=|action=view|timestamp=1735689660 user_1001|game_2077|rating=4.5|action=play|timestamp=1735693200

用PySpark做清洗，我通常写这么几步：

from pyspark.sql import SparkSession from pyspark.sql.functions import col, regexp_extract, to_timestamp spark = SparkSession.builder.appName("GameRec_Clean").getOrCreate() # 读取HDFS上的原始日志 raw_df = spark.read.text("hdfs://localhost:9000/data/game_log/") # 按分隔符解析字段 def parse_line(line): return line parsed = raw_df.selectExpr( "split(value, '\\|')[0] as user_id", "split(value, '\\|')[1] as game_id", "split(value, '\\|')[2] as rating_raw", "split(value, '\\|')[3] as action", "split(value, '\\|')[4] as ts" ) # 过滤空值、提取评分数字 clean_df = parsed.filter( col("user_id") != "" & col("game_id") != "" & col("rating_raw").startswith("rating=") )

这里我给一个非常实在的建议：清洗逻辑不要写得太复杂，但一定要每个步骤都有“设计感”，比如你要明确说清楚“我过滤掉了没有评分的view行为，因为ALS只认明确评分”。这句话就点出了你对ALS算法的理解，比堆一堆代码强得多。

清洗完之后，把评分数据转换成ALS需要的格式：(userId, gameId, rating)。这里需要把字符串ID编码成长整数，因为Spark MLlib要求数值型ID：

from pyspark.ml.feature import StringIndexer user_indexer = StringIndexer(inputCol="user_id", outputCol="userId") game_indexer = StringIndexer(inputCol="game_id", outputCol="gameId") # 构建pipeline from pyspark.ml import Pipeline pipeline = Pipeline(stages=[user_indexer, game_indexer]) df_encoded = pipeline.fit(clean_df).transform(clean_df)

4.3 数据落地：HDFS和MySQL怎么分工

很多同学搞不清什么数据该放HDFS，什么该放MySQL。我的划分标准很简单：

HDFS存放原始日志、清洗后的明细数据、模型输出的中间结果。特点是文件大、不经常改、按批次追加。
MySQL存放业务结果数据，比如推荐结果表、统计汇总表、用户表、游戏表。特点是数据量小、查询频繁、要支持Web接口实时读取。

以MySQL为例，两张核心表的设计：

-- 游戏表 CREATE TABLE game_info ( game_id INT PRIMARY KEY, game_name VARCHAR(255), game_type VARCHAR(100), publish_date DATE, avg_rating DECIMAL(3,2) ); -- 推荐结果表 CREATE TABLE recommend_result ( user_id INT, game_id INT, score DECIMAL(5,4), rank_no INT, update_time TIMESTAMP );

推荐结果表一定要加update_time字段。这样你展示“推荐结果随用户行为更新”的时候，直接在Web页面上查这个时间字段，就能证明Spark任务是新增了数据的，而不是静态页面上画了个假表。这个细节在答辩时很加分，很多同学忽略了。

5. 推荐算法核心：ALS协同过滤的落地实战

5.1 ALS到底在算什么：一个生活化解释

ALS（Alternating Least Squares，交替最小二乘法）是Spark MLlib里最成熟的协同过滤算法，也是这个项目最大的亮点。

我用一个生活中的例子给你讲透：想象你有一个教室，里面坐着1000个学生（用户），要分配300本小说（游戏）给每个人。你事先不知道每个学生的喜好，只知道一部分学生填过“豆瓣评分”——喜欢还是不喜欢某本书。ALS要做的，就是根据这些零散的评分，猜出每个学生可能给每本书打多少分，然后把最高分的几本推荐给他。

但问题是你没法直接猜“学生-书”这么大一个矩阵，数据太稀疏了。ALS的聪明之处在于：它假设每个学生的喜好可以被几个隐藏因素解释，比如“喜欢剧情向还是竞技向”、“偏单机还是联机”、“吃不吃得下硬核策略”。这几个隐藏因素就是潜在因子（latent factor），维度通常叫rank。ALS同时猜两套向量：每个学生的“偏好向量”和每本书的“属性向量”，两者点乘就是预测评分。

“交替”的意思更好懂：先固定书的属性向量，只优化学生的偏好向量；再反过来固定学生偏好向量，优化书的属性向量。两边轮流猜，猜几轮后预测评分就稳定了。整个过程只需要大量矩阵运算，天然适合Spark分布式计算。

5.2 Spark MLlib实现：核心代码与参数选择

PySpark里直接调用ALS非常简洁：

from pyspark.ml.recommendation import ALS from pyspark.ml.evaluation import RegressionEvaluator # 划分训练集和测试集 train, test = df_encoded.randomSplit([0.8, 0.2], seed=42) # 构建ALS模型 als = ALS( userCol="userId", itemCol="gameId", ratingCol="rating", rank=10, maxIter=10, regParam=0.1, coldStartStrategy="drop" ) model = als.fit(train) # 预测测试集评分，评估误差 predictions = model.transform(test) evaluator = RegressionEvaluator( metricName="rmse", labelCol="rating", predictionCol="prediction" ) rmse = evaluator.evaluate(predictions) print(f"RMSE = {rmse:.4f}")

这里最重要的参数是coldStartStrategy="drop"，这个设置一定要写。如果不写，遇到测试集中没出现过的用户或物品时，模型会预测出空值，后续评估直接报错。这个问题是我见过最多的一个报错点，没有之一。

对于参数调优，我提供一个实际能用的经验区间：

参数	初始值	说明
rank	10	潜在因子维度，数据量小可以降到5，数据量大可以到20
maxIter	10	迭代次数，5~20之间试
regParam	0.1	正则化系数，防止过拟合，0.01~0.2调试
alpha	1.0	隐式反馈置信度参数，隐式数据才需要调

调优不要手调参数硬猜，用Spark MLlib自带的ParamGridBuilder+CrossValidator做网格搜索：

from pyspark.ml.tuning import ParamGridBuilder, CrossValidator param_grid = (ParamGridBuilder() .addGrid(als.rank, [5, 10, 15]) .addGrid(als.maxIter, [5, 10]) .addGrid(als.regParam, [0.01, 0.1]) .build()) cv = CrossValidator( estimator=als, estimatorParamMaps=param_grid, evaluator=evaluator, numFolds=3 ) cv_model = cv.fit(train) best_model = cv_model.bestModel

这个环节跑完，你手里有两个硬指标：RMSE（预测评分误差）和推荐列表覆盖率。答辩时能说出“我在rank=10、regParam=0.1的参数组合下，RMSE从0.95降到0.81”，评委就会觉得你是认认真真调过参的，而不是Demo复读机。

5.3 从“评分预测”到“TopN推荐列表”

模型训练好只是第一步，你还需要为用户生成真正可展示的推荐列表。这一步的操作逻辑是：

先拿到所有用户的ID列表；
对每个用户，用模型预测他没玩过的所有游戏的评分；
按预测评分降序排序，取前10个作为推荐结果；
关联游戏表补全游戏名称和类型，写入MySQL。

# 获取所有用户和游戏的笛卡尔积 all_users = df_encoded.select("userId").distinct() all_games = df_encoded.select("gameId").distinct() user_game = all_users.crossJoin(all_games) # 预测所有未评分组合的评分 predictions = model.transform(user_game) # 过滤掉用户已经评分过的游戏 df_rated = df_encoded.select("userId", "gameId").withColumn("rated", lit(1)) recs = predictions.join(df_rated, ["userId", "gameId"], "left_anti") # 按用户分组取Top10 from pyspark.sql.window import Window from pyspark.sql.functions import row_number window = Window.partitionBy("userId").orderBy(col("prediction").desc()) top10 = recs.withColumn("rank_no", row_number().over(window)) \ .filter(col("rank_no") <= 10)

注意left_anti这个连接方式，它的语义是“保留左表中在右表没有匹配到的记录”，正好用来过滤掉用户已经玩过的游戏。这一步如果没做，你会把用户已经玩过的游戏再次推荐给他，演示时被评委指出来会非常尴尬。

6. 游戏可视化大屏：把数据变成“看得见的亮点”

6.1 可视化设计思路：大屏不是图表堆砌

游戏推荐系统做了大量计算，最后怎么让评委快速看懂？全靠可视化大屏。我见过很多失败案例：把十几个ECharts图表密密麻麻塞满一屏幕，每个图表之间毫无逻辑，看起来像卖杂货的。

好的可视化大屏必须讲一个“数据故事”。我在这个项目里建议你围绕三条故事线设计：

用户画像区：展示用户数量、评分分布、活跃时段。用饼图、柱状图回答“我们的用户喜欢什么”。
游戏热度区：展示Top10最火游戏、各类型游戏占比、平均评分走势。用排行榜和折线图回答“哪些游戏受欢迎”。
推荐效果区：展示推荐命中率、推荐Top10游戏列表、ROI类指标。用雷达图或热力图回答“我们的推荐系统有没有用”。

这三块恰好对应你系统的输入、处理、输出，逻辑完整。

6.2 ECharts大屏实战：图表与接口的配合方式

前端我用Vue + ECharts，后端用Spring Boot，整体分成三层：

后端提供统一JSON格式的接口，比如/api/stat/hot_games返回游戏热度Top10；
前端用axios请求接口，拿到数据后塞进ECharts配置项；
大屏布局采用响应式网格，每个图表组件独立，方便单独刷新。

这里挑一个我最常用的图表配置示例，展示“游戏类型占比”饼图：

option = { title: { text: '游戏类型占比', left: 'center' }, tooltip: { trigger: 'item' }, series: [{ name: '类型占比', type: 'pie', radius: ['45%', '70%'], data: gameTypeData, // 来自后端接口 label: { formatter: '{b}: {d}%' } }] };

注意，图表的核心其实不在前端配置，而在后端的SQL聚合逻辑。很多同学把大量时间花在调图表样式上，结果后端永远返回写死的假数据。我在指导时反复强调：先保证后端能从MySQL查出真实数据，再考虑图表好不好看。数据是真的，图表稍微朴素一点，演示效果也不会差；数据是假的，图表再炫，老师多问两句就露馅。

6.3 前后端联调要注意的三个细节

细节一：接口响应时间要控制。大屏如果一次性查太多SQL，接口可能好几秒才返回，演示现场非常尴尬。我的做法是在MySQL里把结果提前聚合到统计表，接口直接查统计表，基本毫秒级返回。

细节二：Redis做缓存（可选但加分）。热门统计类接口加一层Redis缓存，设置5分钟过期，减少数据库压力，面试时也能提一句“我了解缓存穿透和缓存击穿的基本概念”。

细节三：大屏要支持定时刷新。推荐结果可能每10分钟更新一次，大屏上要能看到“数据更新于 xx:xx”的时间标识，这样评委才能把你的Spark批处理任务和可视化关联起来，形成完整闭环。

7. 常见问题排查与避坑手册

7.1 环境类问题：90%的坑都出在这里

问题现象	常见原因	解决办法
`NameNode`进程启动失败	配置文件路径不对，或格式化后端口被占用	`jps`检查进程；查看`/opt/hadoop/logs/`日志；改配置后重新格式化并重启
HDFS上传文件报 “Under replicated”	`dfs.replication`未改成1	确认`hdfs-site.xml`里副本数是1
PySpark报 Python 版本不一致	`PYSPARK_PYTHON`指向了错误的Python	在`spark-env.sh`统一指定Anaconda的Python路径
Spark任务 OOM	Executor内存不足，或ALS参数过大	限制`executor-memory`，降低`rank`和`maxIter`
Web接口连MySQL慢	缺少索引，或查了未聚合的大表	给`user_id`、`game_id`加联合索引；预聚合统计表

这里单独提醒一句：Hadoop启动时如果报Cannot set priority of namenode process之类错误，多数是系统权限问题，检查一下Hadoop安装目录属主是不是当前用户，别用root直接跑集群，文件权限会乱套。

7.2 算法与数据问题：看起来“跑通”了但效果很差

最典型的失败场景是：ALS跑完，推荐结果全是同一款游戏，比如每个用户前10名里8个都是《绝地求生》。这个问题通常由两个原因造成：

一是热门游戏倾斜。大部分用户都玩过热门游戏，ALS模型在它们身上的置信度高，冷门游戏评分稀疏，永远排不上去。解决办法是给评分矩阵做归一化，或者用“每个人先减去自己平均分”的方式消除用户评分尺度的差异。

二是没有过滤已玩过的游戏。前面提过要用left_anti过滤，如果不过滤，已玩过的高分游戏一定会排在前面，推荐列表就失去了“发现新游戏”的意义。

还有一个非常隐蔽的坑：用户ID和游戏ID是字符串，ALS能不能跑？能跑，但结果里全是字符串ID，关联游戏表时还要再映射回来，容易搞混。我建议直接用StringIndexer编码成数值ID，最后展示时再关联回原始ID和名称，链路更清晰。

7.3 答辩演示防翻车经验谈

这部分是我个人带项目下来最想强调的实操经验。

第一，演示前一定要预演“数据更新”环节。你可以在答辩现场手动触发一次Spark重跑，然后刷新大屏，向评委展示“刚才的推荐结果从10点12分更新到了10点22分”。这个动作看似简单，但临场操作时如果Spark任务要跑3分钟，全场都会低头看手机。我的经验是提前把要跑的数据规模缩到训练时间在30秒以内，速度比“大而全”重要得多。

第二，准备一张“架构图”和一张“数据流图”的PDF备用。不是用Mermaid画的，而是你提前在绘图工具里画好，答辩当天放到桌面，评委问哪里就指哪里。这比现场切换代码窗口讲架构，效果强十倍。

第三，把踩坑记录整理进文档。毕设文档里加一节“开发过程中遇到的典型问题与解决方案”，把你写这篇项目时实际踩过的坑（比如Hadoop副本数、ALS冷启动策略、数据倾斜）都写进去。这个对评分的影响非常大，因为这直接证明你做的不是“照着教程复刻”，而是真正独立解决过问题。

第四，提前测试项目能完整迁移。如果有条件，把你的整套环境做成一个虚拟机镜像，答辩前在别的机器上完整跑一遍流程。很多同学的代码在自己的笔记本上能跑，换台机器就废了，Java版本不一致、Hadoop路径写死、数据库IP不对，全是环境问题。换机器测试能提前暴露90%的迁移问题。

最后再分享一点个人体会

我做了这么多年大数据方向的实践和指导，最大的感受是：这种“Hadoop+Spark+游戏推荐系统”的题目，真正值钱的不是哪段算法代码，而是你能否完整理解一条数据从出生到展示的全过程。很多同学写代码很快，但讲不清楚为什么ALS要交替优化，为什么HDFS副本数要设为1，为什么大屏接口要走聚合表。这些“为什么”才是答辩时老师真正想听的。

做这个项目，心态上不要追求“每一步都完美”，尤其是环境搭建阶段，出错是常态。我自己的经验是：Hadoop和Spark的坑，90%都是环境问题，不要怀疑自己的代码，先看日志；算法部分的坑，90%都是数据问题，先检查数据长什么样，再检查模型参数。

如果你正在做这个题目，按照上面的链路走一遍，遇到卡住的地方先画数据流图、再查日志、最后才是改代码。把这套思路跑熟，你的系统不仅“能演示”，还能“讲得通”，这才是毕业设计真正的意义。

Hadoop+Spark游戏推荐系统：从数据清洗到可视化大屏实战