写这个题目的经验我其实积攒了不少。每年到毕设季总会有学生拿着基于SpringBoot大数据技术的诗词信息系统这类题目来问我说看了半天不知道从哪下手担心大数据组件太重跑不起来又怕业务系统写得太浅撑不起大数据这三个字。今天就把我从选题、架构到编码、排错、答辩的完整思路捋一遍给准备做类似题目的同学一个可以直接参考的路线。这个项目的核心词是基于SpringBoot大数据技术按毕设标准看它属于典型的业务系统数据分析复合型题目SpringBoot负责网站业务Hadoop/Spark这类组件负责数据采集、清洗、分析和可视化。诗词这个领域选得其实很聪明——数据公开、结构丰富、分析维度多而且做出来的可视化大屏很有辨识度评委基本都会多看一眼。1. 为什么我推荐把诗词信息系统当大数据毕设选题1.1 大数据毕设的常见误区很多学生对大数据毕设的第一反应是要搭一个几十台机器的集群不然不好意思叫大数据。这是个认知偏差。本科阶段的毕设评委真正考察的是你有没有走通数据采集—数据清洗—分布式存储—离线分析—可视化展示这条完整链路而不是看你的节点数量。我见过不少学生把时间全花在搭环境上三台虚拟机起Hadoop集群内存16G的笔记本跑得风扇狂转结果业务系统没怎么写最后答辩时能展示的东西很少。反过来有人用单机伪分布式模式配合Spark本地模式把重点放在分析出了什么结论和系统能不能用上反而拿了高分。所以做这类题目第一件事是摆正心态大数据毕设的关键词是链路完整和分析有价值不是集群规模大。1.2 诗词数据为什么适合做分析诗词信息系统的数据基础天然适合大数据技术发挥。全唐诗收录了近5万首宋词也有两万多首加上元曲、诗经、乐府等公开可获取的诗词数据轻松超过10万条。这个量级用MySQL直接查询也能跑但一旦涉及全量词频统计、情感分析、风格聚类这类计算传统的单机SQL处理起来就很吃力了这正是Spark可以登场的地方。更重要的是每首诗词都带有丰富的结构化字段朝代、作者、体裁、词牌、标题、正文。这就意味着你可以做历朝历代的诗词数量趋势分析可以做高频意象统计月风酒花这些字在哪个朝代出现得最多可以做李白和杜甫的风格对比甚至可以做基于情感词典的诗词情感倾向分析。这些分析结果随便拿出几个都能让大屏内容丰富起来论文的第七章系统测试也有的写。1.3 选这个题目的实际性价比和做电商数据分析、舆情分析这类题目相比诗词系统的优势在于数据不用花时间造也基本不涉及隐私合规问题。你不需要模拟用户点击流不需要从零伪造订单数据网上的公开诗词数据集拿过来就可以用。对比一下电商数据分析的难点在于数据造假痕迹重、分析维度雷同舆情分析则需要持续采集实时数据做起来很累。诗词系统则是数据现成、分析有趣、可视化漂亮属于性价比很高的选择。当然它也有短板——业务系统如果只做单纯的诗词浏览和搜索功能上会显得单薄。所以我的建议是无论如何都要加上用户收藏笔记批注这类交互功能让系统不是只有一个展示壳子。2. 整体架构设计SpringBoot 与大数据组件的分工边界2.1 技术选型清单与职责划分整个系统我推荐的分层方式是SpringBoot 管业务Hadoop 体系管数据MySQL 既存业务数据也存分析结果ECharts 做可视化。具体分工如下表层次技术组件承担职责前端展示Vue / Thymeleaf ECharts页面渲染、数据可视化大屏业务接口SpringBoot MyBatis-Plus用户管理、诗词检索、收藏笔记、统计接口业务存储MySQL Redis可选用户数据、业务数据、统计分析结果缓存数据存储HDFS存储采集到的原始诗词数据和清洗后的数据离线计算Spark或 Spark Hive词频统计、朝代分布、情感分析、作者对比数据采集Python / HttpClient Jsoup爬取公开诗词数据写入 HDFS有一个细节值得注意SpringBoot 和 Spark 在职责上要严格分开。SpringBoot 只读取 MySQL 里的分析结果不直接去读 HDFS也不在业务请求里跑 Spark 任务。这样做的原因很简单——Spark 任务的启动和计算耗时通常在秒级甚至分钟级如果每次用户请求都触发一次 Spark Job系统的并发能力会非常差而且业务链路会被拖死。2.2 数据流向一条链路串起所有组件我习惯把整个系统理解成一条单向数据管道爬虫或开源数据集拿到的原始 JSON/CSV 先做一轮清洗和结构化清洗后的数据存两份一份进 HDFS 作为大数据分析的原始数据一份解析后写入 MySQL 作为业务系统的诗词表Spark 定时任务读取 HDFS 数据执行统计分析把结果写回 MySQL 的统计结果表SpringBoot 提供统计查询接口从 MySQL 读取分析结果返回给前端ECharts 大屏通过接口拿到数据渲染成图表。这套流程最大的好处是边界清晰每个组件只干自己擅长的事。MySQL 管事务HDFS 管大批量文件存储Spark 管分布式计算SpringBoot 管接口和业务逻辑。哪个环节出了问题排查范围都很小。2.3 为什么保留 MySQL 而不是全部用 Hive 存这是个很实际的问题。既然用了大数据组件为什么不索性连业务数据都放进 Hive 或 HBase毕设场景下我强烈不建议这么做。原因是你的业务系统里有大量高频、小粒度的操作——用户登录、查询一首诗、保存一条笔记这些操作对响应时间要求在毫秒级。Hive 底层是 MapReduce查询延迟很高根本不适合承担在线业务HBase 虽然查询快但需要额外的集群资源和运维成本。MySQL 是最稳妥的选择而且 MyBatis-Plus 做 CRUD 的效率远高于操作 Hive。大数据体现在分析环节就好了不要为了用技术而用技术这个原则在答辩时也可以明确讲给评委听。3. 数据采集与清洗从爬取到入库的完整链路3.1 数据来源先找开源数据集再决定要不要爬虫我建议优先使用 GitHub 上现成的开源中文诗词数据集比如 chinese-poetry 这类项目里面已经按朝代、作者整理好了 JSON 格式的诗词下载下来就能用。这样做至少有三个好处数据质量有保障字段齐全不需要费太多功夫去解析乱七八糟的 HTML不用承担爬虫可能带来的访问频率、内容版权等方面的麻烦节省下来的时间可以用到更有价值的功能开发和分析上。如果导师要求必须体现数据采集过程或者你确实想展示爬虫能力那就自己写一个爬虫作为补充。技术栈有两种选择纯 Java 用 HttpClient Jsoup或者用 Python 的 Requests BeautifulSoup。前者和项目主体语言统一后者更简洁。考虑到数据清洗和后续处理大概率会用到 Python 的 jieba 分词我建议采集环节也直接用 Python一条链走通。3.2 爬虫采集的合理姿势爬虫代码本身不复杂关键是要克制。我见过有人用高并发多线程去爬一个静态网站结果IP被封数据没拿到还浪费时间。正确的做法是控制频率加适当延时设置合理的 User-Agent先爬少量页面验证解析逻辑再批量执行。一个简单的示例逻辑如下import requests from bs4 import BeautifulSoup import json import time base_url https://example.com/poems?page headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) } poems [] for page in range(1, 101): resp requests.get(base_url str(page), headersheaders, timeout10) soup BeautifulSoup(resp.text, html.parser) for item in soup.select(.poem-item): poems.append({ title: item.select_one(.title).text.strip(), author: item.select_one(.author).text.strip(), dynasty: item.select_one(.dynasty).text.strip(), content: item.select_one(.content).text.strip() }) time.sleep(1) with open(poems_raw.json, w, encodingutf-8) as f: json.dump(poems, f, ensure_asciiFalse, indent2)这里只是演示结构实际网站的选择器要根据页面结构调整。数据落地之后一定要抽样检查几个样本确认没有乱码、没有解析错位再进入清洗环节。3.3 清洗规则去重、补全、统一编码原始数据不管来自开源项目还是爬虫都不可能直接入 HDFS必须先清洗。我的清洗规则一般包含以下几项去空白和不可见字符正文中混入的换行、空格要统一处理比如把连续多个空格合并成一个繁体转简体很多数据源是繁体字为了后续检索和分析统一需要做转换Python 的 opencc 库可以很好地完成这件事去重基于标题作者内容哈希做全量去重避免同一首诗在数据源里出现两次字段结构化统一朝代、作者、体裁字段的格式比如把唐代唐唐朝统一成唐异常值过滤正文过短少于10个字的记录直接丢弃这类多半是解析错误产生的碎片。处理完的干净数据我建议每行一条 JSON 的形式存储因为后续 Spark 读取 JSON 比 CSV 更灵活不用关心字段顺序。示例格式如下{title:静夜思,author:李白,dynasty:唐,genre:五言绝句,content:床前明月光疑是地上霜。举头望明月低头思故乡。}清洗代码最好和采集代码分开独立成脚本在论文里也可以单独作为一个小节描述。3.4 中文分词分析的地基如果不做分词Spark 做词频统计时就只能按字切分像床前明月光会被切成单个汉字统计出来的结果全是前明月这种单字分析价值不大。所以清洗之后要加一道分词。Java 生态推荐 HanLPPython 生态推荐 jieba。两者的词频统计效果都不错。我的习惯是用 HanLP 的标准分词模式再加上自己维护的停用词表把之乎者也啊呀这类虚词和标点过滤掉保留有实际意义的意象词。分词后的数据可以增加一个字段seg_content这样后续 Spark 做词频统计时连分词的步骤都省了直接按空格 split 就行。这也是一个典型的把计算前移到预处理环节的思路在大数据工程里很常见。4. 业务系统搭建SpringBoot 核心功能模块拆解4.1 业务模块规划与数据库设计业务模块我建议围绕四条主线设计用户、诗词、交互、统计。不要贪多功能在精不在多但一定要保证每个功能是完整闭环的。推荐的核心表结构如下t_user用户表字段包括 id、username、passwordBCrypt加密、nickname、avatar、create_timet_poem诗词表字段包括 id、title、author、dynasty、genre、content、seg_content、create_timet_author作者表字段包括 id、name、dynasty、description、poem_countt_favorite收藏表字段包括 id、user_id、poem_id、create_timet_note笔记表字段包括 id、user_id、poem_id、content、create_timet_stat_result统计结果表字段包括 id、stat_type、stat_name、stat_value、extra_json、update_time。其中 t_stat_result 这张表是用来承接 Spark 分析结果的。它设计得很灵活stat_type表示分析类型朝代分布、作者Top10、词频Top50等stat_name是分析对象名称朝代或作者名stat_value是对应的数值extra_json可以存额外的数据比如词云图需要的词列表。这样表结构不需要为每种分析单独建表Spark 写入时只要拼 JSON 就可以了。4.2 认证授权与公共能力用户模块推荐直接使用 JWT 做无状态认证Spring Security 能用但配置成本稍高如果是为了简洁够用用一个自定义拦截器加 JWT 工具类就够了。注册时密码用 BCrypt 加密登录成功后返回 token前端后续请求在请求头里带上Authorization: Bearer token拦截器校验通过后放行。Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token ! null token.startsWith(Bearer )) { token token.substring(7); if (JwtUtil.verify(token)) { return true; } } response.setStatus(401); return false; } }这样处理的好处是代码量少、逻辑清晰论文里也好写。实际使用中记得在 WebMvcConfigurer 里注册拦截器并放行登录注册接口、诗词列表和详情接口——毕竟游客浏览诗词内容是合理的需求。4.3 搜索与筛选功能的实现层次诗词检索是系统的门面至少要支持三种方式关键字搜索匹配标题或正文、按朝代筛选、按作者筛选。用 MyBatis-Plus 的 LambdaQueryWrapper like条件就能覆盖。如果想让这个模块更有含金量可以引入 Elasticsearch把诗词数据同步到 ES利用 IK 分词器做中文分词检索这样可以支持输入一句词就能搜到出处的体验。不过 ES 的加入会显著增加部署复杂度对资源有限的毕设环境确实是个负担我一般是把它作为论文的扩展与展望章节来写而不是要求在系统里必须落地。4.4 一个能加分的每日推荐模块每日推荐是那种成本低但看起来高级的功能。实现思路很简单基于用户的收藏记录计算朝代偏好。比如用户收藏了10首诗其中6首是唐代的那系统每天推荐诗词时就优先从唐代诗词里随机选取再混入一些其他朝代的高评分诗词。数据量小的时候直接写 SQL 就能算不需要写协同过滤算法但在论文里可以把它包装成一个基于用户行为的简单推荐策略并且注明未来可以替换为基于 Spark ALS 的协同过滤推荐——这样既脚踏实地又体现了对大数据算法的理解。5. 数据分析引擎Spark 与 Hive 如何产出有价值的分析结果5.1 分析维度怎么规划最出效果分析维度的规划决定了论文的价值天花板。我推荐从浅到深安排四个分析任务保证既有统计类结果又有算法类结果历代诗词数量趋势按朝代聚合输出柱状图直观反映唐诗宋词的繁荣周期高频词与意象分析统计全量诗词分词后出现次数最多的 Top50 词汇用词云展示作者创作风格对比选取李白、杜甫等代表性诗人统计他们作品中的高频词和平均句长做对比分析诗词情感倾向分析基于情感词典统计每首诗的正负情感分数再按作者聚合判断不同诗人的情感基调。其中第四个维度最有研究感但情感词典的质量直接影响结论所以如果搞不到一个足够大的中文情感词典我建议退一步做意象词统计而不是情感分析这样结论更容易自圆其说。5.2 Spark 离线统计任务示例用 Java 写 Spark 任务可能显得有些啰嗦但既然后端主体是 SpringBoot全栈 Java 对毕设来说统一性更好、答辩讲解也省事。下面给一个从 HDFS 读取诗词数据并统计词频 TopN 的完整示例import org.apache.spark.sql.Dataset; import org.apache.spark.sql.Row; import org.apache.spark.sql.SparkSession; import static org.apache.spark.sql.functions.*; public class PoetryWordCount { public static void main(String[] args) { SparkSession spark SparkSession.builder() .appName(PoetryWordCount) .master(local[*]) .config(spark.sql.shuffle.partitions, 4) .getOrCreate(); DatasetRow df spark.read().json(hdfs://localhost:9000/data/poetry/clean_poems.json); df.createOrReplaceTempView(poems); DatasetRow words spark.sql( SELECT word, COUNT(*) AS cnt FROM ( SELECT explode(split(seg_content, )) AS word FROM poems ) t WHERE length(word) 1 GROUP BY word ORDER BY cnt DESC LIMIT 50 ); words.coalesce(1) .write() .mode(overwrite) .option(driver, com.mysql.cj.jdbc.Driver) .option(url, jdbc:mysql://localhost:3306/poetry_db?useUnicodetruecharacterEncodingutf8) .option(user, root) .option(password, 123456) .option(dbtable, t_stat_result) .format(jdbc) .save(); spark.stop(); } }这个任务用到了 Spark SQL 的explode和split函数从清洗好的seg_content字段中切分出单词并统计逻辑简单但完整体现了读取分布式存储—执行分布式计算—结果写回数据库的链路。如果需要把多个统计维度都跑一遍可以在同一个 SparkSession 里注册多个临时表最后统一写结果。5.3 Hive SQL 作为补充如果环境里装了 Hive也可以把清洗后的数据建一个外部表这样就能用纯 SQL 做聚合统计。比如统计历代作品数量CREATE EXTERNAL TABLE IF NOT EXISTS poems ( title STRING, author STRING, dynasty STRING, genre STRING, content STRING, seg_content STRING ) ROW FORMAT SERDE org.apache.hive.hcatalog.data.JsonSerDe LOCATION /data/poetry/clean_poems; SELECT dynasty, COUNT(*) AS cnt FROM poems GROUP BY dynasty ORDER BY cnt DESC;注意 Hive 的 JSON SerDe 对数据格式有要求文件必须是每行一个 JSON 对象不能是 JSON 数组这也是我在清洗环节强调每行一条 JSON的原因。5.4 分析任务的调度策略Spark 任务不需要常驻系统里我建议采用定时调度方式每天凌晨1点由 Crontab 或 SpringBoot 的Scheduled触发一次全量分析结果覆盖写入 MySQL 的统计结果表。毕设场景数据量不大全量分析完全跑得动不需要设计增量分析的复杂逻辑。一个具体的 Spark 提交命令模板如下spark-submit \ --class com.example.PoetryAnalysisJob \ --master local[4] \ --driver-memory 2g \ poetry-analysis-1.0.jarlocal[4]表示本地模式用4个线程模拟并行--driver-memory 2g控制驱动程序内存这两个参数在环境差的机器上尤其重要。6. 可视化大屏与后端联调从 Spark 结果到 ECharts 大屏6.1 大屏的布局与图表规划可视化大屏是整个项目最直观的成果展示也是答辩时最容易吸引评委注意力的部分。布局上我建议参考常见的左中右结构顶部系统标题 数据更新时间 核心指标卡片诗词总数、作者总数、朝代数量、收藏总数左侧诗人作品 Top 10 柱状图、词牌名 Top 10中间历代诗词数量趋势折线图这是全场视觉焦点右侧高频词汇词云、各朝代作品占比饼图。做之前先画一个简单的布局草图确定每个图表的位置和尺寸再去写代码可以避免反复返工。6.2 SpringBoot 统计接口设计大屏的数据来自统计结果表SpringBoot 需要提供对应的查询接口。我一般会设计一个聚合接口一次请求返回大屏所需的全部数据减少前端请求次数GetMapping(/api/dashboard/overview) public ResultDashboardVO overview() { DashboardVO vo new DashboardVO(); vo.setPoemCount(poemMapper.selectCount(null)); vo.setAuthorCount(authorMapper.selectCount(null)); vo.setDynastyTrend(statService.queryDynastyTrend()); vo.setTopAuthors(statService.queryTopAuthors(10)); vo.setTopWords(statService.queryTopWords(50)); vo.setDynastyPie(statService.queryDynastyPie()); vo.setUpdateTime(statService.queryLastUpdateTime()); return Result.success(vo); }这里queryTopWords返回的数据需要包含词名和出现次数格式上要和 ECharts 词云组件的数据结构对齐。6.3 ECharts 渲染与数据刷新ECharts 的代码不在多关键是数据拼装正确。以词云为例数据格式是[{ name: 月, value: 2314 }, ...]ECharts 词云插件按 name 显示词、按 value 决定字号。有了接口之后前端只需要用 Axios 拉数据再 setOption 即可。数据刷新我推荐用轮询每30秒请求一次接口。对大屏来说这已经足够实时而且实现起来比 WebSocket 简单得多。如果要加分可以在后端用 Redis 缓存统计结果并给前端返回一个上次更新时间让用户看到数据不是静态的。6.4 联调阶段最容易忽略的两个问题跨域问题。SpringBoot 默认禁止跨域请求大屏页面如果和接口不在同端口比如前端 Vue 跑在 8081后端跑在 8080必须配置跨域过滤器。一般实现WebMvcConfigurer的addCorsMappings方法即可解决。数据字段命名问题。Java 后端习惯用驼峰命名dynastyTrend前端 ECharts 可能习惯下划线dynasty_trend如果两边没对齐图表就是空白的。最省事的办法是在后端 DTO 统一用驼峰返回前端照单全收不要在联调阶段来回改字段名。7. 毕设排错实录环境与代码层面最常遇到的问题7.1 Spark 与 SpringBoot 的版本冲突这是新手最容易踩的坑。SpringBoot 3.x 默认基于 JDK 17而 Spark 3.2 之前的版本对 JDK 17 的支持并不好运行时经常出现Unsupported class file major version的错误。我的建议是SpringBoot 用 2.7.xJDK 用 8 或 11Spark 用 3.3.xHadoop 用 3.3.x。这套组合我实测下来最稳网上的教程也最多。如果你非要上 SpringBoot 3.x那就要注意 Spark 版本必须 3.3 以上且还需要处理很多兼容性问题对一个赶毕业设计的学生来说没必要。7.2 Windows 环境下 Hadoop 的 winutils 报错很多同学在 Windows 上跑 Spark 程序启动时会报类似Could not locate executable null\bin\winutils.exe in the Hadoop binaries的错误。这是因为 Hadoop 的本地库没有 Windows 版本。解决办法去 GitHub 下载对应版本的 winutils 和 hadoop.dll放到一个文件夹里然后配置系统环境变量HADOOP_HOME指向该文件夹并把%HADOOP_HOME%\bin加到PATH里。配置好后重启 IDE问题就消失了。7.3 中文乱码的三种来源中文乱码是诗词系统里最容易出现的问题而且可能出现在三个环节数据文件编码、数据库连接、前端显示。数据文件统一用 UTF-8 编码保存清洗脚本里写入文件时显式指定encodingutf-8JDBC 连接 URL 加上characterEncodingutf8参数前端 HTML 页面设置meta charsetUTF-8。这三处都做了乱码基本不会出现。还有一个隐蔽的点Spark 读取 JSON 时如果数据文件带 BOM 头会影响字段解析导致读出来全是 null。处理办法是清洗阶段用不带 BOM 的 UTF-8 写文件。7.4 Spark 任务频繁 OOM 的调参思路本地模式下 Spark 任务 OOM大多数情况不是集群瓶颈而是默认参数不合适。常见的调整方向有三个减少并行度spark.sql.shuffle.partitions默认200对数据量不大的任务来说太多了改成4或8限制 Driver 内存--driver-memory 2g根据自己的机器内存情况调整不要贪大用 Kryo 序列化在 SparkConf 里设置spark.serializer为org.apache.spark.serializer.KryoSerializer能减少内存占用。另外数据量不大的情况下就用local[2]或者local[4]不要用local[*]后者会把笔记本所有 CPU 核心都拿去跑任务容易把机器弄死。7.5 远程调试与交付环境准备标题里提到的远程调试是毕设交付阶段很现实的需求。导师不一定在你的电脑上看演示所以交付前一定要把项目环境整理成一键可运行的状态。我一般会做三件事写一个清淅的 README 启动文档包含 JDK、Maven、MySQL、Hadoop/Spark 的安装版本、配置步骤、启动顺序、账号密码提供脚本化的启动工具比如start_all.bat或start_all.sh依次启动 MySQL、Hadoop、Spark 任务和 SpringBoot 应用避免手工敲一堆命令远程调试时确认 SpringBoot 端口和数据库端口在防火墙里放行如果用的是云服务器还要注意安全组规则。远程调试最怕的是本地能跑远程一跑就崩。崩的原因大半出在路径和版本差异上本地写死的绝对路径、本地独有的环境变量、Hadoop 版本不一致等。所以我建议把 HDFS 的路径尽量配置在配置文件里不要硬编码在 Java 代码中。8. 论文写作与答辩演示的实战建议8.1 论文结构怎么搭这类题目的论文结构其实很成熟按学校给的模板走就行核心是内容的颗粒度。我特别想提醒的是第三章需求分析和第四章系统设计不要写得像流水账每个功能模块的设计要讲清楚为什么这么设计。比如搜索功能你不仅要说用户输入关键词可以搜索诗词还要说明搜索采用 MySQL LIKE 匹配考虑到数据量在十万级这个方案足够如果数据量达到百万级可以引入 Elasticsearch 做分词检索。这种写法就是典型的体现思考深度评委很吃这一套。8.2 演示顺序的编排逻辑答辩演示环节一般只有五到十分钟顺序安排很关键。我的建议是先用一分钟展示系统整体界面让评委建立直观印象接着走一遍核心业务闭环注册→登录→搜索诗词→查看详情→收藏→写笔记然后切换到大屏页面说明这些图表的数据全来自 Spark 对 HDFS 上十万条诗词数据的离线计算最后展示爬虫脚本和 Spark 任务的运行日志证明数据链路的真实性。注意第4步可以只展示代码和日志不用现场跑因为现场跑 Spark 任务有可能因为环境问题翻车。8.3 高频答辩问题与应答策略我把评委针对这类题目最常问的问题整理了一下每个都给出参考应答方向供大家准备答辩时参考常见问题参考应答策略你这个数据量多大够得上大数据吗数据量约10万条重点强调处理链路是分布式架构可以横向扩展Spark 和你直接用 SQL GROUP BY 有什么区别Spark 支持分布式计算数据量大时可扩展集群节点SQL 受单机资源限制你的数据清洗都做了什么去重、繁体转简体、结构化字段抽取、分词按这四个方向逐一展开系统最大的瓶颈在哪里搜索模块目前是数据库 LIKE数据量大幅增长后需引入 Elasticsearch如果重新做一次你会改进什么引入实时流处理Kafka/Flink、基于ALS的推荐算法、引入全文检索这些问题回答的关键是诚实但不露怯遇到没做的功能就说是后续展望不要现场编造。8.4 那些论文里可以写但工作量不大的加分点如果还有多余的时间和精力下面这些点可以只写论文不做系统也可以作为展望章节的内容效果都不错引入 Elasticsearch 做全文检索引擎替换数据库模糊匹配引入 Kafka 做实时诗词数据流的采集管道引入 Flink 做流式计算实现用户访问热度实时排行引入协同过滤推荐算法基于用户收藏行为做个性化诗词推荐。这几点写进第九章总结与展望里评委一看就知道你对技术生态有整体认识而不是只会照抄代码。最后分享一点我的真实体会。带过这么多届毕设我发现诗词信息系统这个题目最大的价值不是代码量有多少而是它把 SpringBoot 和大数据技术串成了一个完整故事数据从哪来、怎么洗、怎么存、怎么算、怎么展示每一环都在做实实在在的工作每一环又都能在论文里找到对应章节。做完这个项目你收获的不仅是一个能通过的毕设更是一条可以讲清楚的大数据处理链路。如果你正在准备这个题目把心思花在数据链路的完整性上而不是纠结界面美不美观方向就对了。