ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

SpringBoot+Hadoop+AI大模型兼职聚合推荐平台设计与实现

SpringBoot+Hadoop+AI大模型兼职聚合推荐平台设计与实现 这是一类非常典型的“大而全”毕业设计/项目实战题基于SpringBoot大数据爬虫Hadoop智能AI大模型的兼职聚合与个性化推荐平台。我前前后后带人搭过几版类似的东西看到标题里的“精品源码精品论文上万数据集答辩PPT”基本能猜到你想要的是一个既能过答辩、又能真正跑起来的完整闭环。这篇文章就把这个项目从零到一的设计思路、技术选型、核心实现、常见坑全捋一遍同时也会说清楚哪些地方是“看起来高级”但没必要死磕的哪些是必须扎扎实实做好的。适合准备做毕设、或者想拿这套技术栈练手做实战项目的同学参考。1. 项目定位与总体架构拆解1.1 这个项目到底在解决什么问题市面上的兼职信息散落在一堆不同的App、网站、公众号里学生想找个周末兼职、远程兼职、短期实习往往要来回切换好几个平台而且很难判断一条兼职信息靠不靠谱薪资是否合理跟自己的专业、技能、可工作时间匹不匹配。所以这个项目的核心价值就两个聚合和推荐。聚合通过网络爬虫把多个公开渠道的兼职信息抓到本地经过清洗、去重、结构化统一存起来做一个可供检索的兼职信息库。推荐基于用户的基本信息技能、城市、可兼职时间、期望薪资和历史行为浏览、收藏、投递利用协同过滤、内容匹配甚至引入大模型做语义层面的理解把“可能合适的兼职”推给用户。从毕设/项目评审的角度看这个题目比单纯的CRUD管理系统值钱得多。它不是简单堆功能而是把一条完整的数据链路打通了采集-存储-清洗-服务-推荐。评委会特别关注各层之间的衔接而不是单点功能。1.2 整体架构五层模型我帮人搭这类项目习惯把架构分成五层既能应付讲解又方便代码拆分采集层爬虫模块负责抓取公开兼职数据。这里的技术栈可以是Java HttpClientJsoup也可以是Python requestslxml项目里不建议完全脱离开来通常是一个独立模块产出的数据落到临时目录或消息队列。存储层Hadoop HDFS做分布式文件存储主要存放原始抓取数据和处理后的中间结果关系型数据库如MySQL负责存用户、职位、行为等在线业务数据;如果数据量真的大还可以引入Elasticsearch做搜索但这属于加分项不是必备项。计算层Hive或MapReduce做离线清洗与统计比如去重、字段补全、兼职分类的标签提取。这一层体现的是“大数据处理”的核心。服务层SpringBoot提供RESTful API处理前端请求、用户认证、职位查询、收藏投递、推荐结果返回。智能推荐层既可以作为SpringBoot内的一个服务也可以独立成Python微服务。包含用户画像、职位画像、离线召回、在线排序以及可选的AI大模型接口用于生成个性化推荐理由、做语义匹配。下面是我常用的一种简化部署形态[爬虫模块] - (原始数据) - [HDFS] | [Hive清洗] | [MySQL/Redis] | [前端/Vue] - [SpringBoot API] - [推荐服务/Python] | [MySQL业务库]很多同学一上来就被“分布式爬虫”“Hadoop集群”“AI大模型”这些词吓住了。实际上毕设环境完全可以用伪分布式Hadoop推荐服务也可以用轻量模型在线API的方式实现关键是每层之间的数据流要说清楚。1.3 技术选型背后的核心原因《基于SpringBoot大数据爬虫Hadoop智能AI大模型的兼职聚合与个性化推荐平台》这个题目的技术选型是有讲究的SpringBoot当前Java后端的事实标准起步快、生态成熟用来做API层和业务层是最稳的。Controller、Service、Mapper三层结构在论文里也好画图答辩也好讲。Hadoop对应“大数据”这个关键词。实际上海量兼职数据的处理量级可能达不到真正用上集群的程度但你有了Hadoop这套数据采集离线计算的链路项目的高度就不一样了。尤其“上万数据集”这个条件正好卡在能用数据库处理但用Hadoop处理也让合理的区间属于讨巧的设定。爬虫数据从哪里来这是整个系统的血液。没有真实数据推荐算法再牛也是空中楼阁。AI大模型这是最近两年最热的加分项。它不需要你去训练一个大模型更多的是用大模型做三件事抽取兼职文本标签、理解用户自然语言画像、生成解释性推荐文案。说白了是站在大模型的肩膀上做一些轻量应用。2. 数据采集层爬虫设计与合规采集2.1 爬虫模块的定位与职责兼职聚合平台的数据源头一般有主流招聘网站、本地生活服务网站、校园论坛兼职版块、企业官方发布的兼职招聘信息。需要注意爬虫不是乱爬要遵守目标网站的robots协议也要控制抓取频率不要给目标站点带来压力。这是职业素养问题也是保护自己的方式。在设计爬虫模块时要先划分清楚数据流向种子URL - 列表页解析 - 获取详情页URL列表 - 详情页内容抓取 - 字段解析 - 清洗 - 输出如果只抓几个渠道用单线程循环也够为了体现“分布式爬虫”的亮点可以用一个生产者-消费者模型一个模块负责从列表页提取详情链接多个Worker线程从任务队列取链接并发抓取详情页。在Hadoop集群加持下还可以把待抓取URL列表放到HDFS上由多个节点分担抓取任务——不过毕设里这样做的意义不大写论文的时候提一句“可扩展设计”就行。2.2 技术栈选择Java还是Python项目既然主打SpringBoot爬虫模块用Java写会显得技术栈统一但Python在页面解析和文本处理上确实更顺手。我的建议是主爬虫用Java写放到SpringBoot工程里作为一个独立模块如果需要一些特殊的JS渲染页面再额外用Python脚本辅助。Java爬虫常用组合HttpClient Jsoup适合静态页面。Selenium WebDriver适合需要模拟点击、翻页、等待异步加载的页面。注意Selenium非常吃资源不要在服务器上开一堆浏览器实例控制好并发数。Hutool的HttpUtil做简单抓取很方便但不适合重试逻辑复杂的场景。Python辅助爬虫常用组合requests lxml XPathscrapy如果用到了scrapy可以考虑“分布式爬虫”这个关键词配合scrapy-redis实现多节点抓取。但在毕设里引入scrapy会分散精力建议谨慎。举个例子用Java抓取一个列表页解析职位名称和链接String url https://example.com/jobs/list?page1; HttpClient client HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(10)) .followRedirects(HttpClient.Redirect.NORMAL) .build(); HttpRequest request HttpRequest.newBuilder() .uri(URI.create(url)) .header(User-Agent, Mozilla/5.0 (Windows NT 10.0; Win64; x64)) .header(Accept, text/html,application/xhtmlxml) .build(); HttpResponseString response client.send(request, HttpResponse.BodyHandlers.ofString()); Document doc Jsoup.parse(response.body()); Elements items doc.select(div.job-list-item a.job-title); for (Element item : items) { String title item.text(); String link item.absUrl(href); // 存入待抓取队列 }2.3 数据字段设计与清洗爬到的数据结构化做得越早后面Hive清洗和推荐建模就越省事。兼职信息至少要有以下字段字段说明示例job_id唯一标识建议用URL哈希a3f8b2...title职位名称周末英语助教company发布公司/雇主名称某某教育salary_min期望薪资下限200salary_max期望薪资上限300salary_unit薪资单位天/小时/月city城市北京district区域朝阳job_type兼职类型标签家教/餐饮/促销/线上schedule工作时间要求周末/晚上/可协商education学历要求不限/大专/本科experience经验要求经验不限/1-3年description职位详情文本完整描述source来源渠道example.compublish_time发布时间2025-01-10crawl_time抓取时间2025-01-10 10:00洗数据的规则也很直接去重先按URL去重再按“标题公司城市”做模糊去重防止同一条兼职在不同渠道重复抓。薪资解析爬到的可能是“200-300/天”需要拆成salary_min、salary_max、salary_unit。城市归一化比如“北京市”“北京”“朝阳区北京”统一成北京。标签抽取从title和description里用正则或关键词表打标比如“家教”“辅导”“助教”归类到家教类。2.4 合规采集的几个注意事项这个必须多说几句。爬虫无法完全避免被反爬但不能因此去搞破解验证码、绕过登录这类手段。规范的做法是控制频率。同一域名下请求间隔至少1到3秒并发数不要超过5。设置合理的User-Agent并标记爬虫身份方便站点管理员联系。只抓公开信息不碰用户隐私数据、不碰非公开接口。如果目标有明显的“禁止爬取”声明就换一个数据源。反爬应对方面可以做的常规操作包括随机请求头、使用Cookie池、支持断点续抓用Redis或MySQL记录已抓URL、动态调整抓取间隔。3. Hadoop数据存储与离线处理3.1 HDFS目录规划和文件格式搞大数据项目第一件事不是急着写代码而是把HDFS上的目录结构规划好。我用下面这套简单清晰/user/hadoop/兼职数据/ ├── raw/ 原始抓取数据 │ ├── 20250101/ │ ├── 20250102/ ├── clean/ 清洗后数据 ├── dwd/ 明细数据 └── ads/ 统计和应用层数据raw下存的原始抓取结果建议直接用JSON格式一行一条方便后续Hive解析。clean下是清洗后的结构化字段推荐用Parquet或ORC格式压缩率高、读取快。如果没有特殊强迫症CSV也不是不能用但真要体现大数据感觉还是得落到列式存储。3.2 Hive建表和离线清洗Hive是Hadoop生态里最好用的OLAP工具写SQL就能做数据清洗上手成本低。比如在Hive里建一张兼职明细表CREATE EXTERNAL TABLE dwd_job_info ( job_id STRING, title STRING, company STRING, salary_min DOUBLE, salary_max DOUBLE, salary_unit STRING, city STRING, district STRING, job_type STRING, schedule STRING, description STRING, source STRING, publish_time STRING, crawl_time STRING ) PARTITIONED BY (dt STRING) ROW FORMAT SERDE org.apache.hadoop.hive.serde2.OpenCSVSerde STORED AS TEXTFILE LOCATION /user/hadoop/兼职数据/dwd;然后通过一条INSERT OVERWRITE把清洗逻辑跑出来INSERT OVERWRITE TABLE dwd_job_info PARTITION(dt2025-06-01) SELECT job_id, trim(title) AS title, trim(company) AS company, salary_min, salary_max, salary_unit, city, district, CASE WHEN title LIKE %家教% OR title LIKE %辅导% THEN 家教 WHEN title LIKE %促销% OR title LIKE %导购% THEN 销售促销 ELSE 其他 END AS job_type, schedule, description, source, publish_time, crawl_time FROM clean_job_info_temp WHERE title IS NOT NULL AND title ! ;这里体现的是“清洗转换”的过程。答辩的时候一定要把这条SQL讲清楚因为这就是Hadoop在实际项目中发挥的作用——离线批处理。3.3 从Hadoop到业务库怎么服务线上系统Hive处理完的数据最终要在SpringBoot接口里被查询你不能让线上接口直接去查Hive延迟太高。常规做法是离线计算结果同步到MySQL。用Sqoop同步或者写一个DataX任务把ads层数据导入MySQL。如果数据量真的很大MySQL扛不住可以引入Elasticsearch做搜索。但大部分毕设/sprint项目里MySQL加索引就够用了。推荐离线结果同理离线算好每个用户的TopN Job写入Redis或MySQL的recommend表在线接口直接读。3.4 Hadoop部署伪分布式就够吗《Hadoop伪分布式搭建》《Hadoop和Zookeeper整合实战》这些都是热搜关键词。常用于配置如果你是课设/毕设一台内存16G以上的电脑就足够了。伪分布式不需要Zookeeper配置core-site.xml、hdfs-site.xml、yarn-site.xml一个NameNode一个DataNode就能跑。如果你要坚持集群模式三台虚拟机即可但每台至少4G内存不然跑MapReduce会频繁OOM。搭建的时候永远先确认$JAVA_HOMEhadoop-env.sh里不写JAVA_HOME会导致各种诡异问题。启动完先执行jps看进程NameNode、DataNode、ResourceManager、NodeManager都在才叫启动成功。一个实际经验Hadoop 3.3以上版本跟Java 8/11/17的兼容性都还行但Java 17会把一些反射警告刷屏不影响使用。真实项目中建议用Java 8或11稳定网上资料也最多。4. SpringBoot后端服务设计4.1 工程目录与分层SpringBoot服务是整个平台的中枢。既要给前端Vue提供接口也要对内调度推荐服务。我建议按下面的模块划分job-platform/ ├── job-common/ 公共模块统一返回结果、异常处理、工具类 ├── job-admin/ 后台管理模块 ├── job-api/ 面向C端用户的接口模块 ├── job-crawler/ 爬虫模块 ├── job-recommend/ 推荐服务模块 ├── job-datasource/ 数据库、Redis、消息队列配置 └── job-quartz/ 定时任务模块简化版本也可以是一个单体Module但至少Controller、Service、Mapper、Entity、DTO这些包要分开。这直接关系到论文里UML图的画法也关系到代码分。分层清晰比多写几个功能重要得多。4.2 核心表和接口设计用户表user(id, username, password, city, education, skills, available_time, expected_salary, tags) 职位表job_info(id, job_id, title, company, salary_min, salary_max, city, job_type, schedule, description, publish_time, status) 行为表user_behavior(id, user_id, job_id, behavior_type(view/favorite/apply), create_time) 推荐结果表recommend_result(id, user_id, job_id, score, reason, create_time)后端接口按这个清单来方法路径说明POST/api/user/register注册同时采集用户画像POST/api/user/login登录返回JWTGET/api/jobs分页查询兼职支持筛选GET/api/jobs/{id}职位详情POST/api/behavior上报浏览/收藏/投递行为POST/api/recommendations获取个性化推荐结果GET/api/recommendations/{userId}查看某用户的推荐列表POST/api/admin/job/import管理员手动导入清洗好的数据4.3 SpringBoot整合关键点1. MyBatis-Plus 动态数据源如果离线数据从Hadoop同步到MySQL业务表在MySQL如果用了Redis做缓存就需要配置多数据源。MyBatis-Plus的DS注解可以切换数据源推荐用。2. Redis做热门兼职缓存兼职数据访问热度差异大热门前十的职位可能被反复查。用Redis缓存列表数据可以明显降低数据库压力。Cacheable(cacheNames hotJobs, key #page : #size) public PageResultJobVO getHotJobs(int page, int size) { // 查询热门前职位 }3. 消息队列提高采集异步性用SpringBoot集成ActiveMQ或RabbitMQ把爬虫抓到的数据先发到MQ再由消费者异步写入HDFS或者MySQL。这样既解耦又能体现工程设计的深度。如果不想引入队列至少要用线程池异步处理别让抓取逻辑阻塞接口调用。4.4 API防爬防护与业务安全题目热词里面反复出现“controller层如何防护防止爬虫”“前端防爬虫”。这说明大家都意识到平台上线后接口会被别人恶意爬取。防止他人爬我们的接口手段一般是用户网关限流用Spring AOP或拦截器对单个IP、单个Token限制访问频率比如1秒最多10次请求。超过就返回“请求过于频繁”。JWT认证非公开接口必须带token解析失败直接401。参数签名针对重点接口前端传参时带sign MD5(params salt)后端验签。用来防止参数被篡改和数据被恶意遍历。验证码登录、注册、批量查询接口加图形验证码或滑块验证。敏感数据脱敏手机号、邮箱等字段返回时打码。防SQL注入使用参数绑定不要拼字符串。防XSS前端提交内容做HTML转义后端的过滤器也可以统一处理。给你一段拦截器的思路Component public class RateLimitInterceptor implements HandlerInterceptor { Autowired private StringRedisTemplate redisTemplate; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String ip request.getRemoteAddr(); String key rate:limit: ip; Long count redisTemplate.opsForValue().increment(key); if (count ! null count 1) { redisTemplate.expire(key, Duration.ofSeconds(10)); } if (count ! null count 20) { response.setStatus(429); response.getWriter().write(请求过于频繁请稍后再试); return false; } return true; } }这套东西不是毕设核心加分项但写进论文“系统安全设计”一章比空泛地写“保证了系统安全”要硬很多。5. 智能推荐与AI大模型落地5.1 推荐系统的整体链路推荐系统不是只有“协同过滤”这一种算法。在这个项目里推荐链路需要设计成下面三层缺一不可召回层从几万个职位里快速找出200个候选职位。冷启动时按城市、求职类型、薪资范围召回有历史行为后用基于物品的协同过滤或者简单规则相似用户投递过的职位召回。排序层对200个候选职位打分排序。排序可以分成两个阶段先基于特征规则打分城市匹配、薪资匹配、时间匹配、技能匹配再混合模型排序。如果数据量不大直接用规则加权评分会有非常好的效果也容易讲清楚。展示层返回推荐的职位和推荐理由。推荐理由用大模型生成这是项目里最有亮点的地方。5.2 怎么用AI大模型做个性化推荐“AI大模型”在就业平台里不是让你自己从零训练一个Transformer而是做下面这几件事第一结构化用户画像生成。用户在注册时可能会填“我是英语专业学生周末有空想找跟英语相关的兼职”。这段描述是半结构化的借助大模型可以抽取成标签输入我是英语专业大二学生周末和暑假有空希望找线上或线下的英语助教工作薪资要求不高。 输出JSON { major: 英语, tags: [英语助教, 线上兼职, 线下兼职, 教育], available_time: [周末, 暑假], salary_expectation: 中等 }第二职位语义标签扩展。爬虫抓到的职位标题可能很简短比如“辅导机构招周末助教”。直接用关键词匹配用户搜“英语助教”可能搜不到。用大模型对职位文本做语义理解生成扩展标签原始标题辅导机构招周末助教扩展标签英语助教、作业辅导、周末兼职、教育机构、学生兼职这样推荐召回阶段就不容易漏掉候选。第三生成个性化推荐理由。这也是最能打动评审的点。当用户看到推荐结果时不再只有一个生硬的职位标题而是一句解释“这与你之前浏览的‘周末英语助教’相似且薪酬在同类兼职中偏上符合你的周末时间安排在朝阳区。”大模型可以通过职位信息、用户画像、推荐匹配点来生成这段话。5.3 推荐服务具体怎么落地推荐服务不一定要用重框架。我建议拆成一个独立的Python推荐微服务SpringBoot通过HTTP接口调用它。Python侧可以用FastAPI封装两个接口POST /recall传入userId返回候选职位ID列表。POST /rank传入userId和候选职位列表按照相关性打分返回TopN。POST /explain传入userId和推荐职位ID调用大模型生成解释文案。Python里可以简单实现一个基于内容的召回def compute_score(user_profile, job_item): score 0.0 if user_profile[city] job_item[city]: score 0.3 if user_profile[job_type] job_item[job_type]: score 0.3 if user_profile[salary_min] job_item[salary_max]: score 0.2 if any(tag in job_item[tags] for tag in user_profile[tags]): score 0.2 return score当然这只是演示逻辑真实项目里这个分数要经过归一化和模型融合。但毕设展示阶段能把这条链路讲通比堆一堆“深度学习模型”更有说服力。5.4 离线推荐与在线推荐推荐结果不需要每次请求都现算否则延迟高到没法用。项目里可以分两条线离线计算每天凌晨用Spark或Python脚本跑一次全量用户推荐TopN结果存入MySQL/Redis的推荐表。用户打开App直接读缓存。在线兜底如果用户是新用户或离线结果为空走规则召回实时算一个粗推荐出来。这个双轨设计在论文里非常好写离线部分体现“大数据处理”在线部分体现“系统可用性”。5.5 大模型API调用注意点调用外部大模型API时不要在前端直接暴露密钥也不要让SpringBoot直接去调用。常规做法是做一个加密密钥中转层所有大模型请求都走服务端并且设置超时时间避免第三方接口慢导致推荐接口超时。推荐服务里对模型调用要有降级方案模型挂了就返回规则生成的推荐理由比如“城市和求职类型匹配”。6. 数据集、论文结构与答辩准备6.1 “上万数据集”怎么构建才靠谱很多同学问上万条兼职数据从哪来总不能真的抓一万条吧。其实有两种合规的方式爬虫采集真实数据多抓几个渠道每个渠道抓几百到一千条凑出3000到5000条基本数据再通过数据增强字段组合、薪资微调、城市分布调整扩充到一万条以上。注意这些数据仅用于学习演示不用于商业用途。公开数据集自造数据网上有一些招聘公开数据集可以下载做底子再混合爬虫数据补充。我在实际项目里还会额外生成一批“模拟行为数据”给用户分配标签模拟浏览、收藏、投递行为用于推荐算法的效果演示。否则系统上线当天没数据可推。模拟生成的时候要有倾向性比如英语专业的学生更容易浏览家教类兼职这样推荐结果看起来才合理。6.2 精品源码的工程化要求源码这东西不是能跑就行。我整理了一份送给师弟们的最低标准README要写清楚JDK版本、Maven版本、Hadoop版本、MySQL版本、初始化脚本、启动顺序。必须提供database/init.sql和样例数据导入脚本。第三方依赖版本集中管理用Maven的properties标签统一版本号。配置项外置到application.yml敏感信息至少要有占位符。日志要分级。不能用System.out.println打点至少用lombok的Slf4j。接口返回格式统一。推荐写一个ResultT对象code/message/data。6.3 精品论文怎么组织论文结构不用太标新立异按标准硕士/本科论文套路来就行但技术细节要写扎实绪论背景、国内外研究现状、研究内容、论文结构。需求分析功能性需求、非功能性需求、用例图。相关技术介绍SpringBoot、Hadoop、爬虫、推荐算法、大模型API。系统设计总体架构设计、数据库设计、功能模块设计、推荐算法设计。系统实现每个模块的核心代码讲解、核心界面截图。系统测试功能测试用例表、性能测试数据。答辩时最容易翻车的点就是“相关技术介绍抄了一大堆但是跟后面的设计实现完全脱节”。写论文前先定好架构图所有技术介绍都是为了解释你的架构服务。6.4 答辩PPT与演示要点答辩PPT一般15到20页重点讲这几页系统架构图一页讲清楚数据流。爬虫模块截图展示抓取的原始数据和清洗结果。Hadoop离线处理展示Hive建表语句和清洗前后的数据对比。推荐流程展示推荐接口的返回JSON里面要有推荐理由生成的部分。测试结果负载测试或压力测试数据哪怕只是用JMeter简单跑一下也比空口说系统稳定强。还有一个非常实用的答辩经验提前准备一个40秒的demo走场。从注册账号、补全画像、浏览职位、上报行为、刷新推荐一条线走完。很多同学一紧张就随便点点到哪个算哪个结果把自己绕进去了。演示要准备两套一套数据完整的主演示一套数据缺失的空状态演示。7. 常见问题与排查技巧实录7.1 Hadoop篇启动失败、内存不足、跑任务卡死问题1NameNode is not started/ 反复格式化格式化HDFS前先把NameNode进程停掉然后清空dfs.namenode.name.dir配置的目录再执行hdfs namenode -format否则会有集群ID不一致的问题。问题2DataNode起不来报磁盘空间不足HDFS默认会保留一定空间如果磁盘剩余不足DataNode会自动退出。检查dfs.datanode.du.reserved参数并确认/data/hadoop目录有足够空间。问题3跑Hive任务时内存溢出Hive跑MR任务时Map和Reduce的堆内存需要撑住。可以配置property namemapreduce.map.java.opts/name value-Xmx1024m/value /property如果机器内存只有16G不要同时启动太多服务。Hadoop Hive MySQL Redis SpringBoot 前端占用大概12G左右建议给虚拟机分配8G以上或减少不必要的组件。7.2 爬虫篇抓不到数据、被限制、解析失败问题1页面是异步加载的HttpClient抓的HTML里没数据这种情况要用Selenium或Playwright渲染后再解析。优点是省事缺点是慢。我习惯用Scrapy/Selenium混合模式列表页用浏览器渲染详情页如果静态就直接HttpClient抓。注意Selenium的WebDriver版本要和浏览器版本匹配不然报SessionNotCreatedException。问题2请求过一段时间就被封IP不要一味增加代理成本。先检查是不是请求头太规律、频率太高。最稳妥的方案是限速随机延迟User-Agent尽量用真实的浏览器版本或者直接用固定的浏览器UA而不是随机生成。问题3XPath写的没问题但取不到值大概率是HTML里面包含了命名空间或者内容在iframe里。先右键检查确认元素位置如果确实在iframe里Selenium里要用driver.switchTo().frame()切进去。7.3 SpringBoot篇版本兼容、jar冲突、启动慢问题1SpringBoot版本太高跟某些插件不兼容这是一个非常常见的问题。比如SpringBoot 3.x要求JDK 17老一些的MyBatis或者数据库驱动就不适配。最稳妥的组合是JDK 8 SpringBoot 2.7.x MyBatis-Plus 3.5.x Hadoop 3.3.x。不要一上来就追最新版毕业设计求稳不求新。问题2Maven依赖冲突启动报NoClassDefFoundError优先用mvn dependency:tree查看依赖树找到冲突的jar然后在pom.xml里用exclusions排除。比如Hadoop的ZooKeeper版本跟项目里其他依赖冲突时排除掉Hadoop传递的旧版本即可。问题3SpringBoot整合Flink或者整合Hadoop时启动变慢Hadoop相关的依赖往往带了一堆传递依赖启动时可能触发不必要的自动配置。解决方式是在SpringBootApplication注解里排除自动配置类或者在配置文件里关闭相关自动配置。SpringBootApplication(exclude { org.apache.hadoop.security.UserGroupInformation.class // 不直接排除仅示意 })更合理的做法不要让SpringBoot直接依赖Hadoop客户端在SpringBoot里只通过Hive/Impala JDBC去查数把Hadoop和业务服务解耦。7.4 推荐与大模型篇延迟高、效果差问题1推荐接口响应时间超过3秒大概率是每次请求都实时算了推荐。解决方案是改成离线结果定时任务或者至少加一层Redis缓存。如果线上确实需要实时召回对候选集加一层布隆过滤器或者减少候选数量。问题2大模型生成推荐理由太慢大模型的在线调用一般在1到3秒如果放在排序链路里会拖垮接口。推荐理由是异步加载的主接口先返回职位列表前端拿到职位后用空位展示再通过/api/explain异步拉取推荐理由或者干脆在离线阶段先生成好TopN题的推荐理由存库直接取。问题3推荐结果一看就不合理比如给北京用户推荐了上海的岗位这是推荐特征没做好。位置、时间、技能、期望薪资四个硬条件至少要作为硬条件过滤而不是作为可以权衡的软特征。硬过滤不过的职位不进入后续排序否则推荐效果会明显偏离。7.5 项目联调中的其他坑端口冲突Hadoop相关端口很多NameNode 9870、DataNode 9864、ResourceManager 8088SpringBoot是8080MySQL是3306Redis是6379。联调之前先列一张端口表谁占用了谁好查。CORS跨域前端Vue在5173端口后端在8080端口不配置CORS就会报跨域。SpringBoot里写一个WebMvcConfigurer统一处理。数据时区问题爬到的发布时间可能是带时区的字符串入MySQL时统一转成LocalDateTime存UTC返回给前端时转成北京时间。8. 最后分享一点实际做的体会我在实际辅导这类项目时最常跟人说的一句话是不要在技术选型上搞“四不像”要把每层技术用到“恰到好处”。这个题目真正的难度不在某一个单独的模块多深而在把SpringBoot、Hadoop、爬虫、AI大模型、个性化推荐这五样东西串成一个完整闭环。你能把数据从采集到展示这一条链路讲清楚把你处理过的数据样例展示出来把推荐结果的前后变化说清楚这比写出一个性能极高的算法更有价值。另外一个建议是答辩前把全套环境重启一遍从头到尾走一遍流程。很多人平时开发是慢慢调试出来的数据库里字段值被改乱了、缓存没清、爬虫任务没跑一到演示就露馅。把系统做成“我昨天刚部署完现在马上能跑”的状态是很多答辩高分的真正秘密。如果你是准备自己动手做这个平台按照我上面说的顺序来推进先搭Hadoop单机版再抓数据、洗数据然后同步到MySQL接着写SpringBoot接口最后做推荐和大模型封装。每完成一步都可以看到东西跑起来不容易中途放弃。祝顺利。
返回列表