DynamoDB中Dynamo Streams+Lambda触发器与Kinesis Streams+Lambda触发器的差异

1. 原生绑定与数据来源 #

• Dynamo Streams：是DynamoDB内置的流服务，和特定表深度绑定，只能捕获该表的插入、更新、删除变更数据。可配置记录视图类型（仅主键、新数据、旧数据、新旧数据全包含），启用后自动同步表变更，无需额外写代码推送数据。
• Kinesis Streams：是独立的通用流服务，和DynamoDB无强绑定。要获取DynamoDB变更数据，需手动通过Lambda或其他工具转发到Kinesis流，同时它也支持接收ECS、第三方应用等其他来源的数据。

2. 数据保留时长 #

• Dynamo Streams：固定保留24小时，无法调整，适合短期处理变更的场景。
• Kinesis Streams：可灵活配置保留1小时到365天，适合需要数据回溯、长期审计的需求。

3. 吞吐量与扩展逻辑 #

• Dynamo Streams：吞吐量与绑定的DynamoDB表读写容量挂钩，表扩容时流吞吐量自动同步提升，无需单独配置分片。每个流分片对应表的一个分区，消费时按表的分区逻辑分配任务。
• Kinesis Streams：需手动配置分片数量，每个分片提供1MB/秒写入、2MB/秒读取能力，扩容时需手动增加分片（或开启自动扩缩容），成本与分片数量直接相关。

4. 消费灵活性 #

• Dynamo Streams：主要通过Lambda触发器、KCL（Kinesis客户端库）或API调用消费。Lambda触发器默认保证同一主键的变更顺序，因为同主键记录会落在同一个分区，消费时按顺序处理，但无法跨分区并行处理同主键变更。
• Kinesis Streams：除Lambda和KCL外，还可对接Kinesis Firehose直接转存数据到S3、Redshift等服务。Lambda消费时可设置并行化因子，允许同一个分片被多个Lambda实例并行处理（但会打破单分区内的顺序性，若需顺序需自行处理），玩法更灵活。

5. 批量处理细节 #

• 两者均支持配置Lambda批量大小，但存在差异：
  • Dynamo Streams：Lambda批量上限为1000条或6MB（取较小值），且批量内记录均来自同一个DynamoDB分区，天然保证顺序。
  • Kinesis Streams：Lambda批量上限为10000条或6MB（取较小值），批量记录可来自多个分片（开启并行化时），顺序性需根据业务需求自行把控。

6. 成本对比 #

• Dynamo Streams：无额外费用，包含在DynamoDB读写容量费用中——按需模式按读写请求付费，预留模式包含在预留容量内。
• Kinesis Streams：按分片小时数收费，叠加数据写入/读取流量费，以及Lambda消费的计算和请求费，成本更高但可控，适合预算充足、需要更多功能的场景。

选型建议 #

• 优先选Dynamo Streams：仅处理单张DynamoDB表变更、对成本敏感、需严格保证变更顺序、无需长期存储流数据的场景。
• 优先选Kinesis Streams：需要整合多来源数据、需长期存储流数据、需要更高吞吐量灵活性、需对接Firehose等其他AWS服务的场景。

内容的提问来源于stack exchange，提问作者variable