Redshift 中的高效 ETL Upsert

Question

我在将可更新表从 ​​OLTP 环境迁移到 Redshift 时遇到性能问题。我们的基本工作流程是典型的 OLTP->S3->Redshift 数据流。假设我想对这样的表进行 ETL 处理

create table source_data (
id int primary key,
status varchar,
value decimal(10,4),
dateLastTouched datetime,
dateCreated datetime,
index datelasttouched_index (dateLastTouched));

到 Redshift 中的类似表。为了准备 ETL，我创建了排序键 dateLastTouched 和 dist 键 id。我们对 dateLastTouched 的任何记录进行 ETL 处理，该记录位于上一个作业的最大 dateLastTouched ETLd 之后。

此设置非常适用于没有更新旧记录的表（例如，去年的记录更改了其状态），但是当您添加该功能时，无论如何我都无法有效地看到 ETL。我们目前的做法是：

1. 使用 dateLastTouched 将所有新的或更新的记录发送到 S3。
2. 将 S3 中的数据复制到临时表中。
3. 从目标表中删除与新数据具有相同主键的所有记录。
4. 插入暂存表中的所有记录。

鉴于我们使用 dateLastTouched 作为排序键的设置，第 3 步非常慢。通常需要 1-2 分钟，很明显随着时间的推移需要更长的时间。我们不能将排序键更改为主键，因为我们需要 dateLastTouched 来报告在表上运行相当频繁的查询。 我们考虑过的一些想法：

1. id 和 dateLastTouched 的交错排序键。我们在另一张桌子上尝试了这个，性能提升并不显着。真空重新索引时间也很糟糕。
2. 不要删除，只需插入并让定期作业将“每个 id 的最新记录”具体化到另一个表。这并不理想，因为它实际上将大表占用的空间翻了一番，而且更新并不频繁。

对于从 S3 到 Redshift 的高效 upsert，是否有更好的范例？还是我只需要吃 ETL/物化视图的成本？

Answer 1

另一种选择是使用 2 个版本的表格，一个按 id 排序用于 ETL，另一个按 dateLastTouched 排序用于报告。当 ETL 过程在第一个上完成时，您只需重新创建第二个（不使用 order by，而只是使用 truncate t2、insert into t2 select * from t1 和 vacuum reindex t2）

此外，根据集群的表大小和配置，在不考虑 upsert 的情况下重新加载表的整个主体实际上可能会更快