Redshift中的尺寸建模和ETL

9

我一直在研究Amazon的Redshift数据库，以作为将来替换我们的数据仓库的可能。我的经验一直是使用维度建模和Ralph Kimball的方法，因此看到Redshift不支持自动递增列的串行数据类型等功能有点奇怪。

但是，AWS Big Data博客最近有一篇博客文章，介绍如何针对星型架构优化Redshift：https : //blogs.aws.amazon.com/bigdata/post/Tx1WZP38ERPGK5K/Optimizing-for-Star-Schemas和交错排序在Amazon Redshift上

我的问题是在Redshift中加载星型架构的最佳实践是什么？我在Redshift的任何文档中都找不到答案。

我倾向于将文件从S3导入到临时表中，然后在插入目标表之前使用SQL进行诸如查找和生成代理键之类的转换。

这是别人目前在做什么吗？有没有值得花这笔钱的ETL工具来简化这一过程？

etl dimensional-modeling redshift

— 恩克罗斯
source

9

与Kimball的关系一定是正确的，而不是Redshift的inmon。

有很多模式，我在不同的用例中都使用了它们

“ ELT”模式-加载源表以完全进行红移，在加载数据之前不要进行任何重大转换。为此，您可以加载到s3，然后使用redshift copy命令，或者我建议使用“ AWS数据迁移服务”，该服务可以将源（例如mysql或postgres）同步到目标（例如redshift），然后定期运行Redshift中的sql进程会填充暗淡的事实。如果需要，您可以使用基于云的第三方工具“简化”此过程-例如Matillion（我不建议使用第三方工具）
“ ETL模式”-使用Apache Spark转换飞行中的数据。并将暗淡和事实加载到redshift spark-> s3-> redshift中。我为此使用了EMR，这很好。如果您使用AWS Glue，这也是采取的方法
不要改造！-类似于1），但仅使用已加载的表。

请注意，如果您有一个包含重复值而不是事实和维度的宽表，那么Redshift有时会更好。这样做的原因是，列式方法使Redshift可以将不同的值压缩到相当有效的水平。我没有何时使用多个尺寸vs宽桌子的公式，唯一的方法就是尝试看看！

一些链接

适用于Redshift taret的AWS DMS

AWS胶水

— 乔恩·斯科特
source

1

如果您的尺寸相当简单（很少有属性），请同意有关使用宽表而不是星型模式的评论，请考虑将所有数据合并到一个表中。对于大多数来自传统数据库平台（例如SQL Server和Oracle）的人来说，这是违反直觉的，但是当您考虑像Redshift这样的列式MPP数据库实际上是如何工作时，这便开始变得有意义。

— 内森·格里菲思

我同意这种对性能影响和查询简单性的评估，但是，如果随着时间的推移维度发生变化，将其拆分为维度表可以缓解令人困惑的结果。

— 默林

2

对于ETL，有AWS Glue。这是一项托管的无服务器ETL服务，已加载到Redshift中。

https://aws.amazon.com/glue/

— 约书亚·古特曼
source

我要说的是，仔细阅读有关胶水限制的信息。例如，如果要使用Python脚本，则Pandas和Numpy不可用。另外，您的脚本不能轻易地从事件中触发，因此，如果您要运行流式ETL系统，则还需要lambda来触发脚本运行等

— 。– PizzaTheHut

2

我目前正在处理类似的任务。它是建立ETL过程和设计尺寸模型的基础。我已经为解决该问题的最佳方法进行了很多研究，并发现了在使用MPP时绝对应该应用的惊人有用的技术资源。

回答问题

我的问题是在Redshift中加载星型架构的最佳实践是什么？

一定要看看这个资源。我敢打赌，您会发现它非常有用。这是一个约35页的文档，其中包含使用MPP列式存储的强大技术的强大技术。它支持您看到的评论

请注意，如果您有一个包含重复值而不是事实和维度的宽表，那么Redshift有时会更好。这样做的原因是，列式方法使Redshift可以将不同的值压缩到相当有效的水平。我没有何时使用多个尺寸vs宽桌子的公式，唯一的方法就是尝试看看！

乔恩·斯科特（Jon Scott）评论

希望你能像我一样有用

— 若奥·卡西亚斯（Joao Caxias）
source

1

我认为从S3加载是一种常见的模式。

我们需要强制执行唯一性约束，因此我们选择写入Postgres，然后复制新数据以每10分钟进行一次红移。

我们使用https://github.com/uswitch/blueshift加载到Redshift中。

— 山姆
source

1

由于Redshift是一个列式数据库，因此存储和查询性能将不同于RDBMS模型。柱状数据库的优化也不同。由于通常磁盘I / O较少，而磁盘加载的数据较少，因此查询速度更快。

就您引用的AWS博客文章而言，我认为您已经查看了这些建议，并考虑了哪些选项最适合您的数据以进行分发，键，游标，工作负载管理等，并且对该方法至少有一个好主意你会用。我发现使用可视化表示更容易，您可以考虑使用快速而肮脏的数据库图来显示现有表如何迁移到Redshift。涵盖主要数据，以了解将要传输的数据量。而且我当然会使用Amazon的ODBC / JDBC驱动程序，在任何情况下加载大量数据都会很麻烦，而转移到其他数据库类型则要麻烦得多。

至于ETL / ELT，还有其他张贴者提到的AWS Glue。是的，有许多工具，其中一些是免费的。亚马逊确实有《数据库最佳实践指南》，也可能对您有帮助。我在其他论坛上看到的一个提示是，尽可能原始地加载数据并在Redshift中进行转换。那将导致您进入ELT流程。有这么多的选择，也许可以比较一下这两种方法。这是Panopoly 的博客文章，解释了它们之间的差异，这可能有助于您确定路径。

— 本·施密茨
source

1

亚马逊最近在Redshift中发布了一些ETL最佳实践

https://aws.amazon.com/blogs/big-data/top-8-best-practices-for-high-performance-etl-processing-using-amazon-redshift/

在关于此主题Tony Gibbs的演示中，AWS Solution Architect为UPSERT样式负载推荐以下模式：

在临时表中加载CSV数据（来自S3）
从PRD表中删除匹配的行

从舞台插入数据

BEGIN;
CREATE TEMP TABLE staging(LIKE …); — copies dist keys
copy staging from ’s3://… COMPUTE OFF;
DELETE deep_dive d
USING staging s WHERE d.aid = s.aid;
INSERT INTO deep_dive SELECT * FROM staging
DROP table staging;
COMMIT;

如果可能，最好使用DROP TABLE或TRUNCATE进行DELETE以避免虚影行

观看有关他的演讲和幻灯片的视频。

在我们的团队中，我们通常使用SQL COPY语句直接从S3将数据加载到Redshift中。

并使用出色的Apache Airflow工具管理我们所有的ETL 。

我们还使用Stich等集成服务，这些服务直接写入Redshift，然后使用CREATE TABLE LIKE和SELECT INTO 将数据移动到另一个架构中。

— 姆索利
source