简介：面向大数据方向毕业设计及Spark入门进阶学习者，这份基于Spark2.x的新闻浏览日志实时分析与可视化项目源码，完整覆盖Flume日志采集、HBase存储、Kafka消息中转、Spark Streaming实时消费与统计的典型链路，适合复现新闻热点排行、各时段用户浏览量峰值等指标。包体共35个文件，压缩包大小3.46MB，以scala与java源码、jar依赖为主，辅以png可视化截图、js与xml配置，以及项目说明和参考步骤文档。目录按flume_hbase、sparkStu、weblogs、z_pic划分，清晰对应数据采集、示例测试、实时处理和可视化资源，便于分层查阅。已集成Spark SQL离线分析与前端展示，并配有项目说明和部署步骤，可帮助理解从数据接入到指标呈现的完整流程。目前已有68人学习，适合用于毕业设计选题落地、流处理项目练手或课程设计参照。
1. 从课设焦虑到真正跑通的实时链路：这套 Spark2 新闻日志系统值得你拆一遍
每个做大数据的毕设选手大概率都卡过同一道坎：Spark 官方示例能跑，但一换到自己的业务数据就全线翻车。这套基于 Spark2 的新闻浏览日志实时分析与可视化系统，解决的就是「从日志到统计结果再到可视化大屏」这一整条链路的落地问题。它不是那种只贴几个 WordCount 的阉割版课设，而是把日志生成、消息缓冲、流式计算、结果存储、图表展示串在一起的可运行项目，附带操作步骤说明文档。适合两类人：一是需要交毕设、急需一个能演示能答辩的完整系统的学生，二是想快速搭一套流式分析 Demo 验证思路的从业者。接下来我会按实际拆项目的顺序，把架构选型、核心代码、部署顺序和排错记录都过一遍，让你拿到手不是对着源码发呆，而是能直接跑起来、能讲明白、能改参数。
2. 为什么奠基在 Spark2 这一代：流批一体的真实取舍
2.1 微批次架构不是缺陷：毕业设计场景下的正确姿势
这套资源选型 Spark2 而不是 Spark3 或 Flink，有很现实的原因。Spark Streaming 在 2.x 时代已经非常成熟，DStream 抽象对刚接触流式计算的学生来说更容易理解——它本质上还是 RDD 的那套机制，把连续的数据流切成一个个微批次，每个批次走一遍 RDD 的转换流程。这意味着你之前学的 map、filter、reduceByKey 在流式场景下还能复用，学习成本比 Flink 的 DataStream API 低一个量级。
在真实部署中，新闻浏览日志的实时性要求是秒级到分钟级。Spark Streaming 的批处理间隔设置成 2 到 5 秒，对 PV、UV 这类统计口径完全够用。Flink 能做到毫秒级事件时间处理，但在这个项目里属于杀鸡用牛刀，还会引入更多调试复杂度。更重要的是，Spark2 对 YARN 和 Standalone 两种部署模式的兼容性很好，课设环境里通常是一台 8G 内存的笔记本，Spark2 的默认参数就能跑起来，不像 Spark3 动辄要调一些新参数。
这套系统的数据流是「模拟日志生成器 → Kafka → Spark Streaming → Redis + MySQL → 可视化后端」。选择 Kafka 做中间缓冲是关键的，原因在于：如果让日志生成器直连 Spark Streaming，一旦消费者处理不过来，数据就会丢；Kafka 天然可以保存一定时长的数据，让生产者和消费者解耦。后面我测试的时候把批处理间隔从 2 秒改成 5 秒，Kafka 里的数据一条没丢，这就是缓冲层最大的价值。
2.2 组件版本组合：为什么这个组合最容易跑通
常见的做法是 Spark 2.4.x + Kafka 0.10.x 或 Kafka 2.x 搭配 spark-streaming-kafka-0-10 连接器。这套组合有几个好处：一方面，2.4 是 Spark2 系列的最终稳定版，bug 修复最全；另一方面，0-10 版本的接收器支持直接消费 Kafka 的 offset，不需要走老版本的 Receiver 模式，避免了不少 checkpoint 和事务上的坑。
Redis 和 MySQL 的分工要提前想清楚。实时榜单、今日 PV、当前在线数这类要求毫秒级响应的数据放 Redis，用 String 和 ZSet 两种数据结构就够；历史汇总、用户明细、维度报表落 MySQL，供可视化和后续离线分析用。这套系统在初始化时会自动建库建表，文档里也给了初始化脚本，省掉了很多手搓 SQL 的时间。
部署上，资源包内给的部署顺序是标准做法：先启动 Zookeeper、Kafka，再启动日志生成器确认数据进 Kafka，然后启动 Spark Streaming 应用，最后启动可视化后端。这个顺序每次都要严格遵守，后面避坑章我会详细说为什么顺序错了会有各种诡异现象。
2.3 源码目录结构：拿到手先盯这四个位置
我第一次拆这套源码的时候，先扫了一遍目录结构，发现代码组织得相当规整。建议你也按这个顺序来：
src/main/java ├── generator // 日志生成器，模拟新闻浏览行为 ├── streaming // Spark Streaming 消费与计算逻辑 ├── common // 工具类、常量、数据库连接池 ├── web // Spring Boot 后端接口 └── resources // 配置文件、初始化脚本generator包里的日志生成器值得先看，它决定了你后续所有计算的输入长什么样。streaming包是核心，DStream 的构建、窗口计算、Redis 写入都在这。web包则是可视化看板的数据接口层，前端请求过来之后从 Redis 和 MySQL 拿数据再组装成 JSON 返回。
文档操作步骤说明里我建议先翻到「环境准备」这一章，里面列了 JDK 1.8、Maven 3.x、Redis、MySQL 的具体安装命令。其中有一条容易被忽略：Kafka 的配置里要新增advertised.listeners，否则消费者在局域网内连不上 broker，这条我记得很清楚，因为第一次跑就直接栽在这里。
3. 把新闻浏览日志变成可计算的流：采集、清洗与窗口统计
3.1 模拟日志生成器：没有真实数据时怎么自造数据源
项目没有给你真实生产环境的日志，而是提供了一个日志生成器，这是课设项目里的常规做法，也是最稳妥的做法。生成器用 Java 实现，核心逻辑是每隔固定时间随机生成一条新闻浏览记录，字段包括用户 ID、新闻 ID、新闻分类（娱乐、体育、财经等）、浏览时长、时间戳、来源渠道（App 端、Web 端）。
核心代码如下，这是我从生成器里提取出来的简化版：
// GeneratorThread.java - 日志生成器核心线程 public class GeneratorThread implements Runnable { private static final Random random = new Random(); // 新闻分类池，模拟真实新闻 APP 的频道划分 private static final String[] CATEGORIES = {"娱乐", "体育", "财经", "科技", "军事", "教育"}; private static final String[] CHANNELS = {"App", "Web", "小程序"}; // KafkaProducer 配置由 resources/kafka.properties 读取 private KafkaProducer<String, String> producer; @Override public void run() { while (true) { // 随机生成一条浏览记录，JSON 格式输出 JSONObject log = new JSONObject(); log.put("user_id", "u_" + random.nextInt(10000)); log.put("news_id", "n_" + random.nextInt(5000)); log.put("category", CATEGORIES[random.nextInt(CATEGORIES.length)]); log.put("duration", 5 + random.nextInt(120)); // 浏览时长 5~124 秒 log.put("channel", CHANNELS[random.nextInt(CHANNELS.length)]); log.put("timestamp", System.currentTimeMillis() / 1000); // 发送到 Kafka topic: news-browse-log ProducerRecord<String, String> record = new ProducerRecord<>("news-browse-log", log.toString()); producer.send(record); // 每秒生成 5~20 条随机日志，模拟不同时段的流量波动 Thread.sleep(50 + random.nextInt(200)); } } }这段代码里的Timestamp字段用的是 Unix 时间戳（秒级），而不是字符串日期。这一点很重要，Spark Streaming 在做窗口切分时直接拿这个字段做结束时间判断，省去了字符串转时间戳的步骤。如果你自己改数据源，我建议也统一用秒级时间戳，否则后续要处理时区转换和 SimpleDateFormat 的坑。
随机间隔用了Thread.sleep(50 + random.nextInt(200))，也就是每秒生成大约 5 到 20 条数据。这个速率对于课设演示是合理的：数据量太小，窗口统计结果半天不动，演示效果差；数据量太大，笔记本可能扛不住。等你把整套链路跑通以后，可以把这个速率调高到每秒 200 条，顺便测试一下系统的吞吐上限，这也是答辩时的加分项。
3.2 DStream 消费与窗口计算：核心代码与参数调整
这是整个系统最核心的代码，你要看明白的不是语法，而是窗口参数之间的运算关系。我用一段去掉了细节的代码展示核心逻辑：
// NewsBrowseStreaming.scala - 实时统计入口 val sparkConf = new SparkConf().setAppName("NewsBrowseStreaming") .setMaster("local[2]") // 本地模式跑 2 个线程，一个跑 receiver，一个跑计算 val ssc = new StreamingContext(sparkConf, Seconds(2)) // 批处理间隔 2 秒 // 从 Kafka 消费日志，Topic 名为 news-browse-log val kafkaParams = Map[String, Object]( "bootstrap.servers" -> "localhost:9092", "key.deserializer" -> classOf[StringDeserializer], "value.deserializer" -> classOf[StringDeserializer], "group.id" -> "news-streaming-group", "auto.offset.reset" -> "latest", "enable.auto.commit" -> "false" ) val topics = Array("news-browse-log") val stream = KafkaUtils.createDirectStream[String, String]( ssc, LocationStrategies.PreferConsistent, ConsumerStrategies.Subscribe[String, String](topics, kafkaParams) ) // 转换：提取 (分类, 1) 用于 PV 统计 val pvDStream = stream.map(record -> { val json = JSON.parseObject(record.value()) (json.getString("category"), 1L) }) // 窗口：每 10 秒统计一次过去 60 秒内各分类的浏览量 val windowedPv = pvDStream.reduceByKeyAndWindow( (a: Long, b: Long) => a + b, // 窗口内累加 Seconds(60), // 窗口长度 Seconds(10) // 滑动间隔 )参数设置是最容易踩坑的地方。窗口长度 60 秒表示结果里统计的是过去一分钟内产生的数据，滑动间隔 10 秒表示每 10 秒输出一次结果。这里有个性能上的要点：窗口长度必须是批处理间隔的整数倍，滑动间隔也必须是批处理间隔的整数倍。上面批处理间隔是 2 秒，窗口长度 60 秒正好是 30 倍，滑动间隔 10 秒是 5 倍，没问题。
如果你有一个需求是「每 5 秒统计过去 30 秒的实时热点」，那参数就应该是reduceByKeyAndWindow(func, Seconds(30), Seconds(5))，批处理间隔可以保持 2 秒不变，因为 30 和 5 都能被 2 整除。如果改成窗口长度 90 秒而批处理间隔还是 2 秒，Spark 会直接报错，因为 90 不是 2 的整数倍。这个关系我记得特别清楚，之前帮人调试时见过窗口长度设成奇数导致任务无法启动的翻车现场。
UV 统计的逻辑和 PV 略有不同，核心是去重。DStream 里先提取出(分类, 用户ID)，然后在窗口内做distinct()再去统计数量，即对用户 ID 集合做去重后取大小：
// UV 统计：窗口内对用户 ID 去重后计数 val uvDStream = stream.map(record -> { val json = JSON.parseObject(record.value()) (json.getString("category"), json.getString("user_id")) }).window(Seconds(60), Seconds(10)) // 先开窗口，再在窗口内去重 val uvResult = uvDStream.transform(rdd -> { rdd.groupByKey() // 按分类分组，同组内是用户 ID 集合 .mapValues(ids -> ids.toSet.size) // 去重后求数量 })这里有个性能陷阱：groupByKey在窗口较大、用户量较大时会有数据倾斜风险，大量数据聚集到同一个分类下。但在这个课设规模下（每秒 5~20 条日志，用户池 1 万人），完全不是问题。如果你的场景要处理的是千万级的真实日志，那需要改成approxCountDistinct这类近似去重算法来保证性能，这属于进阶优化了。
3.3 结果写 Redis 与 MySQL：数据落地谁说了算
计算完的结果不能只留在内存里，可视化端要反复读取，所以必须落到存储。这套系统采用了双写策略：Redis 存实时榜单，MySQL 存全部明细汇总。
Redis 的写入逻辑我用了一段样例代码展示：
// RedisWriter.java - 将统计结果写入 Redis public class RedisWriter { private Jedis jedis = new Jedis("localhost", 6379); public void writePv(String category, long count) { // Key 示例：news:pv:财经，Value 为当前累计浏览量 // 这个 Key 设计决定了可视化端查询的方式 String key = "news:pv:" + category; jedis.set(key, String.valueOf(count)); } public void writeRank(List<CategoryCount> rankList) { String key = "news:rank"; // 用 ZSet 存储分类热度榜，member 是分类名，score 是浏览量 // ZSet 天然按分数排序，后端直接取出前 N 名就是热点排行 for (CategoryCount item : rankList) { jedis.zadd(key, item.count, item.category); } // 设置过期时间，防止旧数据积压 jedis.expire(key, 3600); } }Redis 的 Key 设计直接决定了可视化接口的查询复杂度。news:pv:财经这种平铺结构适合按分类精确查询，news:rank用 ZSet 存储排行榜数据是省力的做法——ZSet 的zrevrange命令可以直接取出分数最高的前 N 项，比在 MySQL 里做ORDER BY LIMIT快得多，对答辩时的实时性演示很有帮助。
MySQL 的写入口径和 Redis 不同。Redis 存的是一分钟窗口内的最新结果，MySQL 存的是按小时聚合的历史明细，因为窗口一变旧数据就要被清理，而历史趋势图需要持续的数据沉淀。格式化输出到 MySQL 的代码走的是 JDBC batch 写入，两个常用参数值得关注：rewriteBatchedStatements=true是必须开的，否则 batch 写入性能和逐条写入没区别；useServerPrepStmts=false则避免不必要的预编译开销。这两条没配置好，MySQL 写入在流量大的时候会成为新的瓶颈点。
4. 可视化端联动：大屏看板的数据接口与刷新逻辑
4.1 后端接口设计：前端拿到的是聚合后的结果
可视化部分采取的是「数据接口 + 图表渲染」的架构，后端是用 Spring Boot 2.x 搭的轻量级服务。接口的设计逻辑可以直接照抄：前端不直接访问 Redis，而是走后端封装好的 REST API。这样做的好处是把 Redis 的连接逻辑和数据结构隐藏在服务端，前端只关心 JSON 结构即可。
接口清单大致分为三类：第一类是实时总览接口，返回当前总 PV、总 UV、在线用户数；第二类是分类统计接口，返回各新闻分类的浏览量排行；第三类是趋势接口，返回最近 N 个时间点的流量变化曲线。这三类接口对应了大屏上最常见的三个区域。
实时总览接口的简化逻辑如下：
// RealtimeController.java - 实时看板接口 @RestController @RequestMapping("/api/realtime") public class RealtimeController { @Autowired private RedisTemplate<String, String> redisTemplate; // 返回当前实时总览数据，前端每 5 秒轮询一次 @GetMapping("/summary") public Map<String, Object> summary() { Map<String, Object> result = new HashMap<>(); // 从 Redis 中读取聚合计数值 // "news:total:pv" 由 Spark 作业在每批结束后更新 result.put("totalPv", redisTemplate.opsForValue().get("news:total:pv")); result.put("totalUv", redisTemplate.opsForValue().get("news:total:uv")); result.put("onlineUsers", redisTemplate.opsForValue().get("news:online")); return result; } // 返回分类热度排行 Top10，直接读 ZSet @GetMapping("/rank") public List<CategoryRank> rank() { // zrevrange news:rank 0 9 取出热度最高的 10 个分类 Set<String> topCategories = redisTemplate.opsForZSet() .reverseRange("news:rank", 0, 9); // 按顺序组装成列表返回 return buildRankList(topCategories); } }这个接口设计的核心思路是「读什么就返回什么」，服务端不做复杂聚合，所有聚合已经在 Spark 端完成。好处是接口响应时间稳定在毫秒级，前端轮询不会产生额外压力。关于数据一致性，需要理解的是：Redis 里的值是最新一批计算完成的结果，有一个批次间的天然延迟，但可视化大屏本来就是展示滚动数据，这点延迟完全在可接受范围内。
4.2 前端图表刷新：轮询模式是课设场景的最优解
前端可视化走的是 ECharts 图表渲染，几个面板分别是柱状图（分类排行）、折线图（流量趋势）、数字卡片（总 PV/UV）。刷新机制这里踩过一个重要的坑，我需要把当时的排查过程讲清楚。
项目文档里给的常见做法是前端用一个定时器每隔 5 秒向后端拉一次数据，属于轮询方案。还有一个方案是 WebSocket 长连接，服务端有更新就主动推送。我实际对比过两种方案：这个项目的场景下，轮询是更好的选择。原因一是每个接口的数据量只有几百字节，5 秒一次的请求开销可以忽略；原因二是轮询的实现和调试成本比 WebSocket 低很多，不用处理连接断开重连的问题，答辩时也少一个不稳定因素。
前端轮询核心代码如下：
// dashboard.js - 大屏数据刷新逻辑 function refreshData() { // 并行请求三个接口，避免串行等待 Promise.all([ fetch('/api/realtime/summary').then(res => res.json()), fetch('/api/realtime/rank').then(res => res.json()), fetch('/api/realtime/trend').then(res => res.json()) ]).then(([summary, rank, trend]) => { // 更新数字卡片 document.getElementById('totalPv').textContent = summary.totalPv; document.getElementById('totalUv').textContent = summary.totalUv; // 更新分类排行柱状图 rankChart.setOption({ xAxis: { data: rank.map(item => item.name) }, series: [{ data: rank.map(item => item.value) }] }); // 更新趋势折线图 trendChart.setOption({ series: [{ data: trend.points }] }); }); } // 每 5 秒刷新一次 setInterval(refreshData, 5000); // 页面加载后立即执行一次，避免首屏空白 refreshData();刷新间隔设为 5 秒，对应后端窗口统计的输出间隔 10 秒，这样一个刷新周期内必然能看到新数据。如果刷新间隔比计算间隔还短，两次刷新拿到的数据可能完全一样，演示时会显得系统「卡住了」。这个时间关系的对齐很容易被忽略，但影响演示观感很直接。
我一个比较具体的习惯是：调前端图表的时候，打开浏览器开发者工具看 Network 面板，关注每次轮询请求的响应时间。如果响应时间超过 1 秒，说明后端可能在做重计算，要回查接口逻辑；如果响应时间稳定在几十毫秒，那问题就出在别的地方。大屏「数据不动」的故障排查思路，后面避坑章还会继续展开。
4.3 部署顺序：每一步怎么验证是对的
部署部分我建议按照「基础设施 → 数据生产 → 计算 → 展示」的顺序走。我第一次是直接照着文档跑，结果乱成一锅粥，后来整理出一套带验证动作的部署流程，每一步确认无误再走下一步，效率反而最高。
第一步启动基础设施：先启动 Zookeeper，用jps确认 QuorumPeerMain 进程存在；再启动 Kafka，用kafka-topics.sh --list确认news-browse-log这个 topic 是否处于正常状态。topic 不存在时用命令手动创建：
# 创建新闻日志 topic，partition 设为 1，副本数为 1 kafka-topics.sh --create \ --bootstrap-server localhost:9092 \ --topic news-browse-log \ --partitions 1 \ --replication-factor 1partition 数在课设环境设 1 就够了，因为日志生成器的压力很小，多个 partition 反而引入跨分区数据乱序的问题。第二步启动日志生成器，然后用 Kafka 自带消费者命令观察数据是否正常进入 topic。这一步是最容易确认的验证点：
# 消费并打印 topic 中的原始数据，观察生成的日志格式 kafka-console-consumer.sh \ --bootstrap-server localhost:9092 \ --topic news-browse-log \ --from-beginning如果这里能看到一条条 JSON 数据滚动输出，说明数据源这一环没有问题了，故障范围缩小到消费端。第三步启动 Spark Streaming 应用，看控制台日志里是否出现「Batch: 1」以及后续处理完成的输出标志。第四步启动 Spring Boot 后端，最后打开浏览器访问可视化大屏。每一步的输出结果都对得上，整条链路才算真正稳定跑通。
5. 避坑与排查：Spark2 系统从跑通到答辩的血泪记录
5.1 Kafka 消费端一直拉不到数据：advertised.listeners 缺失导致
现象：日志生成器正常发送数据，用kafka-console-consumer.sh能消费到，但 Spark Streaming 应用启动后日志显示消费了 0 条记录，控制台一片安静。
原因：Kafka broker 的server.properties中没有配置advertised.listeners。在本地测试时，客户端通过localhost:9092连接 broker 没问题；但当客户端进程不在本机、或者连接串配置成了内网 IP 时，broker 内部的存储元数据里还是默认的主机名，客户端拿着这个地址去连接会失败，体现为接口无响应。Spark 应用位于同一个 Kafka 集群但进程独立，受这个问题影响最严重。
解决：在 Kafka 的server.properties中显式配置advertised.listeners=PLAINTEXT://localhost:9092，然后重启 Kafka。配置完成后用kafka-topics.sh --describe确认 broker 的广播地址已被正确更新。从那以后我只要见到配置文件里有 listen 相关项，都会顺手显式写出 advertised 那一行。
5.2 窗口统计结果神秘翻倍：reduceByKeyAndWindow 与批处理间隔倍数问题
现象：PV 统计数值明显比日志生成器实际产生的日志条数多，有时候是两倍，有时候是好几倍，但又找不出规律。
原因：窗口长度和批处理间隔没有保持整数倍关系。Spark Streaming 的窗口操作要求windowLength和slideInterval都必须是batchDuration的整数倍。如果窗口长度为 60 秒而批处理间隔是 2 秒，这个组合是合法倍数；但如果有人修改过窗口长度而忘了改批处理间隔，比如把窗口改成 65 秒，批处理间隔仍是 2 秒，Spark 会报错。而另一种情况更隐蔽：没有报错但计算结果重叠，是因为窗口内的数据与相邻窗口存在重叠，又没有做去重逻辑，同一个时间段内的数据被统计了两次。
解决：严格遵守「窗口长度和滑动间隔都是批处理间隔整数倍」这一条铁律，修改窗口参数时把三个值一起改。改完以后手动验证一组小数据，比如生成 20 条日志，窗口长度设 10 秒、输出间隔设 5 秒，确认统计结果精确等于 20 条。这类问题属于参数隐性问题，肉眼排查很难发现，必须从数值上做校验。
5.3 内存溢出频繁触发：local[1] 模式跑 Streaming 必然翻车
现象：Spark Streaming 应用跑一会儿就报java.lang.OutOfMemoryError，或者直接卡死无响应。
原因：setMaster("local[1]")是课设里最常见的错误写法。Streaming 模式下，一个线程既要跑 receiver 接收数据，又要跑批处理计算任务，两者互相抢占资源。数据接收不过来时会产生积压，时间一长内存就被占满。第二原因是没有设置 checkpoint 目录，窗口操作默认要在内存里保存中间状态，批处理间隔越小、状态保存时间越长，内存开销越大。
解决：至少用local[2]，一个线程处理接收、一个线程处理计算；条件允许的话local[4]更稳。同时要在代码里设置 checkpoint，ssc.checkpoint("hdfs://localhost:9000/checkpoint")或者本地目录都可以。如果数据量确实大，可以调大 Executor 内存，--executor-memory 2g起步。课设场景的数据量不大，这两个配置到位基本不会再触发 OOM。
5.4 趋势图出现空白断层：数据时间窗口边界对齐问题
现象：折线图每隔一段时间会出现「掉下去又弹回来」的形状，有时直接一段空白，看起来像数据丢了。
原因：日志生成器的时间戳是System.currentTimeMillis()当前时刻，但窗口统计框架是依据 DStream 批次的生成时间来切分的，而不是依据日志里字段包含的时间。在生成器刚启动时，由于日志的随机延迟，数据会被切到相邻的批次里，导致某个窗口统计到的数据只有正常值的一半左右。另外，如果曾经手动改过系统时间，或者容器时间未同步，就会出现更大范围的错位。
解决：检查日志时间戳和 Spark 处理端的时间基准是否一致。最直接的办法是在可视化趋势接口里对比「统计结果里的时间」和「系统当前时间」，相差超过一个窗口长度就要先解决时间基准问题。实际项目里我习惯让日志生成器使用与消费者完全一致的时间源，如果部署在单机上就用系统时间，避免跨机器时钟漂移问题。
5.5 大屏数据一直不动：Redis 里根本没更新的数据
现象：可视化界面正常打开，接口没有报错，图表也有数据，但数据始终是启动时的那一批。排查半天，代码逻辑看似都对，完全束手无策。
原因：Spark 作业和可视化后端连接的 Redis 库 ID 不一致。Redis 默认有 16 个数据库，如果 Spark 端写入用的是localhost:6379/0，而可视化后端读取用的是localhost:6379/1，两边互不相见，前端无论怎么刷新看到的都是同一个旧值。这个坑非常隐蔽，因为两边代码单独看都没有任何错误提示。
解决：检查两端 Redis 配置的database参数。我的做法是把连接串统一写到一个配置文件里，或者直接在代码中硬编码jedis.select(0)并在两边保持一致。想快速验证的话，用 Redis 命令行工具登录后keys news:*看一下当前库里的数据，再切换到另一库检查，就知道是不是这个问题了。
这几条是我完整跑一遍之后整理的踩坑记录，问题都从「现象 → 原因 → 解决」三个层面拆开，对照排查会比重新读源码快得多。
6. 把新闻日志换成你自己的数据源：用同一套链路验证系统通用性
资源包里给你的是新闻浏览日志的模拟数据，但整套架构完全可以换数据源跑，这一步值得你自己动手做一遍。换数据源的核心改三个地方：日志生成器、字段映射、可视化接口的取值逻辑。
先说最简单的换法：改造生成器。你把CATEGORIES从新闻分类换成别的业务维度，比如换成商品类目「手机数码、家用电器、服饰鞋包」，把news_id换成product_id，这就从新闻热度变成了商品热度。关键修改点在两个位置：GeneratorThread 里的 JSON 字段名需要跟着改，同时 Spark 端解析 JSON 的getString("category")、getString("news_id")等调用要保持一致。字段名不对是最容易出的问题，但报错信息往往不明显，只显示序列化失败。
第二个换法是直接换输入源。如果你的数据是 CS 或 Web 日志文件，可以写一个脚本把日志文件里的字段按固定格式推送到 Kafka，格式如下：
# 将日志文件按行读入，使用 kafka-console-producer 发送 cat /path/to/your/app.log | \ awk -F'\t' '{print "{\"user_id\":\""$1"\",\"category\":\""$2"\",\"timestamp\":"$3"}"}' | \ kafka-console-producer.sh --broker-list localhost:9092 --topic news-browse-log这里有一个很容易疏忽的问题：原始日志的字段分隔符、字段含义要先确认清楚，awk 的列索引对应错就会产生脏数据。我自己换过一次，当时用 tab 分隔结果原始日志里混着空格，解析出来大量空值，整个统计结果全是 0，花了一晚上排查才意识到是分隔符的锅。
第三个换法更适合答辩场景：把统计维度从「分类」推广到「用户偏好画像」。保持架构不变，把category换成user_level（用户等级）、channel（来源渠道）等维度，前端接口增加一组查询参数来控制按哪个维度统计。这不算改架构，只是在原有基础上加映射关系，但演示效果会明显增强，因为评委看到的是「这套系统不仅能做新闻热度，还能灵活切换到不同维度」，这比单纯的功能堆砌更有说服力。
验证换源是否成功，有一个实用的检查清单：前提是日志生成器输出格式正常、Kafka 能消费到数据、控制台能看到百分比进度。然后依次检查：Spark 输出到 Redis 的 Key 前缀是否已更新、可视化接口的查询逻辑是否匹配新 Key、大屏上是否出现新增维度的数据。三个不动就说明链路哪里接错了，按第 5 章的排查表按图索骥即可。
这套系统截至目前我前后跑过三遍，每次换数据源或者调窗口参数，都会强制把「生成器 → Kafka → Spark → Redis/MySQL → 可视化」这五段日志从头到尾过一遍。第 5 章里那些坑，几乎都是在换源的过程中踩到又填平的。现在每跑一遍，我更倾向于把验证过程写成脚本而不是原地看日志，虽然一开始会慢一些，但后续调试效率是肉眼可见的提升。希望这篇拆解能帮你把这套源码真正吃透，祝你一次跑通、答辩顺利。
本文还有配套的精品资源，点击获取
