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查詢來查看鑽取報告（例如，當您想要查看具體哪些客戶捲入您的總計）。