每年毕业季计算机专业的同学都在同一个问题上来回拉扯毕业设计到底选什么题目才既拿得出手、又不容易翻车。今天要聊的这套“锦江酒店大数据分析与个性化推荐系统”就是我眼中的标准答案之一技术栈横跨爬虫、大数据存储、离线计算、推荐算法、前后端分离可视化和部署工作量饱满关键点清晰答辩时有东西可讲代码实现也不至于让人秃头。整套系统的名字已经说明了它的全部技术构成Django写后端APIVue做前端界面和可视化图表Hadoop负责海量酒店数据集的存储与离线分析爬虫解决数据来源问题协同过滤推荐算法完成个性化推荐的核心逻辑。它面向的是酒店、民宿、客栈这类住宿业务场景做的是两件事第一把酒店数据摆到屏幕上看清楚比如价格分布、评论热度、区域排行第二让每个用户看到的酒店推荐列表不一样真正做到“千人千面”。这篇博文会把这套系统从数据采集到前端展示的完整链路全部拆开包括技术选型的原因、Hadoop环境搭建的坑、协同过滤的代码实现思路、Django和Vue联调时的典型问题。无论你是准备拿它当毕设参考还是想了解大数据应用类项目怎么落地这篇内容都能提供一份可以直接抄作业的路线图。1. 项目全景与设计拆解开箱一个系统之前先得明白它解决的是什么问题。住宿预订场景里用户面对几百上千家酒店、民宿、客栈筛选成本极高。用户要的是“哪些酒店更适合我”平台要的是“怎么把合适的房源推到用户面前”。这套毕设的核心就是把数据从零散的网页信息变成结构化的数据资产再用算法完成个性化匹配。1.1 需求拆解与功能模块划分从标题可以看出需求本身被拆成了几个清晰的模块这也是毕设选题最值得参考的地方。数据采集层负责从公开网站上抓取酒店名称、价格、评分、评论内容、位置、设施等字段解决“数据从哪里来”的问题。数据分析层基于Hadoop的分布式存储与MapReduce离线计算能力对采集到的数据进行统计加工比如不同城市的酒店均价、价格区间分布、评论数量排行等维度这些统计结果最终会以可视化图表的形式展示在前端页面。推荐层是系统的技术亮点利用用户对酒店的评分或行为数据构建协同过滤模型计算出用户可能感兴趣的酒店列表。业务层和后端服务层由Django完成负责提供RESTful API、用户登录注册、推荐结果查询、统计数据查询。前端展示层由Vue实现SPA应用配合ECharts绘制图表用户在里面可以看到数据看板、浏览酒店列表、查看个性化推荐结果。整套系统形成一条完整的数据流水线爬虫采集原始数据、Hadoop与MySQL分层存储、Django组织业务逻辑、Vue渲染可视化结果。每一层职责单一层与层之间通过接口或文件解耦这种分层架构在答辩时可以很清晰地讲出设计思路。1.2 技术栈选型为什么偏偏是它们几个每个被选中的技术都有不可替代的理由。数据库层面的选型几乎是毕设大数据方向的标配。Hadoop能撑起“大数据分析”这个题眼分布式文件系统适合存放海量非结构化数据MapReduce能完成离线统计任务面试官或答辩老师问起来这东西能讲的东西非常多。MySQL则负责业务数据用户信息、评分数据、最终的统计结果等结构化数据放在关系型数据库里Django的ORM访问起来非常顺手。后端选择Django而不是Spring Boot核心原因是Python生态里爬虫、数据分析、机器学习与Web开发一体化协同的便利性。爬虫用requests和BeautifulSoup推荐算法用pandas、numpy后端用Django全程一种语言代码切换成本几乎为零。前端使用Vue主要因为它组件化开发效率高与ECharts这种基于JavaScript的图表库配合成熟。管理后台、用户端、数据看板在这种场景下拆成组件开发极为顺畅Vue生态的vue-router、axios等配套也成熟稳定。协同过滤算法作为推荐系统的核心选它不是因为它最先进而是因为它最经典、效果可解释、适合教学演示。基于用户的协同过滤推荐相似用户喜欢的东西基于物品的协同过滤推荐相似物品这两种思路写起来不复杂计算过程透明答辩时可以讲得头头是道而且数据规模在毕设场景下完全撑得住。1.3 系统总体架构与数据流转过程完整的调用链路可以描述为爬虫定时抓取酒店信息与评论原始数据一份落入HDFS另一份清洗后写入MySQLHadoop上的MapReduce任务读取HDFS文件统计价格、热度、区域等维度结果回写MySQL中的统计表Django后端通过ORM读取统计数据和酒店数据经过推荐算法模块生成个性化推荐列表通过RESTful API暴露给前端Vue前端调用API获取数据用户在小程序端或管理后台看到图表和推荐酒店。这里有一个容易被忽略的设计点Hadoop和Django不是直连的中间用MySQL做了一个汇总与中转。为什么要这样设计因为Django直接读HDFS极其别扭而MapReduce任务本身也不适合频繁被业务系统调用。Hadoop负责批量离线计算MySQL负责在线实时查询各司其职数据经过“HDFS计算回写MySQL”这个标准流程完成打通这也是工业界离线数仓的经典路径。2. 数据采集爬虫设计与清洗落库没有数据后头的算法和可视化就全成了空中楼阁。爬虫模块在整个项目里是基石决定了后面能做多少事情。2.1 爬虫目标与数据字段设计要支撑后续的分析和推荐需要采集的信息分成几个层级。基础层是酒店属性酒店名称、所属城市、详细地址、经纬度、星级档次价格层是当前房型的日均价格、价格区间口碑层是综合评分、评论数量、评论正文设施层是WiFi、停车场、早餐、游泳池等标签。这些字段基本覆盖了统计分析和推荐算法对数据维度的需求。字段设计在爬虫启动前就要定义好。建议直接定义Python字典结构后面存MySQL时字段名能一一对应。评论正文是推荐算法的“原材料”因为可以通过评论里提取用户偏好也可以通过评论长度、热度等维度做统计分析。所以评论必须抓而且多多益善。我建议每个酒店至少抓取两页评论大约40条左右一套项目做下来有几千条评论规模做统计已经像模像样了。2.2 爬虫实现步骤与反爬对抗策略数据源选择上建议用公开的酒店信息聚合网站而不是某一家酒店官网聚合网站的酒店列表更丰富页面结构也更规整。爬虫技术栈用requests加BeautifulSoup加lxml足够requests发起HTTP请求BeautifulSoup配合lxml解析HTML提取节点这套组合足够简单可靠。以酒店列表页为例直接请求目标列表页面在HTML里定位酒店列表容器逐个提取酒店名称、评分、评论数、价格和详情页链接。详情页需要再发一次请求解析出酒店的地址、经纬度、设施列表和评论区域。抓取过程要注意通过解析链接规律构造请求控制页数范围在10到20页之间数据量控制在300到500条酒店记录加若干条评论已经足够做分析和推荐了。反爬对抗是爬虫绕不开的话题实际项目里最常用的策略有四件套第一伪装User-Agent从常见浏览器UA池里随机挑一个不要每次请求都用同一个第二控制请求频率代码里写time.sleep加上random.uniform生成延时控制在1到3秒之间瞬间高频请求几乎必然被封第三构造Referer和Cookie让请求看起来像正常浏览器访问第四必要的重试机制遇到HTTP 403或503时休息几秒再尝试单条记录失败的不要影响整体流程记入日志即可。注意爬虫类项目务必将抓取频率控制在合理范围仅用于学习研究不要对目标站点造成访问压力。这也是毕业设计里老师一定会问的合规性问题提前想好这句话。2.3 数据清洗与入库流程原始数据基本是不能直接用的我见过太多人把爬下来的数据一股脑塞进库里结果统计时冒出一堆房价为0的记录评分还有两位数这种离谱数值。清洗流程一定要做成一条独立的流水线。第一步去重以酒店名加城市作为唯一键重复的直接丢弃。第二步处理缺失值价格为空或等于0的记录要么补全国平均价要么直接过滤我建议价格仍由正常统计渠道获得太离谱的样本直接删掉对后续分析更干净。第三步统一格式价格转成float评论数转成int纬度、经度统一成小数设施字段用逗号拼接成一整串文本。第四步做敏感数据脱敏比如用户昵称、手机号这类字段不需要的干脆不采集。清洗后的数据同时做两件事写入MySQL时按表结构批量insert写一份CSV文件保存到本地后续上传到HDFS。MySQL表设计建议三张表hotel酒店表、review评论表、user用户表推荐系统还需要一张rating评分表。如果没有真实评分数据可以基于评论内容自动生成模拟评分比如评论中“很好、棒”这类正向词占比越高评分越高用jieba分词和情感词库做一个简单的情感打分。3. Hadoop大数据分析层环境搭建与离线统计任务Hadoop在这个项目里的存在感主要靠伪分布式环境的搭建过程和MapReduce统计分析任务来体现。对毕设来说证明你理解大数据技术栈并能实操比单纯跑通更重要。3.1 Hadoop伪分布式环境搭建要点我用的是Hadoop 3.x版本运行在一台8G内存的Ubuntu虚拟机上。伪分布式模式只需要一个节点NameNode和DataNode、ResourceManager和NodeManager都在同一台机器上对笔记本配置要求不高也能完整展示HDFS上传文件、MapReduce执行任务的全流程。环境搭建有几个关键步骤特别容易踩坑。安装好JDK后修改/etc/profile配置JAVA_HOME和HADOOP_HOMEPATH里追加$HADOOP_HOME/bin和$HADOOP_HOME/sbin注意修改完一定执行source /etc/profile让环境变量生效有很多同学在这反复失败却始终没搞明白原因。接着配置ssh免密登录。Hadoop的脚本会通过ssh启动远程进程如果没有免密配置每次启动都要输密码严重影响效率。执行ssh-keygen -t rsa生成密钥再用ssh-copy-id localhost把公钥拷贝到本机之后就能免密登录了。这一步看似小儿科实际是环境能跑通的关键前提。然后修改Hadoop配置文件core-site.xml里设置NameNode地址和临时目录hdfs-site.xml设置副本数为1伪分布式下副本数为3必然出错因为只有一台DataNodeyarn-site.xml设置ResourceManager地址和内存相关参数。配置文件修改完毕后先格式化NameNodehdfs namenode -format格式化之前必须确保HDFS没有启动否则会报错。启动验证阶段执行start-dfs.sh和start-yarn.sh然后用jps命令检查进程看到NameNode、DataNode、ResourceManager、NodeManager四个进程就说明基本成功了。浏览器访问9870端口可以看到HDFS管理界面访问8088端口是YARN的资源管理器界面。3.2 MapReduce离线统计任务设计Hadoop的价值要在具体计算任务中体现我给这套系统设计了三个统计维度。价格区间统计任务以CSV格式的酒店数据为输入map阶段按城市分组读取每条酒店记录的价格字段根据价格区间阈值输出“城市区间”作为key1作为value。reduce阶段累加计数最终输出每个城市各区间的酒店数量。这样就能得到“北京经济型酒店多少家、高端酒店多少家”这类统计结果。评论热度统计任务分析每条评论的长度和数量map阶段按城市输出评论总数和评论总长度reduce阶段计算平均评论长度用于衡量用户在哪些城市更愿意写长评。区域热门酒店排行任务按城市分组统计酒店评分总数reduce阶段取Top10得到每个区域口碑最好的酒店列表。这些结果落回MySQL后前端可视化就直接有数据可用了。我把三个任务统一打成一个jar包提交到YARN通过命令行执行hadoop jar提交运行。整个过程跑下来Hadoop部分的工作量在答辩时是肉眼可见的大。3.3 分析结果回写业务库的策略MapReduce计算完成后输出到HDFS的结果需要导回MySQL供业务系统使用。推荐的做法是在每个Reduce任务的cleanup阶段通过JDBC连接MySQL直接写入统计表。这样任务跑完数据自动落库后续只要定期重新触发统计任务就能刷新数据。另一条可行路径是先把结果输出为CSV文件到HDFS再通过sqoop将文件导入MySQL。但毕设环境里额外装sqoop太重了我建议直接JDBC写入。这里有个体验上的小技巧把统计表的写入操作封装在Reduce的setup方法里建立连接在cleanup里批量写入避免每条记录都开关一次数据库连接。4. 协同过滤推荐算法核心原理与落地方案推荐算法是这套系统的门面也是答辩时候选人一定会被深挖的地方。讲清楚原理、写清楚代码、分析清楚效果这块做好了整个项目的技术深度就有了。4.1 协同过滤的基本思想与选型逻辑协同过滤的核心思想概括成一句话就是人以群分物以类聚。基于用户的协同过滤UserCF找到与当前用户兴趣相似的其他用户把那些相似用户喜欢的酒店推荐给当前用户基于物品的协同过滤ItemCF找到与用户曾经喜欢的酒店相似的酒店然后推荐出去。那这个场景到底选UserCF还是ItemCF我的建议是两个都实现推荐结果按权重混合。原因是住宿场景有很强的地域属性用户在不同城市的需求差异巨大。一个用户在北京喜欢高档酒店不代表他在成都也想住高档酒店纯UserCF在这种场景下效果不稳定。ItemCF基于物品相似度计算结果更容易解释用户也更容易接受“因为你喜欢这些酒店所以推荐相似酒店”的逻辑。把两种算法的结果按6比4加权混合实测效果和解释性都更好。4.2 评分矩阵构建与相似度计算协同过滤的一切计算都建立在评分矩阵之上。矩阵的行是用户列是酒店值是对应评分。在真实项目中用户对酒店的显式评分很少需要从行为数据构造隐式评分。一个可以直接使用的经验公式是评分等于打分的平均值乘以评论情感得分系数情感得分范围为0.8到1.2。用户对某酒店评论了且打高分评分就高如果只看过没评论评分设为默认中值3分。这样做的好处是把稀缺的显式偏好和一抓一大把的浏览行为结合起来矩阵的稀疏度会明显下降。相似度计算采用调整后的余弦相似度。直接计算用户对两件物品评分的余弦夹角公式上是两个评分向量的点积除以两个向量模长的乘积。但实际使用中需要先做均值中心化处理减去该用户的平均评分再算余弦否则用户打分习惯的不同会严重干扰相似度结果。喜欢打高分的用户和严格打低分的用户可能实际偏好完全一致但不做中心化时相似度却很低。为了让小白也能理解打个比方两个人都喜欢住江景房一个习惯给所有酒店打4分以上一个从不超过3分原始分数毫无可比性。把每个人的评分减去自己的平均分后正负号才真正反映“这个人对这个酒店的态度是偏高还是偏低”。4.3 推荐生成与冷启动处理预测用户对未评分酒店的评分核心计算逻辑是找到与目标用户最相似的K个用户通常K取10到20用这K个用户对该酒店的评分加权平均得到预测值权重就是相似度。加权平均的目的是让更相似的用户评价比重更大。纯协同过滤的致命伤是冷启动问题。新用户没有任何行为数据新酒店也没有任何评分记录。这个问题必须在毕设里给出解决方案否则答辩会被问到卡壳。我的方案是一个混合推荐策略对没有行为记录的新用户直接返回热门酒店推荐热度分等于平均评分乘以评论数的对数既考虑口碑也考虑被关注程度对没有评分记录的新酒店使用基于内容的推荐兜底计算它与用户依据地理位置和设施标签产生的偏好之间的匹配度同时结合同城市同价位区间的热门酒店作为补充。4.4 协同过滤核心代码实现下面是关键代码的骨架完整代码在项目里也就一百多行import numpy as np import pandas as pd from sklearn.metrics.pairwise import cosine_similarity def build_user_item_matrix(ratings_df): # 构建用户-酒店评分矩阵缺失值填0 matrix ratings_df.pivot_table( indexuser_id, columnshotel_id, valuesrating ).fillna(0) return matrix def center_rating(matrix, user_mean): # 均值中心化减去每个用户的平均评分 return matrix.sub(user_mean, axis0) def user_based_cf(matrix, target_user, top_k15): # 计算目标用户与其他用户的余弦相似度 user_sim cosine_similarity(matrix) sim_df pd.DataFrame(user_sim, indexmatrix.index, columnsmatrix.index) # 取最相似的K个用户 target_sim sim_df[target_user].sort_values(ascendingFalse)[1:top_k1] # 加权平均预测评分 target_vector matrix.loc[target_user] unrated_hotels target_vector[target_vector 0].index predictions {} for hotel in unrated_hotels: weighted_sum 0 sim_sum 0 for other_user, sim_value in target_sim.items(): rating matrix.loc[other_user, hotel] if rating 0: weighted_sum sim_value * rating sim_sum sim_value if sim_sum 0: predictions[hotel] weighted_sum / sim_sum # 按预测分排序取TopN top_n sorted(predictions.items(), keylambda x: x[1], reverseTrue)[:10] return top_n实际项目里比这段代码要完整得多包含了物品相似度预计算缓存、两种算法的结果融合、冷启动兜底分支。但核心逻辑就是上面这两三部曲矩阵构建、相似度计算、加权预测。只要把这段思路讲清楚面试官就知道你是真写了代码而不是拿现成文件充数。5. Django后端与Vue前端接口设计与可视化联动Hadoop跑出数据推荐算法算出结果最终都要通过Web系统呈现出来。这部分的工程质量直接决定了演示效果。5.1 Django项目结构与RESTful接口设计Django项目我采用标准的MVT加上DRFDjango REST Framework扩展后端整体变成提供JSON数据的API服务器前端页面完全由Vue接管。项目内部按功能拆分成几个app包括用户管理app、酒店数据app、推荐引擎app、数据统计app。API设计遵循RESTful风格核心接口覆盖整个系统功能面接口路径方法功能说明/api/registerPOST用户注册/api/loginPOST用户登录返回JWT令牌/api/hotelsGET酒店列表支持分页与关键词过滤/api/hotels/GET查看酒店详情/api/recommend/user_idGET获取个性化推荐列表/api/statistics/hotel-priceGET返回价格分布统计/api/statistics/region-rankingGET返回区域排行统计/api/user/ /ratingsPOST提交用户评分Django后端实现时几个关键点要特别注意。用户认证我使用simplejwt插件签发JWT令牌前端每次请求在Authorization头带上Token请求需要登录才能访问的接口时在视图函数上加permission_classes修饰。跨域问题使用django-cors-headers解决。在settings.py中配置CORS_ALLOW_ALL_ORIGINS为True开发阶段直接全放行部署时再收紧。酒店列表与统计接口使用Django的ORM查询统计结果表是MapReduce任务写入到MySQL的ORM模型和表结构完全对应查询周期极短。推荐接口内部调用推荐引擎模块先查用户评分数据再走到推荐算法代码最后返回酒店ID列表并关联出酒店完整信息。5.2 Vue前端项目结构与可视化组件开发Vue前端使用Vue 3加Vite构建相比Vue 2加Webpack体验上轻快很多。项目目录下按页面拆分为登录页、数据看板页、酒店列表页、推荐结果页、个人中心页。路由使用vue-router数据请求使用axios封装统一的request模块在拦截器里自动附加JWT令牌响应错误时统一处理提示和跳转。数据看板页是可视化的重头戏我用ECharts实现了四个核心图表。第一张地图展示不同城市的酒店数量和均价热力地图数据需要GeoJSON网上能找到免费的全国地级市GeoJSON数据加载后配置visualMap组件将均价映射到颜色深浅。第二张柱状图展示各城市酒店价格区间分布横向维度是价格区间纵向是酒店数量。第三张饼图展示酒店星级分布。第四张词云图基于Hadoop统计和分词处理后的评论热点词生成需要echarts-wordcloud扩展包。图表数据全部从后端API动态获取页面加载时统一发起请求拿到数据后通过computed属性转换成ECharts需要的格式。这里有个高频坑ECharts图表数据更新时如果使用setOption时没有设置notMerge参数旧数据容易残留。我的做法是在每次更新前先调用chart.clear()再调用setOption彻底避免数据错乱问题。5.3 前端页面与后端接口的联动调试前后端分离开发最让人头疼的就是联调阶段。前端开发服务器跑在5173端口后端跑在8000端口跨域问题无法回避。除了后端启用cors-headers外前端还需要在vite.config.js里配置devServer的proxy代理把以/api开头的请求全部代理到后端服务。export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://127.0.0.1:8000, changeOrigin: true } } } })配置完成后前端请求写/api/xxx而不是完整地址开发时完全感觉不到跨域的存在。本地开发时前后端要在两个终端分别启动后端用python manage.py runserver前端用npm run dev。联调阶段常用的技巧是先用浏览器直接访问后端API地址验证接口数据再回到前端页面调试渲染逻辑逐步定位问题出在接口侧还是界面侧。6. 常见问题与避坑经验系统开发过程中一定会遇到各种奇奇怪怪的报错我把几个最常见、最容易卡住的问题整理成清单每一条都是实打实踩过的坑。6.1 爬虫数据质量问题爬虫最大的坑是数据抓回来清洗不干净导致的连锁反应。有一版我只做了去重没做价格区间的异常过滤结果推荐算法跑出来的TopN酒店全部是单价9.9元或者99999元的异常记录。排查了大半天才定位到是脏数据问题。这里提醒大家数据清洗不是在爬虫写完以后再做而应该在字段设计阶段就同步考虑规则。每跑完一轮爬虫先打印几条样本数据肉眼检查一遍再考虑入库。6.2 Hadoop环境启动失败Hadoop启动不了大概能占到大数据方向毕设问题的一半。进程起不来先别急着翻日志按顺序排查先确认hostname是否和配置中的一致然后确认ssh免密能否通过接着确认JAVA_HOME是否配置正确最后查看logs目录下对应进程的日志文件。NameNode起不来的高频原因之一是磁盘空间不足默认存储在/tmp目录下经常跑着跑着临时文件爆掉。建议在core-site.xml里把hadoop.tmp.dir改成自己指定的目录一劳永逸。6.3 Django执行查询与删除对象时的认知陷阱Django的ORM对新手有一套隐藏的坑。用QuerySet批量删除对象时模型里重写的delete方法不会被执行只有遍历逐个删除才会触发。当时为了清理测试数据调用filter().delete()后以为自定义逻辑会走结果日志里什么都没输出排查了很久才发现是这个机制。另外执行查询时QuerySet是惰性的只有真正需要数据时才访问数据库分析性能问题时要留意数据库实际执行的查询次数。类似细节在系统设计文档里写清楚答辩时反而能成为加分点说明你对框架的运行机制有深入理解。6.4 协同过滤的推荐效果不好排查如果推荐出来的酒店用户完全不想看优先检查评分矩阵的稀疏度用户平均行为数量只有一两条的话相似度计算全凭噪声数据结果基本是随机的。解决的办法是两个一个是增加隐式评分数据把浏览、收藏行为也折算成评分另一个是K值调参K取太大把不相似的用户圈进来K取太小结果随机波动大。我最终把K定为15两种算法加权比6比4实测是平衡效果和稳定性的较优组合。6.5 Vue安装依赖与环境配置的坑Vue项目最容易卡在依赖安装阶段不同Node版本对依赖兼容性影响极大。我用了Node 18安装Vite 4加Vue 3的组合目前最稳。npm install偶尔会因为网络问题失败可以换用国内镜像源。前端报错里有一类特别常见模块类型不匹配比如某个组件用了require引入ESM模块。解决思路是统一用import语法配置package.json里的type字段为module保持代码风格一致能避免大量莫名其妙的报错。6.6 前后端联调时的鉴权问题JWT令牌过期用户被强制下线这个逻辑本身正常但前端要处理好过期后的自动刷新和跳转。我的做法是在axios响应拦截器里判断HTTP 401状态码清除本地存储的用户状态跳转回登录页并提示登录已过期。注意不要把用户手动退出登录也误判成Token过期需要根据后端返回的具体错误码区分。写在最后的一些经验分享整套系统做完我最大的体会是毕设项目的节奏控制很重要。标准化流程是先花两周时间搭好技术骨架Hadoop环境、Django项目、Vue项目全部跑通最小可用版本再花三周时间填充业务功能爬虫写完能存数据推荐算法有初步结果可视化图表有数据可画最后两周做联调、打磨界面、准备演示数据和答辩材料。前期只要把骨架搭对后面填肉非常快。最怕的就是一开始就纠结算法效果好不好、图表做的精不精美本末倒置。最后再分享一个演讲和演示的小技巧答辩前一定准备一份干净的演示数据数据量不用大但分布要有特点让算法推荐结果里有一眼就看出“这个推荐有道理”的案例。演示时从用户浏览某个酒店开始到推荐结果中出现同类酒店收尾评委对你的系统理解深度马上不一样。毕业设计这东西做完只是第一步能讲明白才是真的本事。