6.2 时序原生计算趋势
6.2 时序原生计算趋势
本节摘要：TSDB 下一程是 Time-Native Compute：
anomaly_score()、forecast()不再是外部 UDF，而是与存储共享索引的下推原语。并列趋势：SQL 复兴（Influx IOx、QuestDB）、Arrow 向量化（10–100× 窗口聚合）、OpenTelemetry/OpenMetrics 互操作、时序 Foundation Model（TimesFM 等）训练数据来自 TSDB 集群。
本节地图
阅读完本节，你应当能够：
- 解释时序原生计算与「TSDB + 外部 Python UDF」的差异
- 说明 Arrow 列式对窗口聚合的意义
- 列举 IEEE P2861 类标准化工作方向
一、问题与直觉
今天 anomaly 检测常 导出 CSV → Jupyter → 回写告警——延迟与数据一致性难保证。理想查询：
SELECT device_id, anomaly_score(temperature, 'sliding_window', 300) AS score FROM sensors WHERE time > now() - interval '1 hour';
anomaly_score 若能下推到存储层，与 Gorilla 压缩块、时间索引同路径执行，才称 时序原生——抹平存储与计算边界。
二、核心原理
| 趋势 | 现状 | 代表 |
|---|---|---|
| SQL 复兴 | 时序 SQL 标准化 | Influx 3 SQL、QuestDB |
| 向量化 | SIMD 批量聚合 | Arrow/DataFusion、ClickHouse 系 |
| 云原生 | 存算分离 object store | Influx 3、Mimir |
| AI 耦合 | 训练数据管道 | TimesFM、M6-TS |
| 语义标准 | 跨库 time_bucket |
IEEE P2861 草案 |
原生计算 vs 外部 UDF：差在哪
两者的差别不是「一个函数叫不叫 UDF」，而是数据移动的成本。外部 UDF 的路径是：查库 → 序列化导出 → 跨进程传输 → Python 计算 → 结果回写；原生计算的路径是：函数直接读压缩块与索引 → 在列存上向量化计算 → 返回结果。前者多出至少两轮全量数据移动，后者几乎没有。对「10 万台设备 × 30 天原始数据」这种规模的异常检测，前者要几十分钟，后者可以压到秒级。这才是「原生」两个字的工程含义。
SQL 与向量化
2019 年后 TSDB 普遍回归 SQL——不是妥协，而是 原语标准化。QuestDB、Influx IOx（DataFusion）、Timescale 均用列式向量化执行 time_bucket + avg，相对逐点遍历 10–100× 提升（SOURCE 向量化段落）。
向量化为什么能有这么大差距？列式存储下，同一列的所有值在内存里是连续数组，一次 SIMD 指令可以同时对多个值做加法或比较；而逐点遍历每取一个值都要做指针解引用与类型判断。窗口聚合在 TSDB 中占比极高，所以「列式 + SIMD」直接作用于最热路径。
时序 Foundation Model
MIT/Google TimesFM、阿里云 M6-TS 依赖 TSDB 提供带标签、高保真、可追溯血缘的原始流——TSDB 成为 AI for Time 的燃料工厂，质量守门在 ingest 与 retention 层。
互操作
OpenMetrics 统一 exposition；OTLP 统一摄取；下一步是 时间语义 ISO 级标准——不同库的 fill()、interpolate() 语义一致后，联邦查询与迁移才可行。
互操作
| 方向 | 工程含义 |
|---|---|
| 原生计算 | 告警闭环在库内完成 |
| 存算分离 | S3 冷存 + 无状态 query |
| 多模态 | TSDB + 向量/图库时间主键对齐 |
| 数字孪生 | 实测流 + 物理方程约束 |
三、工程实践要点
今日可落地：Timescale continuous aggregate + Grafana ML plugin；VM 内建 anomaly detection 实验特性；Prom recording rules 预计算特征。
选型预留：若 2 年内要做库内 forecast，优先 SQL + 下推能力强的引擎，避免深度绑定仅 PromQL 栈。
数据质量：Foundation Model 再强，错误 timestamp 与暴涨 cardinality 仍会毁掉训练—— ingest 治理仍是第一性。
一个务实的落地路线
「时序原生计算」听起来前沿，但可以拆成渐进步骤，不必等某款产品一次到位。第一步，先用现有的 continuous aggregate、recording rule 等物化手段，把常用的特征（均值、P95、变化率、最近 24h 基线）预计算成普通指标，让告警与报表直接消费——这一步不需要任何新引擎。第二步，把 anomaly 检测从「导出 + 外部脚本」改成「数据库内 SQL 函数 + 定时任务」，即使没有下推，也能消除重复导出，让特征与原始数据同源。第三步，当某个引擎真正发布了库内 anomaly/forecast 原语，再针对最高频的检测场景做 PoC，验证延迟与准确率后局部替换。这条路线的好处是每一步都有独立收益，且不赌单一厂商的技术方向——无论未来哪个产品跑出来，你已经积累的物化特征与 SQL 资产都能复用。
评估下一代引擎的检查清单
面对新出的时序引擎或新版本，用下面这些问题快速判断它离「时序原生」有多近：窗口函数（time_bucket/SAMPLE BY）是否是内置原语还是依赖 UDF；anomaly/forecast 类函数能否下推到存储层；执行引擎是否列式向量化（Arrow/DataFusion 类）；是否支持存算分离与对象存储冷层；exposition 与摄取是否兼容 OpenMetrics/OTLP；fill、interpolate 等语义是否有明确文档可对齐。六项里命中越多，越接近下一代的形态。
⚠️ 常见坑：把时序大模型当黑盒替代领域特征——工业场景仍需物理约束与可解释告警。
💡 关键直觉：TSDB 从「系统的镜子」变为「智能的胎盘」——存储、计算、ML 边界持续模糊。
自测题
- 「外部 UDF」与「原生下推」在数据移动上差了几步？为什么差距能到数量级？
- Arrow 列式 + SIMD 为什么对窗口聚合特别有效？
- 用六项检查清单评估一个你正在用的 TSDB 新版本。
核心回顾
- Time-Native Compute 下推 anomaly/forecast
- SQL + Arrow 向量化是性能主线
- OTel/OpenMetrics 统一摄取与 exposition
- 时序 FM 依赖高质量 TSDB 数据基座
- 标准互操作 降低迁移与联邦成本
本教程至此收束四大产品对比全栈；版本迭代请以各厂商当前 major 发布说明为准。