企业官网建设流程全解析

简介：一份基于Spark 2.2的新闻网大数据实时分析系统完整设计与实现源码，适用于计算机专业毕业设计、课程设计或大数据实战练习。项目围绕新闻数据的采集、实时清洗、统计分析与个性化推荐展开，能够帮助学习者理解离线与实时处理链路的常见组合方式。压缩包共403个文件，包含364个XML配置、14个Scala源码、5个Java类、4个Shell脚本以及属性/说明文档等，整体压缩后仅262KB，体积小巧但模块划分清晰，方便按目录定位配置、脚本与核心逻辑。源码均已在本地编译通过，下载后按配套文档配置环境即可直接运行，难度适中且经过助教审定，适合作为系统实现参考；其中还包含Kafka、HBase集成示例，如异步写入HBase的序列化处理类，对学习实时推荐、日志接入具有一定的借鉴价值。目前已有242人学习下载，值得正在准备大数据类项目的开发者和学生参考。

1. 基于Spark2.2的新闻网实时分析：毕设题目背后的真实工作量

当你在选题清单里看到「基于Spark2.2的新闻网大数据实时分析系统设计与实现」时，大概率以为这就是一个统计新闻点击量的普通管理系统。但实际上，把它拆开看：Spark2.2、实时分析、新闻网、设计与实现，四个词对应了流处理框架选型、数据接入、业务场景和系统落地四件事。很多学生卡在第一步——以为跑通一个WordCount就能毕业，结果发现实时分析要面对的不只是代码，还有消息队列、状态管理、结果存储和可视化。这篇笔记的目标就是讲清楚：这套系统用什么架构落地、关键参数怎么设、哪个环节最容易翻车，以及做完之后怎么验证它确实是实时而非定时跑批。适合正在选题或中期答辩前需要快速理清技术路线的同学，也适合想找一套完整实时分析链路做参考的入门工程师。

2. 技术选型与系统架构：Spark2.2在实时分析里扮演什么角色

2.1 为什么毕设选Spark2.2而不是Flink或Spark3

先说结论：对于「计算机课程毕设」这个场景，Spark2.2并不是性能最好的选择，而是资料最齐、坑最透明 的选择。2017年发布的Spark2.2引入了Structured Streaming（结构化流），但绝大多数教材和网上的毕设代码还在用Spark Streaming的DStream API；而Spark2.2恰好是DStream API成熟、Structured Streaming刚起步的版本，网上能搜到的「SparkStreaming + Kafka + HBase/Redis」教程大部分都基于2.2或2.3。对写论文的人来说，DStream有清晰的批处理间隔（batch interval）、窗口（window）、状态更新（updateStateByKey）概念，画架构图、写原理章节都比Flink的连续流更容易表述。选Flink当然更贴近工业界，但一旦在集群部署、checkpoint恢复上出问题，毕设时间往往不够填坑。

另一个实际原因是Scala版本。Spark2.2官方预编译包用的是Scala 2.11，配套的spark-streaming-kafka-0-10_2.11依赖在Maven中央仓库里非常齐全，不需要自己编译。如果你用了Spark3.x加Scala2.12，部分老的Kafka客户端配置类会发生包名变动，照着老教程抄容易编译报错。对只求稳妥毕业的学生来说，环境兼容性比技术前沿性更重要。当然，如果导师明确要求用Flink做真正的实时，那另说；但题目写死Spark2.2时，顺着它做是成本最低的路径。

如果按照大数据学习路线一路学到Spark，你大概率会先接触RDD、DStream再接触Structure Streaming。Spark2.2正好卡在这条路线中间：老师讲的是DStream，网上博客写的也是DStream，连Spark UI上的Streaming标签页都还是旧的批次监控。选这个版本，意味着你遇到任何一个编译错误，stackoverflow上基本都有现成回答，这是后发版本没法比的。

2.2 一条完整的新闻实时分析链路长什么样

我在带毕设时的常见做法是：新闻网站的行为数据（浏览、点击、评论）先打入Kafka，Spark Streaming按固定间隔从Kafka拉取数据，在内存里做窗口聚合，得到「每分钟新闻点击TopN」「每小时热点新闻」等指标，写入MySQL或Redis，再用Web后端配合ECharts把指标拉出来画成数据大屏。整套系统的核心不是算法，而是数据管道的稳定性。新闻数据不需要像推荐系统那样做复杂模型，重点是「实时性」的证明：从新闻产生点击到大屏数字变化，延迟控制在秒级。

为什么中间要加Kafka而不让Spark直连业务库？因为新闻网站的业务库是OLTP，直接轮询查询会拖垮业务，而且Spark Streaming从Kafka消费可以利用分区并行度做负载均衡。最简单的拓扑是：生产者(模拟点击流) -> Kafka topic(news_click) -> Spark Streaming(消费+窗口聚合) -> MySQL/Redis(结果) -> WebSocket/Polling(前端)。如果你的毕设不想引入太多组件，也可以用Spark Streaming直接读socket流，但那样「大数据量、分布式」的论证就会薄弱很多，所以只要机器内存够，我还是建议把Kafka放进架构图。

这条链路还有一个容易被忽视的角色：ZooKeeper。Kafka的broker注册和旧版本offset记录都依赖它。很多同学习惯把ZooKeeper和Kafka装在同一台机器上，这没问题，但要注意Kafka是磁盘IO密集型的，ZooKeeper是内存和cpu敏感的，两个进程抢资源可能导致Kafka连接超时。我在虚拟机上分配资源时，给ZooKeeper最少512MB堆，给Kafka最少1GB内存，然后再给Spark留出2GB以上，这样才能跑出流畅的实时效果。

2.3 集群部署策略：一台机器和四台机器的差别

很多毕设实际是在一台Windows笔记本上跑的：本地启动ZooKeeper、Kafka、Spark（local模式），MySQL也在本机。这样能运行，但只能证明功能通了。如果答辩老师问Spark分布式体现在哪里，你会很难回答。我一般会建议至少准备三台虚拟机（Linux），组成一个master+worker的小集群，Spark以yarn-client模式提交，Kafka也至少分两个broker部署。这样资源充足，跑起窗口聚合时才能看到多个executor的日志。

部署上有个容易被忽略的点：Spark2.2默认从HDFS读取数据时需要Hadoop配置，但毕设里如果只是从Kafka消费，并不强制依赖HDFS。所以不需要为了「大数据」非装一套三节点的HDFS，只要Hadoop客户端库存在、core-site.xml里fs.defaultFS指向本机能访问的地址即可。把存储留给MySQL/Redis，把HDFS排除在最小架构外，能省出大量折腾时间——这一步往往比调Spark参数更影响进度。

给你一张我在三台虚拟机上常用的资源分配表，注意这是毕设演示级别，不追求高并发：

如果你只有一台8G内存的笔记本，就用local模式，但把上面三个角色压缩成进程：ZooKeeper+Kafka+Spark local。这时候spark.master设成local[2]，表明用两个线程，一个接收数据一个处理数据。这个模式跑通后，再考虑拆到多台机器。集群部署的意义在于让你在答辩时能说出「spark-submit --master yarn --executor-memory 1g --num-executors 3」，而不是只是看的参数。

3. 从零搭起一个可复现的Spark2.2新闻实时分析系统

3.1 模拟新闻点击流：从Python脚本到Kafka topic

实时分析的第一步是拿到持续产生的数据。毕设里没有真实业务流量，最常见做法是写一个Python脚本，模拟用户对新闻的点击行为：随机挑新闻ID、随机用户ID、随机时间戳，然后按固定频率发送到Kafka。下面是我常用的生成脚本简化版。

import json import random import time from datetime import datetime from kafka import KafkaProducer news_pool = [f"news_{i}" for i in range(1, 51)] # 50条新闻 producer = KafkaProducer( bootstrap_servers='192.168.1.10:9092,192.168.1.11:9092', value_serializer=lambda v: json.dumps(v).encode('utf-8') ) while True: record = { "news_id": random.choice(news_pool), "user_id": f"u{random.randint(1000, 9999)}", "action": random.choice(["view", "like", "comment"]), "ts": datetime.now().isoformat() } producer.send('news_click', record) time.sleep(random.uniform(0.05, 0.5))

逻辑说明：这里每条消息都是一个行为事件，action字段可以扩展成浏览、点赞、评论，后续做分类统计时不用改数据结构。bootstrap_servers设置了两个broker地址，是为了让数据分散到分区。参数上，发送频率直接决定Spark侧看到的「流量大小」——如果你希望窗口聚合结果更像真实热榜，把休眠时间调到0.05到0.5秒随机，让流量有波动；如果只是验证功能，固定0.2秒也可以。

有几个坑提前说：KafkaProducer发送是异步的，脚本结束前要调用producer.flush()，否则最后几条会丢；另外ts用本地时间，Spark侧为了统一处理时刻，通常忽略这个字段，所以不要在生成端纠结时区。启动脚本前，先手动建好Kafka主题，命令如下：

kafka-topics.sh --create --bootstrap-server localhost:9092 \ --replication-factor 1 --partitions 3 --topic news_click

分区数设3对毕设足够，但如果你的Kafka有两个broker，replication-factor可以设2，保证某个broker宕机时topic还能消费。主题创建后，用kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic news_click先看10秒，确认消息真的进来了，再往下做。这一步花两分钟，能省下后面排查「为什么Spark没有数据」的半天。

3.2 Spark Streaming消费Kafka：核心代码与三个必调参数

接下来是系统主程序。用Scala写Spark Streaming，从Kafka拉取news_click主题，每10秒做一个批次，统计每个新闻ID的点击量，再叠加到累计值上。注意，Spark2.2时代官方推荐用spark-streaming-kafka-0-10_2.11这个连接器，它支持Direct模式，不需要单独维护ZooKeeper里的offset，代码如下。

import org.apache.spark.SparkConf import org.apache.spark.streaming.{Seconds, StreamingContext} import org.apache.spark.streaming.kafka010._ import org.apache.kafka.common.serialization.StringDeserializer val conf = new SparkConf() .setAppName("NewsStreamAnalysis") .setIfMissing("spark.master", "local[2]") val ssc = new StreamingContext(conf, Seconds(10)) val kafkaParams = Map[String, Object]( "bootstrap.servers" -> "192.168.1.10:9092", "key.deserializer" -> classOf[StringDeserializer], "value.deserializer" -> classOf[StringDeserializer], "group.id" -> "news-stream-group", "auto.offset.reset" -> "earliest", "enable.auto.commit" -> (false: java.lang.Boolean) ) val topics = Array("news_click") val stream = KafkaUtils.createDirectStream[String, String]( ssc, LocationStrategies.PreferConsistent, ConsumerStrategies.Subscribe[String, String](topics, kafkaParams) ) val counts = stream .map(record => { val obj = new com.google.gson.JsonParser().parse(record.value()).getAsJsonObject (obj.get("news_id").getAsString, 1) }) .reduceByKey(_ + _) counts.foreachRDD { rdd => val topN = rdd.sortBy(_._2, ascending = false).take(10) // 这里把topN写入MySQL或Redis topN.foreach(println) } ssc.checkpoint("hdfs://localhost:8020/checkpoint/news/") ssc.start() ssc.awaitTermination()

逻辑说明：createDirectStream返回的每条 ConsumerRecord 里既有消息key也有value，所以第一步要从JSON里解析出news_id。reduceByKey是在每个批次内做聚合，批次间隔10秒意味着结果每10秒刷新一次。foreachRDD是DStream时代的经典出口，可以在里面批量写库，避免每条数据都建立连接。

三个必调参数：第一，enable.auto.commit设为false，配合手动提交offset；第二，auto.offset.reset在毕设调试阶段必须设为earliest，如果默认latest，Kafka里积压的新闻流量会在启动后被跳过，实时效果看起来像「死机」；第三，ssc.checkpoint路径必须设置，否则后面用updateStateByKey做累计统计时会直接报「Checkpoint directory has not been set」。至于spark.master，本地调试用local[2]，至少两个线程，因为Streaming需要一个接收器线程加一个处理线程，用local[1]会白白多等一个批次。

如果你还想做「累计点击量」，也就是从启动到现在所有新闻的排行榜，那么需要换成updateStateByKey，把历史状态累加。这个算子对毕设论文很有用，因为它牵扯到「状态管理」的知识点，但代价是必须设置checkpoint，而且状态在内存里，不能无限增长。下面的代码片段展示了用法：

val updateFunc = (values: Seq[Int], state: Option[Int]) => { Some(values.sum + state.getOrElse(0)) } val totalCounts = counts.updateStateByKey(updateFunc)

这里的state是Spark Streaming在内部维护的上一个批次结果。你会发现，如果不设checkpoint，这个算子直接抛异常；设了checkpoint之后，它才能把状态持久化。这个例子放在论文里，可以解释「容错」是怎么实现的。

3.3 结果存储与可视化：从批结果到数据大屏

聚合结果不能一直打印在控制台。常见实现是开一个foreachRDD，把top10写入MySQL的news_hot_rank表，或者写入Redis的zset，让后端接口直接读取。考虑到数据大屏需要秒级刷新，我一般倾向于Redis：把每分钟热点新闻存成ZSET，score是点击量，Web后端每隔2秒拉取集合的reverseRange(0, 9)，再通过WebSocket推给前端ECharts。

如果为了论文里好写「持久化」，也可以选MySQL，但要解决「高频更新」的问题：每10秒更新一次表记录，MySQL的写入压力并不大（每批只有几十条），真正麻烦的是一段时间后数据量膨胀。我建议建一张news_rank_snapshot表，字段包括window_start, window_end, news_id, cnt, rank，用INSERT ... ON DUPLICATE KEY UPDATE更新同一时间窗口的记录，而不是无限追加。这样既能画出趋势图，又控制了行数。下面是一条可参考的落地SQL。

CREATE TABLE news_rank_snapshot ( window_start DATETIME NOT NULL, window_end DATETIME NOT NULL, news_id VARCHAR(20) NOT NULL, cnt INT NOT NULL, rank INT NOT NULL, PRIMARY KEY (window_start, news_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

说明：window_start记录该轮窗口的开始时间，rank冗余出来是为了前端直接按排序取数。每轮写入前先DELETE FROM news_rank_snapshot WHERE window_start = ?，再批量插入，避免主键冲突。对于毕设的演示场景，这个操作足够可靠，且比upsert语句更直观。前端展示部分不赘述，用ECharts的line或bar图表，配合定时器拉取接口即可。

如果要用Redis，我写个极简的写入片段：

// 在foreachRDD中 rdd.foreachPartition { part => val jedis = new Jedis("localhost", 6379) val pipeline = jedis.pipelined() part.foreach { case (newsId, cnt) => pipeline.zadd("news:hot:" + currentWindow, cnt.toDouble, newsId) } pipeline.sync() jedis.close() }

这段代码把每个新闻ID作为member，点击量作为score写入zset。pipeline批量提交，减少网络往返。前端要取Top10，只需要ZREVRANGE news:hot:xxx 0 9。注意zset的score是累计值，如果只想要单窗口排名，就要用不同的key（比如带window_start），否则会叠加混乱。

4. 参数与调优：让实时分析稳定不掉线的五个关键设置

4.1 batch interval 到底设多大：10秒还是5秒

StreamingContext的批次间隔决定了Spark多久生成一个RDD。设太短，如1秒，在单机local模式下会因为调度开销过大导致处理速度跟不上数据产生速度，出现「堆积延迟」；设太长，如30秒，大屏刷新看起来就像PPT。我的经验是：新闻点击流这种每秒几十到几百条的量级，本地虚拟机设10秒，集群模式设5秒比较合理。判断标准是日志里的Total delay或Scheduling delay：如果处理时间稳定小于批次间隔，说明当前配置健康；如果经常超过，就要么加内存，要么调大间隔。

具体看Spark UI的Streaming标签页，有一个表格列出每个批次的Scheduling Delay和Processing Time。前者表示Spark等待资源的时间，后者表示真正执行统计的时间。如果Scheduling Delay长期不为0，说明executor不够；如果Processing Time接近批次间隔，说明计算本身太重。对新闻TopN来说，计算量很小，瓶颈通常出在JSON解析和写库上。所以，把批次间隔从5秒调到10秒往往就能解决问题，而不是疯狂加executor。

4.2 checkpoint 目录的坑：本地路径还是HDFS

前面代码里写的checkpoint("hdfs://...")，不少同学图省事换成checkpoint("./cp")，结果提交集群后每次重启都报任务恢复失败。原因是：updateStateByKey和window操作依赖checkpoint保存RDD血缘和状态，如果路径在本地文件系统，不同executor看到的目录不一致。另外，checkpoint里保存的序列化对象和代码版本绑定，改代码后不清理旧目录，会抛出各种反序列化异常。教训是：毕设阶段直接用本地目录跑local模式没问题，但一旦换集群，把checkpoint单独建一个HDFS路径，且每次代码变更后先删除旧checkpoint，再重启应用。

顺带一提，checkpoint粒度是批次级别的，每次batch结束都会写一份元数据。如果你把checkpoint设在Leader节点下的临时目录，可能会因为磁盘不足导致应用挂掉。给checkpoint目录预留至少1GB空间比较稳妥。如果用的是HDFS，建议检查hdfs dfs -du -h /checkpoint/news/，确认里面没有暴涨的临时文件。

4.3 Kafka offset 提交：别再让防火墙背锅

Spark Streaming从Kafka消费时，如果enable.auto.commit保持默认true，Spark会在处理批次前提交offset，导致程序在写入MySQL前崩溃，重启后这批数据丢失（表现为「结果少了数据」）。正确做法是和前面代码一致：关掉自动提交，在foreachRDD处理完并写库成功后，调用stream.asInstanceOf[CanCommitOffsets].commitAsync(rdd.asInstanceOf[HasOffsetRanges].offsetRanges)。虽然Spark2.2官方文档说「至少一次」语义下重复数据处理是正常的，但手动提交可以保证「不丢」；重复问题通过结果表的INSERT ... ON DUPLICATE KEY UPDATE去重消化。

手动提交的代码很简单，放在foreachRDD的最后一行。但要注意，如果你在做take(10)只取了前10条，这个rdd已经被action触发计算了，offsetRanges依然可用。不过如果rdd.isEmpty，调用commitAsync也不会出错。真正的坑是：在foreachRDD里误用了rdd.collect()，然后把collect后的结果写库，等处理完再commit，这样offset是正确的，但如果collect结果太大，driver内存会被撑爆。所以毕设里宁可多写几步，也不要用collect。

4.4 内存与GC：local模式下最常见的OOM

local模式跑Spark Streaming时，默认的spark.driver.memory是1G。如果同时启动Kafka、ZooKeeper、MySQL和Spark，四五个进程挤在一台8G笔记本，很容易在窗口数据量大时GC停顿或OOM。建议单独配置spark.driver.memory=2g，spark.memory.offHeap.enabled=false，并在提交参数里加上--executor-memory 1g。还有一点容易被忽视：Spark Streaming默认会在一个批次结束后丢弃旧数据，但如果你的窗口长度大于批次间隔（比如窗口30秒、间隔10秒），中间会保留三个批次的数据，内存占用一下就上去了，所以窗口千万别设得过大。

怎么判断是内存问题还是代码问题？看日志里的java.lang.OutOfMemoryError: Java heap space，出现这个基本就是堆不够。如果你用了updateStateByKey，状态在内存里累积，还需要额外估算：假设50条新闻、每条状态几十字节，远不够造成OOM；真正会让内存爆炸的是你有10亿条key的假数据。所以毕设级别把新闻池控制在一万条以内，内存完全不是瓶颈。倒是G1垃圾回收器的参数别乱调，默认值在2.2上够用。

4.5 结果写库的并发控制

foreachRDD里的写库操作要避免每条记录都建连接。常见做法是rdd.foreachPartition { part => // 一个分区开一个连接 }，而不是rdd.foreach { record => // 每条一个连接 }。用foreachPartition批量提交SQL，每500条flush一次，MySQL写入速度能快几十倍。这一条不需要改逻辑，但看代码的人一眼就能看出你懂不懂生产实践，答辩时加分。

另一个跟写库相关的参数是批大小。如果你的单批结果超过几百条，建议在partition内部循环里攒一个List[Row]，满100条就ExecuteBatch，然后清空。毕设的TopN每批只有10条，不存在这个压力，但如果你顺便做了全量统计（比如按新闻分类统计），就会用到。不要小看这个细节，很多同学的Spark任务跑着跑着就卡在写库环节，因为每处理一条数据都建立一次JDBC连接，这个开销比计算本身还大。

5. 毕设避坑：六个让Spark实时分析翻车的现场

5.1 现象：Spark版本与Kafka客户端不兼容，一启动就NoSuchMethodError

原因：Maven里的spark-streaming-kafka依赖版本和Spark核心版本不一致。很多人下载了Spark2.2的二进制包，却在pom里写spark-streaming-kafka_2.11:2.1.0，或者反过来，Kafka客户端类从旧包加载，新API找不到方法。解决：统一用spark-streaming-kafka-0-10_2.11的2.2.0（或与Spark完全相同的版本），Kafka服务端用0.10或0.11版本；不要混用0-8连接器，因为0-8的API在2.2里虽然还能用，但offset管理语义完全不同，照着新教程抄会报错。验证方式很简单：看日志第一行的Exception类名。NoSuchMethodError几乎都是依赖冲突，ClassNotFoundException大概率是打包时漏了--packages或fat jar里没有包含Kafka客户端。解决后重新mvn clean package，确保打的是assembly包。

5.2 现象：程序能跑，但控制台打印的counts永远是空的

原因：Kafka topic没有数据，或auto.offset.reset配置为latest。解决：先写一个简单的Kafka消费者（可以用kafka-console-consumer.sh）确认topic里有没有消息；如果确认有，把auto.offset.reset改成earliest，并删除consumer group在__consumer_offsets里的旧记录（新group不用删）。还有一个非常阴间的可能：Kafka生产者往topic发送的key是空，value是JSON，但Spark这边解析JSON时用了错误的类名，Gson解析出的字段为null，sortBy时按null排序不会报错但结果为空——所以先打印一条record.value()看看。

排查命令是：

kafka-console-consumer.sh --bootstrap-server localhost:9092 \ --topic news_click --from-beginning --max-messages 5

如果这里能看到数据，问题就在Spark端。接着在map函数里加一条println(record.value())，re-run一次，确认JSON里字段名是news_id而不是newsId。很多同学从网上抄的生成脚本，字段叫newsId，Spark里却写成news_id，gson解析时返回null，而Scala的getAsString对null会抛异常，如果用了getAsJsonObject再get("news_id")，得到的可能是JsonNull，最后转成字符串"null"，所有key变成同一个。杜绝这个问题的方法就是在生成端和消费端约定好字段名，写死在README里。

5.3 现象：窗口聚合结果每次都比上一次少，或者趋势图断断续续

原因：大概率是checkpoint路径冲突。如果多次重启应用，旧的checkpoint里记录了上一次的应用ID和RDD血缘，而新代码的逻辑已经变化，恢复时某些批次被跳过，导致统计口径对不上。解决：每次改代码后，删除checkpoint目录；不要图省事复用local模式留下的目录。如果是生产化的说法，这叫「无状态重启」，毕设答辩可以说为了调试验证，但别在论文里写成「应用实现了exactly-once」。

具体删除命令取决于你的路径。如果是HDFS：

hdfs dfs -rm -r /checkpoint/news

然后重启应用。这里要注意，如果你是local模式用的文件系统路径，直接rm -rf cp_dir。删完重启后，观察第一个批次的输出是否从0开始累计，而不是从上次的一半开始。这能证明状态清干净了。如果你发现即使删了checkpoint还是跳变，那可能是Kafka的offset问题——旧的group offset还在，Spark又从断点消费了，导致看起来「少」了数据。对策是给group.id换一个新名字，强制从头消费。

5.4 现象：数据大屏的数字卡住不动，但Kafka里消息还在涨

原因：Spark处理延迟超过了批次间隔，导致实际消费速度小于生产速度，积压的offset越来越多。可以从SparkUI的Streaming页面看Scheduling Delay和Processing Time：如果Processing Time接近甚至超过batch interval，说明处理不过来。解决：优先减少每批次的数据量——给topN计算加一个filter把无效action过滤掉；其次给executor增加内存，减少GC；最后才是调大batch interval。不要一上来就加executor数量，因为local模式只有一个进程，加了也没用。

这个现象还经常被误判为网络问题。如果你发现Kafka的Messages in持续增长而Spark的Processed不动，先在Kafka broker节点上看网络IO，如果正常，再用jstack看Spark executor线程在干什么。常见的是卡在数据库连接上：foreachRDD里每写一条数据就new一个连接，数据库连接池被打满，整个批次卡住。解决办法就是4.5节提到的foreachPartition，一个分区共用一个连接。改完之后你会看到Processing Time骤降。

5.5 现象：写MySQL出现中文乱码，新闻标题变成问号

原因：Spark端用UTF-8解析Kafka消息没问题，但MySQL表是latin1字符集，或JDBC连接串没加characterEncoding。解决：建库时统一用utf8mb4，如前面SQL所示；JDBC URL加useUnicode=true&characterEncoding=UTF-8；如果是读文件里带中文的新闻标题，在传入SparkSession之前确认spark.sql.session.timeZone和文件编码一致。这一项看起来低级，但每年答辩都有同学把时间耗在乱码上。

乱码的排查优先级建议先看MySQL：

SHOW VARIABLES LIKE 'character_set_server';

如果服务器字符集是latin1，哪怕建表写了utf8mb4，默认的collation也会乱。彻底做法是改my.cnf的[mysqld]段，重启MySQL。但毕设环境里重启MySQL可能影响其他服务，折中方案是在JDBC URL里显式指定编码。此外，Kafka生产端的value_serializer=lambda v: json.dumps(v).encode('utf-8')已经保证字节是UTF-8，消费端StringDeserializer默认用平台编码，如果两台机器平台不同，最好显式指定value.deserializer并保证Spark启动参数里-Dfile.encoding=UTF-8。

5.6 现象：集群提交后一直处于ACCEPTED状态，不跑任务

原因：Spark2.2配合Yarn时，如果提交脚本里写--master yarn，但集群的HADOOP_CONF_DIR没有指向真实的hdfs-site.xml、yarn-site.xml，客户端连不上ResourceManager。解决：在提交命令里显式--files /etc/hadoop/conf/hdfs-site.xml，或者用--master local[*]先把功能跑通再做yarn模式。对毕设来说，local模式完全够演示，集群属于加分项，不必死磕。

如果你确实想yarn模式跑，先做一件事：在提交机器上执行yarn node -list，如果连这个命令都报错，说明HADOOP_CONF_DIR配置不对。Spark默认会读$HADOOP_HOME/etc/hadoop，没有的话就把conf所在目录位置告诉它。另一个常见原因是资源不足：ResourceManager给Spark application分配不了container，因为集群内存都被其他任务占了。毕设集群通常只有几个G内存，建议加上--executor-memory 512m --driver-memory 1g，并把spark.yarn.executor.memoryOverhead调小到256m。不过这些都是过程指标，最终答辩时，你只要能现场跑起来就够了。

6. 让毕设多拿10分：热度衰减算法与实时性验证技巧

实时分析做完基本功能后，大多数同学停在「统计点击量Top10」这一步。但答辩时老师最常追问的是：你的实时系统和离线统计区别在哪？如果只是每10秒跑一个SQL，那用crontab也能做。为了体现出「实时分析」的价值，我建议在指标上做一个小升级：热度衰减。新闻热榜不应该只看累计点击，因为旧闻的累计值永远压着新文。可以给每条新闻加一个基于当前时间的评分：

score = 当前窗口点击量 * 1 + 上一窗口点击量 * 0.8 + 再上一窗口点击量 * 0.6

在Spark Streaming里实现这个很简单：用reduceByKeyAndWindow，窗口长度设30秒、滑动步长10秒，窗口内聚合后的点击量再乘以一个衰减系数累加到Redis里。这样大屏上能看到新新闻在几分钟内爬升到头部，老新闻逐渐滑落，演示效果非常直观。代码上，把前面例子里的reduceByKey换成下面这样即可。

import org.apache.spark.streaming.{Seconds, StreamingContext} val windowed = stream .map(record => (parseNewsId(record.value()), 1)) .reduceByKeyAndWindow( (a: Int, b: Int) => a + b, (a: Int, b: Int) => a - b, // 用于滑动窗口的逆减逻辑 Seconds(30), // 窗口长度 Seconds(10) // 滑动步长 )

说明：第二个匿名函数是invReduceFunc，当窗口滑动时会移除旧批次数据，它的存在让Spark不用重新计算整个窗口，显著减少计算量。这个API初看不直观，但正是DStream教程里最经典的考点。如果你不想用逆减函数，可以改用reduceByWindow，但性能和内存占用都更差。毕设里能写出带invReduce的版本，说明你真的理解了窗口语义。

最后说验证方法。答辩时要证明「实时」，不能只靠嘴说。我常用的做法是：在数据生成脚本里故意做一个「突发流量」，比如让某个news_15在短时间内被随机选中概率提高到50%，然后观察大屏上它的排名是否在1~2个批次内（10~20秒）冲到第一。把这段观察记录成短视频或几张带时间戳的截图放到毕业设计文档的验证章节里，说服力比任何架构图都强。另一个验证点是「失败恢复」：手动kill掉Spark任务，重启后观察Kafka的offset是否从断点继续消费，从而说明系统具备不丢数据的能力。这两点做完，你的系统就从「课程作业」变成了「有验证的工程实现」。

我自己的习惯是，做完一个实时系统会把所有配置写成一个start_all.sh，包括启动Zookeeper、Kafka、执行spark-submit，并附一个README记录每台机器的IP和内存分配。这样熬完大四再回来看，也能很快恢复演示环境。这套方案虽然用的是Spark2.2的老版本，但链路设计放到今天依然通用，换成Flink或Spark3只需要替换连接器API。希望这篇笔记能帮你在毕设路上少熬两个夜，把时间省下来好好写论文。

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