DynamoDB与Redshift间ETL开发及数据同步、2TB级报表聚合方案咨询

原生的DynamoDB Streams + Lambda + Kinesis Firehose链路仅支持append-only的数据写入，没有原生的变更去重、更新覆盖、删除同步能力，要实现两端数据精准同步，最优方案是构建基于变更日志的幂等同步框架，而非直接适配传统批式ETL流程：

• 改造原有链路的写入逻辑：Lambda消费DynamoDB Streams时，不直接把转换后的业务数据推送到Firehose写Redshift正式表，而是将每条变更记录（包含记录主键、变更时间戳、变更类型（插入/更新/删除）、记录最终值、DynamoDB Streams序列号）统一持久化到S3的分区变更日志中，按变更时间分区存储。
• Redshift端的周期合并逻辑：触发同步时，先通过COPY命令将对应时间窗口的S3变更日志加载到Redshift的临时暂存表，再通过Redshift原生MERGE能力完成数据对齐：
  • 匹配暂存表与业务表的主键，将暂存表中最新的变更值覆盖到业务表
  • 识别变更类型为删除的记录，直接清除业务表中对应主键的行
  • 识别暂存表中无匹配业务表记录的插入类数据，直接写入业务表
• 一致性保障机制：Lambda消费阶段对每条DynamoDB Streams记录做幂等校验，避免重复消费导致的数据偏差；每次同步完成后记录已消费的最大Stream序列号，服务异常重启时从断点续传，杜绝重复处理。

• 方案一：Lambda直连Redshift发送阻塞式UPDATE命令
  该方案不适合长期生产落地，核心存在三个不可忽视的问题：
  1. Redshift作为分布式MPP数仓，单条行级UPDATE会锁对应数据块，频繁的小批次写入会快速占满集群连接池、打崩写入性能，甚至直接影响正常的报表查询效率
  2. Lambda等待UPDATE执行完成的过程会拉长函数运行时长，抬高计算成本；一旦出现执行失败（网络闪断、Redshift连接超时），会直接造成DynamoDB Streams的消费积压
  3. 对2TB量级的大表做频繁单条更新，会产生大量存储碎片，后续的vacuum维护成本会随数据量增长指数级上升
• 方案二：汇总更新、删除类记录按小时维度批量处理
  该方案是目前生产环境验证下来性价比最高的落地路径，配套优化可进一步提升稳定性：
  1. 不硬卡1小时的固定同步窗口，结合实际变更量动态调整触发时机：单窗口变更量小于1000条时，累积到下一个批次合并处理；变更量超过10万条时，提前触发同步流程，不用等待窗口到期
  2. 单批次合并前对暂存表做主键去重：同一主键在单个窗口内存在多次变更时，仅保留序列号最大的最终值参与合并，减少无效计算开销
  3. 将同步延迟控制在1小时以内，完全可以满足绝大多数报表、仪表盘的使用需求，稳定性远高于实时单条UPDATE的模式

2TB量级的聚合结果提取、报表与仪表盘展示场景，Redshift并非非最优选型，反而属于适配度较高的选项，需结合实际查询特征判断适配边界：

• 适合采用Redshift的场景：聚合查询维度固定、单次查询扫描数据量超100GB、查询并发在百级以内，这种场景下Redshift的列式存储、MPP计算能力可以实现秒级返回2TB级别的聚合结果，综合成本低于同性能水平的其他数仓方案
• 需考虑调整选型的场景：
  1. 仪表盘要求毫秒级刷新、查询并发超千级，且查询以小范围点查、固定维度预计算聚合为主，这种场景可通过Redshift Serverless小规格集群配合预计算视图，或调整选型为搭配物化视图的关系型数据库，降低整体使用成本
  2. 若场景要求与DynamoDB实现毫秒级强一致同步，Redshift本身不适合作为实时操作型查询的目标，应将实时查询层部署在低延迟的NoSQL或缓存层，Redshift仅承担离线批量聚合的计算角色

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