AWS Glue能否同步删除目标端对应源端已删数据及实现方法

你提到的第4步操作完全可以实现，不存在AWS Glue的功能限制，只需要在ETL逻辑里补充增量状态比对和目标端删除动作即可。

根据你选择的批处理/流处理同步模式，实现逻辑分两种：

批处理模式（对应你现在定时跑Glue ETL作业的流程） #

• 首先开启Glue作业的Job Bookmark功能，这个功能原生会帮你持久化每次作业运行的状态快照，不用自己额外搭建状态存储。第一次运行作业时，同步全量源表数据到目标端，同时记录源表所有记录的唯一主键（必须选全局不重复的字段，比如业务ID、自增主键）作为基线快照。
• 后续每次作业运行时，除了抽取上次运行后源端新增、更新的行写入目标库，额外拉取当前时刻源表的全量有效主键集合，和上一次作业存储的主键快照做差集：

  差集判定规则：存在于上一次快照、但本次源端查询不存在的主键，就是两次作业间隔内源端被删除的记录

• 拿到待删除的主键列表后，针对目标库类型执行删除操作：
  • 目标为RDS、Aurora等关系型数据库：将待删除主键按批次拆分（单批次主键数量控制在1000以内，避免超过JDBC语句长度限制），拼接DELETE FROM 目标表 WHERE 主键 IN (主键列表)的SQL，通过Glue JDBC连接执行即可
  • 目标为Redshift、S3数据湖：优先做软删除，给目标表加is_deleted字段，把匹配到的待删除记录该字段置为true，后续业务查询时过滤掉已标记数据即可，性能远高于物理删除；如果必须物理删除，Redshift可以先把待删除主键写成临时表，通过关联匹配执行删除，S3则覆盖写入过滤掉待删除主键后的对应分区数据
• 本次作业所有逻辑执行完成后，把本次拉取的源端主键集合更新为新的快照，供下次作业比对使用。

流处理模式（低延迟同步场景） #

如果你需要秒级同步增删改动作，不用定时跑批，可以给源数据库开启CDC（变更数据捕获），配置Glue Streaming作业直接消费源库的binlog、WAL变更日志：

• 源库执行INSERT、UPDATE操作时，日志里会带上变更后的数据，流作业直接按原有逻辑转换写入目标库
• 源库执行DELETE操作时，日志里会明确标记删除事件和对应主键，流作业捕获到该类事件后，直接触发目标端的删除逻辑即可，不需要每次做全量主键比对，性能和延迟都远优于批处理模式。

注意：如果源表数据量超过千万级，不建议用批处理全量主键比对的方案，每次拉取全量主键的耗时和成本都会很高，优先选CDC流处理方案。

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