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

Posted 2023-03-31

【中文标题】如何使用 Pentaho 处理 Amazon Redshift 中缓慢变化的维度？

【英文标题】：How to handle Slowly Changing Dimension in Amazon Redshift using Pentaho?

【发布时间】：2016-05-18 20:43:26

【问题描述】：

由于 Amazon Redshift 针对读取而不是写入进行了优化，我如何使用 ETL 工具（在我的情况下为 Pentaho 数据集成）管理渐变维度过程？

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

有人遇到过这个问题吗？

【问题讨论】：

实际更改/插入的维度行的百分比是多少？如果百分比很小（Dimension Lookup/Update 步骤可能没问题。

【参考方案1】：

Redshift 中的更新很慢，因为更新是在事务中执行的一系列操作：

选择要更新到临时表中的行 删除这些行 根据更新条件更新临时表中的那些行 将更新的行追加到原始表中

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

更新单行所需的时间可能与更新 1000 行一样长。更糟糕的是，由于更新时间过长并且需要写锁，它们会长时间阻塞查询，从而显着影响整体系统性能。

有 3 种方法可以让它更快（全部来自经验）：

避免更新。

如果您有一个条件可以让您区分新行和旧行，只需将新行附加到表中，然后使用该条件修改您的查询。您会惊讶地发现 Redshift 的执行速度更快 - 即使每个查询可能变得有点复杂，因为没有更新会导致系统过载，这些查询可能会运行得更快（确保 dist 键是正确的）。

例如，每个业务密钥的最大时间戳条件运行得非常快（尤其是如果您的业务密钥是您的 dist 密钥 - 这一切都将并行运行）。

这是最好的解决方案。

批量执行更新。

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

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