StreamSQL v1.2.0 是继 v1.0.0 之后一次较完整的能力升级。它补上 CEP 模式识别、分析函数、资源边界和可观测性相关能力，使边缘流处理不再局限于窗口聚合，也能表达连续事件、跨行比较和有状态告警。
从“统计发生了多少次”走向“识别按什么顺序发生”
普通实时聚合擅长回答“过去五分钟出现了多少次高温”，CEP（Complex Event Processing，复杂事件处理）则要回答更复杂的问题：设备先升温，随后持续过热，最后发生停机，这组事件是否在规定时间内连续出现？
这两类问题的状态模型不同。聚合通常围绕窗口维护计数、求和或平均值；CEP 需要维护部分匹配状态，并同时处理事件顺序、时间约束和重复事件。对边缘场景而言，原生 SQL 表达 CEP 有三个直接价值：
- 规则可以靠近设备执行，减少原始事件持续上传带来的网络开销。
- 运维人员可以阅读 SQL 规则，不必把每种模式固化为一段应用代码。
- 检测结果能够继续进入 SQL 管道，参与过滤、关联、聚合或告警输出。
需要注意，CEP 会引入比普通过滤更多的状态。输入乱序、事件时间选择、匹配超时和重复匹配策略，都会改变检测结果。上线前必须用真实事件回放验证规则，而不能只测试理想顺序的数据。
分析函数补上了跨行判断能力
分析函数适合处理“当前行与附近记录之间的关系”。典型场景包括：
- 用
LAG比较当前读数与上一条读数，识别突变。 - 用滑动窗口计算最近若干条记录的平均值或最大值。
- 用
ROW_NUMBER对设备分区后的事件排序或去重。 - 在保留明细行的同时计算累计值，而不是像
GROUP BY那样折叠记录。
这让不少原本需要在业务代码中维护的上一状态、变化率和连续排名逻辑，可以留在流式 SQL 中。它也带来新的工程问题：分区键是否足够均匀、排序依据是事件时间还是到达时间、窗口是否有明确上界。缺少边界的状态会持续占用边缘节点有限的内存。
可以这样实践：检测设备过热并计算温升
下面是一个可改造的示例。假设运行环境支持接近 SQL 标准的 MATCH_RECOGNIZE、LAG 和窗口语法；具体连接器定义、时间属性声明及 CEP 方言需要按 StreamSQL v1.2.0 的实际文档调整。示例中的表结构和阈值是实践假设，不代表版本内置配置。
先准备一组设备事件：
CREATE TABLE sensor_events (
device_id VARCHAR,
event_time TIMESTAMP,
temperature DOUBLE,
status VARCHAR
);
INSERT INTO sensor_events VALUES
('edge-01', TIMESTAMP '2025-01-10 10:00:00', 72.0, 'RUNNING'),
('edge-01', TIMESTAMP '2025-01-10 10:00:10', 86.0, 'RUNNING'),
('edge-01', TIMESTAMP '2025-01-10 10:00:20', 91.5, 'RUNNING'),
('edge-01', TIMESTAMP '2025-01-10 10:00:30', 93.0, 'STOPPED');
使用分析函数计算相邻事件的温度变化：
SELECT
device_id,
event_time,
temperature,
temperature - LAG(temperature) OVER (
PARTITION BY device_id
ORDER BY event_time
) AS temperature_delta
FROM sensor_events;
再用 CEP 描述“正常运行后连续过热，随后停机”的事件序列：
SELECT
device_id,
start_time,
stop_time,
peak_temperature
FROM sensor_events
MATCH_RECOGNIZE (
PARTITION BY device_id
ORDER BY event_time
MEASURES
FIRST(A.event_time) AS start_time,
LAST(C.event_time) AS stop_time,
MAX(B.temperature) AS peak_temperature
ONE ROW PER MATCH
AFTER MATCH SKIP PAST LAST ROW
PATTERN (A B{2,} C)
DEFINE
A AS A.status = 'RUNNING' AND A.temperature < 80,
B AS B.status = 'RUNNING' AND B.temperature >= 85,
C AS C.status = 'STOPPED'
);
生产规则还应增加时间上限，例如要求整个模式在两分钟内完成。否则一个长期未完成的部分匹配可能占用状态。若产品方言不支持直接在模式中声明时限，可以在输入窗口、规则条件或运行时状态 TTL 中设置等价边界。
资源边界与可观测性决定规则能否长期运行
边缘节点通常只有固定的 CPU、内存和磁盘预算。CEP 与分析函数越强，越需要明确状态生命周期。v1.2.0 增加资源边界和可观测性相关能力，其意义不只是方便排错，而是让流任务具备可运营性。
可以围绕以下指标建立监控，具体指标名称以实际版本暴露内容为准：
# 示例配置：字段名称需要按实际 StreamSQL 部署格式调整
runtime:
memory_limit_mb: 512
state_ttl: 10m
checkpoint_interval: 30s
observability:
metrics_enabled: true
health_endpoint: /health
metrics_endpoint: /metrics
log_level: info
配置资源限制时，不要只观察进程是否存活。至少还要关注输入速率、输出速率、处理延迟、乱序或丢弃事件数量、当前状态大小、CEP 部分匹配数量，以及检查点耗时和失败次数。如果部分匹配持续增长而输出没有同步增加，通常意味着模式过宽、结束条件难以满足，或者状态超时没有生效。
升级前的检查清单
v1.2.0 适合希望在边缘侧实现设备异常序列识别、跨事件趋势判断和本地告警的团队，但新能力不应一次性全部打开。建议从一条可回放、可核对结果的规则开始：
- 明确事件时间、到达时间以及乱序处理策略。
- 为 CEP 模式、分析窗口和关联状态设置上界或 TTL。
- 使用历史事件回放，覆盖重复、缺失、延迟和乱序数据。
- 同时压测吞吐、内存占用、检测延迟和恢复时间。
- 为规则版本、匹配数量、状态大小和失败原因建立监控。
- 核对 v1.0.0 任务的 SQL 方言、连接器和状态兼容性，再安排灰度升级。
这次升级真正重要的变化，是 StreamSQL 开始覆盖“连续事件意味着什么”这一层问题。SQL 能降低规则表达门槛，但不会自动消除状态复杂度。规则越接近生产设备，越要给时间窗口、资源使用和异常恢复划出清晰边界。