1. 项目背景与核心需求
在当今快节奏的生活中，健康饮食管理已成为都市人群的普遍痛点。传统营养咨询存在成本高、覆盖面窄的问题，而现有的饮食APP又往往缺乏个性化推荐能力。这正是我们基于SpringBoot和Hadoop构建智能推荐系统的初衷——通过大数据技术解决个性化饮食建议的规模化落地难题。
这个系统需要解决三个核心问题：
- 如何高效处理海量用户饮食日志和食品营养成分数据
- 如何建立精准的用户画像与食品特征模型
- 如何实现低延迟的实时推荐服务
关键设计决策：选择Hadoop作为底层数据平台，主要考虑其分布式存储与批处理能力对海量营养数据处理的天然适配性；而SpringBoot的轻量级特性则完美匹配推荐服务的快速响应需求。
2. 技术架构设计
2.1 整体架构分层
系统采用经典的三层架构设计：
code复制[用户层]
↓ HTTP/JSON
[SpringBoot服务层]
↓ REST API
[Hadoop计算层]
↑ ↓
[数据存储层]
- 表现层：Vue.js构建的响应式前端
- 业务层：SpringBoot 2.7 + Spring Security
- 计算层：Hadoop 3.2.4 + MapReduce
- 存储层：HDFS + MySQL混合存储
2.2 核心组件交互流程
- 数据采集端：移动端APP每日上传用户饮食记录，平均单用户产生约2MB/日的结构化数据
- 批处理作业：每日凌晨通过Oozie调度MapReduce作业，计算以下指标：
- 用户营养摄入偏差值
- 食品组合关联规则
- 用户聚类分组更新
- 实时服务：SpringBoot暴露的推荐API响应时间控制在200ms内
3. Hadoop数据处理实现
3.1 数据模型设计
在HDFS上建立以下目录结构：
code复制/user/nutrition/
├── raw/ # 原始数据
├── processed/ # 清洗后数据
└── models/ # 机器学习模型
食品特征表采用ORC格式存储，相比TextFile节省约60%空间：
java复制CREATE EXTERNAL TABLE food_features (
food_id STRING,
calories DOUBLE,
protein DOUBLE,
carbs DOUBLE,
fat DOUBLE,
vitamins MAP<STRING,DOUBLE>
) STORED AS ORC;
3.2 核心MapReduce作业
营养偏差计算作业的Mapper逻辑示例：
java复制public class NutritionMapper extends Mapper<LongWritable, Text, Text, DoubleWritable> {
private Text userId = new Text();
private DoubleWritable deviation = new DoubleWritable();
protected void map(LongWritable key, Text value, Context context) {
// 解析用户当日摄入数据
UserDailyRecord record = parseRecord(value.toString());
// 计算各营养素与标准值的偏差
double proteinDiff = (record.getProtein() - record.getTargetProtein()) / record.getTargetProtein();
userId.set(record.getUserId());
deviation.set(proteinDiff);
context.write(userId, deviation);
}
}
Reducer端采用加权平均算法处理多日数据，确保推荐稳定性。
4. SpringBoot服务实现
4.1 推荐API设计
核心推荐接口采用三层缓存策略：
- Guava本地缓存（有效期5分钟）
- Redis集群缓存（有效期2小时）
- 数据库持久层
接口定义示例：
java复制@RestController
@RequestMapping("/api/recommend")
public class RecommendationController {
@GetMapping("/daily")
public ResponseEntity<List<FoodItem>> getDailyRecommendation(
@RequestHeader("X-User-ID") String userId,
@RequestParam(defaultValue = "5") int size) {
// 获取用户最新特征向量
UserProfile profile = profileService.getUpdatedProfile(userId);
// 调用推荐引擎
List<ScoredItem> candidates = recommendationEngine.recommend(profile, size);
return ResponseEntity.ok(convertToFoodItems(candidates));
}
}
4.2 性能优化实践
通过以下措施将API平均响应时间从850ms降至210ms：
- 预计算策略：利用Hadoop的批处理结果生成推荐候选集
- 异步加载：使用Spring的@Async注解并行获取用户画像和食品特征
- 结果压缩：配置Jackson的Gzip压缩减少传输数据量
踩坑记录：初期直接查询HDFS导致响应超时，后改为预加载每日推荐结果到MySQL，通过定时任务同步更新。
5. 推荐算法实现
5.1 混合推荐策略
系统采用三种算法并行计算：
- 基于内容的过滤：计算食品营养特征与用户需求的余弦相似度
- 协同过滤：通过用户聚类发现相似群体的饮食偏好
- 时序模型：分析用户饮食周期规律（如周末易摄入高热量）
最终推荐得分计算公式：
code复制final_score = 0.4*content_score + 0.3*cf_score + 0.3*time_score
5.2 冷启动解决方案
对于新用户，采用以下递进策略：
- 首日：推荐地域性热门健康食品
- 第一周：逐步收集基础饮食偏好
- 满两周：启用完整推荐模型
通过A/B测试验证，该方案使新用户7日留存率提升27%。
6. 系统部署方案
6.1 集群资源配置
生产环境采用5节点集群：
- Master节点：16核/64GB内存，运行NameNode和ResourceManager
- Worker节点：8核/32GB内存 ×4，每个节点配置12个Map槽位
- 边缘节点：部署SpringBoot服务，通过Gateway访问Hadoop集群
6.2 容器化部署
使用Docker Compose编排关键服务：
yaml复制version: '3'
services:
hadoop-namenode:
image: bde2020/hadoop-namenode:2.0.0-hadoop3.2.1
environment:
- CLUSTER_NAME=nutrition
ports:
- "50070:50070"
recommendation-api:
image: nutrition-recommend:1.0
depends_on:
- hadoop-namenode
ports:
- "8080:8080"
7. 效果验证与优化
7.1 评估指标体系
建立三级评估体系：
- 算法层面：精确率、召回率、F1值
- 系统层面：QPS、响应时间、错误率
- 业务层面：用户留存率、饮食结构改善度
7.2 实际运行数据
在3个月试运行期间：
- 日均处理用户日志2.3TB
- 推荐准确率达到82.4%（TOP5）
- 高峰时段API吞吐量达1200QPS
发现的主要瓶颈在于HDFS小文件问题，通过以下措施改善：
- 实现用户日志的SequenceFile合并
- 调整HDFS的block大小从128MB至256MB
- 启用NameNode的缓存机制
经过这些优化，MapReduce作业执行时间缩短了40%，集群整体资源利用率更加均衡。