问题描述
我已经开始学习AWS Redshift，并且遇到了许多我认为不利于数据仓库星形/雪花模式的事情。
根据使用响应，所有建议使用Redshift仅插入方法以获得最佳性能，因为它是为读取而设计的。但这是否增加了存储成本？我目前正在研究MSBI，我的事实和维度具有复杂的结构。例如：一个事实表在各种业务（数据集市）中共享，很少有2类维度（我必须在其中跟踪历史记录），而很少有2类维度，没有复杂的场景需要雪花设计。
考虑到在云上进行存储和计算的成本，我希望将微弹性数据保留在云上（与在内部部署系统中所做的相同，这有助于4TB存储）。
现在，如果我在前提下执行相同的方法，则必须运行我的ETL，将键列与暂存进行比较，然后执行CRUD，这将现有系统移至云毫无意义。 如果我采用平面表结构，那么表中的数据量将增加4-6倍，这将增加云上的存储成本，并且在其上进行计算可能会额外花费。
How to handle Slowly Changing Dimension Type 2 in Redshift? Redshift Performance of Flat Tables Vs Dimension and Facts
上述问题的答案是关于平面表如何与Redshift更加相关
但是在Redshift博客上方，讨论了如何优化星型模式。
星型和雪花模式在Amazon Redshift上运行良好，并且 交错排序键的添加通过以下方式进一步增强了性能 在以下情况下，减少I / O以便在表上使用更大范围的过滤器谓词 需要。
现在，如果我选择仅插入的方法（这补充了Redshift架构），那么我最终将为存储支付更多的钱。 并且，如果我选择进行传统的数据仓库设计，那我最终将付出额外的计算成本。
您是否可以陈述一些现实世界的例子，以帮助我了解您在Redshift中所采用的方法？
解决方法
以我的经验，Redshift可以很好地处理平面表，而压缩消除了很多存储开销。对于我的用例，首要的考虑是使ETL尽可能简单。
Redshift几乎总是建议使用ZSTD压缩，但是对于某些尺寸，当您知道几乎没有不同的值时，可以使用BYTEDICT获得更好的压缩。
有了良好的排序键和支持聚合模式的分发键，您可以在查询平面表时利用群集的全部功能，而不受带宽的限制。当然，对于具有分布式维度表的星型架构也是如此，但是总有一个维度不够小而无法分发，而FK不太适合作为分发键。
在您深入研究Redshift之前，还请考虑Athena是否可以为您提供解决方案。使用S3进行存储要比Redshift磁盘便宜得多，并且在许多使用情况下其性能都相当。 Redshift Spectrum中还有一个混合驱动程序，您可以将旧分区卸载到S3，而仅将最新分区保留在较小的群集中。