4. 数据摄取模式与实战

数据摄取是数据管道的第一道关口，选错服务往往意味着后续所有环节都要为吞吐、延迟和运维成本买单。AWS 上最常用的四类摄取服务——Kinesis Data Streams（KDS）、Kinesis Data Firehose、Amazon MSK、AWS DMS——分别面向不同的数据形态和消费模式。理解它们的定位差异，比记住参数更重要。

四类服务的定位差异

KDS 是低延迟、可重放的实时流存储，数据默认保留 24 小时（可延长至 365 天），支持多个消费者并行读取，适合需要自定义消费逻辑、多下游复用的场景。Firehose 是托管投递管道，几乎无需运维，把数据自动写入 S3、Redshift、OpenSearch 等目标，适合"采集即落地"的准实时场景，但不支持多消费者重放。MSK 是托管的 Apache Kafka，保留 Kafka 的 Topic、Partition、Consumer Group 语义，适合已有 Kafka 生态、需要复杂消费拓扑或跨系统集成的团队。DMS 面向数据库迁移与持续复制，通过 CDC 捕获源库变更，适合把关系型数据库的增量数据同步到数据湖或数仓。

Kinesis Data Streams：分片、分区键与消费模式

KDS 的核心概念是分片（Shard）。每个分片提供 1 MB/s 或 1000 条记录/秒的写入能力，读取侧默认 2 MB/s。分区键（Partition Key）决定记录进入哪个分片，相同分区键的记录保证有序。设计分区键时要避免热点——如果所有记录都用同一个键，写入会集中到单个分片，触发 ProvisionedThroughputExceededException。

消费模式有两种：共享吞吐（Shared Throughput）和增强扇出（Enhanced Fan-Out）。共享模式下多个消费者竞争分片的 2 MB/s 读取带宽，适合消费者数量少的场景；增强扇出为每个消费者分配独立的 2 MB/s 管道，适合多消费者并行读取。启用增强扇出后，消费者通过 SubscribeToShard 建立 HTTP/2 长连接，延迟可降至 70ms 左右。

# 创建 4 分片的流
aws kinesis create-stream \
  --stream-name orders-stream \
  --shard-count 4

# 注册增强扇出消费者
aws kinesis register-stream-consumer \
  --stream-arn arn:aws:kinesis:us-east-1:123456789012:stream/orders-stream \
  --consumer-name order-processor

容错方面，KDS 本身通过多可用区复制保证分片数据持久性。消费端需要处理三类失败：Lambda 消费失败会重试直到数据过期，建议配置 MaximumRetryAttempts 和 DestinationConfig 把失败记录送入 SQS 死信队列；KCL 应用通过检查点（Checkpoint）记录消费位点，失败时从上一个检查点恢复；分片分裂或合并后，消费者需要重新分片感知（Resharding Awareness）。

Kinesis Firehose：缓冲、转换与投递

Firehose 的配置围绕三个参数展开：缓冲大小（Buffer Size，1–128 MB）、缓冲间隔（Buffer Interval，60–900 秒）、以及目标配置。数据先进入缓冲，满足任一条件即触发投递。缓冲越大吞吐越高但延迟越大，日志场景常用 5 MB / 300 秒，实时性要求高的场景用 1 MB / 60 秒。

Firehose 支持 Lambda 转换（数据清洗、格式转换）、格式转换（JSON 转 Parquet/ORC）、动态分区（按字段写入不同 S3 前缀）。投递失败时，Firehose 会重试，若仍失败则写入 S3 备份桶（Backup Bucket），这是排查数据丢失的关键入口。源记录（Source Record）保留功能可以把原始数据同时写入另一个 S3 桶，便于对比转换前后差异。

Amazon MSK：Kafka 语义与副本容错

MSK 提供与 Apache Kafka 兼容的 API，Topic、Partition、Offset、Consumer Group 语义完全保留。创建集群时需指定 Broker 数量（至少 2 个，跨 2–3 个可用区）、实例类型（如 kafka.m5.large）、存储容量。副本因子（Replication Factor）建议设为 3，配合 min.insync.replicas=2，可在单个 Broker 故障时继续写入。

MSK 的容错依赖 Kafka 自身的 ISR（In-Sync Replicas）机制。当 Leader 副本故障，Controller 从 ISR 中选举新 Leader。如果 ISR 收缩到低于 min.insync.replicas，生产者会收到 NotEnoughReplicasException，此时应让生产者重试而非降级为异步发送。MSK 还支持多 AZ 部署、自动 Broker 恢复、以及通过 MSK Connect 把数据导出到 S3 或其他目标。

AWS DMS：全量迁移与 CDC 增量复制

DMS 的架构由复制实例（Replication Instance）、源端点（Source Endpoint）、目标端点（Target Endpoint）和迁移任务（Task）组成。全量迁移（Full Load）把源表数据一次性搬过去，CDC（Change Data Capture）则持续捕获 INSERT/UPDATE/DELETE 并应用到目标。两者可以组合为"全量 + CDC"模式，实现不停机迁移。

CDC 依赖源库的日志机制：MySQL 用 Binlog（需 binlog_format=ROW），Oracle 用 LogMiner 或 Binary Reader，PostgreSQL 用逻辑复制槽。配置时需注意：复制实例规格决定 CDC 吞吐，大事务可能造成延迟；目标端要处理主键冲突，常用 Insert 或 Upsert 模式；任务日志中的 CDC latency 指标是判断同步是否跟得上的核心依据。

选型决策与容错对照

选型时先问三个问题：数据是否需要被多个下游重复消费？延迟要求是毫秒还是分钟？源系统是应用日志、Kafka 还是关系型数据库？需要重放和多消费者选 KDS 或 MSK；只需落地选 Firehose；数据库增量同步选 DMS。实际项目中四者常组合使用，例如 DMS 把 RDS 变更写入 KDS，KDS 供 Lambda 实时处理，同时 Firehose 把同一份数据归档到 S3。