使用临时表删除Redshift主表重复数据耗时过长问题咨询

耗时增长是否为预期行为 #

表规模增长时去重操作耗时随之变长属于合理现象，但单步操作超过10分钟属于可优化的非必要损耗，并非不可避免。
原全表扫描的去重逻辑下，主表行数达到数十亿级、存储达TB级时，重复比对需要的哈希计算、数据扫描成本会随数据量线性增长，若计算资源不足以把全表数据加载到内存，还会触发磁盘交换，耗时会呈超线性增长，这就是你之前遇到吞吐量下跌的核心原因。你补充提到的通过加where子句把扫描范围缩小到数千行、MB级后耗时下降，也验证了扫描数据量对耗时的直接影响。

现有处理模式的替代优化方案 #

• 改用MERGE（UPSERT）命令替代先删后写逻辑
  Redshift原生支持的MERGE命令可以一步完成「重复数据更新、新数据插入」的操作，省去单独执行DELETE、INSERT两步的事务开销和锁竞争成本，注意要保证匹配条件命中主表的分布键、排序键，最大化执行效率。
• 优化表的分布键、排序键设计
  把去重时用到的唯一标识字段设置为表的分布键，保证相同主键的行都落在同一个计算节点，避免跨节点JOIN的网络开销；同时把该唯一标识字段设为排序键，Redshift会按排序键顺序存储数据，比对重复时可以直接定位到对应数据块，不需要扫描全表数据。
• 调整批次处理粒度
  你当前使用1k消息的小批次处理，会产生大量频繁的小事务，Redshift需要不断对小批量写入做数据合并，开销极高。可以把批次调整到1万~10万消息的粒度，减少操作频次，单位数据的处理成本会明显降低，整体吞吐量会有显著提升。
• 去重逻辑前置
  导入临时表后先在临时表内部完成一次去重，再和主表的目标范围比对，进一步缩小需要比对的数据集；也可以在ETL上游写入队列前做轻量去重，减少进入下游的重复数据量。
• 冷数据分区归档
  对于单表存储超过5TB的大表，可以按时间字段做分区，把不需要做去重的冷数据归档到S3，通过Redshift Spectrum查询，主表仅保留需要做重复比对的热数据，大幅降低主表的扫描成本。

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