每年到这个时候，总有一堆学弟学妹私信我问“毕设做什么方向好”“有没有现成的源码参考”。如果你对大数据、数据分析、推荐系统这套技术栈感兴趣，又不想做那种纯理论、没法演示的题目，这个项目可以重点研究一下。Python基于Hive数据仓库的酒店数据分析与推荐系统，名字听着长，本质上就是把当下企业里最常用的几个技术点——Hadoop生态里的Hive数仓、爬虫采集、协同过滤推荐、Django后端、Vue可视化——全部串到一条完整的数据链路上。整个项目面向酒店、民宿、客栈这类住宿数据，从采集公开数据、清洗入库，到离线分析、算法推荐，再到前端大屏展示，全程可以跑通，答辩的时候从数据流讲到算法细节，再现场演示界面，内容非常能打。
我当时帮人调试过好几个类似的项目，也踩过不少坑，这篇文章就把整套东西从架构设计到落地实现、再到答辩避坑完整拆开讲清楚，适合正在选毕设题目、或者已经选了类似题目但不知道从哪下手的同学收藏。
1. 先理清楚这个毕设到底要做什么
1.1 项目的核心目标和功能模块
很多人拿到这种题目容易迷茫，因为关键词太多了：Hive、Django、Vue、Hadoop、爬虫、协同过滤、酒店数据分析、可视化……听着像要同时做五个项目。其实你拆开看，就是一个完整的“数据产品”的五层结构：
- 数据采集层：用Python爬虫从公开的OTA平台（比如携程、去哪儿、美团这类网站上对外展示的酒店信息）抓取酒店、民宿、客栈的基础信息，包括名称、价格、评分、评论数、地址、经度纬度、设施标签等。
- 数据仓库层：把爬下来的原始数据，先落一份原始备份，再通过Hive做数据清洗、转换、建模，形成面向分析的主题表，供后续查询统计。
- 离线分析层：基于Hive SQL跑各类分析指标，比如各城市的酒店均价、价格区间分布、评分分布、评论量Top榜、不同档位酒店的数量对比等。
- 推荐引擎层：基于用户行为数据（比如用户浏览过哪些酒店、收藏过哪些、评分打几分），使用协同过滤算法生成个性化推荐列表。
- 展示层：Django作为后端提供API，Vue + ECharts作为前端做可视化大屏和推荐结果展示。
说白了，这就是一个“采集—存储—分析—算法—展示”的闭环。你看这个结构就明白，它不是让你把某一个技术做得特别深，而是要求你把每个环节都打通，整体呈现一套工程化能力，这正是毕设最看重的。
1.2 技术选型为什么这么组合
先解释一下这个技术栈组合的逻辑，因为很多人不理解“为什么非要用Hive”。
先说Hive。酒店数据量大不大？说实话，你爬个几万条数据用MySQL也完全能存。但Hive的价值在于它是数据仓库的经典技术方案，跑的是SQL-on-Hadoop，底层计算引擎是MapReduce或者Tez，它代表的是大数据离线处理的标准思路。毕设用Hive，不是为了“存不下”，而是为了展示你懂数仓建模、懂HQL分析、懂Hadoop生态。而且Hive的表结构设计、分区策略、数据装载这些知识点，面试也常问，一举两得。
Django主要负责业务层和接口层。Python在数据领域生态最好，Django又是Python Web框架里最成熟、文档最全、自带Admin后台的。你不需要额外写太多胶水代码，把分析结果或者推荐结果通过ORM查出来，然后用DRF（Django REST Framework）序列化输出JSON，前端直接消费，非常顺畅。
Vue这边的定位是“轻前端”。如果你的前端功底一般，Vue比React更好上手，而且配合ECharts做可视化图表，一段配置就能画出柱状图、饼图、地图、雷达图，视觉效果好，答辩时演示很加分。
1.3 整体架构和数据流向
我直接按数据流向给你梳理一遍，这套逻辑你写进论文“系统架构”那一章完全够用：
- 爬虫程序从OTA平台抓取酒店公开信息，生成结构化JSON或者CSV文件，同时备份一份到MySQL，方便后续Django直接读取展示。
- 把清洗后的数据文件上传到HDFS，在Hive中创建外部表，完成数据装载。
- 在Hive里对原始表做ETL，生成DWD明细层表和ADS指标层表，跑各种统计SQL，结果导出到MySQL中的分析结果表。
- 用户行为数据（评分记录）进入协同过滤算法模块，用Python离线计算用户相似度矩阵或者物品相似度矩阵，生成每个用户的TopN推荐列表，写回MySQL。
- Django后端从MySQL读取分析结果和推荐列表，暴露RESTful API。
- Vue前端调用Django接口，用ECharts渲染可视化看板，同时展示针对当前用户的酒店推荐卡片。
这套流程里你最需要注意的是：Hive是“离线批处理”的思路，它算完结果后要落到MySQL里供Web系统查询。很多人一开始想把Hive直接当数据库用，让Django直连Hive，那样会又慢又别扭，正确的做法就是“Hive算完，MySQL查”。
2. 爬虫采集与数据预处理
2.1 采集目标与字段设计
爬虫这部分，目标很简单：拿到足够多的酒店/民宿/客栈数据，并且字段要能支撑后续的分析和推荐。
我建议字段至少包含这些：
- 酒店基础信息：酒店ID、名称、城市、行政区、详细地址、经度、纬度、酒店类型（酒店/民宿/客栈）、星级或档次标签。
- 价格与销量：最低价格、最高价格、评分、评论数、销量或预订量。
- 设施服务：是否含早餐、免费停车、健身房、游泳池等布尔型标签，可以转成多值字段。
- 用户关联数据：如果你的系统要做协同过滤推荐，还需要模拟或者真实采集一部分“用户行为”，比如用户ID、酒店ID、评分（1-5分）、评论内容、浏览时间。
很多同学纠结“我没有真实用户数据怎么做推荐”，我的建议是：自己构造一份比较合理的行为数据集。比如设定50个虚拟用户，让每个用户对10到20个酒店有评分行为，评分分布符合常理（高分集中在评分本身高的酒店，低分分散），然后再结合爬到的酒店特征做协同过滤。只要在论文里说明是“为演示推荐流程而构造的用户行为数据集，算法验证在公开数据集上也跑过”，这个点就能站得住。
2.2 爬虫实现的关键点
爬虫核心无非是requests/Selenium + BeautifulSoup/正则。但有几个实操细节直接决定你能不能顺利爬到数据，我一个个说。
第一，请求头必须伪装完整。很多反爬检测看的是User-Agent、Referer、Accept等头部是否像真实浏览器。你光设一个User-Agent不够，最好直接从浏览器复制完整的请求头。另外建议使用requests.Session()保持会话，模拟真实用户的浏览行为。
第二，控制请求频率。千万别用单线程连环请求，酒店平台的风控不是吃素的。我实测下来，每秒1到2个请求，每爬500条休息十几秒，比较稳妥。如果规模再大一点，就用time.sleep加随机抖动，避免访问频率形成固定规律。
第三，如果页面数据不是一次性渲染出来的（比如详情页是异步加载），直接抓HTML拿不到价格和评分，这时候用浏览器开发者工具看Network里的XHR请求，找到真正返回数据的JSON接口，直接请求那个接口，解析JSON比自己抠HTML要靠谱得多。
第四，数据清洗要在爬虫端先做一道。比如把价格里的“¥”和“起”去掉，把“5.0分”转成浮点数5.0，把地址中的空格和换行清除，经纬度如果是字符串要转成float。这些写在解析函数里，一步到位，不然爬到后面再回头清洗就很麻烦。
这里多说一句题外话：爬虫只是做技术验证，抓取范围控制在公开内容、有限规模、学习研究用途，并且严格遵守目标网站的服务条款和访问频率限制，别做大规模商业抓取，这是底线。
2.3 数据清洗与存储策略
清洗这一步看似不起眼，但直接决定Hive查询结果的准确性。酒店数据最常见的问题就是脏数据，比如：
- 价格字段有“暂无报价”或者空值，需要过滤或填充。
- 评分字段出现“暂无评价”这样的文本。
- 城市字段同一城市有不同写法，比如“北京”和“北京市”并存。
- 重复数据，同一家酒店爬了两次，需要按酒店ID去重。
清洗思路是写一个独立的Python脚本，读取原始爬取文件，做去重、类型转换、缺失值处理，然后输出两个文件：一个是清洗后的酒店明细表，另一个是用户行为表（包含用户ID、酒店ID、评分、时间戳）。
存储方面，建议做双写策略：一份存MySQL，给Django展示和推荐系统实时读；一份存本地CSV，用于后续上传HDFS进Hive。这样既保证Web端查询快，又能体现“数据进数仓”的完整流程。MySQL中建两张核心表，一张hotel_info，一张user_rating，Django的model和它们对应，后面开发会非常省事。
3. Hive数据仓库搭建与离线分析
3.1 Hadoop与Hive环境准备
如果你用的是发行版（比如HDP、CDH），环境会简单一些，但毕设一般建议直接用Apache Hadoop + Apache Hive手动搭建，这样既省钱又能把所有配置写进论文。
Hadoop我建议用伪分布式模式，就是一台机器上同时跑NameNode、DataNode、ResourceManager、NodeManager这几个进程。虽然生产环境都是集群，但毕设演示伪分布式足够，而且能完整体现HDFS的存储机制。配置文件主要是core-site.xml、hdfs-site.xml、yarn-site.xml这几个，核心就是把fs.defaultFS设成hdfs://localhost:9000，把副本数设成1，然后格式化NameNode再启动。
Hive的话，重点在于Metastore的配置。初学者最容易踩的坑就是没配好Derby或者MySQL作为元数据存储，导致启动Hive时报错“javax.jdo.JDOFatalInternalException”。我建议直接把Hive的元数据库配到MySQL，用起来稳定，重启不丢元数据。关键是在hive-site.xml里配好javax.jdo.option.ConnectionURL和驱动。
如果你的Win环境跑不起来Hadoop，那就装个虚拟机，在Ubuntu Server上部署，把快照打好，后面出问题随时回滚。网上搜“hadoop伪分布式搭建”和“hive的安装与配置”，照着做基本都能跑通。
3.2 数仓分层建模
Hive建表最能体现你有没有数仓思维，不要上来就建一堆平表，一定要分层。
我建议分三层：
- ODS层（原始数据层）：建外部表ods_hotel_info，映射到HDFS上的原始CSV文件。外部表的好处是删除表不影响原始文件，比较安全。
- DWD层（明细数据层）：把ODS的数据清洗后落到DWD表dwd_hotel_detail，加上ETL逻辑，比如过滤无效价格、标准化城市字段、拆分设施标签。
- ADS层（应用数据层）：面向具体分析需求，生成指标结果表。比如ads_city_price_stats，按城市统计酒店数量、均价、最高价、最低价；ads_hotel_topn，按评分数排序的TopN酒店。
这里说一下每个表怎么建。ODS层表的字段要和原始文件列一一对上，用ROW FORMAT DELIMITED FIELDS TERMINATED BY ','定义分隔符。DWD层表最好加上分区（比如按城市分区），这样后续分析SQL通过分区裁剪能减少数据扫描量，同时也是一个能写进论文的优化点。
数据装载很简单，用LOAD DATA INPATH把HDFS上的文件load进ODS表，然后通过INSERT OVERWRITE TABLE ... SELECT ... 做清洗，生成DWD层。整个过程全用SQL完成，非常好讲解。
3.3 核心分析指标SQL实现
分析指标这部分是答辩讲解的重点，也是可视化页面的数据来源。我给你列几个高频指标和对应的SQL思路：
第一个：城市酒店数量和均价。按city分组，COUNT(*)统计数量，AVG(price)求均价，再按均价降序排列。
SELECT city, COUNT(*) AS hotel_cnt, ROUND(AVG(price), 2) AS avg_price FROM dwd_hotel_detail GROUP BY city ORDER BY avg_price DESC;
第二个：价格区间分布。用CASE WHEN把价格分桶，比如0-200、200-500、500-1000、1000以上，每桶统计酒店数，前端用柱状图或饼图展示。
第三个：评分与价格关系。用AVG(price)和AVG(score)做相关性观察，按评分档位分组统计平均价格，能看出高评分和高价之间是否正相关。
第四个：热门区域Top10。行政区和城市组合统计评论数之和，取Top10展示，适合做地图热力图。
这些SQL写出来以后，把结果INSERT OVERWRITE到ADS层结果表，再通过Sqoop或者直接生成CSV导出到MySQL。如果不想引入Sqoop，也有个取巧的办法：在Hive命令行执行INSERT OVERWRITE LOCAL DIRECTORY，把查询结果导出到本地目录，拿到CSV后自己写个Python脚本灌入MySQL。两种方案都行，第二种对初学者更友好。
3.4 小文件治理与查询优化
这部分属于加分项，写进论文很亮眼。Hive跑批最常见的性能问题就是小文件过多，MapReduce处理大量小文件时，每个文件至少要一个Map任务，启动开销极大。你在ETL里如果用INSERT OVERWRITE TABLE ... SELECT ...，可以顺手设置合并参数：
SET hive.merge.mapfiles=true; SET hive.merge.mapredfiles=true; SET hive.merge.size.per.task=268435456; SET hive.merge.smallfiles.avgsize=16777216;
意思就是Map端和Reduce端结束时都做一轮小文件合并，目标是让输出文件平均大小在16MB以上，合并后的文件大小控制在256MB左右。这样跑下一轮查询或者后续导出的时候，效率会有肉眼可见的提升。
还有几个Hive调优点值得做：开启分区裁剪（分区表查询时WHERE里带上分区字段）、使用TEZ作为执行引擎（在hive-site.xml里设置hive.execution.engine=tez）、对常用关联字段建分桶或者Sort Merge Bucket Join。这些你都跑通以后，完全可以在论文“系统优化”章节里展开。
4. 协同过滤推荐算法落地
4.1 协同过滤的核心思想
协同过滤是推荐系统里最经典、也最适合毕设展示的算法。它核心的想法就一句话：物以类聚，人以群分。
基于用户的协同过滤（User-based CF）这么理解：如果用户A和用户B之前喜欢的酒店很相似，那么A喜欢而B没看过的酒店，有很大概率B也会喜欢。做法是，先构建用户对酒店的评分矩阵，然后计算用户之间的相似度，找到当前用户的K个最近邻，再把这些邻居喜欢的、但当前用户没交互过的酒店按预测评分排序，取TopN作为推荐。
基于物品的协同过滤（Item-based CF）反过来：如果酒店X和酒店Y经常被同一批用户喜欢，说明它们相似，那么喜欢X的用户也可能喜欢Y。它计算的是物品的相似度矩阵，推荐时直接看用户历史喜欢的酒店有哪些相似的酒店，按相似度排序推荐。
毕设里我建议两个都实现，然后做对比分析，这样论文内容更充实。你自己的理解也会更深一层。
4.2 基于用户的协同过滤实现
实现User-based CF的步骤很清楚，用Python的pandas就能搞定：
第一步，构建用户-物品评分矩阵。从MySQL的user_rating表读数据，用pivot_table转成行是用户、列是酒店的二维矩阵，没有评分的位填0。
第二步，计算用户之间的相似度。最简单也最常用的是余弦相似度。公式你自己写也很容易，就是两个向量的点积除以模长的乘积。在pandas里可以直接用cosine_similarity，sklearn的metrics.pairwise里有现成的。
第三步，找邻居并预测评分。对目标用户u，从相似度矩阵里取TopK个相似用户（比如K=10），然后对u没有评过分的酒店i，用这K个用户对i的评分的加权平均来预测：
pred(u, i) = Σ(sim(u, v) * rating(v, i)) / Σsim(u, v)
这里需要注意一点：只有v对i有过评分才能参与计算，如果没有一个人评过i，那预测值直接不出来，这种酒店就不进推荐候选。
第四步，生成推荐列表。把预测评分排个序，去掉用户已经住过或者已经评分过的酒店，取前20个，写入MySQL的recommendation表。前端从这张表取数据渲染推荐卡片。
4.3 基于物品的协同过滤与混合推荐
Item-based CF和User-based CF的代码结构高度对称，区别只是把矩阵转置之后做相似度计算。但它的推荐逻辑更直观，也更适合电商类场景：比如用户看过一家“杭州西湖边的民宿”，系统就推荐“同样在西湖边、评分相似”的其他民宿。实现上，你把评分矩阵转置，变成“酒店-用户”矩阵，然后计算酒店之间的余弦相似度。推荐时，找到用户评分过的酒店列表，取每个酒店最相似的TopN酒店，加权汇总去重，生成推荐列表。
为了论文好看，你可以在离线评估里做一个对比：用交叉验证分别计算User-based CF和Item-based CF的RMSE或MAE，看哪个误差更低。不同的数据集上两者胜负不一定，你只要如实把实验结果写出来，讨论一下差异原因，比如“UserCF在兴趣变化快的场景更好，ItemCF在物品数远小于用户数时计算成本更低”，这个深度就已经超过大部分本科毕设了。
4.4 冷启动与效果优化
推荐算法最怕的就是冷启动。新用户没有任何行为数据，协同过滤算不了；新酒店没人评分，也没法被推荐。你可以在系统里加一个简单的“热度推荐”兜底：新用户没有行为数据时，直接推荐评论数最多、评分最高的酒店，也就是统计意义上的热门榜。前端展示的时候可以加一个标签“热门推荐”，从交互上看体验也很合理。
此外，我当时调试时还发现几个容易被忽略的细节，现在写给你：
- 评分矩阵稀疏度太高时，余弦相似度可能给“只有一次共同评分”的用户对打出虚高的相似度分。解决办法是过滤掉共同评分项少于3个的用户对。
- 相似度归一化。算出来的相似度值域可能差异很大，最好对相似度做Min-Max归一化再参与加权预测，不然预测值容易集体偏高或偏低。
- 离线评估一定要做。把用户行为数据随机拆成训练集和测试集，比如80%训练20%测试，在测试集上算RMSE，让推荐效果有数字支撑。不建议只做demo然后说“效果好”，答辩老师一追问就露怯了。
5. Django + Vue 可视化平台开发
5.1 Django后端接口设计
Django这部分，项目结构建议用官方推荐的分层方式：一个project下面建两个app，一个叫analysis，负责提供统计图表数据接口；另一个叫recommend，负责推荐相关的接口。这样代码职责清楚，答辩讲解也方便。
models.py里要建和MySQL对应的模型，最核心的是HotelInfo和UserRating两张表。用Django ORM查数据非常省事，比如查各城市酒店均价，一条ORM聚合就把活干了。
接口设计遵循RESTful风格，给Vue前端提供JSON。我建议装djangorestframework，然后用serializers序列化Model数据。比如酒店列表接口：
class HotelSerializer(serializers.ModelSerializer): class Meta: model = HotelInfo fields = 'all'
视图里用ListView，queryset从HotelInfo取，再加上filter_backends和filterset_fields，分页一开，前端做筛选就很方便了。分析接口也类似，比如城市价格分布接口，从MySQL分析结果表读数据，按城市返回价格区间、平均价、酒店数。
跨域问题一定要提前处理：Django跑在8000端口，Vue跑在5173端口，两边域名不一样，浏览器会拦截请求。解决方案就是装django-cors-headers，在settings.py里配置CORS_ALLOWED_ORIGINS，把前端地址加进去。这个坑几乎人人都会踩，别等到联调时才一脸懵。
5.2 Vue前端与可视化图表
Vue端的技术要求其实不高，核心就是“会用Vue组件化思想组织页面 + 会配ECharts”。我建议直接用Vue CLI（或者Vite）脚手架创建项目，装好vue-router、axios、echarts这三个依赖就可以了。
页面结构可以做成三块：
- 概况看板：放几个核心指标卡片（总酒店数、平均价格、最高评分、总评论数），下面俩图表，一个是“城市酒店数量Top10”柱状图，一个是“价格区间分布”饼图。
- 区域分析页：一个中国地图热力图，展示各城市酒店密度，点击城市下钻看该城酒店列表和详细统计。
- 推荐展示页：根据当前用户ID，请求Django的推荐接口，展示TopN推荐酒店卡片，卡片带酒店图、价格、评分、标签，还有“为什么推荐”的解释性文案，比如“因为您喜欢西湖周边的民宿”。
图表实现上，ECharts只需要在mounted钩子里初始化echarts.init，然后setOption。图表数据从axios请求拿到后动态填入option，再setOption刷新。如果你觉得手动维护option太繁琐，可以用vue-echarts封装一层，把option作为prop传进去，代码会更干净。
5.3 前后端联调与部署
联调时最烦的问题就是接口地址写死。建议在Vue项目的.env.development里配置API_BASE_URL，axios的baseURL取这个环境变量，后端地址变了只改一个文件。开发模式下Vue CLI自带代理转发，在vue.config.js里把'/api'前缀的请求代理到localhost:8000，这样前端代码里就写相对路径，不用处理跨域。
如果你要打包部署，步骤也很简单：前端npm run build生成dist目录，Django里配置静态文件路径把dist指过去，然后用Django直接托管静态资源。或者更简单的方式，把dist放到Django的static目录，写一个TemplateView指向index.html。这样整个系统可以以Django为单一入口跑起来，演示时不用开两个终端窗口，效果更好。
不过这里有个坑要提醒：Vue是单页应用，刷新的时候如果直接访问某个前端路由（比如/recommend），Django那边没有对应路由会报404。解决办法是给Django加一个URL规则，把前端路由的路径都指向那个TemplateView，或者让Vue用hash模式的路由（history: createWebHashHistory()）。对这个项目来说，用hash路由是最省事的解。
6. 高频问题与答辩避坑实录
6.1 环境配置高频问题
这几年帮人调试这类项目，环境配置阶段的问题是最多的，而且翻来覆去就是那几类。
第一，Hadoop起不来。最常见的是NameNode格式化之后又启动，报“NameNode is already formatted”。很多教程会让你先格式化再启动，但如果你之前已经格式化过一次，下次启动前就不要重复格式化，否则NameNode的clusterID和DataNode不一致，会一直报错。解决办法是把HDFS的tmp目录删掉，从头格式化一次，再启动。
第二，Hive连不上元数据库。如果你用了MySQL做Hive的Metastore，报错多半是“Unable to instantiate org.apache.hadoop.hive.metastore.HiveMetaStoreClient”。这时候先排查MySQL是否能连上，再检查hive-site.xml里驱动类名和连接URL，最后看MySQL里hive用户是否授权了。一个常见坑：你在hive-site.xml里写了“localhost”当JDBC地址，但Hive服务和MySQL在同一台机器上也分情况，建议直接用127.0.0.1，避免主机名解析问题。
第三，Python和Django版本不匹配。Django新版本对Python版本有要求，比如Django 4.2要求Python 3.8以上，Django 5.0要求3.10以上。建议用conda建一个虚拟环境，Python 3.9配Django 3.2或者4.2，这样最稳。裸机装环境出各种奇怪问题，真的是年轻人才受得住的罪。
6.2 项目运行中的典型报错
爬虫阶段遇到最多的：请求返回403。这基本就是被反爬拦截了，先检查User-Agent，再降低请求频率，实在不行就加随机延时和重试机制。我用过的最稳方案是把常用的几个UA列表放数组里，每次请求前random.choice一下。
Hive阶段遇到最多的：LOAD DATA之后select查不到数据。多半是表的SerDe和文件实际分隔符不匹配。比如你用默认的LazySimpleSerDe，但文件是用制表符分的，那Hive会把整行当一个字段。检查一下文件实际分隔符，建表时写对FIELDS TERMINATED BY对应的字符。
Django阶段遇到最多的：前端能打开但请求500。开Django调试模式，先看控制台报错内容，一般是不存在列名、ORM写错字段、或者数据库里的表和model不一致。这里有个墙裂建议：改model之后一定要跑python manage.py makemigrations和python manage.py migrate，别手动去MySQL里改表结构，不然ORM和数据库结构不一致，各种奇怪报错都是这么来的。
推荐计算阶段遇到最多的：结果全是NaN或者推荐列表为空。主要原因是评分矩阵全零——说明用户行为数据里没有匹配到酒店ID，或者矩阵转置后维度不对。检查一下user_rating表里hotel_id是不是真的能在hotel_info表里join到。我调试时还碰过相似度矩阵对角线全1、非对角线全0的情况，这就是数据太少导致的“所有用户之间没有共同评分”，可以把行为数据再补一些，让每个用户平均至少有10条评分记录。
6.3 答辩演示的重点与讲解思路
答辩演示环节要突出“链路完整”，不要只讲UI和代码。我会建议你把现场演示按这个顺序走一遍：
- 先展示爬虫模块的代码和采集结果文件，说明采集字段、清洗逻辑、数据量规模。
- 打开Hive命令行，跑几条核心分析SQL，展示结果，说明数仓分层和查询结果如何进入MySQL。
- 打开Django后台或者API文档页面，展示接口返回的JSON数据，证明“数据链路是通的”。
- 展示Vue可视化看板，把前端图表和你刚才在Hive里跑的SQL结果对应起来，让老师看到“图表数据确实来自Hive分析”。
- 最后展示推荐结果，输入一个用户ID，展示推荐列表，然后结合协同过滤原理现场解释“为什么给这个用户推荐这几家酒店”。
答辩时老师最爱问的其实就几个问题：Hive和MySQL的区别是什么？协同过滤冷启动怎么解决？你们的数据量多大，算法评估指标是多少？每个问题前面都已经有对应内容，你只要把“离线计算、在线查询”这个架构逻辑讲清楚，把RMSE数值张口就来，基本的从容就有了。
最后再说一个很多同学会忽略的细节：答辩现场的演示环境一定要提前两天完整跑一遍流程，包括Hadoop、Hive服务重启、Django启动、Vue打包。我曾经见过现场Hive服务起不来，老师让我直接展示论文中的截图，场面一度很尴尬。你把所有服务开机自启配好，或者写一个一键启动脚本，到时候能省去大量手忙脚乱的时间。
