2. Azure实时数据平台核心组件
Azure 实时数据平台并不是单一产品，而是一条由“接入—处理—服务—分析”构成的组合链路。理解每个组件的定位，比记住产品名称更重要：Event Hubs 负责把海量事件可靠地接进来；Stream Analytics 负责低门槛的持续 SQL 计算；Functions 负责事件驱动的轻量逻辑与外部系统联动；Databricks 负责复杂流处理、机器学习与湖仓一体计算；Synapse 负责把实时结果与历史数据统一到分析仓库；Data Explorer（Azure Data Explorer，ADX）负责高吞吐、低延迟的日志与遥测交互式查询。选型的核心不是“哪个更强”，而是“这段负载应该放在链路的哪一层”。
一、先看数据链路，再看组件边界
一条典型的实时链路可以抽象为：生产者把事件写入 Event Hubs；Stream Analytics 或 Databricks 从 Event Hubs 消费并计算；计算结果可以写入 Synapse、Data Explorer、Blob Storage 或直接调用 Functions；Functions 也可以作为 Event Hubs 的消费者，处理告警、补偿、写回等轻量动作。下图给出各组件在链路中的位置与主要数据流向，便于在选型时先判断“当前问题属于哪一段”。
二、各组件定位与关键参数
Event Hubs 是实时链路的入口。它按分区（Partition）组织事件，分区数决定并行消费上限；吞吐单元（Throughput Unit，TU）或处理单元决定入口吞吐能力。事件默认保留 1 天，可配置到 7 天甚至更久，用于重放和补偿。选型时先估算峰值事件速率与单事件大小，再决定分区数和 TU。例如，假设峰值 2 万事件/秒、单事件 1 KB，则入口吞吐约 20 MB/s，需要结合 TU 的入口能力预留余量，而不是只按平均值配置。
Stream Analytics 适合“持续 SQL”场景：用类似 T-SQL 的语法对 Event Hubs 输入做窗口聚合、过滤、连接和模式识别。它按流单元（Streaming Unit，SU）计费，SU 决定可用的 CPU 与内存。典型用法是 5 分钟滚动窗口统计每台设备的平均温度，并把结果写入 Synapse 或 Data Explorer。它的优势是开发快、运维轻；局限是复杂状态计算、机器学习推理和自定义算子能力有限。
Azure Functions 是事件驱动的轻量计算单元。它可以直接由 Event Hubs 触发，适合做告警发送、写回数据库、调用外部 API、格式转换等“短平快”动作。选型时要关注消费组、批处理大小、并发控制和超时时间。若单次处理超过分钟级，或需要大量内存与复杂依赖，应转向 Databricks 或容器化服务。
Databricks 基于 Spark 结构化流，适合复杂流处理、机器学习推理和湖仓一体。它能处理有状态计算、流与维表连接、Delta Lake 写入，并支持批流统一。代价是集群管理与调优成本更高。典型场景是：从 Event Hubs 读取事件，做会话窗口、异常检测、特征计算，再写入 Delta 表供 Synapse 或 Power BI 使用。
Synapse Analytics 是统一分析服务，负责把实时结果与历史数据放在同一分析平面。它可以用专用 SQL 池承载高并发查询，也可以用 Spark 池做数据工程。实时链路通常把 Stream Analytics 或 Databricks 的结果写入 Synapse，再由 Power BI 做近实时看板。选型时要区分“实时计算”和“实时查询”：Synapse 更偏后者与统一分析。
Azure Data Explorer 面向高吞吐、低延迟的遥测与日志查询。它擅长海量结构化、半结构化数据的交互式分析，支持 KQL 查询和近实时摄入。若场景是设备遥测、应用日志、安全事件，且查询模式以探索、聚合、时间序列为主，Data Explorer 往往比 Synapse 更合适。
三、选型判断表
| 判断维度 | 优先选择 | 说明 |
|---|---|---|
| 海量事件接入与缓冲 | Event Hubs | 分区、保留、吞吐单元决定接入能力 |
| 简单持续 SQL 计算 | Stream Analytics | 窗口聚合、过滤、连接，开发快 |
| 事件触发轻量动作 | Functions | 告警、写回、调用外部 API |
| 复杂流处理与 ML | Databricks | 有状态计算、Delta Lake、批流统一 |
| 实时与历史统一分析 | Synapse | 专用 SQL 池、Spark 池、Power BI |
| 高吞吐遥测日志查询 | Data Explorer | KQL、近实时摄入、交互式探索 |
四、一个可参考的组合示例
假设要构建“工厂设备温度监控”：设备每 5 秒上报一次温度，峰值 1 万事件/秒。接入层用 Event Hubs，分区数设为 8，保留 3 天；计算层用 Stream Analytics 做 1 分钟滚动平均，超过阈值时输出到 Functions 发送告警；同时把原始事件写入 Data Explorer 供工程师用 KQL 排查；再把分钟级聚合结果写入 Synapse，供 Power BI 做产线看板。若后续要加入异常检测模型，则把 Databricks 接入同一 Event Hubs，读取原始事件做特征计算与推理，结果写回 Delta 表。这个组合没有“唯一正确”，但每一层都对应了明确的负载特征。
总结来看，Event Hubs 解决“接得住”，Stream Analytics 解决“算得快”，Functions 解决“连得动”，Databricks 解决“算得深”，Synapse 解决“看得全”，Data Explorer 解决“查得细”。选型时按数据流位置、延迟要求、计算复杂度和团队技能四个维度判断，就能在 Azure 实时数据平台中做出合理组合。