IoT 数据实时分析：流计算在物联网场景中的落地实践

为什么IoT场景里，离线分析会被越顶越多

物联网设备一旦接入系统，数据就不会停。工厂里的传感器、车上的数据盒子、楼宇里的智能电表，都在以固定频率或事件触发的方式往平台回传状态。一开始大家往往觉得“数据量不大，存下来每天算一次就够了”，直到业务方不断提出“今天的数据今天看已经太晚了”这样的反馈，才发现自己面对的真正需求是IoT数据实时分析——不是把数据算出来，而是把数据及时算出来。

举一个简单的计算：一台设备每30秒上报一次，一天就是2880条。10万台设备一天就是28.8亿条。离线任务即使能在一个小时内跑完，也无法覆盖设备故障发生后的关键告警窗口，更不要提那些需要联动处理的场景。

流计算到底解决了什么，不解决什么

流计算解决的，是把无界的数据流变成一组可以持续更新的结果。它不是把批处理变得更快，而是在事件流动过程中完成计算。这对IoT场景特别合适，因为设备数据天然就是无界的。

但流计算不解决数据本身的质量问题。如果上报的数据缺失时间戳，或时间戳格式多种多样，任何框架都算不出可靠结果。这也是很多项目一开始忽略，后面花大代价补齐的部分。

以最常用的温度监控为例，每台传感器每隔几秒上报一次数据。如果只写Kafka消费者，需要自己管理窗口和状态；而使用流计算框架，可以用SQL表达同样的逻辑。

CREATE TABLE sensor_data (
  device_id STRING,
  temperature DOUBLE,
  event_ts TIMESTAMP(3),
  WATERMARK FOR event_ts AS event_ts - INTERVAL '5' SECOND
) WITH (
  'connector' = 'kafka',
  'topic' = 'sensor',
  'properties.bootstrap.servers' = 'kafka:9092',
  'format' = 'json'
);

SELECT device_id,
       AVG(temperature) AS avg_temp
FROM sensor_data
GROUP BY device_id, TUMBLE(event_ts, INTERVAL '1' MINUTE);

这段SQL声明了event_ts作为事件时间，并设置了5秒乱序容忍窗口。随后按设备ID和一分钟窗口求平均温度。注意，这里没有指定处理时间，因为对于IoT场景，传感器真正产生数据的时间和到达服务器的处理时间之间，往往隔着不可忽略的网络抖动。

落地过程中最容易踩的几个坑

流处理框架的上手难度并不高，难在把它放到真实链路中验证。很多IoT项目发现结果不对时，第一反应是调代码，其实问题往往在下面这几点。

把处理时间当成事件时间
窗口粒度和状态大小没有权衡
缺少背压和消费延迟监控
过度追求端到端精确一次

第一点在IoT里非常常见。设备上报通常经过网关和消息队列，任何一段网络抖动都会导致数据延迟或乱序。如果使用服务器接收时间，相当于把一个不稳定的变量混进了计算逻辑。最直接的做法是让设备端把采集时间写进消息体，再在流任务里把它解析成事件时间。

第二点有关资源消耗。窗口越小、key维度过大，状态就会膨胀。比如按秒级窗口计算所有设备每分钟状态，状态存储很快会成为瓶颈。建议先按1分钟或5分钟窗口设计，业务确认延迟可接受后，再去探索更细粒度。

第三点容易被“Kafka可以积压”掩盖。Kafka把消息暂存起来，流任务处理不过来时，消费延迟悄悄增长。必须监控Kafka的滞后量、每个算子的反压比例，否则数据堆到下游写入层才会暴露问题。

第四点是成本误判。Flink端到端精确一次依赖Kafka事务和下游幂等，这在IoT场景中往往没必要。设备重连会导致重复上报，业务上更怕的是长时间没有数据。在架构设计上，不如先接受至少一次语义，把重复放在业务侧消解。

方案对比：Flink、Kafka Streams、Spark Streaming

流计算引擎选型，决定的是后面半年到一年的成本曲线。横向对比三个主流方案，从IoT场景最关心的几个维度来看最直观。

维度	Flink	Kafka Streams	Spark Structured Streaming
事件时间	成熟	支持	有限
状态管理	内置状态后端	依赖Kafka主题	依赖外部存储
延迟水平	毫秒级	毫秒级	秒级
部署复杂度	独立集群	嵌入应用	Spark集群
适用场景	复杂窗口、CEP	简单过滤聚合	批流混合

如果IoT业务已经使用Kafka作为总线，且需求只是过滤、简单聚合，Kafka Streams是成本最低的选择。如果需求涉及大量窗口、动态规则或者需要状态跨越多次事件计算，Flink是更稳妥的答案。Spark Structured Streaming则适合已经构建了Spark数据平台、愿意把实时和批处理放在同一套体系里的团队。