聚合框架本身不优化模型，但能高效生成高质量特征数据——这是推荐系统效果提升的关键前置动作。
直接说结论：聚合框架本身不优化模型，但能高效生成高质量特征数据——这是推荐系统效果提升的关键前置动作。
为什么推荐场景下 $group + $sum 比 find() + 应用层统计快得多
推荐系统常需计算用户近期点击频次、品类偏好强度、行为衰减权重等。如果每次请求都靠应用层拉取原始日志再遍历统计，网络传输+内存计算开销会随用户量线性增长，且无法复用索引。
- 聚合管道在 mongod 进程内执行，避免大量 BSON 序列化/反序列化和网络往返
-
$match阶段可命中userId+timestamp复合索引，快速过滤时间窗口内的行为 -
$group的分组聚合由 C++ 层实现，比 Node.js/Python 的 for 循环快 5–10 倍（实测千万级日志） - 注意：
$sort在$group后使用会强制内存排序，超 100MB 触发errmsg: "Sort exceeded memory limit"，必须加allowDiskUse: true
$facet 一次提取多维度特征，避免多次 round-trip
一个用户画像可能同时需要「最近7天点击数」「收藏品类TOP3」「平均停留时长」——传统方式要发 3 条查询。用 $facet 可在一个请求里并行计算：
db.user_events.aggregate([
{ $match: { userId: "u123", timestamp: { $gt: ISODate("2026-04-06") } } },
{ $facet: {
"clicks": [ { $match: { eventType: "click" } }, { $count: "total" } ],
"topCategories": [
{ $match: { eventType: "click" } },
{ $group: { _id: "$category", cnt: { $sum: 1 } } },
{ $sort: { cnt: -1 } },
{ $limit: 3 }
],
"avgDuration": [ { $group: { _id: null, avg: { $avg: "$duration" } } } ]
}
}
])
- 所有子管道共享上游
$match结果，减少重复扫描 - 每个子管道独立执行，互不影响；但总内存占用是各子管道之和，大结果集仍需
allowDiskUse - 返回结构嵌套，应用层需解析
result[0].clicks、result[0].topCategories等字段
用 $bucketAuto 构建用户分群标签，替代离线 Hive 脚本
运营常需“高价值用户”“沉默用户”“价格敏感用户”等标签用于召回。与其每天跑 Spark 任务写入 MySQL，不如用聚合实时打标：
db.users.aggregate([
{ $lookup: {
from: "user_events",
localField: "_id",
foreignField: "userId",
as: "events"
}
},
{ $addFields: {
"lastActive": { $max: "$events.timestamp" },
"totalClicks": { $size: "$events" }
}
},
{ $bucketAuto: {
groupBy: "$totalClicks",
buckets: 5,
output: {
"userIds": { $push: "$_id" },
"avgLastActive": { $avg: "$lastActive" }
}
}
}
])
-
$bucketAuto自动按分布切分区间（非等宽），比手写$cond判断更鲁棒 -
$lookup关联行为表时，务必在user_events.userId上建索引，否则全表扫描 - 该聚合结果可直接存入
user_segments集合，供推荐服务实时查表召回
真正容易被忽略的是：聚合输出的数据质量，直接决定后续模型训练的天花板。字段缺失、时间窗口错位、去重逻辑遗漏（比如同一点击事件被记录两次），都会让模型学到错误模式。上线前必须用 explain("executionStats") 确认 totalDocsExamined 接近 nReturned，否则说明索引没生效或条件写错。
