Redshift 中的維度建模和 ETL

我一直在研究 Amazon 的 Redshift 數據庫作為我們數據倉庫的未來替代品。我的經驗一直是使用維度建模和 Ralph Kimball 的方法，所以看到 Redshift 不支持自動遞增列的串列數據類型等特性有點奇怪。

但是，AWS 大數據部落格最近發布了一篇關於如何針對星型架構優化 Redshift 的博文：https ://blogs.aws.amazon.com/bigdata/post/Tx1WZP38ERPGK5K/Optimizing-for-Star-Schemas -and-Interleaved-Sorting-on-Amazon-Redshift

我的問題是關於在 Redshift 中載入星型模式的最佳實踐是什麼？我在任何 Redshift 的文件中都找不到這個答案。

我傾向於將我的文件從 S3 導入臨時表，然後使用 SQL 進行轉換，例如查找和生成代理鍵，然後再插入目標表。

這是其他人目前正在做的事情嗎？是否有值得花錢的 ETL 工具來簡化此操作？

與 Kimball 而不是 Redshift 的 inmon 相比，您肯定在正確的軌道上。

這有很多模式，我在不同的案例中都使用過它們

1. “ELT”模式 - 將源表完全載入到 redshift，在載入數據之前不要進行任何重要的轉換。為此，您可以載入到 s3，然後使用 redshift 複製命令，或者我建議使用“AWS 數據遷移服務”，它可以將源（例如 mysql 或 postgres）同步到目標（例如 redshift）然後，定期執行sql 在 redshift 中處理以填充暗淡然後填充事實。如果您願意，您可以使用第三方基於雲的工具來“簡化”此過程 - 例如 Matillion（我不建議使用第三方工具）
2. “ETL 模式” - 使用 apache spark 轉換飛行中的數據。並將暗淡和事實載入到redshift spark->s3->redshift中。我為此使用了 EMR，這很好。如果您使用 AWS Glue，這也是採用的方法
3. 不要變形！- 類似於 1) 但只使用已載入的表。

請注意，如果您有一個包含重複值而不是事實和維度的寬表，Redshift 有時效果會更好。原因是柱狀方法讓 Redshift 將不同的值壓縮到一個非常有效的水平。我沒有一個公式來確定何時使用多個維度與一個平寬的桌子，唯一的方法就是嘗試看看！

一些連結

適用於 Redshift 的 AWS DMS

AWS 膠水

對於 ETL，有 AWS Glue。它是一種託管的、無伺服器的 ETL 服務，可載入到 Redshift（除其他外）。

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

引用自：https://dba.stackexchange.com/questions/103349