1. 项目概述：当大数据遇上美食推荐
去年帮学弟调试毕业设计时遇到个有趣案例——某高校计算机系的"Spark美食推荐系统"，这个项目完美融合了协同过滤算法与Django框架，还涉及大数据处理。典型的"麻雀虽小五脏俱全"式毕业设计，既有算法深度又有工程实现。今天我就从实战角度拆解这类系统的核心模块，分享些教科书上不会写的实现细节。
这类系统本质上要解决三个问题：如何用用户行为数据（评分、浏览、收藏）建立偏好模型？怎样通过协同过滤算法产生推荐？如何用Web框架将算法封装成可交互服务？下面这个架构图能直观展示技术栈关系：
code复制[用户行为数据] → [Spark预处理] → [协同过滤模型] → [Django REST API] → [Web前端]
2. 核心算法选型与优化
2.1 用户协同过滤的工程化实现
用户协同过滤(UserCF)的核心是计算用户相似度矩阵，在Spark中可以用ALS(交替最小二乘)实现。但真实场景会遇到两个坑：
-
冷启动问题：新用户没有历史行为数据时，我的处理方案是：
- 首次登录时要求选择3-5个偏好菜系
- 混合使用热门推荐（全局评分TOP100）和内容推荐（基于菜系标签）
-
矩阵稀疏性问题：当用户-物品矩阵稀疏度>95%时，建议采用这种优化：
python复制# Spark代码示例：加入权重因子
als = ALS(
rank=10,
maxIter=5,
regParam=0.01,
implicitPrefs=True, # 启用隐式反馈
alpha=0.5 # 置信度权重
)
经验之谈：实际测试发现，当数据量<10万条时，直接计算余弦相似度的效率反而高于ALS，因为ALS的迭代计算开销更大。
2.2 物品协同过滤的AB测试策略
物品协同过滤(ItemCF)更适合美食推荐场景，因为菜品间的关联性比用户间的更稳定。关键实现步骤：
- 共现矩阵计算：
python复制# 用Spark SQL统计物品共现次数
spark.sql("""
SELECT
a.item_id as item1,
b.item_id as item2,
COUNT(*) as co_count
FROM user_actions a
JOIN user_actions b ON a.user_id = b.user_id
WHERE a.item_id != b.item_id
GROUP BY item1, item2
""")
- 相似度计算时建议加入时间衰减因子：
code复制sim(i,j) = co_count(i,j) / sqrt(count(i)*count(j)) * e^(-Δt/30)
其中Δt表示行为时间差（天），这样能提升近期行为的权重。
3. 大数据处理实战技巧
3.1 Spark性能调优四板斧
- 分区策略：建议按用户ID哈希分区，保证同一用户数据落在同一节点
python复制df.repartition(100, "user_id")
- 持久化选择：根据数据使用频率选择存储级别：
python复制# 频繁使用的RDD
rdd.persist(StorageLevel.MEMORY_AND_DISK)
# 中间结果
rdd.persist(StorageLevel.MEMORY_ONLY_SER)
- 广播变量：当物品特征表<100MB时：
python复制item_features = spark.table("items").collect()
bc_features = sc.broadcast({i['id']:i for i in item_features})
- 数据倾斜处理：遇到热门菜品时采用两阶段聚合：
python复制# 第一阶段给热门item添加随机前缀
skew_df = df.withColumn("salt", when(col("item_id")=="热门ID", floor(rand()*10)).otherwise(0))
3.2 推荐结果存储方案
推荐结果存储要考虑实时性和存储成本的平衡：
| 方案 | 响应时间 | 适用场景 | 示例 |
|---|---|---|---|
| 实时计算 | >500ms | 小型系统 | 用户请求时实时调用Spark |
| 预计算+Redis | <50ms | 中型系统 | 每天凌晨全量更新 |
| Lambda架构 | 混合 | 大型系统 | 实时更新+批量修正 |
毕业设计中推荐用方案二，Django配置示例：
python复制# settings.py
CACHES = {
"recommend": {
"BACKEND": "django_redis.cache.RedisCache",
"LOCATION": "redis://127.0.0.1:6379/1",
"TIMEOUT": 86400 # 24小时过期
}
}
4. Django工程化实践
4.1 推荐API设计要点
REST接口设计要兼顾前后端协作效率，我常用的响应结构：
python复制{
"code": 200,
"data": {
"user_rec": [...], # 用户协同过滤结果
"item_rec": [...], # 物品协同过滤结果
"hybrid_rec": [...] # 混合推荐结果
},
"meta": {
"algo_version": "v2.1",
"generate_time": "2023-08-20T14:30:00Z"
}
}
4.2 数据库模型设计
美食推荐特有的字段设计技巧：
python复制class Dish(models.Model):
# 基础字段
name = models.CharField(max_length=100)
cuisine_type = models.CharField(max_length=20, choices=CUISINE_CHOICES)
# 推荐相关
hot_score = models.FloatField(default=0) # 热度分
last_recommend = models.DateTimeField(null=True) # 最后推荐时间
# 特征向量 (存储JSON字符串)
features = models.TextField(default="[]")
class Meta:
indexes = [
models.Index(fields=['hot_score']),
models.Index(fields=['cuisine_type']),
]
5. 毕业设计避坑指南
5.1 数据准备常见问题
-
数据量不足：建议至少准备：
- 用户数据：1000+（可用Faker生成）
- 菜品数据：300+（从大众点评爬取）
- 行为记录：5万+（按幂律分布生成）
-
行为类型设计：
python复制ACTION_WEIGHTS = {
"view": 0.3,
"collect": 0.8,
"order": 1.0,
"share": 0.5
}
5.2 答辩演示技巧
-
对比实验展示：至少准备三种场景
- 纯用户协同过滤
- 纯物品协同过滤
- 混合推荐（加权平均）
-
可视化建议：
python复制# 使用pyecharts生成推荐路径图 from pyecharts import options as opts from pyecharts.charts import Graph nodes = [...] links = [...] graph = ( Graph() .add("", nodes, links, repulsion=50) .set_global_opts(title_opts=opts.TitleOpts(title="用户-菜品关联图")) ) -
性能优化报告：记录关键指标对比
优化项 原耗时 优化后 提升幅度 Spark分区 78s 45s 42% 相似度计算 62s 28s 55% 缓存策略 34s 5s 85%
6. 源码结构建议
标准项目目录应包含这些关键部分：
code复制├── algorithm/ # 推荐算法核心
│ ├── __init__.py
│ ├── user_cf.py # 用户协同过滤
│ └── item_cf.py # 物品协同过滤
├── data/ # 数据管道
│ ├── mock_data.py # 模拟数据生成
│ └── spark_etl.py # ETL脚本
├── webapp/ # Django应用
│ ├── api/ # 推荐API
│ └── models.py # 数据模型
└── docs/
├── design.md # 设计文档
└── api_spec.yaml # OpenAPI规范
实现时要注意算法模块与Web模块的解耦，我常用的接口设计模式：
python复制# algorithm/interface.py
class Recommender:
@classmethod
def recommend_for_user(cls, user_id, n=10):
""" 这里实现策略模式，可动态切换算法 """
if config.ALGO_VERSION == "user_cf":
return UserCF.recommend(user_id, n)
else:
return ItemCF.recommend(user_id, n)
这种架构既方便答辩时演示不同算法效果，也便于后续扩展新算法。最后提醒下，在真实部署时记得用gunicorn+nginx做服务化部署，而不是直接跑Django开发服务器。