Hadoop+Spark+Hive酒店推荐系统毕设实战：从爬虫到可视化全流程

计算机毕业设计选了“Hadoop+Spark+Hive酒店推荐系统”，听起来就是一个典型的“大数据全家桶”组合。很多同学看到这个题目第一反应是：终于有个能写进简历的大数据项目了，但真拿到手又有点慌——爬虫怎么写、数据怎么存、推荐怎么算、最后怎么演示，每个环节都是一道坎。我当时带人做这个题的时候，走完一遍才发现，它根本不是“写个推荐算法”那么简单，而是一条从数据采集到数据仓库、再到离线计算和可视化的完整流水线。

这篇内容就是围绕这个题目，把整条链路拆开揉碎了讲清楚。不管你是刚拿到这个毕设题目、准备自己从零写，还是已经在调试网上下载的源码包，这篇都能帮你把每一块逻辑顺明白，知道每一步在做什么、为什么这么做、踩坑点在哪。

1. 这个毕设题目为什么值得做——先把项目定位搞清楚

1.1 题目拆解：这不是一个“推荐系统”，而是一条完整的数据流水线

先别急着写代码。拿到这个题目，第一件事是搞清楚它到底考你什么。从标题上看，它把“Hadoop+Spark+Hive”直接放在项目名前缀，说明出题方或答辩老师想看到的，是“你有能力把分布式的存储和计算框架真正用起来”，而不只是写一个能跑出推荐结果的Python脚本。

拆开看，它其实包含四大模块：

• 数据采集层：酒店爬虫，把公开网页上的酒店名称、价格、评分、评论、位置等信息抓下来。
• 数据存储层：Hadoop HDFS做分布式存储，Hive建数仓表，把原始数据变成能分析的结构化数据。
• 计算与推荐层：Spark从Hive里读数据，做特征处理，跑协同过滤推荐算法，产出“猜你喜欢”的酒店列表。
• 可视化与业务层：把统计结果和推荐结果通过Web页面展示出来，形成“能看”的酒店数据可视化大屏和推荐页面。

说白了，这就是一个涵盖了大数据全链路的小型离线数仓项目。它不是那种单机跑个Python脚本就结束的课设，而是每一步都在“大数据”的语境下工作。这个定位想明白了，你就知道后面每个模块的选型和实现方式都该往哪个方向走。

1.2 技术选型为什么是这“三大件”而不是别的

很多同学会问，做个酒店推荐，我用Python加Pandas加一个Flask页面不香吗？答案当然是香，但那是“数据分析作业”，不是“大数据毕业设计”。毕设题目里点名Hadoop、Spark、Hive，就意味着你必须在分布式环境下完成数据存储和计算，这套选型本身就是题目要考核的重点。

具体拆一拆这三者的分工：

• Hadoop：负责底层存储（HDFS）和资源调度（YARN）。你爬到的几百兆或几个GB的原始数据、清洗后的数据，都放在HDFS上，而不是本地磁盘。
• Hive：把HDFS上的结构化文件映射成二维表，用类SQL语法（HiveQL）做数据清洗、过滤、统计。它解决了“分布式文件系统上怎么查数据”的问题——你不用写MapReduce，写SQL就行。
• Spark：负责更重的计算任务，比如跑ALS协同过滤推荐算法。Hive做ETL和简单统计没问题，但跑机器学习类的迭代计算，还是Spark的强项。Spark可以从Hive表里直接读数据，和Hive是无缝衔接的。

从任务分工也能看出来，这不是“资源重复”，而是“各干各的专业活”。我见过不少同学把题目改成“简单版”：爬虫爬完数据存MySQL，Python算推荐，ECharts做可视化。这样也能交，但答辩时老师问“你的Hadoop呢”，你只能回答“没用到”，这分数就不好看了。

提示：如果你的机器配置一般，可以合理选择“Hadoop伪分布式+Hive本地模式+Spark Local模式”的组合。只要代码逻辑是分布式思路，展示效果不差反稳。后面我会专门讲环境怎么取舍。

2. 数据从哪来：酒店爬虫模块实战拆解

2.1 爬虫目标与合规边界

爬虫是整个项目的数据源头，也是很多同学觉得“最没技术含量”但实际坑最多的环节。先明确爬什么：以酒店信息为例，通常需要四个维度的字段：

• 基础信息：酒店名称、地址、商圈、星级、经纬度
• 价格信息：最低价、房型价格区间
• 评价信息：评分、评论数、好评率
• 特色标签：“近地铁”、“含早餐”、“免费取消”等

这些信息一般分布在OTA（在线旅游平台）网站的列表页和详情页。爬虫的设计上，优先抓列表页，详情页可以用异步接口或详情页二次请求来补数据。这里必须提醒一句：爬虫模块要严格注意合规问题。毕业设计属于学习研究用途，爬取时可以抓公开可见的数据，但要尽量降低请求频率、控制并发，不要对目标站点造成压力，更不能把数据用于任何商业用途。

我建议在代码里显式设置请求间隔，比如每抓一页sleep 1到3秒，并设置合理的User-Agent和Referer。这既是保护自己，也是让数据采集过程更接近真实的工程实践——一味模仿搜索引擎的抓法很容易被限制。

2.2 爬虫实现的核心步骤

以Python为例，爬虫从零实现分四步：

1. 分析目标页面结构，确定列表页URL规律。
2. 用requests库请求页面，拿到HTML内容，处理编码和Cookie。
3. 用BeautifulSoup或XPath解析HTML，提取字段。
4. 清洗字段后存成结构化文件（CSV或JSON），供后续上传HDFS。

import requests from bs4 import BeautifulSoup import time import csv headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" } def fetch_hotel_list(page): url = f"https://example-hotel-site.com/list?city=beijing&page={page}" resp = requests.get(url, headers=headers, timeout=10) resp.encoding = "utf-8" soup = BeautifulSoup(resp.text, "html.parser") hotels = [] for item in soup.select(".hotel-item"): name = item.select_one(".name").text.strip() price = item.select_one(".price").text.replace("¥", "").strip() score = item.select_one(".score").text.strip() hotels.append([name, price, score]) return hotels with open("hotels.csv", "w", newline="", encoding="utf-8") as f: writer = csv.writer(f) writer.writerow(["name", "price", "score"]) for page in range(1, 20): rows = fetch_hotel_list(page) writer.writerows(rows) print(f"page {page} ok, got {len(rows)} items") time.sleep(2)

这里有一个很关键的点：如果只爬静态HTML，用requests加BeautifulSoup就够了，不需要上Selenium，因为Selenium会启动浏览器，爬1000条数据要等很久。但有些站点数据是异步加载的，HTML里只有空壳，这时可以在浏览器开发者工具里找到真实的XHR接口，直接请求那个JSON接口，解析速度反而快得多，也稳定得多。

2.3 清洗与落地的几个关键点

爬下来的数据是脏的，不能直接进数仓。常见问题有：

• 价格字段里有“¥”、逗号、“起”等多余字符，要去掉后转成浮点数。
• 评分字段可能是“4.5分/1032人评价”，要把分数和评论数拆开。
• 缺失值：有些酒店没有星级或标签，需要考虑默认值填充或删行。
• 重复值：同一个酒店在列表页可能出现多次，应该按酒店名称或平台ID去重。

清洗逻辑可以用Pandas写一次性的预处理脚本，也可以把清洗逻辑放到Hive的SQL里做。我的建议是先做一层简单清洗，保证数据格式能解析，剩下的字段规整放到Hive ETL阶段，这样你答辩时可以说“清洗采用了前置脚本+数仓ETL双层方案”，这比单层方案听起来完整得多。

3. 数据仓库与离线批处理：Hive + Hadoop 在这里到底干什么活

3.1 数据落地到HDFS：为什么不用MySQL直接存

爬虫产出的是CSV或JSON文件，接下来就是把它送进数据仓库。这里很多同学会犯一个“惯性错误”：直接把数据分批INSERT到MySQL，然后Hive表用JDBC映射MySQL。这样当然能跑通，但绕了一大圈，Hadoop就变成了纯摆设，答辩时一问就露馅。

正确的做法是：把清洗后的文件先PUT到HDFS的指定目录，然后用Hive建一个外部表指向这个目录。这不是为了炫技，而是因为HDFS本身就是为海量文件存储设计的。爬虫单机跑了1000条数据，你可能觉得MySQL也没问题，但毕设的“种子数据”完全可以多爬几万条，模拟真实场景。HDFS的分布式存储和副本机制，就是为了解决这个问题存在的。

上传HDFS的命令非常简单：

hdfs dfs -mkdir -p /user/hotel/raw/hotel_info hdfs dfs -put /root/hotels.csv /user/hotel/raw/hotel_info/

不过在实际操作中，我发现一个更好的做法是：写一个Shell脚本或Python脚本，自动完成“清洗->上传HDFS->执行HiveSQL建表”。手动一条命令一条命令敲，第一次可以，复现和写文档时会特别痛苦。自动化之后，整个流程的复现成本就低很多，也体现了工程能力。

3.2 Hive建表与ETL：表结构设计、分区、数据清洗

数据进了HDFS，接下来就是Hive出场。先设计原始表，再用SQL清洗生成业务表，这是数仓分层的标准思路。

-- 原始数据表，直接映射CSV文件 CREATE EXTERNAL TABLE IF NOT EXISTS hotel_raw( name STRING, price STRING, score STRING, comment_num STRING, address STRING, star STRING, tags STRING ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS TEXTFILE LOCATION '/user/hotel/raw/hotel_info'; -- 清洗后的业务宽表 CREATE TABLE hotel_clean AS SELECT name, CAST(REPLACE(price, ',', '') AS DOUBLE) AS price, CAST(split(score, '分')[0] AS DOUBLE) AS score, CAST(REPLACE(comment_num, '条评价', '') AS INT) AS comment_cnt, address, CASE WHEN star = '' THEN '未知' ELSE star END AS star, tags FROM hotel_raw WHERE name IS NOT NULL AND price IS NOT NULL;

这里有三个细节值得注意：

第一，为什么外部表用STORED AS TEXTFILE？因为原始CSV就是文本格式，Hive直接读最省事。到了清洗后的表，如果想追求查询性能，可以改成STORED AS ORC，加压缩，跑起来快很多。

第二，为什么要做“原始表”和“清洗表”两层？因为数仓的核心思想就是“原始数据不动，通过ETL产出分析层”。这在简历和毕设文档里都是标准写法，也方便回溯问题。

第三，实际用Hive做主键去重时，ROW_NUMBER()窗口函数是最好用的：

CREATE TABLE hotel_dedup AS SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY name ORDER BY score DESC) AS rn FROM hotel_clean ) t WHERE rn = 1;

这样按酒店名称分组，每个酒店只保留一条评分最高的记录。比group by后再join老半天高效得多。

3.3 Hadoop/YARN资源调度的坑：小文件、内存、堆内存

这个模块里，我见过最多的问题不是SQL写不出来，而是环境本身各种爆雷。说几个高频症状：

• “Job has failed”或者“Container killed by YARN for exceeding memory limits”：多半是YARN分配的内存不够。伪分布式模式下，MapReduce任务默认1GB内存，但虚拟机只给了2GB，很容易挂。解决方法是调小每个容器的内存。

• 文件数量特别多、任务参数反复拉满：爬虫如果按天存储，一个文件夹几千个小文件，Hive跑起来元数据压力很大。建议在清洗后用INSERT OVERWRITE合并一次，或者在上传前用pandas合并分片。

• SSH和端口问题：Hadoop启动后，如果DataNode和NameNode起不来，先检查hostname映射、免密钥登录、防火端口。我见过很多同学卡在“start-dfs.sh”之后jps一看少了个进程，结果只是没配置HADOOP_HOME的环境变量。

经验之谈：如果你是在自己的笔记本上跑，不要死磕“完全分布式三台虚拟机”。伪分布式模式跑通全流程，性价比最高。但伪分布式不代表你代码上可以“单机化”，该用HDFS Path的地方不要写本地路径，该用SparkSession读Hive表的地方不要用Pandas read_csv。

4. 推荐模块：Spark 协同比矩阵分解更现实

4.1 推荐到底用什么算法：从协同过滤到ALS

酒店推荐系统的核心算法，大多数毕设都会选“协同过滤”，这几乎是这一类题目的标准答案。原理很直白：通过用户的历史行为（比如浏览、收藏、预订酒店），找到和他口味相似的其他用户，或者找到他喜欢酒店的相似酒店，然后把相关酒店推荐给他。

在Spark MLlib里，落地最方便的是基于ALS（交替最小二乘法）的矩阵分解协同过滤。ALS会把“用户-酒店评分矩阵”拆解成两个低维矩阵，分别用隐因子表示用户偏好和酒店特征。它不需要你做特别复杂的特征工程，只需要一份“用户ID-酒店ID-评分”三元组，就能训练出可用的推荐模型。

为什么选ALS而不是基于物品的协同过滤或基于内容的推荐？原因有两个：

• ALS在Spark里有现成实现，可以直接调库，代码量小，效果可控。
• 矩阵分解是推荐系统中的经典模型，算法原理答辩时好讲清楚，不像深度学习模型那样容易被老师追问到答不上来。

当然，如果老师问“为什么不用深度学习”，你可以答：离线推荐场景下，ALS在数据量适中时表现不弱于深度模型，而且工程实现简单、可解释性强。这在工程落地时是实打实的优势。

4.2 Spark ALS 的实操参数细节

用Spark跑ALS，核心代码通常长这样：

from pyspark.sql import SparkSession from pyspark.ml.recommendation import ALS from pyspark.ml.evaluation import RegressionEvaluator spark = SparkSession.builder \ .appName("HotelALS") \ .enableHiveSupport() \ .getOrCreate() # 从Hive读用户行为表 ratings = spark.sql("SELECT user_id, hotel_id, rating FROM user_hotel_rating") train, test = ratings.randomSplit([0.8, 0.2], seed=42) als = ALS( userCol="user_id", itemCol="hotel_id", ratingCol="rating", coldStartStrategy="drop", rank=10, maxIter=10, regParam=0.1 ) model = als.fit(train) predictions = model.transform(test) evaluator = RegressionEvaluator( metricName="rmse", labelCol="rating", predictionCol="prediction" ) rmse = evaluator.evaluate(predictions) print(f"RMSE = {rmse}")

这里有几个参数需要认真调：

• rank：隐因子个数。rank太小，模型表达能力弱；rank太大，训练慢且容易过拟合。冷启动场景下，从8到12起步比较稳。
• maxIter：迭代次数，一般10到20次就够了，再多收益很小。
• regParam：正则化参数，用来防止过拟合，一般从0.01到0.1之间网格搜索。

我还想特别说下coldStartStrategy="drop"这个参数，它表示遇到冷启动用户或物品时，直接丢弃预测结果，而不是给个NaN。这是Spark ALS的一个经典坑：默认策略会产生很多NaN预测，导致评估指标全是NaN，看起来像模型坏了，其实只是参数没设。

4.3 冷启动问题怎么处理

协同过滤面前有一个绕不开的问题：新用户没有行为数据，新酒店没有评分记录，算法推荐不出来。这个在答辩时几乎必问。

我的处理思路是加一层“兜底策略”。当用户没有历史行为、ALS无法给出个性化推荐时，就回退到热门酒店推荐：按评分人数降序排序，取前N个，或者按城市、价格区间做条件筛选。这样接口永远有数据返回，用户在页面上也始终能看到推荐内容。

具体实现上，可以在Spark里先算一个热门表：

SELECT hotel_id, COUNT(*) AS cnt, AVG(score) AS avg_score FROM user_hotel_rating GROUP BY hotel_id ORDER BY cnt DESC LIMIT 20;

然后代码里判断ALS模型的输出结果，若为空就查这张热门表。这种规则与算法结合的方案在真实工业界也很常见。

5. 可视化与系统整合：给答辩老师看到的东西

5.1 可视化框架选择：ECharts 最快出效果

可视化是毕设的“门面”。老师第一眼不看你的HDFS文件目录，也不看你Spark日志，而是先看你的展示页面效果。酒店可视化页面，常见的图表有这么几类：

• 全国/某城市酒店数量Top10柱状图
• 酒店价格区间分布饼图
• 酒店评分分布直方图
• 热门酒店推荐列表
• 酒店地址分布的中国地图/省市级地图热力图
• 用户推荐结果展示卡片

框架方面，ECharts是我最推荐的。它上手快，示例库丰富，能直接套模板改数据，不需要写复杂的前端逻辑。如果你不想手撸原生JavaScript，可以直接用Vue或Uniapp配合ECharts组件，也可以直接写一个HTML页面引入ECharts CDN。

5.2 前后端接口与展示逻辑

可视化数据从哪来？两种常见做法：

1. 在Hive里跑统计SQL，把结果导出成JSON或CSV，前端直接读静态文件展示。
2. 写一个后端服务（Spring Boot、Flask或FastAPI），后台用Spark/Hive跑任务，结果存到MySQL或缓存中，前端通过接口动态请求。

第一种做法简单，适合快速出效果；第二种做法更接近真实项目，适合写进“系统设计”章节。我个人建议：统计图表可以用静态JSON，但“推荐结果”这个功能必须做成动态接口，因为推荐结果和当前登录用户有关，不能写死。

接口设计上，后端至少暴露这几个API：

• /api/hotel/stats：返回价格分布、评分分布、城市Top等统计数据
• /api/recommend?userId=xx：返回ALS模型训练出的推荐酒店列表
• /api/hot：返回热门酒店列表

前端页面用Ajax或Axios调接口，拿到数据后setOption渲染ECharts图表。这个链路一旦跑通，整页就能“活”起来。

5.3 打包部署与答辩演示要点

毕设答辩演示时，最大的风险是现场启动不了环境。我见过太多同学在答辩前五分钟还在敲start-dfs.sh，结果集群起不来。这里有几个非常实用的建议：

• 提前把环境启动好，用快照或恢复脚本，避免演示现场临时配置。
• 准备一套“演示数据”和“演示模型”，不用现场重新训练。可以提前把ALS模型保存到磁盘，展示时直接加载，秒出推荐结果，比现场跑10分钟训练强太多了。
• 页面优先展示“效果图”类内容。先放可视化大屏，让老师有个直观印象，再逐步讲到Hive SQL、Spark代码、爬虫脚本，这样讲解节奏是“从宏观到微观”，比反着讲效果好。

还有一个容易被忽视的细节：演示时不要暴露本地绝对路径和数据量过小的“破绽”。比如你爬虫只爬到50条数据，老师问“怎么证明你这个系统能处理大数据量”，你不一定非要现场生成100万条数据，但可以说清楚你的架构设计支持横向扩展，并给出在测试环境下处理的数据量对比结果。

6. 常见问题与踩坑实录

6.1 环境安装与启动阶段

这段是毕设路上最大的坑区。我把它整理成一个速查表，遇到问题直接对照排查：

特别提醒一下：Hadoop的hostname和hosts配置，我建议从一开始就固定下来。很多同学安装时没有统一规划，导致后面Spark和Hive拿到的主机名不一致，各种连接不到。第一次安装时多花十分钟做配置检查，后面能省下几小时的排错时间。

6.2 数据与业务逻辑的坑

爬虫爬下来的数据，经常出现“看起来能入库、算起来就崩”的情况，这里有几个稳定的坑：

• 价格字符转数字报错：“价格像283元起”，直接CAST必然会失败，应该先用正则提取数字部分。
• 评分字段存在缺失：ALS训练数据要求rating列不能为null，建议建模前过滤掉空值，或用平均值填充。
• 用户ID重复：如果爬到的用户行为数据里有大量重复浏览记录，ALS对重复样本的权重会异常，训练时间成倍增加，推荐效果也会偏差。可以先按(user_id, hotel_id)做一次汇总，取平均分。
• 数据倾斜：如果某个城市的酒店数量特别多，Spark处理时可能出现一个Executor撑死、其他Executor饿死的情况。可以加盐重分区或调整并行度来缓解。

实操心得：我建议在你把爬虫和Hive打通后，先做一次“全链路冒烟测试”，就是从爬虫到可视化只用一个很小数据集跑通，确认每个环节的输入输出格式都对，再批量爬完整数据。这个“先跑通再跑量”的习惯，能救很多人的命。

6.3 推荐结果质量差怎么办

很多同学训练完模型，发现推荐出来的酒店跟用户实际兴趣关系不大。这时先别怀疑算法选错了，按顺序排查：

• 评分数据稀疏度是否过高：如果90%的用户只对1家酒店有过评分，矩阵分解很难学到有效特征。这里可以适当增加用户行为数据，或把“收藏”“浏览”这些行为也转成隐式评分。
• 归一化是否做对：评分数值范围如果是0到100，ALS默认会把输出压到某个区间，导致评估指标和展示结果很奇怪。建议评分统一为1到5分制。
• 有没有做数据过滤：如果大量酒店没人评过分，ALS对它们的隐因子向量基本是随机初始化，推荐出来自然乱。可以先过滤掉交互数过少的酒店。

真要在答辩前快速改进展示效果，还有一个万金油技巧：对ALS推荐结果做“规则后处理”，比如保底过滤掉评分低于3.5分的酒店，再按价格区间排序。这样推荐列表看起来会更“合理”，也更容易讲故事。

7. 这次做毕设我学到的三件事

如果你也是今年做这个题目，或者已经在折腾大数据的路上，我想说几句掏心窝的话。

第一，别被“全家桶”吓到。Hadoop、Spark、Hive听起来门槛高，但它们的核心思想都是“把大问题拆成小问题，分给多台机器一起算”。你只要先跑通一个最小版本，再慢慢往里面加模块，这个项目并没有想象中那么可怕。

第二，毕设项目最重要的是“完整闭环”。哪怕你的数据量不大，算法很简单，只要把“爬虫—存储—计算—推荐—可视化”这条链路完整跑通，每一步的输入输出都交代清楚，这就是一个合格的大数据毕设。反过来，如果你只写了5000行算法代码但没有数据支撑，老师反而会觉得不落地。

第三，也是最容易被低估的一点：一定要把“踩坑记录”留好。你在Hadoop配置、Hive SQL、Spark调参过程中遇到的所有问题，不仅是你答辩时的谈资，也是你未来面试时的素材。网上那些写得好的大数据博客，几乎没有一篇不是从真实的坑里爬出来的。你这次踩的每一个坑，都可以变成下一份Offer的垫脚石。