星型模式(数据建模)是否仍与使用数据库的“湖屋”模式相关？

Question

我读到更多关于warehouse体系结构模式的文章，并且遵循Databricks的演示，我几乎看不到任何关于维度建模的讨论，比如在传统的数据仓库中(Kimball方法)。我知道计算和存储成本要低得多，但是没有数据建模对查询性能有更大的影响吗？在Spark3.0之后，我看到了所有很酷的特性，比如，等等，但是因为这些，维度建模已经过时了吗？如果有人用Databricks实现了维度建模，那么您的想法呢？

Answer 1

这里不是个问题，但很有趣。

当然，Databricks等人正在出售他们的云解决方案--我对此没意见。

将此视频https://go.incorta.com/recording-death-of-the-star-schema考虑在内--无论是付费还是对Imhoff的真实看法：

• 计算能力更高，成本更低--如果你管理它，你就可以在飞行中得到更多的东西。
• 尽管如此，SAP Hana也可以这样说，在那里你可以在飞行中执行ETL。我不知道为什么每次我都想要一个二维类型的虚拟创建。
• 星型架构需要思想和维护，但要显示重点。性能问题不那么严重。
• 的确，与多个事实表相比，特殊查询不能很好地处理星型模式。试试看。
• Databricks在与SCALA共享集群方面存在问题，如果您用pyspark的方式进行集群共享，它是可以的。
• 通过Tableau查询是否在德尔塔湖上有效还有待观察--我需要自己看看。在过去，我们有节约服务器等，但它没有工作，但事情现在是不同的。

在我现在的位置上，HDP上有数据湖( Data )，具有增量格式--以及一个维度的Server。后者是由于HDP的现场方面。 没有星型模式意味着人们需要更多的技能来查询。 如果我临时查询，我会选择湖人馆，但实际上我认为你两者都需要。这是一个类似的讨论，你需要ETL工具，如果你有火花。

Answer 2

Kimball的星型模式和Data建模技术仍然适用于Lakehouse模式，并提到了一些优化，如自适应查询执行、动态分区剪枝等，再加上数据跳过、ZOrder、布鲁姆过滤器等，使得查询变得非常高效。

事实上，Databricks数据仓库专家最近发表了两篇相关的博客文章：

• 数据仓库建模技术及其在Databricks Lakehouse平台上的实现:在Lakehouse上使用数据风险和星型模式
• 在数据库Lakehouse平台上实现数据仓库模型的规范指南

Answer 3

在我们的用例中，我们使用PowerBI + Spark访问湖人馆，并且能够显着地减少数据量，使用星型模式返回的查询使最终用户的体验更快，并且节省了计算资源。

但是，考虑到parquet文件和分区剪枝的柱状性质(这两者都会减少每次查询的数据量)，我可以想象在没有星型模式的情况下，合理的设置可以工作。