时效分级与技术选型
| 时效要求 | 典型场景 | 技术方案 | 复杂度 |
|---|---|---|---|
| T+1 天 | 经营日报、月度分析 | 批处理 Glue / EMR | 低 |
| 小时级 | 运营看板、库存同步 | 增量批处理 + 调度 | 低-中 |
| 分钟级 | 实时大屏、异常监控 | Kinesis Firehose + Athena | 中 |
| 秒级 | 风控决策、实时推荐 | Kinesis / MSK + Flink | 高 |
| 毫秒级 | 在线特征查询、限流 | 预计算 + DynamoDB / Redis | 高 |
常见的过度设计：业务只需要小时级，却上了 Flink 集群。运维成本和故障面都大幅增加。
Kinesis 还是 MSK
选 Kinesis Data Streams
- 希望完全托管，不想管集群与版本
- 与 Lambda、Firehose、Analytics 的集成更顺
- 按分片计费，中小规模成本更低
- 团队没有 Kafka 运维经验
选 MSK（托管 Kafka）
- 已有 Kafka 生态与代码，迁移成本低
- 需要 Kafka 特有能力：Connect、Streams、精确一次语义
- 超大吞吐场景，单位成本更优
- 需要跨云或混合部署的一致性
实时管道参考架构
数据源
业务库 CDC
应用埋点
IoT 设备
日志流
接入
Kinesis Data Streams
MSK
DMS CDC
API Gateway
处理
Managed Flink
Lambda
Kafka Streams
窗口聚合
落地
S3（Firehose）
OpenSearch
DynamoDB
Redshift Streaming
消费
实时大屏
风控引擎
推荐服务
告警系统
务必同时把原始流写一份到 S3。流处理逻辑出错时可以重放，这是实时管道的保命设计。