构建多数据源集成的HDFS数据湖，如何同步数据源的删除记录？

这是个非常典型的痛点——在基于不可变架构的数据湖里，处理删除确实比记录更新要棘手不少。结合你目前用HDFS存储、按日期追加新版本的模式，我给你几个适配性很强的解决方案：

1. 标记删除（软删除） #

这是最贴合你现有流程的轻量级方案：

• 给每条记录新增一个is_deleted布尔字段，默认值为false
• 当源数据中出现删除操作时，不要在数据湖里物理删除旧记录，而是插入一条对应主键、is_deleted=true、同步日期为当前日期的新版本记录
• 后续查询最新数据时，先按主键分组取max(sync_date)的记录，再过滤掉is_deleted=true的条目

补充提示：如果担心数据持续膨胀，可以定期运行批处理任务（比如用Spark）清理历史的非最新版本记录，或者利用HDFS的快照、归档策略把旧版本数据冷存起来，既保留不可变性，又控制存储成本。

2. 维护独立的删除事件日志 #

如果你的数据源支持变更数据捕获（CDC，比如MySQL Binlog、PostgreSQL WAL），或者能高效获取删除事件，这个方案会更准确：

• 在数据湖里单独创建一个delete_events数据集，存储被删除记录的主键、删除时间戳
• 同步流程：
  • 若源支持CDC：直接从CDC日志中提取删除事件，写入delete_events
  • 若源不支持CDC：定期拉取源数据的全量主键列表，和数据湖里最新版本的主键列表做差集，得到待删除的主键，写入delete_events
• 查询最新数据时：先获取主数据集的最新版本，再左关联delete_events，过滤掉存在于删除日志中的记录

注意：全量主键对比的方式适合数据量不大的场景，如果源数据量级很大，优先考虑CDC方案，避免性能瓶颈。

3. 分区级替换（适合分区化存储的数据） #

如果你的数据是按业务日期、用户分区等维度在HDFS上分区存储的，可以考虑这种方式：

• 当某个分区内有大量删除操作时，重新生成该分区的完整最新数据（已剔除删除记录），然后覆盖原有分区
• 为了不违背数据湖的不可变性原则，可以先给旧分区创建HDFS快照，再执行覆盖操作，这样依然可以追溯历史版本

这个方案适合批量删除场景，比如按天分区的订单数据，某天的订单有批量取消需要删除，重新生成当天分区会比逐条插入标记记录更高效。

综合来看，标记删除是对你现有架构改动最小的方案，上手最快；如果数据源支持CDC，删除事件日志会是更严谨的选择；分区级替换则适合特定的分区化数据场景，可以根据你的实际数据源特性和业务需求来选择。

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