Amy青梅做大数据方向的毕业设计，最怕的就是选题看着高大上，真上手时发现要么数据跑不动，要么功能东拼西凑连不成一个完整的故事。hadoop+spark新闻推荐系统算是一个比较经典的组合，它把大数据生态里最常用的存储、计算、分析、算法串了起来，而且新闻这个场景大家都很熟悉，推荐效果好不好、分类准不准，一眼就能看出来，答辩时也容易讲清楚。这篇博客我会把这个项目从架构设计、环境搭建、核心算法实现到可视化、问题排查的完整链路拆开讲，给准备做类似系统或者正在为毕业设计发愁的同学一个可以直接参考的底稿。
1. 项目整体设计与思路拆解
1.1 一个新闻推荐系统到底要解决什么问题
先别急着写代码，想清楚系统要干什么。新闻推荐和电商推荐最大的区别在于时效性极强且用户兴趣漂移快。昨天的热点今天可能就没人看了，用户昨天关注科技新闻不代表今天还想看同样的内容。所以这个系统不能只做一个简单的“猜你喜欢”，它需要同时处理三个层次的问题：
- 内容理解：新闻进来之后，系统得知道它讲的是什么、属于哪个分类（体育、财经、科技、娱乐……），这样才能决定把它推荐给谁。
- 用户理解：用户看了哪些新闻、在哪些分类上停留时间更长，这些行为数据要被记录下来，变成用户的兴趣画像。
- 匹配与排序：有了内容和用户两边的东西，推荐引擎要把候选新闻按用户兴趣排序，同时还得兼顾时效性，把最新的、最热的内容往前提。
这个项目标题里提到的“新闻标题自动分类”其实就是在解决第一个问题——内容理解。“新闻数据分析”和“新闻可视化”则是把系统里的数据资产变成直观的统计结果，既是系统的一部分，也是毕业设计展示时最好的素材。推荐系统本身则承担用户理解与匹配排序的工作。三块拼起来，才是一个完整的、可以自圆其说的系统。
1.2 为什么是Hadoop和Spark这套组合
很多同学会问，做推荐系统用Python写个Flask服务不就能跑吗？为什么非要上Hadoop和Spark？这里要说清楚，毕业设计的技术选型要服务于“展示大数据处理能力”这个目标。
Hadoop体系里的HDFS负责存原始数据，比如爬虫抓到的新闻JSON、用户点击日志。这些数据量大、格式杂，不适合直接丢进MySQL。YARN负责任务调度和资源管理，Spark作业跑在YARN上，真正把分布式计算的价值体现出来。而Spark则提供了一套比MapReduce快得多、写起来也舒服得多的计算框架——好几百倍的速度提升在新闻这种文本处理场景里非常明显，比如对几十万条新闻做分词和TF-IDF特征计算，MapReduce可能要跑十几分钟，Spark几分钟就能搞定。
这套组合的另一个好处是后续扩展路径很清晰：今天你用Hive做离线报表，明天可以把同一份数据导到Spark SQL里做即席查询；今天用Spark MLlib做朴素贝叶斯分类，明天想换BERT模型也可以复用同一套数据处理管道。对于毕设来说，技术栈的可讲性很重要，Hadoop+Spark+Spark SQL+MLlib这一条链拿出来，每一样都有充分的理由，面试官或者答辩老师问起来你也能对答如流。
1.3 系统功能模块全景图
我在规划时把整个系统拆成了六个模块，每个模块职责单一，相互之间通过数据解耦：
- 数据采集层：Python爬虫抓取新闻网站的标题、正文、发布时间、来源，同时模拟用户行为生成点击日志。
- 数据存储层：HDFS存原始文件和日志，MySQL存用户信息、推荐结果等业务数据，Hive建外表做离线分析。
- 数据预处理层：Spark作业做数据清洗、中文分词、去停用词、文本特征提取。
- 算法模型层：Spark MLlib训练标题分类模型；基于物品协同过滤和内容相似度计算推荐候选集。
- 推荐服务层：Spring Boot写接口，整合预热好的推荐结果，响应前端的请求。
- 可视化展示层：ECharts大屏展示新闻分类统计、点击热度趋势、推荐效果指标，以及词云等。
模块划分的原则是“每种数据都有明确的流向，每个流向都有明确的技术承载”。这样在论文里画架构图是清晰的，在答辩讲PPT时是一页能讲完的，在写代码时也不会出现“不知道该放哪个包”的尴尬。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境搭建与核心工具选型解析
2.1 集群规划与硬件资源预估
别一开始就想着搭5台机器的集群，学生党没有那个条件，而且毕设的数据量也没到那个规模。我实测下来，3台虚拟机是性价比最高的方案，一台Master，两台Worker（或者一台Master同时做Worker也行，但分成3台更接近真实生产环境的样子）。每台虚拟机分配4GB内存、2个CPU核心、40GB磁盘，跑一个几万条新闻数据的系统绰绰有余。
如果你的电脑配置一般（16GB内存以下），可以考虑2台机器的方案：Master和Worker1合并，另外一台做Worker2。但要注意，Spark的Driver如果跑在Master节点上，内存分配要预留足够，否则执行任务时容易OOM。
软件版本这里必须强调，版本兼容性是搭建环境时最大的坑。我用的组合是：
- Ubuntu 18.04/20.04 64位
- JDK 1.8（不要用JDK 11，Hadoop 2.x和部分Spark组件会有兼容问题）
- Hadoop 2.7.7或3.1.3（推荐3.1.3，HDFS的NameNode性能更好）
- Spark 2.4.x（兼容Hadoop 2.7+，Scala 2.11）
- Hive 2.3.x（如果只做数据分析，其实Spark SQL可以直接代替，但Hive在论文里更“正统”）
- ZooKeeper 3.4.x（Hadoop HA需要，但毕设单NameNode不需要，可以跳过；不过做Hive或Kafka的话强制需要）
- MySQL 5.7
- Spring Boot 2.x + MyBatis + ECharts
2.2 从零搭建Hadoop集群的避坑实录
Hadoop集群搭建的教程网上很多，但不少教程都是“复制粘贴能跑就行”，没解释为什么。我在这里把最关键的几步和容易出错的地方挑出来讲。
第一步：SSH免密登录。 这个是老生常谈，但值得再提醒一次。Master到所有节点（包括自己）都要配好免密。检查方法很简单：在Master上执行ssh worker1，如果不需要输密码就直接进去了，说明配好了。注意authorized_keys的权限必须是600，~/.ssh目录权限必须是700，否则SSH会拒绝加载公钥。
第二步：HDFS配置文件。 核心是core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml这四个。很多同学集群起不来，问题都出在hdfs-site.xml的dfs.replication设置上。如果你是3台机器，副本数设为2或3都行；如果你只有1台机器做伪分布式，副本数必须设为1，不然DataNode会报“Not replicated”的错误。另外，dfs.namenode.name.dir和dfs.datanode.data.dir这两个路径一定要提前创建好，并且确保Hadoop启动用户有写权限。
第三步：格式化NameNode再启动。 首次启动之前执行hdfs namenode -format，但要注意，格式化操作只能在第一次执行，之后每次启动集群不要再重复格式化，否则NameNode的namespace ID会变，DataNode的注册会被拒绝，表现就是DataNode一直处于in secure mode或无法连接。如果确实要重新格式化，必须先把DataNode上的current目录删掉再重新格式化。
第四步：验证集群状态。 启动完成后不要急着跑任务，先执行hdfs dfsadmin -report看各节点是否都算进去了；再打开http://master:50070（Hadoop 3.x是9870）看NameNode的Web UI，确认live nodes数量正确；最后跑一个简单的hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar pi 10 100验证MapReduce能正常执行。
2.3 Spark和ZooKeeper的整合与资源参数设置
Spark的安装比Hadoop简单，就是把解压包放到指定目录，配置spark-env.sh里的JAVA_HOME、SPARK_MASTER_HOST、SPARK_WORKER_CORES、SPARK_WORKER_MEMORY，然后启动。但这里最值得关注的是Spark跑在YARN上的资源规划。
我踩过的最典型的坑是spark.driver.memory和spark.executor.memory设置得太随意。比如Master节点总内存4GB，YARN的ResourceManager要占一部分，如果Spark的Driver申请3GB，再跑两个Executor，内存瞬间爆掉，后果是作业提交后一直卡在ACCEPTED状态，或者跑到一半Executor直接挂了。
我自己用的参数比较保守：
bash复制spark-submit \
--master yarn \
--deploy-mode client \
--driver-memory 2g \
--executor-memory 2g \
--executor-cores 2 \
--num-executors 2 \
--conf spark.sql.shuffle.partitions=100 \
--class com.example.NewsClassifier \
news-recommend.jar
这里有个经验：shuffle分区数不要用默认的200。默认200个分区对几万条新闻这种小数据量来说太多了，每个任务实际处理的数据量很小，序列化和调度开销反而占大头。我一般按照“总数据量 / 128MB”来估算，比如500MB的文本数据，设成100个就差不多了。如果数据量很小，甚至可以直接设成spark.sql.shuffle.partitions=20，速度会有非常明显的提升。
spark.local.dir是我后来才注意到的配置项。默认情况下Spark会把临时数据写到/tmp，如果/tmp空间不够，shuffle过程中会报“No space left on device”。建议把spark.local.dir指向一块空间充足的目录，比如/data/spark-tmp，并且给足磁盘配额。
2.4 Hive和MySQL在系统中的角色定位
Hive在这套系统里的主要作用是做离线的数据分析和报表，而不是核心的推荐计算。你可以把清洗后的新闻数据导入Hive表，用Hive SQL统计新闻分类的数量占比、每天各类新闻发布量、点击量Top 10等结果，这些结果最终会被可视化模块读取并展示。
MySQL的角色更偏业务：存储用户信息、存储推荐结果快照（比如每个用户最新计算好的Top 50条新闻ID）、存储分类模型的评估结果。为什么推荐结果要存到MySQL而不是实时计算？因为协同过滤和相似度计算是离线定时跑的，不可能每个用户请求来了才现场算一遍——那样延迟太高，而且Spark作业的启动时间就要好几秒。离线算好，结果存MySQL，在线查询直接查表，这种“离线计算+在线查询”的模式也是业界推荐的经典架构，写进论文里是加分项。
需要注意的一点是数据同步的时机。我是这样设计的：每2小时跑一次Spark任务，重新计算分类结果和推荐候选集，然后把结果更新到MySQL。在两次计算之间，推荐服务只读MySQL和Redis缓存，不碰HDFS和Spark，这样系统在线部分的压力极小，也避免了对集群资源的频繁占用。
3. 核心模块实现：数据采集、分类、推荐全流程
3.1 新闻数据采集与预处理
新闻数据从哪来？我建议优先找公开数据集，比如有同学共享的新浪新闻分类语料（搜“THUCNews”或“cnews”数据集，里面包含了体育、财经、娱乐等10个分类，纯文本格式，非常适合做中文分类的起步数据）。如果你想自己爬，务必遵守目标网站的robots协议和版权规则，数据仅用于学习研究，不要大规模抓取商用数据。我这里用的是THUCNews里抽取出来的子集，大概10万条新闻标题，已经足够训练一个像样的分类器了。
拿到原始数据后，第一件事是清洗。新闻标题里常见的噪声有：HTML标签残留（如果你从前端页面抓的）、全角半角符号混用、网页转义字符（&、 ）、URL链接、重复数据。我的清洗流程是这样：
python复制import re
def clean_title(title):
# 去HTML标签
title = re.sub(r'<[^>]+>', '', title)
# 去URL
title = re.sub(r'http[s]?://\S+', '', title)
# 转义字符还原
title = title.replace('&', '&').replace(' ', ' ')
# 去掉所有非中文、非英文、非数字的符号（保留中英文和数字）
title = re.sub(r'[^\u4e00-\u9fa5a-zA-Z0-9\s]', '', title)
# 合并多余空格
title = ' '.join(title.split())
return title.strip()
另外还要对数据集做标签分布检查。如果10个分类的样本数悬殊，比如体育类有3万条，科技类只有2000条，训练出来的模型会严重偏向多数类。解决办法是控制每个分类的采样数量基本一致，或者对少数类做简单的过采样（比如复制几条训练样本，虽然方法朴素但比没有强）。
3.2 中文分词与文本特征构建
中文和英文不一样，单词之间没有天然空格，所以分词是最关键的一步。我用的是HanLP，因为它在Spark的分布式环境下用起来方便，分词效果也不错。你也可以用jieba分词，但注意在Spark里每台Worker节点都要能访问到词典文件，把词典放到HDFS上，通过addFile分发到各个Worker的当前工作目录。
分词之后要做两步：去停用词和特征提取。停用词表要自己维护一份，最好包含新闻场景下常见但没意义的词，比如“记者”“报道”“今日”“中国”等——这些词在新闻标题里出现频率极高，但对分类区分度帮助不大，不去掉的话，模型会花很多权重在这些“通用词”上。
特征提取我用的是TF-IDF，在Spark MLlib里有现成的实现：
scala复制import org.apache.spark.ml.feature.{HashingTF, IDF, Tokenizer}
val tokenizer = new Tokenizer().setInputCol("title_cleaned").setOutputCol("words")
val hashingTF = new HashingTF().setInputCol("words").setOutputCol("rawFeatures").setNumFeatures(10000)
val idf = new IDF().setInputCol("rawFeatures").setOutputCol("features")
val pipeline = new Pipeline().setStages(Array(tokenizer, hashingTF, idf))
val model = pipeline.fit(trainingDF)
val trainData = model.transform(trainingDF)
setNumFeatures(10000)表示把词哈希到1万个维度的空间里。这个维度怎么选？太小了容易哈希冲突，分词精度丢失；太大了向量稀疏度高，后续模型训练时间和内存消耗倍增。我用1万维跑出来的效果就已经够好了，如果你的语料更大（百万级标题），可以调到5万维。
3.3 新闻标题自动分类：模型训练与评估指标
分类模型我对比了三种：朴素贝叶斯、逻辑回归、支持向量机（线性核）。在Spark MLlib里，这三种都有现成API，训练时间在10万条数据上都挺快。我的实验结果是：
| 模型 | 准确率 | F1值 | 训练时间（10万条） |
|---|---|---|---|
| 朴素贝叶斯 | 0.912 | 0.907 | 约1.5分钟 |
| 逻辑回归 | 0.935 | 0.932 | 约3分钟 |
| 线性SVM | 0.934 | 0.928 | 约4分钟 |
逻辑回归比朴素贝叶斯好一些，但差距不大。考虑到新闻标题这种短文本场景，词之间有一定相关性，朴素贝叶斯“特征独立假设”并不严格成立，但它胜在训练极快、调参少、模型体积小。如果你的毕设重点不在模型调优上，用朴素贝叶斯已经足够撑场面；如果想让答辩老师眼前一亮，就用逻辑回归，再把多分类的OneVsRest策略讲清楚。
评估时不能只看准确率（Accuracy），在类别不平衡的情况下F1值更能反映模型真实水平。我按8:2划分训练测试集，用Spark自带的MulticlassClassificationEvaluator计算F1：
scala复制val predictions = model.transform(testData)
val evaluator = new MulticlassClassificationEvaluator()
.setLabelCol("label")
.setPredictionCol("prediction")
.setMetricName("f1")
val f1 = evaluator.evaluate(predictions)
println(s"F1 score: $f1")
再生成混淆矩阵，看看具体哪两个类别容易搞混。我的结果是“体育”和“娱乐”有少量误判，因为都有大量明星、球队之类的词；而“科技”和“财经”的边界比较清晰。如果你也想进一步优化，可以做两件事：一是加大特征维度，二是针对易混淆类别补充领域词典。
3.4 分类模型的线上使用方式
分类模型训练好之后不是存个文件就完了。我在项目里做的是把Pipeline模型保存到HDFS上，然后推荐服务通过Spark的PipelineModel.load()加载模型，再用一个优化过的transform函数处理新到的新闻标题。但这里要注意，在Java/Spring Boot的服务里直接调用Spark会有很大的开销——每次都要启动一个SparkSession，资源消耗高、延迟也大。
更轻量的做法是把模型离线导出成通用格式，比如把TF-IDF的词典和逻辑回归的权重提取出来，存成JSON或文本文件，然后在Java代码里实现一个简化的预测函数（分词 → 查词典 → 计算TF-IDF → 线性加权 → softmax → 取最大概率的类别）。这样在线服务完全不依赖Spark，延迟能控制在10毫秒以内，而且逻辑很简单，你完全有把握在论文的“系统设计”章节里讲清楚。
4. 推荐系统：从协同过滤到在线推荐
4.1 三种推荐策略的组合设计
新闻推荐系统里，只用一种推荐策略是不够的，原因在于不同用户和不同场景下的需求不一样。我把推荐策略分成了三层“盖楼”式的结构：
第一层：热度榜兜底。 对于没有历史行为的冷启动用户，直接推荐当天点击量最高的新闻。这个逻辑最简单，但效果其实不差——新闻就是看热点的，新用户愿意点开热门新闻的概率很高。
第二层：基于物品的协同过滤（ItemCF）。 核心思想是“看了这条新闻的人也在看那条新闻”。具体做法是把用户——物品点击矩阵转置，计算新闻与新闻之间的相似度。这个相似度不用在实线请求时算，可以离线凌晨跑一次，把每个新闻最相似的20条新闻存到NoSQL或MySQL里。在线推荐时，根据用户最近点击的5条新闻，把这5条新闻各自最相似的新闻合并、去重、按相似度加权排序。
第三层：基于内容的推荐（Content-based）。 利用第3节训练好的分类模型和文本向量，计算新闻之间的文本相似度（余弦相似度）。当用户点了一条“人工智能”领域的新闻，系统就去找文本向量和它最接近的其他新闻。
我的实际推荐策略是：冷启动用户用第一层；老用户优先出第二层的结果，用第三层做“多样性补充”。这样既保证了推荐结果和用户近期兴趣强相关，又能不断引入新内容，避免推荐列表千篇一律。
4.2 相似度计算与推荐结果生成的Pipeline
如果你用的是Spark MLlib的协同过滤，可以直接用ALS算法。但实际做下来，ALS在新闻这种短生命周期内容上的效果没有在电影场景上好——因为新闻的热度衰减太快，一个用户今天点了某条新闻，明天这条新闻可能就过时了。所以我更推荐自己用Spark实现简化版ItemCF：
- 从日志表里读取用户点击记录，格式是
(userId, newsId, timestamp)。 - 对每个userId，按时间排序取出最近的20条点击新闻。
- 把共现矩阵建出来：统计“同时出现在一个用户点击列表”的两个新闻的共现次数。
- 用余弦相似度或Jaccard相似度归一化共现次数，计算相似度。
- 保存每个新闻的Top 20相似新闻。
这样做的优势是你能从底层原理讲起，而不是“调包调参”。答辩老师最喜欢问“这个相似度是怎么算的”，你把共现矩阵的推导过程写在论文里，再给出核心代码，这一块的分数基本就稳了。
我给出一个关键步骤的伪代码：
scala复制// 假设 df: DataFrame[(userId, newsId)]
val userNews = df.groupBy("userId").agg(collect_list("newsId") as "newsList")
// 对每个用户的新闻列表内两两组合
val cooccurrence = userNews.flatMap { row =>
val newsList = row.getAs[Seq[String]]("newsList").distinct
newsList.combinations(2).map {
case Seq(a, b) => if (a < b) (a, b) else (b, a)
}
}.groupByKey(identity).count().toDF("newsPair", "coCount")
// 计算新闻自身的出现次数，用于余弦归一化
val newsFreq = df.groupBy("newsId").count()
// 再join起来，算出相似度，保存Top20
这一步在10万条点击日志上跑，2分钟左右能算完，完全可以接受。
4.3 冷启动、时效性与推荐效果评估
冷启动是新闻推荐里的重头戏。我的做法是把冷启动拆成两部分：新用户冷启动（没有点击记录）用热度榜+编辑推荐；新新闻冷启动（刚入库还没人点）靠内容推荐策略，即提取新新闻的文本向量，从用户最近感兴趣的新闻里找到向量最接近的内容推出去。这个机制能让一条新新闻在入库后10分钟内就有机会进入推荐流。
时效性怎么处理？我给新闻加了一个时间衰减因子：新闻在推荐候选集里的排序分数，不仅看相似度，还要乘一个decay = exp(-age_hours / 72)。也就是说，入库72小时内的新闻权重衰减最快，超过3天的新闻基本上除非点击很高，否则不会出现在推荐列表前面。这个公式是经验值，但答辩时有理有据，比“我直接把3天前的过滤掉”的说法更有说服力。
效果评估这部分很多同学容易忽略。毕设不是只把系统做出来就结束，你需要回答“这个推荐系统到底推得好不好”。我给自己的系统设计了两类评估指标：
- 离线指标：在历史点击日志上切分训练期和验证期，用** Hit Rate@20**（推荐的Top20新闻里，有多少是用户后来真正点击的）和MRR（推荐列表中首条被点击的新闻的排名倒数）来衡量推荐准确性。
- 在线体验：虽然不是真实的AB测试，但我把“点击率”定义成了日志表里展示次数与点击次数的比值，作为模拟反馈的参考。
在论文里把这两类指标的图表放上去，推荐模块的说服力会强很多。
5. 新闻可视化：让数据自己说话
5.1 可视化大屏的数据指标设计
新闻可视化不是为了炫技，而是服务于两个目的：宏观展示新闻数据的基本盘，以及辅助管理员理解推荐系统的运作情况。我设计的大屏分四个区域：
- 顶部：核心KPI，包括今日新闻总数、用户数、总点击量、活跃新闻数。
- 中部左侧：新闻分类占比饼图（来自分类模型的输出，统计每类新闻的数量和占比）。
- 中部右侧：近7天各分类的新闻量趋势折线图（来自Spark SQL的按日分组统计）。
- 底部：新闻标题词云（用TF-IDF权重排序的前100个词生成）+ 点击量Top 10新闻列表。
这套布局基本覆盖了“新闻数据分析”的要求，而且每块数据都有匹配的技术生成链路，不是空摆设。
5.2 Spark SQL统计结果如何对接ECharts
可视化的核心是数据流动的通路。我是这样设计的：
- Spark清洗后的新闻数据写入Hive数仓表（
news_db.dim_news）。 - 定时任务用Spark SQL跑统计SQL，结果写入MySQL的统计表（比如
news_category_daily_count）。 - Spring Boot提供REST接口查询MySQL。
- 前端Vue页面调用接口，用ECharts渲染。
举例来说，统计今天的新闻分类占比：
sql复制INSERT OVERWRITE TABLE stats.news_category_count
SELECT category_id, category_name, COUNT(*) AS cnt,
COUNT(*) / SUM(COUNT(*)) OVER () AS ratio
FROM news_db.dim_news
WHERE dt = '2025-01-15'
GROUP BY category_id, category_name;
然后Spring Boot里用一个Mapper查询这张表，接口返回给前端：
java复制@GetMapping("/api/statistics/category")
public List<CategoryStat> categoryStat() {
return categoryStatMapper.selectToday();
}
前端ECharts的代码就不贴了，无外乎是pie图配置。重点提醒一下：词云图要用专门的ECharts词云插件，内置的series里没有wordCloud，需要单独安装echarts-wordcloud，而且词云里的词建议提前把权重归一化到[12, 60]区间，不然字体大小对比太夸张，显示效果不好看。
5.3 反哺分析：可视化发现的结论如何指导策略
可视化不单是“展示”，它还能反哺分析。我跑完统计数据后发现一个有趣的现象：工作日早上7点到9点，财经类新闻的点击量显著上升；晚上20点到23点，娱乐类新闻的点击量冲到全天峰值。这不是我事先预想到的，而是从折线图上看出来的。
这就是可视化对推荐系统的价值——你可以根据这个规律，在对应的时间段调高相应分类新闻的推荐权重，让系统更贴近真实用户的使用习惯。在写论文的“实验分析”章节时，这种由数据探索到策略优化的闭环是非常好的素材，体现的是你“用数据指导设计”的思路，而不仅仅是“把图画出来”。
6. 常见问题与排查技巧实录
6.1 环境搭建期：集群起不来怎么办
我总结了一下，集群出问题时的排查优先级应该是：网络 → 权限 → 配置 → 资源 → 日志。
- 网络：先检查
ping worker1通不通，重点看看防火墙，Ubuntu默认的ufw如果开着，会挡掉Hadoop需要用到的多个端口（8020、9864、8088、8042等）。初始化环境时直接执行sudo ufw disable最省心。 - 权限：Hadoop启动用户对数据目录、日志目录没有写权限会报各种Permission denied。一次根治：用同一个普通用户（比如
hadoop）在所有节点上操作，不要一会儿用root一会儿用别的用户。 - 配置：检查
core-site.xml里的fs.defaultFS是不是写成了hdfs://master:8020，主机名是否在全网都能解析，/etc/hosts有没有配置全。 - 日志：Hadoop的日志在
$HADOOP_HOME/logs/下，这绝对是个宝藏路径。DataNode起不来就看hadoop-hadoop-datanode-xxx.log，里面会直接说是Initialization failed for block pool还是别的具体原因。
6.2 Spark作业运行时的性能与内存问题
Spark跑分布式任务，踩坑最多的就是OOM和任务卡死。我整理了两条高频问题：
Executor OOM。 一个典型的报错是java.lang.OutOfMemoryError: Java heap space。很多教程说调大spark.executor.memory就行了，但事实不是这么简单。如果你有4个并发任务，每个任务都很大，即使单Executor内存调到3GB，同时跑4个Executor就是12GB，物理内存根本扛不住。更好的做法是减少并发度、限制单任务的分区里的数据量。我在项目里做的优化是：先把数据用repartition(60)切成更多更小的分区，再把spark.executor.cores设为1，这样每个Executor同时只处理一个任务，内存压力小很多。
Driver端内存爆掉。 典型场景是collect()一个太大的DataFrame——比如你把所有新闻的特征向量都collect回Driver端。Driver是单点的，数据量一大它肯定扛不住。解决办法是尽量使用saveAsParquetFile写回分布式存储，或者用take(n)获取前几条样本用于调试，不要全量拉回。
6.3 数据倾斜、中文编码与其他坑
数据倾斜在新闻场景里很容易发生：某个热点新闻的点击量碾压其他新闻，导致按新闻ID做groupBy时，单个Key的任务要处理的数据远超其他Key。我碰到过一次，一条“世界杯”新闻占了当天80%的点击，groupBy("newsId").count()跑了一个小时都没跑完。解决办法是给热点Key加随机前缀打散，比如把这个Key复制成10份随机key，再聚合。具体做法不复杂，但能明显缩短作业时间。
中文乱码也是高频问题。数据从爬虫进HDFS时，如果编码不统一（UTF-8、GBK混用），Spark读出来全是乱码。我在采集端统一了编码，写Java代码读文件时固定指定StandardCharsets.UTF_8，写HDFS时也指定UTF-8。如果HDFS上已经有乱码数据，可以用spark.read.text时指定encoding选项重新读一遍，或者写一个简单的清洗作业重新落盘。
jar does not exist or is not a normal file，这是提交Spark作业时最常见的报错之一。原因是spark-submit时指定的JAR包路径在Driver端无法解析（比如路径里有空格，或者你用了相对路径但当前目录不对）。解决办法是：把JAR包放在HDFS或者所有节点都能访问到的绝对路径下，不要用相对路径，更不要用带中文和空格的目录名。
写在最后：如果重做一遍，我会怎么做
这个项目从设计到完成，我前后改了三个版本。第一版贪多求全，想在系统里塞进Spark Streaming做实时计算、塞进全文检索，结果基础功能还没完成就把自己拖垮了；第二版果断砍掉实时部分，专注离线分析和推荐；第三版才是现在这个最终形态——功能完整、逻辑闭环、每一部分都能讲出为什么。
如果让我给后来者一句建议：毕业设计的核心不是技术越新越好，而是把一套完整的数据处理链路讲清楚、跑通、做出可展示的成果。你不需要去做大模型微调，不需要引入Flink做实时流处理，能把这个Hadoop+Spark链路里的存储、计算、算法、展示每个环节做到位，并理解每一个选择背后的原因，就已经是一份很有分量的作品了。希望这篇拆解能让你少踩我之前踩过的那些坑。