如何解决具有维度建模的雪花数据库星型模式
我们知道，SNowflake 是一个压缩的列式存储数据库，并且经过优化，可以通过 MPP 和自动缩放来运行查询。我们也知道，为了创建数据集市和 DW，Kimball 和维度建模（星型模式）已经在市场上和实践中应用了几十年。这是成功的，因为我们曾经为我们的 DW 拥有大量的行存储 DB。
所以这里的问题是在 SNowflake 中创建数据集市和 DW，我们是否必须遵循 Kimball ？它是否为性能增加了任何价值，事实上我读到它为已经调整为处理列压缩数据的引擎增加了开销？我们是否仍然需要为列使用代理键并强制创建 Facts 和 Dimensions 和星型模式，我们可以在其中简单地加入平面非规范化表以获得相似或更好的性能？
像 SNowflake 这样的超级数据库从建模的最佳实践角度推荐什么？ Kimball 是否必须拥有或多余，因为它违背了列式存储优势的目的？
我认为 SAP HANA / Redshift / Big Query 甚至 Azure sql 数据仓库，没有人推荐这个，我找不到任何一行推荐使用 Kimball 或星型架构。很少有人提到，“它也适用于星型模式”，这并不意味着必须使用星型模式？
解决方法
要记住的一件事：Snowflake 是面向行的列式商店。这是一个重要的区别。这意味着 Snowflake 可利用与列式存储相关的所有显着压缩增益，但仍保持面向行的数据存储方法。
为什么这很重要？
使用微分区方法，这意味着我们仍然可以使用查询谓词消除大量行，然后仅查询满足查询条件的行分组中的列存储。所以你真的可以两全其美。
在我看来，Snowflake 几乎可以支持任何数据模型（或部分/混合实现）。
此外 - 面向行的列存储中的“冗余”值往往会导致非常非常好的压缩。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
