如何避免AWS Glue重复处理文件导致Redshift数据量翻倍问题

当前数据量精确翻倍的核心原因是写入Redshift的环节未做增量过滤或幂等校验，以下方案均兼容raw层、stage层保留运行日期分区的要求：

方案1：基于水位线的增量写入（性能最优，推荐） #

• 首先在Redshift目标表新增etl_run_date字段，和raw、stage层的分区字段对齐，也可使用业务数据自带的业务日期作为水位线判断标准
• 每次Glue作业启动前，先查询Redshift目标表的最大水位值，参考SQL：SELECT MAX(etl_run_date) AS max_watermark FROM 目标表
• Glue加工curated层数据时，仅筛选stage层中分区日期大于上述水位值的新增数据，避免拉取全量历史数据参与计算
• Redshift写入环节用追加模式写入筛选后的增量数据即可

方案2：UPSERT幂等写入（准确性最高，适合中小数据量场景） #

• 给Redshift目标表设置唯一主键，一般为业务主键+日期标识的联合主键
• 每次Glue加工完curated层数据后，调用Redshift的MERGE语句完成写入，参考逻辑：

  MERGE INTO 目标表 t
  USING 临时curated数据表 s
  ON t.联合主键 = s.联合主键
  WHEN MATCHED THEN UPDATE SET 非主键字段1 = s.非主键字段1, 非主键字段2 = s.非主键字段2
  WHEN NOT MATCHED THEN INSERT (全字段列表) VALUES (s.全字段列表);
  

• 该方式天然幂等，即使作业重复运行也不会产生重复数据，完全不需要改动raw、stage层的现有分区逻辑

方案3：分区替换写入（适合Redshift表按日期分区的场景） #

• 若Redshift目标表也按运行日期/业务日期做分区，每次Glue作业仅处理本次运行对应的日期分区数据
• 写入Redshift前先删除本次待写入日期分区的所有历史数据，再写入该分区新加工的数据
• 该方式可完全避免同一日期分区内的重复数据，和raw、stage层的日期分区规则完全兼容

上游重复拉取排查补充 #

如果排查发现重复数据在raw层就已经存在，可在landing到raw的Glue作业中添加已处理文件校验逻辑：将所有处理过的landing区文件路径存入DynamoDB表，每次作业运行前先校验文件是否已处理，仅拉取未处理的新文件写入raw层，该逻辑不会影响raw层的日期分区规则。

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