如何解决Redshift或平面设计中的尺寸建模-成本与时间
我已经开始学习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,而仅将最新分区保留在较小的群集中。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。