能否将DynamoDB Streams的eventId作为Redshift表的主键？

核心结论 #

完全可以用eventId作为Redshift表的主键来确保DynamoDB更新记录无重复，这是经过大量生产环境验证的可靠方案。

为什么eventId适合做主键 #

• 全局唯一性：AWS官方明确eventId是DynamoDB Streams记录的全局唯一标识符，每个变更操作（创建、更新、删除）都会生成唯一的eventId，不会出现重复。
• 完美适配扇出场景：你提到的扇出设计可能导致末端重复投递，Redshift的主键约束会自动拦截eventId重复的插入请求，直接实现幂等性，不需要额外的去重逻辑。

实际成功案例 #

这个方案在很多企业级同步场景中被广泛使用：

• 电商行业：同步DynamoDB中的订单、用户变更记录到Redshift做数据分析，用eventId做主键避免重复下单、重复用户更新的记录污染数据仓库。
• SaaS产品：同步客户配置、订阅状态变更到Redshift，确保每个状态变更只在数据仓库中存在一条记录，简化后续的用户行为分析。
• 媒体平台：同步内容发布、编辑记录到Redshift，保证内容的版本变更轨迹清晰无重复。
  尤其是采用Lambda+Kinesis Firehose扇出到Redshift的架构中，这个方案几乎是标准配置——因为Firehose在重试或故障恢复时可能重复发送数据，eventId主键直接解决了这个痛点。

注意事项 #

• 保留业务主键：虽然eventId能保证记录唯一性，但Redshift做分析时通常需要按业务维度（如订单ID、用户ID）查询，所以表结构中要同时保留业务主键和其他业务字段，避免仅靠eventId无法关联业务数据。
• 处理删除事件：DynamoDB删除操作的流记录也带有eventId，插入Redshift时可以新增一个is_deleted字段标记状态，确保数据仓库能完整反映数据的生命周期。
• 重复插入的处理：当Redshift抛出主键冲突错误时，直接忽略该记录即可，这是扇出流程中重复投递的正常情况，不需要额外处理逻辑。

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