MongoDB聚合框架里的$expMovingAvg是一个专门用于计算指数移动平均的窗口操作符，通常在处理时间序列数据时用来平滑指标波动。与普通的$avg不同，它会对较远的历史值赋予更低的权重，从而让计算结果对最近的数据更敏感。理解它的参数含义和执行机制，可以帮助我们在监控、预测和异常检测等场景中写出更高效的聚合查询。
指数移动平均的基本原理与参数解析
指数移动平均（Exponential Moving Average，简称EMA）的核心思想是：每一个新计算出的平均值都由“上一期平均值”和“当前值”按一定比例混合而成。在MongoDB的$expMovingAvg中，这个比例可以通过两种方式指定。第一种是n参数，表示等效窗口大小，MongoDB会基于n推导出一个衰减系数，使得最近n个文档的权重分布近似于简单移动平均但带有指数衰减特性。第二种是alpha参数，直接指定新旧数据的混合比例，取值范围为0到1之间，值越大代表当前值权重越高、历史遗忘越快。
在聚合管道里，$expMovingAvg必须出现在$setWindowFields阶段中，因为它依赖窗口上下文来访问“前一个文档”的计算结果。如果我们使用n，语法上类似于{ $expMovingAvg: { input: "$value", n: 10 } }；如果使用alpha，则写成{ $expMovingAvg: { input: "$value", alpha: 0.3 } }。需要特别注意的是，input字段必须是数值类型表达式，否则会报类型错误。此外，n和alpha不能同时出现，只能二选一，这也是初学者经常忽略的限制。
从数学角度看，当使用alpha时，第t期的EMA值满足公式：EMA_t = alpha * value_t + (1 - alpha) * EMA_{t-1}。MongoDB在窗口起点会直接用第一个文档的input值作为初始EMA，后续依次递推。这种实现意味着如果文档顺序错乱，结果将完全不可信，因此$setWindowFields中的sort字段设置是强制且关键的。相比之下，n模式更偏向“最近n个点的指数加权”，适合不想手动算alpha的用户。
在聚合管道中的完整使用示例
假设我们有一组设备上报的温度数据，集合sensor_data中包含ts（时间戳）和temp（温度值）两个字段。我们希望按时间顺序计算出温度的指数移动平均，以及时察觉异常升温。下面是一段完整的聚合代码，演示了如何用alpha方式实现：
db.sensor_data.aggregate([
{
$setWindowFields: {
sortBy: { ts: 1 },
output: {
ema_temp: {
$expMovingAvg: {
input: "$temp",
alpha: 0.2
}
}
}
}
},
{
$project: {
_id: 0,
ts: 1,
temp: 1,
ema_temp: 1
}
}
]);
在上面代码中，$setWindowFields的sortBy保证了文档按照时间升序处理，这样每一行的ema_temp都是基于之前所有已排序文档递推出来的。如果不写sortBy，MongoDB会按照存储顺序计算，而存储顺序在分片或批量写入时并不一定等于业务时间顺序。通过$project我们仅保留关心字段，方便后续应用层消费。
如果我们改用n参数，只需把alpha替换为n即可，例如n: 5表示以最近5个数据点为基础的指数平滑。n的取值会影响平滑程度：n越小，曲线越贴近原始数据，噪声大但响应快；n越大，曲线越平缓，滞后明显。实际项目中，通常结合业务采样频率来选，比如每10秒上报一次，用n=30大约覆盖5分钟趋势。下面的示例展示n模式并添加窗口分区，按设备ID分开计算：
db.sensor_data.aggregate([
{
$setWindowFields: {
partitionBy: "$device_id",
sortBy: { ts: 1 },
output: {
ema_temp: {
$expMovingAvg: {
input: "$temp",
n: 5
}
}
}
}
}
]);
通过partitionBy我们让不同设备各自维护独立的EMA序列，避免互相干扰。这一点在多维监控中非常重要，因为A设备的历史温度不应影响B设备的平滑值。从执行计划看，$expMovingAvg在窗口阶段是单遍扫描完成的，时间复杂度线性，远比先$group再做客户端计算要高效。
常见误区、性能对比与适用边界
不少人在使用$expMovingAvg时会误以为它可以像$avg一样直接放在$group里，这是错误认知。$expMovingAvg属于窗口函数，只能存在于$setWindowFields中，它的“移动”特性依赖于有序窗口而非分组聚合。另一个误区是认为alpha和n可以共存，实际上MongoDB会直接抛出异常。还有人忘记排序，导致EMA曲线出现无规律跳跃，排查半天才发现是sortBy缺失。
与传统$avg或$shift配合自连接相比，$expMovingAvg的最大优势是原生支持且执行效率高。若用$avg做固定窗口平均，需要定义窗口范围如{ window: { range: [-4, 0] } }，每次都要重算区间内所有值；而EMA只需复用上一状态，常数级内存。但在需要“严格等权最近n期”的场景下，EMA并不合适，因为它的权重是指数衰减而非截断等权，老数据虽权重小却永远不会归零。
从适用边界来说，$expMovingAvg非常适合趋势平滑、轻量预测和突变检测，比如服务QPS毛刺发现、股价短期走向。它不适合需要可解释区间统计的报表，也不适合数据乱序到达且无法重排的流式管道。如果必须在乱序环境使用，建议先通过$sort或外部清洗保证顺序。在集群规模较大时，合理添加partitionBy能让窗口计算并行化，减少单分区数据倾斜带来的性能瓶颈。
MongoDBaggregation_pipelineexpMovingAvg修改时间：2026-08-13 21:00:30