1. 实时数据分析系统全景

实时数据分析系统要解决的核心问题，不是“把数据存起来再慢慢算”，而是让业务事件在产生后的秒级到亚秒级内完成采集、传输、处理、存储与查询，并把结果反馈到监控看板、告警、风控或推荐等下游动作中。它与传统批处理的差别，主要体现在三个维度：时延目标（分钟/小时级 vs 秒级/毫秒级）、数据形态（有界历史数据集 vs 无界持续事件流）、计算语义（一次全量计算 vs 持续增量计算 + 窗口聚合）。理解这三点，才能正确选择 AWS 上的服务组合，而不是把批处理架构简单“加速”。

本课程的目标是让读者具备端到端设计与部署能力：能够根据业务时延与一致性要求，选型采集、缓冲、计算、存储、查询各层服务；能够定义事件 schema 与分区键；能够配置窗口、水位线与乱序容忍策略；能够用基础设施即代码方式部署并验证整条链路；能够在出现延迟、重复、丢数时定位到具体环节。学完本课程，你应当能独立交付一条可观测、可扩展、成本可控的实时数据管道。

AWS 实时数据服务矩阵

AWS 并没有一个“实时分析一体机”，而是由多个服务各司其职。按数据流方向，可划分为五层：

• 采集/接入层：Kinesis Data Streams（KDS）提供自定义吞吐的持久化流；MSK（托管 Kafka）适合已有 Kafka 生态或需要多消费者组重放；IoT Core 面向设备侧 MQTT 接入；API Gateway + Lambda 适合低频事件。
• 缓冲与传输层：KDS/MSK 承担削峰填谷与多订阅分发；Kinesis Data Firehose 负责免运维地投递到 S3、Redshift、OpenSearch。
• 计算层：Managed Service for Apache Flink 处理有状态窗口聚合、乱序与 exactly-once；Lambda 适合轻量无状态转换；Glue Streaming 适合 Spark 生态的微批 ETL。
• 存储层：S3 作为数据湖底座存放原始与加工后数据；Timestream 面向时序指标；DynamoDB 存放需低延迟点查的最新状态。
• 查询与消费层：OpenSearch 支撑日志检索与聚合看板；Athena 对 S3 做交互式 SQL；QuickSight 提供可视化；CloudWatch 承载指标告警。

选型的关键判断依据是：时延要求决定计算引擎（Flink 亚秒级、Lambda 百毫秒级、Glue 分钟级微批）；是否需要重放与多消费者决定用 KDS 还是 Firehose；查询模式决定落 OpenSearch 还是 Timestream 还是 S3+Athena。下面这张图给出了一条典型端到端架构的总览，也是本课程后续章节将逐层展开的对象。

典型业务场景与选型对照

不同场景对时延、吞吐、一致性的要求差异很大，选型不能一刀切。下表给出三类常见场景的对照，参数为教学示例，实际需按业务压测确定。

端到端数据流的关键环节

以“电商订单实时风控”为例，一条事件从产生到决策的完整路径如下：

1. 事件产生：下单服务在订单创建时生成 JSON 事件，包含 order_id、user_id、amount、event_time、ip 等字段。
2. 写入流：生产者以 user_id 为分区键调用 PutRecord，保证同一用户的事件进入同一分片，便于按用户做有状态聚合。
3. 流计算：Flink 作业消费 KDS，按 user_id 做 5 分钟滚动窗口，统计该用户近 5 分钟订单数与金额总和；当金额总和超过阈值（示例：5000 元）时输出风险事件。
4. 状态与容错：Flink 每 60 秒做一次检查点写入 S3，故障时从最近检查点恢复，KDS 位点由检查点统一管理，保证 at-least-once 或 exactly-once（取决于 sink 实现）。
5. 结果落库：风险事件写入 DynamoDB 供决策服务低延迟点查，同时写入 OpenSearch 供运营检索。
6. 可观测：CloudWatch 监控 KDS 的 IteratorAge、Flink 的检查点时长与失败次数、DynamoDB 的写入延迟；当 IteratorAge 持续超过 60 秒时触发告警。