AWS Redshift + Tableau Performance Booster

Question

我使用AWS Redshift作为我的Tableau桌面的后端。 AWS群集正在运行，两个dc1.large节点和我分析的数据库表是30GB（启用红移压缩），我选择了Redshift而不是Tableau提取性能问题，但似乎Redshift实时连接比提取速度慢得多。我有什么建议，我应该看看？

Answer 1

要使用红移为喜欢的Tableau BI平台后端，有四件事情可以做，以解决延迟：

1）并发：红移是不是在同一时间运行多个查询巨大因此在开始调整数据库之前，请确保您的查询不会排在其他查询后面。 （如果您是群集上唯一的一个，这应该不成问题。）

2）表大小：只要可以，就可以使用聚合表以获得更好的性能。更少的行扫描意味着更少的IO和更快的周转！

3）查询复杂度：理想情况下，您希望您的BI工具发出简单，快速的查询。确保你的源表很快，并且Tableau没有被迫做一堆连接。此外，如果您的查询确实需要连接多个表，请确保任何大型表具有相同的分配键。

4）“索引”：技术上，红移不支持真正的索引，但您可以通过使用“交错”排序关键字接近同样的事情。传统的复合排序键无济于事，但交叉排序键可以让您快速访问多个向量中的行（例如date和customer_id），而无需扫描整个表。

现实检验

所有这些东西进行优化后，你经常会发现，你仍然不能一样快的Tableau提取物。简单地说，一个“快速”的Tableau仪表板需要在5秒内将数据返回给用户。如果您的仪表板上有7个可视化对象，并且每个基础查询都需要800毫秒才能返回（这对于数据库查询来说速度非常快），那么您仍然几乎无法达到目标性能。现在，如果其中一个查询需要5秒或更长时间，无论您做什么，您的仪表板都会感觉“缓慢”。

总结 红移可以使用上面的方法进行调整，但它可能会或可能不值得付出努力。使用实时Redshift查询而不是Tableau Extracts的最佳应用程序是在数据太大而无法创建数据提取的情况下，以及需要数据的粒度级别使预聚合不可行时。一个好的策略是使用提取来创建主要仪表板，以便尽可能快地进行探索/发现，然后使用直接（实时）Redshift查询来查看钻取报告（例如，当您想要查看具体哪些客户卷入您的总计）。