每年到了毕业季都有不少人卡在小说推荐系统这类题目上。选了这个题的人十有八九是奔着HadoopHivePySpark这套大数据组合去的——听着硬核、答辩有的聊但真动手之后才发现这里的坑一个比一个深爬虫爬下来一堆脏数据、Hive里小文件多到查不动、PySpark的ALS调参调到怀疑人生、可视化数据跟网页对不上。这篇文章把我自己完成这个项目时踩过的坑、试出来的方案、以及源码和文档里的设计逻辑全部摊开讲从技术选型、系统架构到爬虫采集、数仓建模、推荐算法、图表展示一条链路串下来。准备做这个题目或者正在做相关毕设的同学可以直接照着抄作业。1. 这套技术栈是怎么选出来的Hadoop、Hive、PySpark各管哪一段先说结论这个项目并不是为了用大数据而用大数据而是整套系统里确实有不得不分布式处理的环节。选型之前要搞清楚每层组件在干什么否则答辩时老师问一句为什么这里用Hive不用MySQL你答不上来就尴尬了。1.1 三个组件各自的职责边界我最初的设计是爬虫抓完小说数据后直接写到MySQL然后后端读取MySQL做推荐和展示。后来发现这个思路走不通——小说正文加上用户行为日志动辄几百万条记录单机MySQL做复杂聚合查询比如按分类统计、按热度排行、跨时间段对比非常吃力而且爬虫每天增量更新数据一旦膨胀后续跑SQL会越来越慢最终会卡在原始数据能存但分析不动的尴尬局面。换成Hadoop这套组合之后逻辑清晰了很多HadoopHDFS YARN负责底层存储和资源调度。爬虫抓下来的原始小说数据、用户行为日志全部落进HDFS。HDFS的块存储和副本机制保证了数据不丢而且扩容方便。我当时用了三台虚拟机搭了一个小集群存储上完全没操心过。Hive负责离线数据仓库。原始数据不能直接拿来喂推荐算法需要清洗、转换、聚合。用Hive SQL做ETL非常顺手比写MapReduce效率高一个量级。它的核心价值是把SQL翻译成分布式作业让数据分析的门槛大幅下降。PySpark负责推荐算法训练和特征加工。ALS协同过滤算法在MLlib里有现成实现用PySpark调用比用Scala写更省事而且可以直接读Hive表省去了数据来回导的麻烦。这套组合的逻辑就是Hadoop存Hive洗PySpark算。三者各有侧重没有重叠。如果只用了Hadoop而不用Hive你写MapReduce清洗数据会累死如果不用PySpark而用别的框架ALS算法就得自己实现工作量直接翻倍。1.2 数据在系统里是怎么流转的从顶层看整个项目的数据流大概分五条线我建议你画图的时候也按这个顺序画答辩最清楚爬虫模块定时抓取小说网站的列表页和详情页采集书名、作者、分类、字数、评分、简介、正文等字段。原始数据以JSON或Parquet格式写入HDFS指定目录按日期分区。Hive的外部表映射这些目录通过ETL脚本生成干净的ODS层表再做轻度的清洗和标准化得到DWD层表。PySpark读取DWD层的用户打分和小说信息表训练ALS推荐模型产出用户-小说推荐列表和相似小说列表。推荐结果从Hive导出到MySQL供后端实时查询后端接口返回给前端用ECharts做可视化展示。这套链路里有个容易被忽略的点**Spark的推荐结果为什么要导回MySQL而不是直接让前端查Hive**因为前端页面需要秒级响应查询HDFS上的数据要走YARN任务启动开销太大用户体验很差。MySQL才是面向展示的存储HDFS只是面向分析的存储。这个设计思路在答辩时非常加分说明你理解不同存储引擎的适用场景。2. 小说爬虫采集链路的设计与合规细节爬虫模块是整个数据链条的源头数据质量直接决定后面推荐效果。我见过很多人栽在爬虫上最常见的问题就是要么爬下来一堆乱码要么字段丢得七零八落要么爬一半被目标网站封了IP。2.1 用requests还是Scrapy我的选择和建议如果你只是毕设级别、抓几万本小说用requests XPath就够没必要上Scrapy。我的爬虫脚本就是requests写的原因是逻辑简单、调试方便、依赖少。Scrapy的异步并发能力强适合大规模采集但学习成本更高而且对于小说站这种中等规模的数据量性能优势根本发挥不出来。核心代码结构大致是这样import requests from lxml import etree headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Referer: https://example.com/ } def fetch_page(url): resp requests.get(url, headersheaders, timeout10) resp.encoding utf-8 return etree.HTML(resp.text) def parse_novel_list(html): items [] for node in html.xpath(//div[classbook-list]//li): title node.xpath(.//a/text())[0].strip() author node.xpath(.//span[classauthor]/text())[0].strip() category node.xpath(.//span[classcategory]/text())[0].strip() intro node.xpath(.//p[classintro]/text()) intro intro[0].strip() if intro else items.append({ title: title, author: author, category: category, intro: intro }) return items写XPath的时候有一个坑很多同学直接用Chrome的检查→Copy as XPath功能复制出来的路径往往带tbody或非常长的绝对路径目标网站结构稍微变一下就会抓空。我的经验是尽量写成相对路径、语义化class选择器比如//div[classbook-list]//li这样容错率更高。2.2 数据清洗与HDFS落盘抓下来的原始数据往往是脏的简介里带HTML标签、分类字段是连载中这种冗余前缀、正文里夹杂广告行。清洗这一步不要放到Hive去做直接在爬虫里做掉更省事。我当时的清洗规则大致是去HTML标签re.sub(r[^], , text)提取字数把字数123.45万转成1234500这种数字方便后续排序和可视化过滤空行、去首尾空格、统一全半角符号字段缺失的记录直接丢弃避免下游出现NULL污染清洗完之后把每条记录写成JSON行JSON Lines用org.apache.hadoop.fs的接口或者直接hadoop fs -put上传到HDFShadoop fs -mkdir -p /data/novel/raw/20250101 hadoop fs -put /home/user/novel_data_20250101.json /data/novel/raw/20250101/这里建议按天建目录不要一股脑塞到一个文件夹里后面Hive分区表会非常依赖这个目录结构。如果你数据量大加一个--iterator参数或者用pandas分块写入都行。2.3 爬虫合规与反爬的实用心得这个话题必须专门说因为太多人在这一步翻车。首先明确一个前提做毕设采集数据一定要选择有合法授权、允许爬取的网站或者使用公开数据集。我实际用的是老师提供的公开样例站点域名和robots.txt都允许学术采集。如果你自己去找小说站下手先看robots.txt严格遵守Disallow规则。爬虫技术本身是中性的但应用时要守住版权和协议边界。反爬方面我稳定运行几周的经验是控制请求频率每抓一个详情页sleep 0.5~1秒并发控制在单线程。不贪快稳定最重要。轮换UA和Referer提前准备一批常见的浏览器UA随机使用避免特征过于一致。设置重试机制遇到超时或5xx错误指数退避重试最多3次。内容校验如果返回的页面里找不到书名关键字大概率被反爬了直接丢弃并暂停一段时间。这几点听起来简单但能让爬虫长时间不挂。很多同学栽在爬太快被限制上一被限制就慌了拼命换IP反而越搞越糟。我的态度是毕设项目的数据量不需要极限爬取稳定比速度重要得多。3. Hive数据仓库模型分层、小文件治理和标号计算的实战记录数据进了HDFS只是开始真正让数据能用的是Hive这边。这一章是项目里工作量最重、也最容易被答辩老师追问的地方。3.1 从ODS到DWD表模型怎么设计我一共建了三层表对应数仓的经典分层思路但做了简化ODS层原始数据层ods_novel_raw外部表映射HDFS的JSON目录字段直接加载不做任何转换。DWD层明细数据层dwd_novel_info清洗后的结构化表字段类型规范化按分类进行分区。DWS层汇总数据层dws_novel_stats按分类、作者、时间做聚合存排行和统计指标供可视化使用。建表时我踩了个坑一开始全部用TEXTFILE格式几百MB数据查起来特别慢。后来统一换成ORC Snappy压缩查询速度提升了50%以上而且文件体积小了很多。给你参考我的建表语句CREATE EXTERNAL TABLE ods_novel_raw ( title STRING, author STRING, category STRING, intro STRING, words_count BIGINT, score DECIMAL(3,1), status STRING, crawl_date STRING ) PARTITIONED BY (dt STRING) ROW FORMAT SERDE org.apache.hadoop.hive.serde2.JsonHiveSerDe STORED AS TEXTFILE LOCATION /data/novel/raw;这里要特别提醒ODS层外部表不要动它的原始文件清洗逻辑全放在DWD层。外部表删掉表结构不影响HDFS里的数据安全。DWD层则用STORED AS ORC建内部表并通过INSERT OVERWRITE ... SELECT从ODS层灌数据。INSERT OVERWRITE TABLE dwd_novel_info PARTITION (dt20250101) SELECT title, author, category, intro, words_count, score, status FROM ods_novel_raw WHERE dt20250101 AND words_count 0;3.2 小文件过多从根源到合并手段这是Hive实战里必被问到的问题。当时我把JSON数据按天上传每天几百个JSON文件每个文件几十KBHive跑一个聚合任务就要启动上百个map任务全是元数据开销慢得离谱。这就是典型的小文件问题——NameNode内存被大量文件记录占满计算引擎被大量无意义的任务头尾开销拖垮。处理办法有几个按优先级排源头控制爬虫落盘时用pandas.DataFrame.to_parquet按批次合并每个Parquet文件控制在128MB左右不要一条一条写小文件。Hive合并ALTER TABLE ... CONCATENATE只对ORC格式生效合并后文件数会显著下降。Spark重分区读取小文件目录之后coalesce(n)或repartition(n)把数据攒成少量大分区再写出去。distcp动态合并如果文件太碎用hadoop distcp -Ddfs.block.size134217728把HDFS上的文件重新拼接成更大块。distcp的参数里-update和-append配合使用可以增量合并-m控制map数这几个参数在面试里也常考。我最终用的组合方案是爬虫端每天落盘前先合并成约100MB的大文件Hive侧定期对ORC表执行CONCATENATE。这样处理之后同样一个聚合查询从原来十几分钟压到了三分钟左右。3.3 给每行标号与窗口函数排行计算的正确姿势hive给每一行标号这个需求在小说排行场景里特别常见。比如我要取每个分类下热度前100的小说就必须用到窗口函数ROW_NUMBER()SELECT title, author, category, heat_score, ROW_NUMBER() OVER (PARTITION BY category ORDER BY heat_score DESC) AS rn FROM dws_novel_stats WHERE dt20250101;这里要注意ROW_NUMBER()是纯粹按序标号并列时结果不重复RANK()允许并列且会留空号DENSE_RANK()并列不留空号。做Top N排行时如果你需要每个人都有一个唯一名次用ROW_NUMBER()如果你希望同样热度并列第一用DENSE_RANK()。这个区别我在初版代码里搞混过一次导致排行结果和页面展示对不上排查了半天才发现是对函数语义理解错了。窗口函数配PARTITION BY的性能问题也要重视分区键的基数越大shuffle越严重。如果是为了全量Top N而非分组Top N直接ORDER BY ... LIMIT N更高效不需要走窗口函数。4. PySpark推荐核心ALS协同过滤的落地与调参经验推荐算法是整个项目的灵魂PySpark在这里的价值是读取Hive数据、分布式训练ALS模型、一键产出全部用户的推荐列表。4.1 用户评分从哪来隐式反馈的构造小说网站通常没有显式的打星行为但有点击、收藏、阅读、加入书架这些隐式行为。ALS在MLlib里支持隐式反馈通过implicitPrefsTrue来启用。构造训练数据的标准做法是用户对某本小说的点击/阅读次数转成(userId, novelId, count)三元组count越大代表偏好越强做一次对数变换rating log(1 count)压制极端大值我之前犯过一个错误直接拿count当rating喂给ALS结果热门小说被无脑推荐给所有人个性化完全失效。原因就是count服从长尾分布个别大爆款把其他小说的特征都压下去了。做log(1count)之后效果改善非常明显。4.2 ALS参数调优rank、regParam、alpha的实操经验MLlib的ALS接口长这样from pyspark.ml.recommendation import ALS als ALS( userColuser_id, itemColnovel_id, ratingColrating, implicitPrefsTrue, alpha40, rank20, regParam0.1, maxIter15, coldStartStrategydrop ) model als.fit(train_df)关键参数的理解rank隐式特征维度类似用多少维向量去表达用户和小说。我试过10、20、30发现20左右最均衡。再大的话训练时间明显增加RMSE下降却不明显。regParam正则化系数控制过拟合。调参时我按0.01, 0.05, 0.1, 0.5四档试过0.1效果最好0.5特征过于平滑推荐结果千篇一律。alpha隐式反馈的置信度权重控制行为次数的置信度曲线。对于小说这种阅读行为次数跨度大的场景alpha在40左右比较合适。alpha太小高行为次数样本没有体现出应有权重太大则低次数样本几乎被忽略。coldStartStrategy冷启动时新用户/新小说在模型中无特征预测会得到NaN。直接设成drop丢弃否则会污染评估指标。调参不是拍脑袋要跑交叉验证。PySpark里有现成的ParamGridBuilder CrossValidator但代价是训练时间成倍增加。我的实操建议是先用小规模数据跑五折交叉确定大致参数范围后再用全量数据训练最终模型。评估指标我用了两个RMSE均方根误差和AUC。隐式反馈下RMSE意义有限更多看AUC——离线时把测试集的正样本和随机负样本配对用模型打分看AUC能到多少。我当时调完参数AUC稳定在0.83左右对毕设来说已经很够看了。4.3 冷启动和推荐结果导出ALS解决不了冷启动。新注册用户没有任何行为模型给不出个性化推荐。我的兜底方案是新用户走热门榜用DWS层的热度统计Top 50填充推荐位新小说则走相似内容推荐用item的KMeans聚类或基于分类的规则匹配。这套方案在答辩里很讨喜说明你不仅会用模型还理解模型的边界。训练完的模型直接产出全量用户的推荐列表user_recs model.recommendForAllUsers(20)这个结果会非常大不能直接给前端。正确做法是把user_id和novel_id为键的推荐列表写回Hive表再通过INSERT OVERWRITE把它导入MySQL里的recommend_result表后端按用户ID去查询。5. 可视化模块从Spark结果到前端图表的完整通道很多人以为可视化就是前端写几个图表其实真正的难点在数据怎么从分布式集群平稳地到达浏览器。可视化做得好看答辩第一印象就好。5.1 数据通道Spark结果导入MySQL的稳妥步骤我走过的完整通道是Spark写回Hive → Hive表导出到MySQL → Spring Boot后端接口 → ECharts渲染。不建议用Flask直接连Hive响应太慢而且并发一大就崩。从Hive导出到MySQL我一开始用sqoop export后来发现配JDBC驱动时踩了很多版本坑。更省事的方式是直接在PySpark里用JDBC写MySQL(df .write .mode(overwrite) .option(driver, com.mysql.cj.jdbc.Driver) .option(user, root) .option(password, your_password) .jdbc(jdbc:mysql://localhost:3306/novel_db?useSSLfalseserverTimezoneAsia/Shanghai, recommend_result, overwrite))这个方案避开了Sqoop的各种版本兼容问题。要注意MySQL的max_allowed_packet默认可能偏小推荐结果一张大表写入时会报包大小超限改大一点即可。另外导MySQL前先在Spark侧做一次dropDuplicates([user_id, novel_id])否则弹窗展示时会出现重复数据。5.2 ECharts图表字段口径的统一是最大的坑可视化页面我放了四个核心图表分类占比玫瑰图、热度Top10横向柱状图、近30天阅读量趋势折线图、小说标签词云。做之前觉得ECharts的api很简单做完才发现大部分时间花在对齐字段口径上——数据库里存的words_count是整型前端接口返回的却是字符串图表排序直接失效score在MySQL里是DECIMAL(3,1)转成JSON后变成了浮点浮点精度问题导致柱状图标签显示9.8999999这类鬼东西。我这个项目的解决办法是后端在返回前统一做类型转换整数用Integer小数用BigDecimal并调用setScale(1, RoundingMode.HALF_UP)分类字段全部用枚举码表映射中文名。这套处理逻辑写在后端的DTO层前端拿到的JSON字段类型永远可控。趋势折线图的数据来自DWS层的日统计表按dt分组求阅读量。这里有个效率技巧不要后端每次请求都查MySQL全表而是在Spark离线阶段把日报表聚合好MySQL里只存30天前端一次拉全量即可。查询时间从几百毫秒压到几十毫秒。6. 毕业设计交付物文档、PPT和答辩讲演的实操建议最后这部分不是技术题但决定你最终成绩。很多做完系统的人栽在交付物上技术再好讲不出来一样白搭。6.1 源码组织与文档结构源码目录我建议按模块划分不要一锅粥全扔在src里project ├── crawler # 爬虫模块 ├── hive_etl # Hive SQL脚本 ├── spark_engine # PySpark推荐和统计 ├── backend # Spring Boot接口 ├── frontend # Vue ECharts页面 └── docs # 项目文档文档我写了六章绪论、需求分析、系统设计、实现细节、测试与调优、总结。这里有个教训截图不要后补开发过程中随手截。我当时觉得最后统一截图就行结果后期集群重装了Hive表里的测试数据全没了想补截图也没有只能拿空表硬凹效果差很多。6.2 答辩演示怎样讲才不翻车PPT的逻辑不要按开发顺序讲按业务价值→架构设计→关键技术→测试结果来讲。老师最常问的几个问题提前准备ALS为什么不用SVD——大数据场景下ALS的并行化程度更高SVD在分布式实现上代价更大MLlib里对SVD的分布式支持完全不如ALS成熟。Hive和MySQL的边界是什么——Hive跑离线分析MySQL跑在线查询各干各的。爬虫数据不合法怎么办——明确说明只使用授权公开数据遵守robots协议并展示你是如何限制频率和用途的。推荐效果如何验证——AUC、RMSE以及你在离线评测里做的抽样分析。演示时我强烈建议准备一份真实用户生成的测试数据现场给老师看推荐列表随用户历史行为变化而变化这比任何口头解释都直观。我第一次答辩演示用的测试账号数据太少推荐结果和热门榜没区别老师直接质疑这推荐系统是不是就是Top N排行当场尴尬。后来分析了一下原因重新模拟了一批用户行为数据覆盖了多种偏好类型的用户推荐结果确实体现出了个性化差异这个质疑才彻底化解。再分享一个经验演示前一定要检查MySQL服务、HDFS的NameNode进程和HiveMetaStore是否都在运行。我在正式演示前一个小时才发现Hive服务挂着启动集群等了十几分钟冷汗都出来了。提前准备好启动脚本start-all.sh加Hive服务启动命令一键拉起能省去很多焦虑。
每年到了毕业季都有不少人卡在小说推荐系统这类题目上。选了这个题的人十有八九是奔着HadoopHivePySpark这套大数据组合去的——听着硬核、答辩有的聊但真动手之后才发现这里的坑一个比一个深爬虫爬下来一堆脏数据、Hive里小文件多到查不动、PySpark的ALS调参调到怀疑人生、可视化数据跟网页对不上。这篇文章把我自己完成这个项目时踩过的坑、试出来的方案、以及源码和文档里的设计逻辑全部摊开讲从技术选型、系统架构到爬虫采集、数仓建模、推荐算法、图表展示一条链路串下来。准备做这个题目或者正在做相关毕设的同学可以直接照着抄作业。1. 这套技术栈是怎么选出来的Hadoop、Hive、PySpark各管哪一段先说结论这个项目并不是为了用大数据而用大数据而是整套系统里确实有不得不分布式处理的环节。选型之前要搞清楚每层组件在干什么否则答辩时老师问一句为什么这里用Hive不用MySQL你答不上来就尴尬了。1.1 三个组件各自的职责边界我最初的设计是爬虫抓完小说数据后直接写到MySQL然后后端读取MySQL做推荐和展示。后来发现这个思路走不通——小说正文加上用户行为日志动辄几百万条记录单机MySQL做复杂聚合查询比如按分类统计、按热度排行、跨时间段对比非常吃力而且爬虫每天增量更新数据一旦膨胀后续跑SQL会越来越慢最终会卡在原始数据能存但分析不动的尴尬局面。换成Hadoop这套组合之后逻辑清晰了很多HadoopHDFS YARN负责底层存储和资源调度。爬虫抓下来的原始小说数据、用户行为日志全部落进HDFS。HDFS的块存储和副本机制保证了数据不丢而且扩容方便。我当时用了三台虚拟机搭了一个小集群存储上完全没操心过。Hive负责离线数据仓库。原始数据不能直接拿来喂推荐算法需要清洗、转换、聚合。用Hive SQL做ETL非常顺手比写MapReduce效率高一个量级。它的核心价值是把SQL翻译成分布式作业让数据分析的门槛大幅下降。PySpark负责推荐算法训练和特征加工。ALS协同过滤算法在MLlib里有现成实现用PySpark调用比用Scala写更省事而且可以直接读Hive表省去了数据来回导的麻烦。这套组合的逻辑就是Hadoop存Hive洗PySpark算。三者各有侧重没有重叠。如果只用了Hadoop而不用Hive你写MapReduce清洗数据会累死如果不用PySpark而用别的框架ALS算法就得自己实现工作量直接翻倍。1.2 数据在系统里是怎么流转的从顶层看整个项目的数据流大概分五条线我建议你画图的时候也按这个顺序画答辩最清楚爬虫模块定时抓取小说网站的列表页和详情页采集书名、作者、分类、字数、评分、简介、正文等字段。原始数据以JSON或Parquet格式写入HDFS指定目录按日期分区。Hive的外部表映射这些目录通过ETL脚本生成干净的ODS层表再做轻度的清洗和标准化得到DWD层表。PySpark读取DWD层的用户打分和小说信息表训练ALS推荐模型产出用户-小说推荐列表和相似小说列表。推荐结果从Hive导出到MySQL供后端实时查询后端接口返回给前端用ECharts做可视化展示。这套链路里有个容易被忽略的点**Spark的推荐结果为什么要导回MySQL而不是直接让前端查Hive**因为前端页面需要秒级响应查询HDFS上的数据要走YARN任务启动开销太大用户体验很差。MySQL才是面向展示的存储HDFS只是面向分析的存储。这个设计思路在答辩时非常加分说明你理解不同存储引擎的适用场景。2. 小说爬虫采集链路的设计与合规细节爬虫模块是整个数据链条的源头数据质量直接决定后面推荐效果。我见过很多人栽在爬虫上最常见的问题就是要么爬下来一堆乱码要么字段丢得七零八落要么爬一半被目标网站封了IP。2.1 用requests还是Scrapy我的选择和建议如果你只是毕设级别、抓几万本小说用requests XPath就够没必要上Scrapy。我的爬虫脚本就是requests写的原因是逻辑简单、调试方便、依赖少。Scrapy的异步并发能力强适合大规模采集但学习成本更高而且对于小说站这种中等规模的数据量性能优势根本发挥不出来。核心代码结构大致是这样import requests from lxml import etree headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Referer: https://example.com/ } def fetch_page(url): resp requests.get(url, headersheaders, timeout10) resp.encoding utf-8 return etree.HTML(resp.text) def parse_novel_list(html): items [] for node in html.xpath(//div[classbook-list]//li): title node.xpath(.//a/text())[0].strip() author node.xpath(.//span[classauthor]/text())[0].strip() category node.xpath(.//span[classcategory]/text())[0].strip() intro node.xpath(.//p[classintro]/text()) intro intro[0].strip() if intro else items.append({ title: title, author: author, category: category, intro: intro }) return items写XPath的时候有一个坑很多同学直接用Chrome的检查→Copy as XPath功能复制出来的路径往往带tbody或非常长的绝对路径目标网站结构稍微变一下就会抓空。我的经验是尽量写成相对路径、语义化class选择器比如//div[classbook-list]//li这样容错率更高。2.2 数据清洗与HDFS落盘抓下来的原始数据往往是脏的简介里带HTML标签、分类字段是连载中这种冗余前缀、正文里夹杂广告行。清洗这一步不要放到Hive去做直接在爬虫里做掉更省事。我当时的清洗规则大致是去HTML标签re.sub(r[^], , text)提取字数把字数123.45万转成1234500这种数字方便后续排序和可视化过滤空行、去首尾空格、统一全半角符号字段缺失的记录直接丢弃避免下游出现NULL污染清洗完之后把每条记录写成JSON行JSON Lines用org.apache.hadoop.fs的接口或者直接hadoop fs -put上传到HDFShadoop fs -mkdir -p /data/novel/raw/20250101 hadoop fs -put /home/user/novel_data_20250101.json /data/novel/raw/20250101/这里建议按天建目录不要一股脑塞到一个文件夹里后面Hive分区表会非常依赖这个目录结构。如果你数据量大加一个--iterator参数或者用pandas分块写入都行。2.3 爬虫合规与反爬的实用心得这个话题必须专门说因为太多人在这一步翻车。首先明确一个前提做毕设采集数据一定要选择有合法授权、允许爬取的网站或者使用公开数据集。我实际用的是老师提供的公开样例站点域名和robots.txt都允许学术采集。如果你自己去找小说站下手先看robots.txt严格遵守Disallow规则。爬虫技术本身是中性的但应用时要守住版权和协议边界。反爬方面我稳定运行几周的经验是控制请求频率每抓一个详情页sleep 0.5~1秒并发控制在单线程。不贪快稳定最重要。轮换UA和Referer提前准备一批常见的浏览器UA随机使用避免特征过于一致。设置重试机制遇到超时或5xx错误指数退避重试最多3次。内容校验如果返回的页面里找不到书名关键字大概率被反爬了直接丢弃并暂停一段时间。这几点听起来简单但能让爬虫长时间不挂。很多同学栽在爬太快被限制上一被限制就慌了拼命换IP反而越搞越糟。我的态度是毕设项目的数据量不需要极限爬取稳定比速度重要得多。3. Hive数据仓库模型分层、小文件治理和标号计算的实战记录数据进了HDFS只是开始真正让数据能用的是Hive这边。这一章是项目里工作量最重、也最容易被答辩老师追问的地方。3.1 从ODS到DWD表模型怎么设计我一共建了三层表对应数仓的经典分层思路但做了简化ODS层原始数据层ods_novel_raw外部表映射HDFS的JSON目录字段直接加载不做任何转换。DWD层明细数据层dwd_novel_info清洗后的结构化表字段类型规范化按分类进行分区。DWS层汇总数据层dws_novel_stats按分类、作者、时间做聚合存排行和统计指标供可视化使用。建表时我踩了个坑一开始全部用TEXTFILE格式几百MB数据查起来特别慢。后来统一换成ORC Snappy压缩查询速度提升了50%以上而且文件体积小了很多。给你参考我的建表语句CREATE EXTERNAL TABLE ods_novel_raw ( title STRING, author STRING, category STRING, intro STRING, words_count BIGINT, score DECIMAL(3,1), status STRING, crawl_date STRING ) PARTITIONED BY (dt STRING) ROW FORMAT SERDE org.apache.hadoop.hive.serde2.JsonHiveSerDe STORED AS TEXTFILE LOCATION /data/novel/raw;这里要特别提醒ODS层外部表不要动它的原始文件清洗逻辑全放在DWD层。外部表删掉表结构不影响HDFS里的数据安全。DWD层则用STORED AS ORC建内部表并通过INSERT OVERWRITE ... SELECT从ODS层灌数据。INSERT OVERWRITE TABLE dwd_novel_info PARTITION (dt20250101) SELECT title, author, category, intro, words_count, score, status FROM ods_novel_raw WHERE dt20250101 AND words_count 0;3.2 小文件过多从根源到合并手段这是Hive实战里必被问到的问题。当时我把JSON数据按天上传每天几百个JSON文件每个文件几十KBHive跑一个聚合任务就要启动上百个map任务全是元数据开销慢得离谱。这就是典型的小文件问题——NameNode内存被大量文件记录占满计算引擎被大量无意义的任务头尾开销拖垮。处理办法有几个按优先级排源头控制爬虫落盘时用pandas.DataFrame.to_parquet按批次合并每个Parquet文件控制在128MB左右不要一条一条写小文件。Hive合并ALTER TABLE ... CONCATENATE只对ORC格式生效合并后文件数会显著下降。Spark重分区读取小文件目录之后coalesce(n)或repartition(n)把数据攒成少量大分区再写出去。distcp动态合并如果文件太碎用hadoop distcp -Ddfs.block.size134217728把HDFS上的文件重新拼接成更大块。distcp的参数里-update和-append配合使用可以增量合并-m控制map数这几个参数在面试里也常考。我最终用的组合方案是爬虫端每天落盘前先合并成约100MB的大文件Hive侧定期对ORC表执行CONCATENATE。这样处理之后同样一个聚合查询从原来十几分钟压到了三分钟左右。3.3 给每行标号与窗口函数排行计算的正确姿势hive给每一行标号这个需求在小说排行场景里特别常见。比如我要取每个分类下热度前100的小说就必须用到窗口函数ROW_NUMBER()SELECT title, author, category, heat_score, ROW_NUMBER() OVER (PARTITION BY category ORDER BY heat_score DESC) AS rn FROM dws_novel_stats WHERE dt20250101;这里要注意ROW_NUMBER()是纯粹按序标号并列时结果不重复RANK()允许并列且会留空号DENSE_RANK()并列不留空号。做Top N排行时如果你需要每个人都有一个唯一名次用ROW_NUMBER()如果你希望同样热度并列第一用DENSE_RANK()。这个区别我在初版代码里搞混过一次导致排行结果和页面展示对不上排查了半天才发现是对函数语义理解错了。窗口函数配PARTITION BY的性能问题也要重视分区键的基数越大shuffle越严重。如果是为了全量Top N而非分组Top N直接ORDER BY ... LIMIT N更高效不需要走窗口函数。4. PySpark推荐核心ALS协同过滤的落地与调参经验推荐算法是整个项目的灵魂PySpark在这里的价值是读取Hive数据、分布式训练ALS模型、一键产出全部用户的推荐列表。4.1 用户评分从哪来隐式反馈的构造小说网站通常没有显式的打星行为但有点击、收藏、阅读、加入书架这些隐式行为。ALS在MLlib里支持隐式反馈通过implicitPrefsTrue来启用。构造训练数据的标准做法是用户对某本小说的点击/阅读次数转成(userId, novelId, count)三元组count越大代表偏好越强做一次对数变换rating log(1 count)压制极端大值我之前犯过一个错误直接拿count当rating喂给ALS结果热门小说被无脑推荐给所有人个性化完全失效。原因就是count服从长尾分布个别大爆款把其他小说的特征都压下去了。做log(1count)之后效果改善非常明显。4.2 ALS参数调优rank、regParam、alpha的实操经验MLlib的ALS接口长这样from pyspark.ml.recommendation import ALS als ALS( userColuser_id, itemColnovel_id, ratingColrating, implicitPrefsTrue, alpha40, rank20, regParam0.1, maxIter15, coldStartStrategydrop ) model als.fit(train_df)关键参数的理解rank隐式特征维度类似用多少维向量去表达用户和小说。我试过10、20、30发现20左右最均衡。再大的话训练时间明显增加RMSE下降却不明显。regParam正则化系数控制过拟合。调参时我按0.01, 0.05, 0.1, 0.5四档试过0.1效果最好0.5特征过于平滑推荐结果千篇一律。alpha隐式反馈的置信度权重控制行为次数的置信度曲线。对于小说这种阅读行为次数跨度大的场景alpha在40左右比较合适。alpha太小高行为次数样本没有体现出应有权重太大则低次数样本几乎被忽略。coldStartStrategy冷启动时新用户/新小说在模型中无特征预测会得到NaN。直接设成drop丢弃否则会污染评估指标。调参不是拍脑袋要跑交叉验证。PySpark里有现成的ParamGridBuilder CrossValidator但代价是训练时间成倍增加。我的实操建议是先用小规模数据跑五折交叉确定大致参数范围后再用全量数据训练最终模型。评估指标我用了两个RMSE均方根误差和AUC。隐式反馈下RMSE意义有限更多看AUC——离线时把测试集的正样本和随机负样本配对用模型打分看AUC能到多少。我当时调完参数AUC稳定在0.83左右对毕设来说已经很够看了。4.3 冷启动和推荐结果导出ALS解决不了冷启动。新注册用户没有任何行为模型给不出个性化推荐。我的兜底方案是新用户走热门榜用DWS层的热度统计Top 50填充推荐位新小说则走相似内容推荐用item的KMeans聚类或基于分类的规则匹配。这套方案在答辩里很讨喜说明你不仅会用模型还理解模型的边界。训练完的模型直接产出全量用户的推荐列表user_recs model.recommendForAllUsers(20)这个结果会非常大不能直接给前端。正确做法是把user_id和novel_id为键的推荐列表写回Hive表再通过INSERT OVERWRITE把它导入MySQL里的recommend_result表后端按用户ID去查询。5. 可视化模块从Spark结果到前端图表的完整通道很多人以为可视化就是前端写几个图表其实真正的难点在数据怎么从分布式集群平稳地到达浏览器。可视化做得好看答辩第一印象就好。5.1 数据通道Spark结果导入MySQL的稳妥步骤我走过的完整通道是Spark写回Hive → Hive表导出到MySQL → Spring Boot后端接口 → ECharts渲染。不建议用Flask直接连Hive响应太慢而且并发一大就崩。从Hive导出到MySQL我一开始用sqoop export后来发现配JDBC驱动时踩了很多版本坑。更省事的方式是直接在PySpark里用JDBC写MySQL(df .write .mode(overwrite) .option(driver, com.mysql.cj.jdbc.Driver) .option(user, root) .option(password, your_password) .jdbc(jdbc:mysql://localhost:3306/novel_db?useSSLfalseserverTimezoneAsia/Shanghai, recommend_result, overwrite))这个方案避开了Sqoop的各种版本兼容问题。要注意MySQL的max_allowed_packet默认可能偏小推荐结果一张大表写入时会报包大小超限改大一点即可。另外导MySQL前先在Spark侧做一次dropDuplicates([user_id, novel_id])否则弹窗展示时会出现重复数据。5.2 ECharts图表字段口径的统一是最大的坑可视化页面我放了四个核心图表分类占比玫瑰图、热度Top10横向柱状图、近30天阅读量趋势折线图、小说标签词云。做之前觉得ECharts的api很简单做完才发现大部分时间花在对齐字段口径上——数据库里存的words_count是整型前端接口返回的却是字符串图表排序直接失效score在MySQL里是DECIMAL(3,1)转成JSON后变成了浮点浮点精度问题导致柱状图标签显示9.8999999这类鬼东西。我这个项目的解决办法是后端在返回前统一做类型转换整数用Integer小数用BigDecimal并调用setScale(1, RoundingMode.HALF_UP)分类字段全部用枚举码表映射中文名。这套处理逻辑写在后端的DTO层前端拿到的JSON字段类型永远可控。趋势折线图的数据来自DWS层的日统计表按dt分组求阅读量。这里有个效率技巧不要后端每次请求都查MySQL全表而是在Spark离线阶段把日报表聚合好MySQL里只存30天前端一次拉全量即可。查询时间从几百毫秒压到几十毫秒。6. 毕业设计交付物文档、PPT和答辩讲演的实操建议最后这部分不是技术题但决定你最终成绩。很多做完系统的人栽在交付物上技术再好讲不出来一样白搭。6.1 源码组织与文档结构源码目录我建议按模块划分不要一锅粥全扔在src里project ├── crawler # 爬虫模块 ├── hive_etl # Hive SQL脚本 ├── spark_engine # PySpark推荐和统计 ├── backend # Spring Boot接口 ├── frontend # Vue ECharts页面 └── docs # 项目文档文档我写了六章绪论、需求分析、系统设计、实现细节、测试与调优、总结。这里有个教训截图不要后补开发过程中随手截。我当时觉得最后统一截图就行结果后期集群重装了Hive表里的测试数据全没了想补截图也没有只能拿空表硬凹效果差很多。6.2 答辩演示怎样讲才不翻车PPT的逻辑不要按开发顺序讲按业务价值→架构设计→关键技术→测试结果来讲。老师最常问的几个问题提前准备ALS为什么不用SVD——大数据场景下ALS的并行化程度更高SVD在分布式实现上代价更大MLlib里对SVD的分布式支持完全不如ALS成熟。Hive和MySQL的边界是什么——Hive跑离线分析MySQL跑在线查询各干各的。爬虫数据不合法怎么办——明确说明只使用授权公开数据遵守robots协议并展示你是如何限制频率和用途的。推荐效果如何验证——AUC、RMSE以及你在离线评测里做的抽样分析。演示时我强烈建议准备一份真实用户生成的测试数据现场给老师看推荐列表随用户历史行为变化而变化这比任何口头解释都直观。我第一次答辩演示用的测试账号数据太少推荐结果和热门榜没区别老师直接质疑这推荐系统是不是就是Top N排行当场尴尬。后来分析了一下原因重新模拟了一批用户行为数据覆盖了多种偏好类型的用户推荐结果确实体现出了个性化差异这个质疑才彻底化解。再分享一个经验演示前一定要检查MySQL服务、HDFS的NameNode进程和HiveMetaStore是否都在运行。我在正式演示前一个小时才发现Hive服务挂着启动集群等了十几分钟冷汗都出来了。提前准备好启动脚本start-all.sh加Hive服务启动命令一键拉起能省去很多焦虑。
