1. 实时数据处理系统概述
实时数据处理系统是一类在数据产生后极短时间内完成采集、传输、计算与输出的系统。它的核心目标不是“把数据存下来慢慢算”，而是让数据在仍然具有决策价值的时间窗口内被处理并产生结果。这里的“实时”并不等于零延迟，而是指端到端延迟满足业务设定的时限：例如风控要求 100 毫秒内给出判断，设备告警要求 1 秒内触发，运营看板允许 5 秒级更新。因此，实时系统的第一设计动作不是选组件，而是明确延迟目标与数据时效边界。
实时处理与批处理的关键差异
批处理把一段时间的数据积累成有限数据集，按小时或按天统一计算，优点是吞吐高、实现简单、结果可重跑；缺点是结果滞后，无法响应正在发生的事件。实时处理则把数据视为连续到达、永不结束的流，计算逻辑常驻运行，每来一条或一小批数据就更新结果。两者最本质的区别在于：批处理面向“有界数据集”，实时处理面向“无界数据流”。
这种差异会传导到系统设计上。批处理可以等数据全部到齐再算，实时处理必须处理乱序、迟到和重复数据；批处理失败后通常整批重跑，实时处理需要依靠检查点、水位线和幂等写入来保证一致性。下面这张图对比了两者在数据流、延迟和结果更新方式上的差异，并给出 Azure 上对应的服务落点。
典型应用场景
实时处理的价值集中在“时间敏感 + 持续到达”的场景。常见有四类：
- 实时监控与告警：IoT 设备温度、振动、压力持续上报，超过阈值立即触发工单或停机，而不是等日报发现。
- 实时风控与反欺诈：支付、登录、下单事件在百毫秒内完成规则与模型评分，拦截异常交易。
- 实时推荐与个性化：用户点击、浏览、加购行为实时更新画像，影响下一次页面展示。
- 实时运营看板：订单量、成交额、在线人数按秒级刷新，支撑运营即时决策。
这些场景的共同点是：数据一旦过期，价值迅速衰减。判断一个业务是否真的需要实时处理，可以问三个问题——结果晚 1 分钟是否会造成损失？数据是否持续不断产生？是否需要基于最新状态做自动动作？若答案都是“是”，才值得引入实时链路。
Azure 实时数据服务全景
Azure 的实时数据服务可以按“接入—传输—计算—存储—输出”五段来理解，每一段都有明确职责，选型时先定位数据处在哪一段。
| 环节 | 代表服务 | 核心职责 | 典型参数关注点 |
|---|---|---|---|
| 接入 | Azure Event Hubs、IoT Hub | 高吞吐接收事件，提供分区缓冲 | 吞吐单位、分区数、保留期 |
| 传输 | Event Hubs、Service Bus | 解耦生产与消费，削峰填谷 | 分区键、消费组、死信队列 |
| 计算 | Stream Analytics、Azure Databricks、Functions | 窗口聚合、过滤、关联、评分 | 窗口长度、水位线、并行度 |
| 存储 | Cosmos DB、ADLS Gen2、Azure SQL | 保存热结果与冷明细 | 一致性级别、分区键、TTL |
| 输出 | Power BI、SignalR、Logic Apps | 看板刷新、推送、触发动作 | 刷新频率、推送延迟 |
以“工厂设备温度监控”为例，一条最小可用链路是：设备通过 IoT Hub 上报温度，Event Hubs 承接事件流，Stream Analytics 用 30 秒滚动窗口计算每台设备的平均温度，当平均值超过 80°C 时写入 Cosmos DB 并触发 Logic Apps 发送告警。这里 30 秒窗口、80°C 阈值都是示例参数，实际需按设备采样频率和工艺要求调整。判断链路是否达标，看三个指标：端到端延迟是否小于业务时限、告警是否在窗口结束后及时触发、断流恢复后结果是否仍然正确。
设计实时系统时要先想清楚的事
第一，明确时间语义。事件时间（数据实际发生时刻）与处理时间（系统处理时刻）在乱序场景下差异很大，窗口聚合应优先按事件时间并设置水位线容忍迟到。第二，明确一致性要求。是“至少一次”可接受，还是必须“精确一次”？这决定是否需要检查点与幂等写入。第三，明确扩展方式。实时链路通常按分区水平扩展，分区键选择不当会造成热点。第四，明确失败处理。消费失败是重试、跳过还是进死信队列，必须提前定义，否则故障时会丢数据或阻塞。