简介基于Spark2.x的新闻网大数据实时分析可视化系统项目是面向大数据方向毕业设计及实战学习的完整工程包覆盖新闻数据从采集、清洗、分析到可视化展示的全链路开发过程。压缩包内共35个文件整体约3.43MB包含10个JAR依赖包、7个Scala源文件、6个Java源文件另有PNG效果图、JS与XML前端配置以及部署文档与参考步骤目录结构清晰便于按模块定位。源码实现了文本挖掘、情感分析、主题模型等常用算法借助Spark的RDD与流处理能力对新闻数据进行分布式计算并将结果以图表形式直观呈现。部署文档详细说明了软硬件准备、安装配置与运行流程同时附带全部数据资料能够支持读者从零复现整个实时分析系统。该项目适用于媒体舆情监控、市场分析等实际场景尤其适合用作毕业设计蓝本或大数据实时分析入门的综合案例目前已有45人学习下载对于需要参考完整工程结构与快速搭建原型的学习者具有很高参考价值。1. 基于Spark2.x的新闻网大数据实时分析一份能跑通的毕业设计源码如果你正在找大数据方向的毕业设计参考或者想快速搭一套“数据采集 → 实时分析 → 可视化大屏”的完整链路这份基于 Spark2.x 的新闻网大数据实时分析可视化系统源码会是非常合适的切入点。它不是那种只贴几个类文件、缺胳膊少腿的课程设计而是把 Flume、HBase、Spark Streaming、ECharts 可视化这条完整链路都串起来了还附带部署文档和可以导入的新闻日志数据。整套系统解决的典型问题是新闻网站的访问日志产生后如何实时统计出热点新闻、用户地域分布、访问趋势等指标并以可视化的方式呈现出来。对准备答辩的学生或者想抄作业的工程师而言它的价值在于——技术栈主流、代码量适中、能跑出可视化大屏的效果对新手而言最大的门槛反而不在 Spark 本身而在 Flume 自定义 Sink 和 HBase RowKey 设计这两个细节上。2. 系统架构与技术选型为什么是 Flume Kafka Spark Streaming HBase2.1 整体数据流向从日志埋点到前端大屏拿到源码后先别急着打开 IDE先把数据流向搞清楚。这套系统的标准链路是新闻网站的前端页面埋点产生访问日志 → Flume 监听日志目录采集数据 → 通过自定义的 HBase Sink 将解析后的结构化数据直接写入 HBase 表 → Spark Streaming 从 HBase 中拉取新增数据做实时计算窗口统计、TopN→ 计算结果写入 Redis 或 MySQL → Spring Boot 提供 HTTP 接口 → 前端 ECharts 定时轮询接口渲染大屏。这个链路的一个关键设计是实时计算的数据源不是 Kafka而是直接读 HBase这意味着你在部署时需要先启动 HBase再启动 Spark Streaming 任务否则任务会因为连接不到 HBase 而直接失败。源码里flume_hbase目录下的自定义 Serializer 是连接 Flume 和 HBase 的桥梁weblogs目录存放的是原始日志样例src目录包含了 Spark Streaming 任务和前端可视化模块。2.2 为什么 Spark2.x HBase 这个组合仍然适合做毕设很多人会问2024 年了为什么还要选 Spark2.x原因很实际——毕业设计要的不是新技术而是“能讲清楚原理、能跑出结果、能有创新点”。Spark2.x 的 Structured Streaming 虽然不如 Spark3.x 的 Delta Lake 那么时髦但它的 RDD 和 DStream API 更容易被答辩老师理解而且社区资料最多遇到问题几乎都能搜到解决方案。HBase 作为列式存储数据库特别适合存储新闻日志这种稀疏、多版本、按 RowKey 查询的场景。相比 MySQL 存储日志HBase 的写入吞吐量要高一个数量级这也是生产环境的选择。源码中的pom.xml文件定义了关键依赖版本Spark 2.4.x、HBase 1.4.x、Flume 1.8.x这些版本在 CDH 5.x / 6.x 集群上可以直接跑不需要做兼容性适配。如果你用的是 Apache 原生 Hadoop 3.x 环境需要注意 HBase 1.4 和 Hadoop 3 的兼容性问题建议直接用 CDH 6.3.2 或者自己用 Docker 搭一套 HDP 环境。2.3 Flume 自定义 Sink 的工作原理flume_hbase目录下的KfkAsyncHbaseEventSerializer.java和SimpleHbaseEventSerializer.java是这套系统里最有技术含量的部分。Flume 的 HBase Sink 默认使用SimpleHbaseEventSerializer它会把 Event 的 body 整体作为一个 column value 写入 HBase这对我们来说完全不可用因为我们希望把一条日志解析成多个字段时间、IP、URL、状态码等分别存到不同列。自定义 Serializer 的作用就是重写getActions()方法返回一个Put列表每个 Put 对应 HBase 中的一行。// 自定义 Serializer 的核心逻辑摘自 KfkAsyncHbaseEventSerializer.java Override public ListPut getActions() { ListPut puts new ArrayList(); // 1. 解析 Flume Event 的 body是一行原始日志 String body new String(event.getBody(), StandardCharsets.UTF_8); // 2. 按分隔符切割字段 String[] fields body.split(,); if (fields.length 6) { return puts; // 字段不够的脏数据直接丢弃 } // 3. 生成 RowKey这里采用时间戳反转 随机数避免热点 String rowKey SimpleRowKeyGenerator.generateRowKey(fields[0], fields[1]); Put put new Put(Bytes.toBytes(rowKey)); // 4. 把字段逐列写入 cf:info 列族 put.addColumn(Bytes.toBytes(cf), Bytes.toBytes(ip), Bytes.toBytes(fields[0])); put.addColumn(Bytes.toBytes(cf), Bytes.toBytes(time), Bytes.toBytes(fields[1])); put.addColumn(Bytes.toBytes(cf), Bytes.toBytes(url), Bytes.toBytes(fields[2])); put.addColumn(Bytes.toBytes(cf), Bytes.toBytes(status), Bytes.toBytes(fields[3])); puts.add(put); return puts; }这段代码里最关键的是SimpleRowKeyGenerator.generateRowKey()方法如果 RowKey 设计不合理HBase 的数据会分布不均匀导致某些 RegionServer 压力过大出现数据倾斜。常见的 RowKey 设计是“倒序时间戳 MD5 哈希前缀”这样做的好处是新数据能分散到不同 Region避免顺序写造成单 Region 热点。源码中的SimpleRowKeyGenerator实现比较简单但足够教学用。2.4 HBase 表结构设计与建表语句配套的部署文档中给出了建表语句这里我直接摘录核心部分# 在 HBase Shell 中执行 create news_log, {NAME cf, VERSIONS 1, COMPRESSION SNAPPY}参数说明news_log是表名cf是列族名VERSIONS设为 1 表示只保留最新版本COMPRESSION使用 Snappy 压缩可以节省约 60% 的存储空间。如果你的集群没有安装 Snappy可以去掉这个参数但生产环境建议保留。这张表存储的是原始日志数据Spark Streaming 都是从这个表里 Scan 增量数据的。3. 核心模块实战Spark Streaming 实时统计的完整实现3.1 从 HBase 拉取增量数据的设计思路Spark Streaming 从 HBase 读数据有几种常见做法一是直接new HBaseRDD通过TableInputFormat全表扫描二是维护一个偏移量Offset每次只 Scan 上次处理到的位置之后的新数据。本项目的做法是第二种——利用 HBase 的 RowKey 有序性记录上次处理到的 RowKey 位置每次 Scan 从这个位置开始取数据。这样避免了对全表的重复扫描效率更高。// Spark Streaming 核心代码从 HBase 增量拉取数据 JavaDStreamString logDStream ssc.receiverStream(new HBaseReceiver(zkQuorum, tableName)); logDStream.foreachRDD((rdd, time) - { // 1. 记录本次批处理开始的 RowKey 位置 String lastRowKey getOffsetFromRedis(); // 2. 创建 HBase Scan 对象设置起始 RowKey Scan scan new Scan(); scan.setStartRow(Bytes.toBytes(lastRowKey)); scan.setCaching(500); // 每次 RPC 拉取 500 行 // 3. 通过 HBaseContext 执行 Scan JavaPairRDDImmutableBytesWritable, Result hBaseRDD hbaseContext.hbaseRDD( TableInputFormat.class, scan, NewsLogMapper.class); // 4. 解析 Result 为新闻日志对象 JavaRDDNewsLog newsLogRDD hBaseRDD.map(tuple - parseResult(tuple._2)); // 5. 执行统计计算 ... });这里的HBaseReceiver是源码中自定义的 Receiver它的作用是周期性从 HBase 拉取新数据并交给 Spark Streaming 处理。scan.setCaching(500)参数很关键如果设置太小比如默认的 100Scan 大表时会频繁发生 RPC性能会大幅下降如果设置太大比如 10000又可能导致 RegionServer 内存溢出。500 是一个比较稳妥的中间值。3.2 窗口统计与 TopN 计算批处理间隔与窗口长度的权衡实时统计的核心需求有两个一是统计最近 5 分钟的新闻访问 TopN二是统计每个小时的访问量趋势。前者的实现用到了 Spark Streaming 的窗口操作窗口长度定为 300 秒滑动间隔定为 30 秒——这意味着每 30 秒会计算一次最近 5 分钟的数据。// 窗口统计 TopN 新闻摘自 sparkStu 模块 JavaDStreamNewsLog windowedStream newsLogDStream.window( Durations.seconds(300), // 窗口长度 5 分钟 Durations.seconds(30) // 滑动间隔 30 秒 ); JavaPairDStreamString, Long newsCounts windowedStream .mapToPair(log - new Tuple2(log.getNewsId(), 1L)) .reduceByKey(Long::sum); // 取 Top10 热门新闻 newsCounts.transformToPair(rdd - rdd.sortByKey(false)).top(10);窗口长度和滑动间隔的比例决定了计算的实时性和计算成本的平衡。窗口越长统计结果越平滑但对内存的占用也越大因为 Spark 需要缓存窗口内的所有数据。这里滑动间隔 30 秒是依据业务场景选的——新闻访问量的变化通常以分钟为单位30 秒的刷新频率已经能覆盖大屏的视觉需求也让计算任务不至于密集到压垮集群。3.3 可视化大屏ECharts 动态数据对接实现可视化的实现在src/main/webapp目录下前端用的是 ECharts 3.x后端是一个 Spring Boot 服务提供/api/hotNews、/api/trend等接口返回 JSON 数据。前端通过setInterval每 30 秒请求一次接口更新图表。一个比较典型的实现是新闻词云图它需要将统计结果按热度排序后映射成词云需要的{name, value}格式。// 前端词云图数据刷新逻辑 function fetchHotNews() { $.ajax({ url: /api/hotNews, type: GET, dataType: json, success: function (data) { // 将后端返回的 TopN 新闻列表转成词云格式 var wordCloudData data.map(function (item, index) { return { name: item.title, value: item.count * (10 - index) // 权重递减突出第一名 }; }); myChart.setOption({ series: [{ type: wordCloud, data: wordCloudData }] }); }, error: function () { console.error(获取热点新闻失败); } }); } // 每 30 秒刷新一次与 Spark Streaming 的滑动间隔保持一致 setInterval(fetchHotNews, 30000);value: item.count * (10 - index)这行做了权重衰减避免第一名新闻的词云字重过大导致画面失衡。这个细节可以在答辩时讲成“对展示效果做了加权处理”是加分项。如果你的前端没有wordCloud系列别忘了引入echarts-wordcloud.min.js插件这个在部署文档里有说明。4. 完整部署流程从零开始跑起这份源码的十二个关键步骤4.1 环境准备版本选择与集群搭建在动手部署之前先对齐环境版本。这份源码是针对 CDH 5.x 设计的但经过实测在 Apache 原生环境下也能跑通前提是版本要匹配Spark 2.4.0、HBase 1.4.0、Flume 1.8.0、ZooKeeper 3.4.10、JDK 1.8。如果你的机器内存只有 8G建议用伪分布式模式部署即所有组件都在一台机器上每个组件使用独立端口内存 16G 以上可以搭建一个 3 节点的集群namenode 和 resourcemanager 放在一台机器上其余两台做 DataNode 和 RegionServer。这里有一个容易踩坑的地方HBase 1.4 版本的hbase-env.sh中默认不配置HBASE_CLASSPATH但 Spark Streaming 连接 HBase 时需要把 HBase 的hbase-site.xml和所有依赖 jar 放到 Spark 的 classpath 下。如果你在本地跑 Spark 任务连接远程 HBase必须在 Spark 任务的--jars参数中显式带上 HBase 客户端 jar 包否则会报NoClassDefFoundError。# Spark 任务提交命令伪分布式模式 spark-submit \ --class com.news.spark.NewsStreamingApp \ --master local[2] \ --jars hbase-client-1.4.0.jar,hbase-common-1.4.0.jar,hbase-server-1.4.0.jar,hbase-protocol-1.4.0.jar,htrace-core-3.2.0.jar \ --driver-java-options -Dlog4j.configurationfile:./log4j.properties \ news-spark-1.0.jar \ zk1:2181 news_log 60参数说明local[2]表示本地模式用 2 个线程跑--jars后跟 HBase 相关的客户端 jarzk1:2181是 ZooKeeper 地址news_log是要消费的 HBase 表名最后的60是批处理间隔秒。4.2 配置 Flume自定义 Sink 的部署细节Flume 的配置文件是整个链路中最容易出错的地方。源码目录下的flume_hbase文件夹里已经打好了flume-ng-hbase-sink.jar你需要把这个 jar 以及它的依赖比如hbase-client.jar、htrace-core.jar复制到 Flume 的lib目录下。然后编写flume-hbase.conf# Flume Agent 配置监听日志目录 - HBase Sink agent.sources logdir agent.channels ch agent.sinks hbaseSink # 1. 监听日志目录 agent.sources.logdir.type spooldir agent.sources.logdir.spoolDir /var/log/news agent.sources.logdir.fileSuffix .COMPLETED agent.sources.logdir.deletePolicy IMMEDIATE agent.sources.logdir.ignorePattern ^\\.\\S$ # 2. Channel 使用内存队列 agent.channels.ch.type memory agent.channels.ch.capacity 10000 agent.channels.ch.transactionCapacity 5000 # 3. 自定义 HBase Sink agent.sinks.hbaseSink.type hbase agent.sinks.hbaseSink.table news_log agent.sinks.hbaseSink.columnFamily cf agent.sinks.hbaseSink.serializer com.news.flume.KfkAsyncHbaseEventSerializer agent.sinks.hbaseSink.serializer.charset UTF-8 agent.sinks.hbaseSink.batchSize 500 agent.sinks.hbaseSink.znodeParent /hbase agent.sinks.hbaseSink.zookeeperQuorum zk1:2181这里的deletePolicy IMMEDIATE表示 Flume 读完之后立即删除日志源文件如果你希望保留原始日志做离线分析可以改为IMMEDIATE之外的策略比如NEVER。batchSize设为 500 是一个适合教学环境的中间值——太大如 2000会导致 Flume 事务超时太小如 100则写入 HBase 的吞吐量上不去。启动 Flume 命令bin/flume-ng agent \ --conf conf \ --conf-file conf/flume-hbase.conf \ --name agent \ -Dflume.root.loggerINFO,console启动后重点观察日志中有没有HBaseSink: Wrote X events的输出如果没有说明数据没有进入 HBase需要检查spoolDir目录下是否有日志文件以及 HBase 表是否存在。4.3 验证数据HBase Shell 查询与前端可视化联调数据写入 HBase 后可以用 HBase Shell 验证# 进入 HBase Shell scan news_log, {LIMIT 10}如果能从终端里看到 10 行数据说明链路已经通了。接下来启动后端 Spring Boot 服务再打开浏览器访问前端页面。正常情况下你应该能看到基于 ECharts 的地图、折线图和词云图。如果前端有数据但图表不显示优先检查浏览器的 Console 网络请求——看看/api/trend接口返回的 JSON 数据结构是否和前端解析用的字段名一致。这是前后端联调最常见的问题很多人拿到源码后直接部署发现前端报Cannot read property length of undefined就是字段名对不上。5. 部署与运行避坑指南这五个问题能劝退 80% 的人5.1 Flume 启动后不采集数据日志只输出到控制台现象Flume 进程正常启动但 HBase 表里始终没有数据终端日志也没有任何 Event 写入记录。原因spooldir的spoolDir目录配置不对或者 Flume 进程没有该目录的读写权限。还有一个隐藏问题——如果你在spoolDir目录下直接复制一个文件进去Flume 能识别但如果文件正在被写入文件名的后缀不是.COMPLETEDFlume 会认为文件还在传输中不会去读。解决先用chmod 777确保目录权限再把日志文件放进去观察 Flume 控制台输出。如果日志文件非常大超过 100MBFlume 需要完整读完才开始下一批此时不要用tail -f去写同一个文件Flume 的spooldir对正在写的文件是无能为力的。5.2 Spark Streaming 启动后报Connection refused错误现象Spark 任务提交后运行几秒钟就报java.net.ConnectException: Connection refused指向某个 HBase RegionServer 的端口。原因这不是网络不通而是 HBase 的 RegionServer 因为内存不足自动退出了。当你的机器内存只有 4GB 时NameNode、DataNode、HMaster、RegionServer、Spark 任务一起跑HBase 会被系统 OOM Killer 杀掉。解决调大虚拟内存或减少 HBase 堆内存设置。在hbase-env.sh中把HBASE_HEAPSIZE从默认的 1GB 调到 512MB同时确认hbase-site.xml中hbase.regionserver.global.memstore.size不要超过 0.4给 Spark 留出内存空间。5.3 HBase 表数据倾斜热点 Region 导致写入性能骤降现象运行一段时间后发现 HBase 的某个 RegionServer CPU 使用率明显高于其他节点写入吞吐量下降。原因SimpleRowKeyGenerator使用时间戳直接作为 RowKey 前缀同一秒内的所有日志都落在同一个 Region形成写热点。解决换用带随机前缀的 RowKey源码中虽然给了SimpleRowKeyGenerator但你可以改造它把System.currentTimeMillis()进行哈希取模后拼到 RowKey 的前四位这样数据就能均匀分布到 16 个 Region 上。5.4 前端可视化的地图区域无法显示现象词云图和折线图都能正常渲染但中国地图的省份区域是空白。原因ECharts 3.x 的地图数据是异步加载的需要引入china.js地图数据文件。很多人只引入了echarts.min.js忘了引入china.js。解决确认webapp/static/js目录下有china.js且在 HTML 中先引用echarts.min.js再引用china.js顺序反了会直接报错。如果部署时把前端和后端放在了不同域名下还需要在 ECharts 的geo组件中配置map: china并确保地图数据已全局注册。5.5 Spark Streaming 任务停留在 WAITING 状态不消费数据现象提交 Spark 任务后Spark Web UI 能看到任务在运行但没有任何数据处理日志输出HBase 中的数据量也不增长。原因自定义的 HBase Receiver 是阻塞式的它一直在等待 HBase 有新的数据返回。如果你没有往 HBase 写入新数据它就一直空转还有一种可能是scan.setStartRow设置的位置已经超过了当前数据的最大值导致每次 Scan 都取不到数据。解决先确认 HBase 表里有没有数据用 HBase Shell 查再检查 Redis 中记录的 lastRowKey 是否异常。可以在启动任务前把 Redis 中的 lastRowKey 清空让它从头开始扫描验证数据量是否增长。6. 把项目改成自己的毕业设计RowKey 优化与多维度分析的进阶技巧很多学生拿到的这份源码能跑通但答辩时被问到“你做了什么改进”就哑口无言。下面分享三个最实用的改造方向不需要大改代码但能让你的项目从“运行成功”提升到“有设计亮点”。6.1 改造 RowKey用哈希散列解决数据热点问题源码自带的SimpleRowKeyGenerator太简单了直接用时间戳做 RowKey这在生产环境会出大问题。改造的思路是把 RowKey 设计成三段式哈希前缀 时间戳 随机数。哈希前缀可以由用户 ID 或 URL 哈希取模得到比如Math.abs(url.hashCode() % 16)这样做的好处是数据会均匀分散到 16 个分区写入吞吐量能提升好几倍。public static String generateRowKey(String url, String time) { // 1. 对 URL 取哈希并映射到 0-15 范围作为前缀 int hashPrefix Math.abs(url.hashCode() % 16); // 2. 保留原始时间戳用于 Range Scan 时按时间过滤 String reverseTime new StringBuilder(time).reverse().toString(); // 3. 拼接三段中间用下划线分隔 String rowKey hashPrefix _ reverseTime _ ThreadLocalRandom.current().nextInt(1000); return rowKey; }改造后HBase 的写入压力被分散到 16 个 Region不会再出现单点热点。与此同时你需要调整 Spark Streaming 的 Scan 逻辑把setStartRow的起始位置从原来的“按时间戳顺序”改为“按哈希前缀遍历 0-15”否则数据会漏读。6.2 增加维度分析接入 Redis 存储 PV/UV 统计结果原始版本只统计了 TopN 新闻和访问趋势如果能在答辩时展示出 PV/UV 的实时计算结果会更有说服力。Spark Streaming 的mapWithState函数非常适合做 UV 去重统计它能在状态中维护每个用户上次的访问记录并对超时状态自动清理。// 使用 mapWithState 实现 UV 统计 JavaMapWithStateDStreamString, String, Long, Tuple2String, Long uvStateStream accessStream.mapToPair(log - new Tuple2(log.getUserId(), log.getTime())) .mapWithState(StateSpec.function((userId, time, state) - { // 第一次访问则计数加 1 if (state.exists() state.get() 0) { return new Tuple2(userId, state.get()); } else { state.update(state.get() 1); return new Tuple2(userId, state.get()); } }).timeout(Durations.seconds(1800))); // 30 分钟超时统计结果写入 Redis 的ZSET中前端展示时就多了一个“实时在线人数”的指标。6.3 性能调优参数让你的任务在集群上跑得更稳最后给出三个我在多次复现中验证过的参数推荐值。一是 Spark Streaming 批处理间隔不要低于 30 秒除非你有专门的流处理集群否则 10 秒甚至更短的批处理间隔会让 HBase 的 Scan 成为瓶颈二是spark.streaming.kafka.maxRatePerPartition虽然在本项目中不直接生效因为不是读 Kafka但如果你后续接入了 Kafka这个参数一定要设置防止消费速度超过下游分析速度三是 HBase 的hbase.client.scanner.caching建议设为 500这个参数控制每个 RegionServer 每次 RPC 返回给客户端的行数太大会导致客户端内存溢出太小又会让 Scan 变慢四是提交 Spark 任务时务必加上--conf spark.serializerorg.apache.spark.serializer.KryoSerializer可以让结果数据的序列化体积缩小到 Java 默认序列化的 1/10 左右。从那以后我每次拿到这类带自定义 Sink 的 Spark 项目都强制走一遍“先看配置文件再跑通链路最后改源码”的流程先确认 Flume 配置文件里的表和列族名是否和 HBase 中一致再用几条测试日志跑通端到端链路最后才去阅读和修改源码逻辑。这个习惯帮我避开了很多“代码看起来没问题但就是跑不出数据”的坑。希望这次的拆解能帮你把这份源码真正跑起来也能在答辩时讲清每个环节的设计取舍。本文还有配套的精品资源点击获取