如何使用Pentaho处理Amazon红移中缓慢变化的维度？

由于Amazon Redshift针对读取而不是写入进行了优化，我如何使用ETL工具（在我的例子中是Pentaho数据集成）管理缓慢变化的维度过程

由于ETL工具将逐行进行更新/插入（维度查找/更新），因此性能将极低

---

有人经历过这个问题吗

红移中的更新速度较慢，因为更新是在事务中执行的一系列操作：

选择要更新到临时表中的行

删除那些行

根据更新条件更新临时表中的那些行

将更新的行追加到原始表中

所有这些都必须跨节点协调

更新一行可能需要多达1000行的时间。更糟糕的是，由于更新时间太长，需要写锁，因此它们会长时间阻止查询，从而显著影响整体系统性能

有3种方法可以加快速度（全部来自经验）：

避免更新

如果有一个条件允许您区分新行和旧行，只需将新行附加到表中，并使用该条件修改查询即可。您可能会惊讶地发现红移的执行速度更快——尽管每个查询可能会变得更复杂，因为没有使系统过载的更新，但这些查询可能会运行得更快（确保dist键正确）

例如，一个关于每个业务密钥的最大时间戳的条件运行得非常快（特别是如果您的业务密钥是dist密钥，那么它将并行运行）

这是更好的解决方案

分批执行更新

如果您的更新适用于一系列行，请使用where条件一次性更新所有行。尽管您的里程数可能会有所不同，但1000个批次的效果很好

创建一个存储“新”行的表，然后在该表至少有1000行大之后使用连接进行更新

---

实际更改/插入维度行的百分比是多少？如果百分比很小（<20%左右），那么

维度查找/更新

步骤可能就可以了。我也面临同样的疑问。让PDI在MySQL的本地实例中维护维度表，然后每次执行截断并完全加载到红移中可能会更快。你最后是怎么做的？