AWS Timestream：应使用计划查询还是预计算聚合处理时序数据？

嘿，刚好我之前在项目里处理过几乎一模一样的IoT时序数据聚合需求，来给你唠唠这两种方案的优劣势，帮你做选择～

先明确下你的场景：每小时从传感器摄入温度、湿度数据，需要计算日均值做报表分析，现在纠结是实时摄入时预计算均值存起来，还是用Timestream的计划查询定时计算。

我给你拆解下两种方案的利弊，再给你点实际的决策建议：

一、预计算聚合（实时摄入时计算存储） #

这种方案就是每次传感器数据进来，你就更新对应日期的均值（比如用Lambda触发摄入事件，计算并写入聚合表）。

优点： #

• 查询速度拉满：报表直接读预存的均值，不用每次扫描大量原始数据，毫秒级就能拿到结果，适合需要极致查询速度的场景
• 支持实时部分聚合：比如中午想看看当天上午的温度均值，预计算可以实时更新，马上就能拿到

缺点： #

• 复杂度高，要自己扛很多细节：
  • 得处理数据补传的情况：比如传感器漏传了前几个小时的数据，你得重新计算对应日期的均值，还要处理并发更新的问题（比如两条数据同时更新同一天的均值，会不会算错）
  • 要维护数据一致性：如果某条数据摄入失败，你的均值就不准了，得自己写重试、补偿逻辑
• 维护成本高：之后如果要改聚合逻辑（比如加个湿度的均值，或者改成按周聚合），你得改摄入端的代码，还要重新跑历史数据的聚合
• 存储冗余：原始数据和聚合数据都要存，虽然Timestream存储成本不高，但如果聚合维度多（比如按传感器组、区域），存储量会翻倍

二、AWS Timestream计划查询（Scheduled Queries） #

这是Timestream原生的全托管定时聚合功能，你可以设置每天凌晨跑一次查询，计算前一天的所有传感器日均值，然后写入到专门的聚合表。

优点： #

• 全托管，省心省力：Timestream帮你搞定所有脏活累活——定时触发查询、处理并发、重试失败的任务、确保数据一致性，你只要写好聚合SQL就行
• 灵活性拉满：之后要改聚合逻辑？直接改计划查询的SQL就行，不用碰摄入端的代码；要加新的聚合指标（比如湿度均值），也是改SQL的事儿，分分钟搞定
• 成本可控：计划查询只在指定时间跑，计算成本可预测；而且每次只扫描前一天的原始数据，扫描量小，查询成本低
• 数据一致性有保障：你可以设置查询延迟执行（比如每天凌晨2点跑），确保所有传感器的当日数据都已经摄入完毕，再计算均值，不会漏数据

缺点： #

• 聚合结果有延迟：比如要等第二天才能拿到前一天的均值，适合T+1的报表场景，如果是要实时看当日的部分均值，这个方案就满足不了
• 查询速度不如预计算：虽然比扫全量原始数据快很多，但还是不如直接读预存的均值，但对于报表这种非实时场景，这点延迟完全可以忽略

三、给你的实际决策建议 #

结合你的场景（每小时摄入数据，做日均值报表），我给你几个判断标准：

• 如果你的报表是T+1的（比如第二天看前一天的均值）：直接用计划查询就够了，这完全是Timestream设计这个功能的初衷，省掉自己维护预计算逻辑的麻烦，香得很
• 如果你的需求是实时获取当日的部分均值（比如仪表盘要实时显示当天的累计平均）：那可以考虑预计算，但一定要做好数据补传、并发更新的处理
• 如果之后可能要扩展聚合维度或指标：优先选计划查询，灵活性甩预计算几条街，改SQL比改摄入代码简单太多

另外，你现在的查询SQL完全可以复用在计划查询里，只要调整下时间范围（比如用bin(time, 1d)结合前一天的时间过滤），然后把结果写入到聚合表，之后报表直接查这个聚合表就行，比如：

SELECT
  bin(time, 1d) AS day,
  sensor_id,
  AVG(measure_value::double) AS daily_avg_temperature,
  AVG(humidity::double) AS daily_avg_humidity
FROM "iot"."test"
WHERE time BETWEEN TIMESTAMP 'yesterday 00:00:00' AND TIMESTAMP 'yesterday 23:59:59'
GROUP BY bin(time, 1d), sensor_id
ORDER BY day ASC

备注：内容来源于stack exchange，提问作者Hamza Morsi