2. AWS实时数据摄取入口选型
实时数据分析系统的第一道关口不是计算引擎，而是数据摄取入口。入口选错，后面无论是 Flink、Spark Structured Streaming 还是 Lambda 消费，都要用额外的中间层去弥补语义、吞吐或协议上的缺口。AWS 上常见的四个入口是 Kinesis Data Streams（KDS）、Kinesis Data Firehose、Amazon MSK 和 AWS IoT Core。它们并非互相替代的同层产品，而是分别面向“自定义流处理”“免运维投递”“Kafka 生态兼容”“海量设备接入”四类不同诉求。
四个入口的本质差异
Kinesis Data Streams 是一个托管的、可持久化的实时数据流服务。数据以“记录”为单位写入，每条记录最大 1 MB，由分区键决定进入哪个分片（Shard）。每个分片提供 1 MB/s 或 1000 条记录/s 的写入能力，读取侧每分片 2 MB/s，并支持最长 365 天的保留期。它的核心价值在于：写入即持久、可被多个消费者重复读取、支持按分片并行消费、可与 KCL 或 Lambda 的增强扇出（Enhanced Fan-Out）配合。代价是分片需要容量规划，写入按 PUT 载荷计费，消费者要自己处理检查点与重试。
Kinesis Data Firehose 是“投递管道”而非“消息总线”。它接收数据后，按缓冲大小（如 5 MB）或缓冲间隔（如 60 秒）触发一次投递，目标可以是 S3、Redshift、OpenSearch、Splunk 或第三方 HTTP 端点。它支持可选的 Lambda 转换、格式转换（JSON 转 Parquet/ORC）和动态分区。关键限制是：Firehose 不提供可重放的持久化流，消费者无法像读 KDS 那样“回放”数据；它本质上是近实时的批量投递，端到端延迟通常在 60 秒量级，而非毫秒级。
Amazon MSK 是托管的 Apache Kafka。它保留了 Kafka 的全部语义：Topic、Partition、Offset、Consumer Group、Exactly-Once 语义、Kafka Connect、Kafka Streams。对于已经使用 Kafka 的团队，MSK 意味着迁移成本最低、生态工具可直接复用。代价是运维复杂度高于 KDS：需要管理 Broker 规格、存储、分区数、副本因子，虽然 AWS 托管了底层节点，但 Topic 设计、分区均衡、消费者滞后（Lag）仍需自行负责。
AWS IoT Core 面向设备接入，而不是通用数据流。它支持 MQTT、HTTPS、WebSocket 协议，设备通过证书或 Cognito 身份认证后发布消息到 Topic。IoT Core 的核心能力是“设备连接管理 + 规则引擎”：规则引擎可以用 SQL 语句把消息路由到 KDS、Firehose、Lambda、S3 等下游。它天然处理断线重连、离线消息（通过 Shadow）、设备影子状态同步。但它不适合作为高吞吐的通用数据总线，单账户的发布/订阅速率有配额限制。
选型决策的四个判断维度
把四个入口放在一起比较时，不要只比“功能列表”，而应按以下顺序逐层过滤：
第一层：数据源协议与接入方式。如果数据来自 MQTT 设备、需要双向通信或设备影子，IoT Core 是唯一自然选择；如果数据来自已有 Kafka 集群或团队已深度使用 Kafka 生态，MSK 的迁移成本最低；如果数据来自应用埋点、日志采集器（如 Fluent Bit、Kinesis Agent），KDS 或 Firehose 都可承接。
第二层：是否需要可重放与多消费者。KDS 和 MSK 都支持多消费者独立读取同一份数据，且可以回放历史。Firehose 一旦投递完成，数据就进入目标存储，无法从 Firehose 侧重读。IoT Core 的消息在规则引擎转发后也不保留可重放副本。因此，如果下游既有实时告警又有离线入湖，且两者需要读同一份原始流，应优先 KDS 或 MSK。
第三层：延迟与吞吐形态。KDS 和 MSK 可以做到毫秒级端到端延迟；Firehose 的缓冲机制决定了它通常在 60 秒左右；IoT Core 的规则引擎转发延迟通常在百毫秒到秒级。如果业务要求“秒级看板”或“实时风控”，Firehose 单独使用往往不够，需要 KDS 作为前置缓冲。
第四层：运维投入与成本结构。Firehose 几乎零运维，按传输数据量计费；KDS 按分片小时数和 PUT 载荷计费，需要容量规划；MSK 按 Broker 实例和存储计费，运维复杂度最高；IoT Core 按连接数、消息数和规则引擎执行次数计费，设备规模大时成本需要仔细估算。
一个可执行的选型决策表
下面这张表可以直接用于方案评审时逐项打勾。假设场景为“某电商平台需要将订单事件、应用日志、IoT 仓储传感器数据统一接入，并同时支持实时风控和离线数仓”。
| 判断项 | KDS | Firehose | MSK | IoT Core |
|---|---|---|---|---|
| 数据源协议 | SDK / KPL / Agent | SDK / Agent / 直接 PUT | Kafka Producer | MQTT / HTTPS |
| 可重放 | 是（最长 365 天） | 否 | 是（按保留策略） | 否（转发后不保留） |
| 多消费者 | 支持（含增强扇出） | 不支持 | 支持（Consumer Group） | 不支持 |
| 典型延迟 | 毫秒级 | 60 秒级 | 毫秒级 | 百毫秒～秒级 |
| 运维复杂度 | 中（分片规划） | 低 | 高（Topic/分区/副本） | 低（设备管理除外） |
| 本场景适配 | 订单事件 + 风控 | 日志入 S3 | 已有 Kafka 链路 | 仓储传感器 |
组合使用而非二选一
实际生产系统中，四个入口经常组合出现。一个典型的组合模式是：IoT Core 接收设备 MQTT 消息，规则引擎将消息转发到 KDS；应用日志通过 Firehose 直接投递到 S3 做 Parquet 转换；订单事件写入 KDS 供 Flink 做实时风控；如果团队已有 Kafka 集群，则 MSK 作为统一总线，再通过 KDS 或 Firehose 桥接到 AWS 分析服务。选型不是“选一个”，而是“为每类数据流选择最合适的入口，并明确它们之间的桥接关系”。
常见误判与纠正
第一个常见误判是“Firehose 可以替代 KDS”。Firehose 的缓冲和投递语义决定了它不适合做实时风控的输入，因为风控需要在秒级内对单条事件做出判断，而 Firehose 可能还在缓冲。第二个误判是“MSK 一定比 KDS 强”。MSK 的运维成本和最小集群规模在低吞吐场景下并不经济，如果团队没有 Kafka 经验，KDS 的托管程度更高。第三个误判是“IoT Core 只能接设备”。IoT Core 的规则引擎也可以接收 HTTPS 消息，但它的配额和计费模型是按消息数设计的，不适合替代通用数据总线。
选型的最终依据不是产品功能多少，而是数据流的语义要求与团队运维能力之间的匹配度。把“协议、重放、延迟、消费者、运维、成本”六个词写在评审白板上，逐项确认，就能避免大多数入口选型错误。