这段时间帮不少准备毕业设计的同学调试过“Django 大数据技术 热门游戏推荐系统”这个组合题发现一个很有意思的现象你以为最难的推荐算法实际大多数人都卡在数据清洗和环境部署上而真正把整个链路跑通之后这题反而变成了一个很适合练手的完整闭环项目。前端展示面够宽后端逻辑覆盖了从爬虫到算法到调度的全部流程大数据组件可以轻量切入也能随时加深研究深度。这篇文章就把这个项目从选题定位、技术选型、数据建设、推荐算法实现、Django工程整合、离线任务调度到部署调试的完整过程拆开讲最后聊一下毕设文档编排和答辩准备的实用经验。如果你正在做这个题目或者是想从零搭一套包含“采集—计算—推荐—展示”闭环的Web系统这篇内容基本就是一份可以直接抄作业的复盘。1. 课题定位与整体技术选型的思考1.1 为什么“热门游戏推荐系统”适合做毕设很多人看到“热门游戏推荐系统”这个名字第一反应是“不就是按热度排个榜吗”。确实如果只做一个静态排行榜半天就能搞定但这显然撑不起一个毕设的工作量和评审深度。这个题目的价值点在于它把“数据采集”、“数据存储”、“算法设计”、“Web应用”、“离线计算”五个环节串成了一条完整链路每个环节都有充分的展开空间。从实际开发角度来说这个题目的数据源很好找。游戏平台的公开数据、各种开源游戏数据集、榜单页面都是现成的素材不需要像医疗、金融类项目那样到处找接口或者伪造数据。推荐算法也有明显的梯度感最简单的热门加权排序可以做一个版本基于用户的协同过滤可以做一个进阶版基于物品的协同过滤再加一层冷启动处理最后做一个混合推荐整个系统逻辑层次一下子就丰富了。尤其对想冲良好或优秀等级的同学来说大数据离线分析模块是天然加分项——因为热门游戏推荐必然涉及大量用户行为日志日志的采集、清洗、聚合统计正好对应大数据技术栈中的典型场景。1.2 系统功能边界与角色设计我一般建议把这个系统拆成三个角色视角普通用户、管理员、系统后台任务。普通用户关注的是逛游戏、搜游戏、看详情、打评分、收收藏以及打开首页时拿到一套“猜你喜欢”的推荐列表。管理员侧重游戏库管理、用户管理、评论审核、热度数据的可视化查看。系统后台任务是整个项目里容易被忽视但很重要的部分——定期爬取数据更新游戏库、定时重算推荐结果、离线统计用户行为日志。普通用户注册登录、浏览游戏、搜索筛选、游戏详情、评分、收藏、推荐列表 管理员游戏管理、用户管理、订单评论管理、数据统计看板、推荐参数配置 后台任务定时爬虫更新、热度重算、协同过滤离线计算、行为日志聚合这个三角色模型的好处是每个角色都有对应的页面、接口、数据表和后台任务写文档和画功能结构图的时候章节非常清晰不会出现“功能需求只有两页纸”的尴尬。1.3 整体技术选型与架构决策我的技术选型组合是这样的层级技术选型选型理由Web框架Django 4.2 Django REST FrameworkDjango自带Admin后台和ORM适合管理类页面快速搭建DRF方便提供推荐接口数据存储MySQL 8.0 RedisMySQL存游戏、用户、评分等结构化数据Redis存热门榜缓存和实时行为计数大数据计算pandas PySpark Celery行为日志量级上来后用Spark做离线聚合pandas负责临时清洗和小批量处理Celery做任务调度数据采集requests BeautifulSoup轻量爬虫足够应对榜单页和详情页数据抓取不需要上Scrapy这种重框架前端展示Bootstrap jQuery ECharts毕设前端不追求工程复杂度能清晰展示数据和图表即可部署环境Windows/Linux Nginx Gunicorn本地演示用runserver足够部署上线时再切到Gunicorn这套组合在“大数据”和“Django”之间取得了一个平衡。你不需要搭一套真正的Hadoop集群但要在项目里体现出对大数据处理流程的理解——日志采集、分布式文件存储的思想、离线批处理、结果回写关系型数据库供Web应用读取。不少同学问我“要不要装虚拟机跑三台机器的Hadoop集群”我的建议是如果你的题目范围只是“推荐系统的设计与实现”那用Spark的local模式加合理的数据管道设计就足够了重点是讲清楚大数据处理流程而不是堆硬件。2. 数据层建设游戏数据从哪来、怎么存2.1 爬虫采集数据源的选取与反爬处理数据源是整个系统的基础。我常用的做法是从公开的游戏资讯平台和榜单页面抓取游戏的基础字段包括游戏名称、类型、发行商、发售日期、价格、评分、封面图链接、标签、简介。抓详情页的时候顺手把该游戏的用户评价数和好评率也拿下来这些字段对后面的热度计算非常有用。爬虫这块的代码设计其实很直接requests加BeautifulSoup就能完成大部分工作import requests from bs4 import BeautifulSoup HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0 Safari/537.36 } def fetch_game_list(): games [] for page in range(1, 6): url fhttps://example-game-site.com/top?page{page} resp requests.get(url, headersHEADERS, timeout10) soup BeautifulSoup(resp.text, html.parser) for item in soup.select(.game-item): game { name: item.select_one(.game-name).get_text(stripTrue), category: item.select_one(.game-category).get_text(stripTrue), publisher: item.select_one(.game-publisher).get_text(stripTrue), price: item.select_one(.game-price).get_text(stripTrue), rating: float(item.select_one(.game-rating).get_text(stripTrue)), cover: item.select_one(img)[src], } games.append(game) return games有几个容易踩的细节需要说一下。第一务必通过requests.Session()复用连接避免频繁创建连接导致被站点限流。第二每抓一页最好停顿1到3秒不要让对方的压力测试在日志上观察到你的抓取节奏。第三详情页的字段往往比列表页丰富如果后面要做内容推荐或标签相似度前期就要把详情页字段一起抓到手避免后面再返工。2.2 数据清洗与结构化存储爬回来的数据第一时间不要急着往MySQL里灌先用pandas做一轮清洗。我习惯上的清洗流程是import pandas as pd df pd.DataFrame(raw_games) # 1. 去重 df df.drop_duplicates(subset[name]) # 2. 处理空值和异常价格 df[rating] pd.to_numeric(df[rating], errorscoerce).fillna(0.0) df[price] df[price].replace(免费, 0).astype(float) # 3. 类型字段标准化 df[category] df[category].str.strip().str.lower() # 4. 图片缺失时补默认占位图 df[cover] df[cover].fillna(/static/img/default.jpg)清洗后入库。Django的ORM建表直接清晰下面是核心模型设计from django.db import models class Game(models.Model): name models.CharField(max_length100, verbose_name游戏名称) category models.CharField(max_length50, verbose_name游戏类型) publisher models.CharField(max_length100, verbose_name发行商) release_date models.DateField(nullTrue, blankTrue, verbose_name发售日期) price models.FloatField(default0, verbose_name价格) rating models.FloatField(default0, verbose_name用户评分) rating_count models.IntegerField(default0, verbose_name评分人数) hot_value models.FloatField(default0, verbose_name综合热度值) cover models.URLField(blankTrue, verbose_name封面图) tags models.CharField(max_length200, blankTrue, verbose_name标签) create_time models.DateTimeField(auto_now_addTrue) class Meta: ordering [-hot_value] db_table game def __str__(self): return self.name class Rating(models.Model): user models.ForeignKey(users.User, on_deletemodels.CASCADE, verbose_name用户) game models.ForeignKey(Game, on_deletemodels.CASCADE, verbose_name游戏) score models.FloatField(verbose_name评分) play_duration models.IntegerField(default0, verbose_name游玩时长/分钟) create_time models.DateTimeField(auto_now_addTrue)注意MySQL字符集和Django配置保持一致否则中文写入时会出现乱码。建库时要用utf8mb4Django侧配置里设置DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: game_recommend, USER: root, PASSWORD: 123456, HOST: 127.0.0.1, PORT: 3306, OPTIONS: {charset: utf8mb4}, } }2.3 大数据计算组件的引入边界很多同学对“大数据技术”这个关键词的理解是“我必须在项目里用上Hadoop”这个想法需要打个折扣。一个典型的误区是硬堆技术栈结果集群起不来连作业都交不了。我更建议用分阶段的方式引入大数据能力第一阶段行为日志落CSV或JSON文件用pandas做离线统计这是项目能跑通的最简方案。第二阶段日志量模拟到几十万条级别引入Spark以local模式做聚合计算体现出分布式计算框架对海量日志的处理能力。第三阶段把原始日志文件按日期分区存放使用Spark读取后输出聚合结果到MySQL形成“日志采集—离线批处理—结果回写—Web读取”的完整大数据流程。这个设计在答辩时非常有说服力。你可以现场演示一个包含50万条记录的游戏行为日志文件用Spark的DataFrame API做groupBy聚合输出统计结果到控制台和数据库再对比Django ORM直接聚合同量级数据的耗时。性能和架构思路都体现出来了评审老师看到的是你对大数据处理流程的理解而不是你背了多少组件名词。3. 推荐算法核心从“热门”到“个性化”的递进实现3.1 基于热度加权排序的推荐实现整个系统里最基础的推荐是热门榜单。热门不能简单地按“评分人数”排序因为老游戏天然有优势新游戏永远上不了榜。需要设计一个综合考虑多个因素的热度公式。我用过的权重方案是这样的hot_score 0.25 * zscore(最近30天浏览量) 0.20 * zscore(平均评分) 0.20 * zscore(收藏数) 0.15 * zscore(总时长) 0.10 * zscore(评分人数) 0.10 * zscore(新游加权分)这里的zscore是指标准化到统一量纲。直接拿原始值加权会出现一个严重问题——评分的取值范围只有0到10而浏览量可能是几万藏在后面后面直接回写MySQL前端接口优先读Redis。为什么这么绕因为Django ORM直接几十万级别做聚合计算会把请求耗时拉到几百毫秒甚至秒级而Redis读取热榜是毫秒级。设计一次离线计算换来全站的接口性能优势这就是大数据和Web应用结合的实际意义所在。5.2 Pandas/Spark离线特征计算与结果回写离线计算部分我推荐使用本地CSV文件模拟日志数据源再用pandas和Spark分别实现两套计算逻辑方便在文档里做对比。pandas版本适合解释逻辑代码很短适合写在文档的算法设计章节里import pandas as pd df pd.read_csv(data/game_log.csv) stats df.groupby(game_id).agg( visit_cnt(user_id, count), avg_score(score, mean), collect_cnt(is_collect, sum) ).reset_index() stats[hot_score] stats[visit_cnt] * 0.4 stats[avg_score] * 0.3 stats[collect_cnt] * 0.3 stats.sort_values(hot_score, ascendingFalse, inplaceTrue)Spark版本突出海量数据的处理能力体现大数据框架的价值。我一般用一个独立脚本放在项目的script/目录下from pyspark.sql import SparkSession from pyspark.sql.functions import col, count, avg, sum spark SparkSession.builder.appName(GameHotCalculator).master(local[*]).getOrCreate() df spark.read.csv(data/game_log.csv, headerTrue, inferSchemaTrue) stats df.groupBy(game_id).agg( count(user_id).alias(visit_cnt), avg(score).alias(avg_score), sum(is_collect).alias(collect_cnt) ) stats.filter(collect_cnt 500) \ .orderBy(col(visit_cnt).desc()) \ .write.mode(overwrite) \ .jdbc(jdbc:mysql://localhost:3306/game_recommend?useUnicodetruecharacterEncodingutf8mb4, game_daily_stats, properties{user: root, password: 123456})把计算结果写回MySQL之后Django侧就可以直接读取这张统计表来生成热榜而不用实时扫描日志。数据管道变成了“原始CSV日志 → Spark聚合 → MySQL统计表 → Redis缓存 → Django API → 前端展示”每一步的职责都单一清晰答辩画架构图的时候分分钟就能讲明白。5.3 缓存优化与接口性能提升Web接口的性能优化同样不能忽略。我在项目里做了三件套Redis缓存热榜、DRF分页、ORM查询优化。首先推荐接口在返回前先查Redis如果缓存命中就直接返回序列化结果否则查MySQL并回填Redis。Redis键可以设成类似recommend:user:{uid}:hot这种格式过期时间设置在30分钟到1小时之间。第二件所有列表接口都用DRF的分页器。Django默认的PageNumberPagination在深分页时效率很低推荐接口数据量不大但为了演示“大数据量下的优雅处理”建议使用CursorPagination或者给分页设置合理的page_size。第三件ORM查询杜绝懒加载导致的N1。推荐列表必然要连表查游戏信息和封面必须用select_related预取外键from django.db.models import F games Game.objects.filter(hot_value__gt0) \ .select_related(publisher_info) \ .prefetch_related(tag_relations) \ .order_by(-hot_value)很多同学的项目卡死不是算法问题不是数据库问题而是一个简单的懒加载循环里反复查了上百次数据库。这个问题在文档和答辩里也很容易写成一节“性能优化实践”比空谈优化方法有说服力得多。6. 调试部署中的高频问题与排查思路6.1 一次典型的Celery任务调度踩坑全程说说我在调试时遇到次数最多的一类问题Celery任务不执行或者执行失败看起来似乎是“定时任务没到时间”的配置问题但实际上是代码或环境内部的隐藏问题。有一次同学发来报错任务日志显示连接Redis失败但Redis明明已经启动了。详细看代码才发现它用了localhost来连Redis而Redis绑定的却是127.0.0.1对应的不同网卡端口。完整排查链路是这样的先看Celery日志发现连接被拒绝接着查Redis运行状态发现进程正常但没有监听localhost而是绑定在另一个IP用redis-cli -h 127.0.0.1 ping确认手动访问没问题之后再检查Django的settings里BROKER_URL配置把localhost改为实际IP之后任务立即恢复。这个排查过程看起来简单但它非常典型——绝大多数Celery调度失败都是连接地址、防火墙、队列名不一致这三种原因造成的。另一个高频问题是我的老熟人了Celery定时任务执行了但推荐结果没有更新。查了任务函数发现逻辑写错把hot_value全置0了。因为代码里写的是Game.objects.update(hot_value0)而不是从统计数据表重新赋值。这个坑提醒我定时任务一定要有幂等性重复运行不会产生二次污染而且每次运行后最好把统计结果单独写入一张历史表方便回滚和追踪。6.2 数据库与中文乱码问题Django连MySQL时的中文乱码是毕设调试的经典“开门黑”。通常现象是爬虫抓到的中文数据在Python里显示正常写入MySQL之后变成问号或者乱码。问题原因大概率在三个地方数据库本身的字符集、Django数据库连接配置、控制台输出编码。一行排查命令可以快速定位数据库字符集SHOW VARIABLES LIKE character_set%;如果character_set_database不是utf8mb4就需要重建库或者修改库属性。同时Django侧也要再检查一遍OPTIONS里的charset参数两端统一后中文基本不会再乱。还有一种情况是Windows终端显示乱码但库里数据正常这种直接强制终端用utf-8输出即可别在数据库上浪费时间。6.3 推荐参数调优与结果评估系统上线后怎么评估推荐效果很多同学在这个环节很虚觉得“推荐效果”就是个主观感受。实际操作中可以用三个可量化指标做评估推荐列表点击率、收藏转化率、用户评分行为覆盖率。具体做法是把推荐列表里被用户点击的游戏ID和实际产生的收藏行为记录下来按天统计。比如某天推荐接口下发10000次用户的点击次数是1200次点击率为12%。第二天调整了热度权重点击率变成14%那就说明调整方向有效。再比如用了协同过滤后收藏转化率从3%涨到5%这个数据记录在文档的实验分析章节比任何口头描述都有说服力。一般我建议预留1到2周的实验周期用A/B测试的简化思路记录两组数据然后把对比结果做成柱状图放进文档。参数调优方面热点权重的调整要谨慎。把时间衰减系数调得过大推荐列表会频繁大变用户体验反而变差。通常衰减系数取0.7到0.96之间比较合适具体取决于你希望榜单被新游戏渗入的速度。协同过滤的阈值参数可以通过观察推荐结果的多样性来调整推荐列表里连续出现同类型游戏数量过多就把多样性约束加上去。7. 毕业设计文档编排与答辩准备的实用经验7.1 文档结构怎么排才不容易被挑刺毕设文档最忌讳“功能说明书式”的写法通篇在讲按钮怎么点没有任何设计决策和实验分析。基于这个项目我推荐下面的章节编排绪论选题背景、国内外推荐系统研究现状、主要研究内容、论文结构安排相关技术介绍Django框架、大数据技术栈、推荐算法原理这部分不要照抄书要紧扣项目实际用到的技术系统需求分析功能需求、用例图、非功能需求系统设计架构设计、数据库设计、模块接口设计、算法流程设计系统实现关键功能页面截图、核心代码解释、推荐算法实现细节系统测试功能性测试用例表、性能测试结果、推荐效果对比实验总结与展望项目不足和后续扩展方向写文档时一定把“为什么这样做”写进去。例如技术选型一节不只要列出Django和Spark还要说明是因为项目需要快速开发Web和批量处理日志才选的。在系统设计章节把协同过滤的算法步骤用流程图表示注意是画在文档里的图不是项目里的动态图。在系统实现章节每个功能模块放1到2张截图、配一段300字左右的核心逻辑说明这个篇幅和节奏比较合适。7.2 答辩演示过程怎么准备答辩演示的顺序直接决定评审老师的印象分。我建议按照“数据—算法—系统—效果”的链路来演示而不是从登录页开始一个页面一个页面点过去。开场先展示Spark读取游戏行为日志并输出聚合结果的画面让老师第一眼就知道你用了大数据技术。第二步打开Django管理后台展示游戏数据表和管理操作突显系统的后台管理能力。第三步打开首页展示推荐接口返回的数据和页面渲染效果重点演示不同用户登录后推荐列表的变化现场验证协同过滤的效果。最后打开Redis和数据库展示缓存策略和热度值字段的更新再用ECharts图表展示几天的行为数据统计。有些问题被问概率极高你的推荐算法和普通的热门榜单有什么区别你的系统用了什么大数据组件为什么选择协同过滤而不是深度学习你的数据是哪来的建议提前把这些问题的答案写成一页纸不要背稿用大白话回答。例如“协同过滤和热门的区别”可以这样表达热门榜是弹给所有人看的同一张榜协同过滤是根据你玩过什么、和哪些玩家相似把你可能喜欢但没听过的新游戏找出来。能一句话讲清原理的答辩者通常比背教科书定义的人更能让老师信服。这个项目做到后期我最大的体会是它不能只当“一个网页”来做而要从数据流的角度想问题。从抓回来的原始字段到清洗后的表格再到离线计算出来的热度分最后变成用户看到的推荐列表每一步都有自己的职责和挑战。你每解决一个数据或性能问题文档里就多一个实验和避免踩坑的素材。答辩时把这些真实的处理过程讲出来比单纯展示截图更有分量。后面如果想扩展可以考虑接入真实API、加登录验证码、把Spark计算升级为独立服务集群——这个项目的天花板基本上取决于你愿意投入多少时间把某一环挖到底。
