概述
流式处理（Stream Processing）对物联网设备上报的数据流进行实时计算，无需等待数据落库后再批处理。设备数据以"流"的形式持续产生，流式处理引擎在数据到达时即时计算，实现秒级甚至毫秒级延迟的告警、聚合、分析。与规则引擎相比，流式处理支持更复杂的计算逻辑：多流关联、窗口聚合、CEP复杂事件检测、有状态计算。Flink、Spark Streaming、Kafka Streams是主流选择，其中Flink在低延迟、Exactly-once、状态管理方面表现突出，广泛应用于物联网实时场景。
物联网流式处理的典型架构：设备数据经MQTT/Kafka接入，Flink作业消费Kafka Topic，进行过滤、聚合、关联、告警判断，结果写入时序库、告警服务、或下发回设备。与规则引擎形成互补：规则引擎适合简单"条件-动作"，流处理适合复杂计算、多流关联、状态累积。
核心能力
窗口计算
滚动窗口（Tumbling）、滑动窗口（Sliding）、会话窗口（Session）。按时间或数量划分窗口，在窗口内做SUM、AVG、COUNT等聚合。支持事件时间、处理时间、水印机制处理乱序。物联网场景常用1分钟、5分钟滚动窗口做实时聚合。
CEP与状态管理
CEP（Complex Event Processing）：检测事件序列模式，如"A发生后5分钟内B发生"。有状态计算：跨消息的状态累积（如滑动平均、累计计数）。Exactly-once语义：故障恢复后不重不丢。Flink的Checkpoint机制保障状态一致性。
多源汇
支持Kafka、MQTT、HTTP、数据库等作为数据源与输出。可与时序库、告警服务、消息队列、API等对接。支持动态加表、Schema Evolution。
物联网典型应用
实时告警：温度超限、设备离线、异常波动检测。实时聚合：按设备、区域、时间窗口的用量汇总，支撑大屏。异常检测：基于统计或ML模型的实时异常识别。数据同步：多源数据融合、格式转换、写入多目标。与规则引擎、数据微服务、告警服务协同，构建完整的实时数据处理链路。
流上状态怎么对齐事件时间
连续到达的事件如何被分窗计算
流作业在事件还在到达时维持计算状态：按键累加、按窗口汇总、按先后顺序识别一组事件，再把结果写到下游。输入是有序或近似有序的事件，状态挂在键上，例如某台设备最近一个窗口的计数。它不假定这些点已经躺在一张可以反复扫描的表里。作业重启时，检查点把状态和流上的读取位置一起恢复，计算从上次一致的位置继续。
滚动窗口彼此衔接，适合做不重叠的分钟用量。滑动窗口按步长重复计算，适合观察最近一段时间是否越限。会话窗口按空闲间隔切开，适合把一阵密集上报收成一段。窗口用事件时间还是处理时间，决定结果跟不跟设备时钟走。现场问题多数问的是事情发生在设备上的时刻，因此要带上设备时间，同时保留入库时间供核对。
水位线值得启用的上报节奏
水位线表示：早于这个事件时间的数据，按目前观察到的乱序程度，大概已经到齐。它适合上报间隔相对稳定、乱序有上限的流。设备经常离线数小时再补传时，水位线要么被拖住、窗口迟迟不关，要么把补传判成迟到丢弃。这种流应把补传单独分区，或允许窗口关闭后按修订规则更新，而不是用一条很紧的水位线硬切。
启用前先量乱序的分布：多数点迟到几秒，还是有一批点迟到几小时。水位线的宽松度按这个分布设置，更晚的点进入侧输出。流作业负责计算，实时分析负责读取已经发布的结果。两边的窗口定义和分组键要一致，否则对流上的数字再查一次会对不上。
乱序时钟、反压和端到端投递语义
设备时间被设到未来，水位线会跟着跳，随后到达的正常点全被当成迟到。作业应限制单个点能够推动水位线的幅度，异常时钟进入侧输出。某个键每秒涌入的数据远超其他键时，这个键所在的并行度成为瓶颈，整体延迟上升。过热的键要拆开，或在接入层先限速、采样，只增加无关分区并不能消除这个热点。
下游写不赢时出现反压，是流量不匹配的信号。继续扩大内存缓冲，作业会拖到检查点超时。上游若是消息队列技术，消费位置必须和检查点一起提交，否则恢复后会从已处理的位置再次读取。恰好一次指的是作业状态与支持事务的下游一起提交。下游若只是普通插入，恢复后仍可能多写一行。接收结果的业务表要用幂等键。模式检测若把“几分钟内先后出现”写成处理时间，网络抖动就会造出虚假序列。
键决定状态落在哪。用设备标识做键，窗口统计跟着设备走；要用区域做键，就得在进入窗口之前完成设备到区域的映射。映射表事后变更，不会回头改写已经关闭的窗口。并行度调整后，状态会按新的分区重新摆放，检查点里的旧分区在恢复时必须对得上。未关闭窗口还在时就更换键的算法，恢复出来的计数会写到另一组键上，用量会突然减半或翻倍。变更键之前应先让旧窗口关闭，并用一段重叠时间对比新旧两条结果。