星型模式（数据建模）仍然与使用 Databricks 的 Lake House 模式相关吗？

Question

随着我对 Lake House 架构模式的了解越多，以及关注 Databricks 的演示，我几乎看不到任何关于传统数据仓库（Kimball 方法）中的维度建模的讨论。我知道计算和存储要便宜得多，但是如果没有数据建模，查询性能是否会有更大的影响？从 Spark 3.0 开始，我看到了所有很酷的功能，例如自适应查询引擎、动态分区修剪等，但是维度建模是否因此而过时了？如果有人使用 Databricks 实现维度建模，请分享您的想法？

Answer 1

Kimball 的星型模式和 Data Vault 建模技术仍然与 Lakehouse 模式相关，并且提到的优化，例如自适应查询执行、动态分区修剪等，与数据跳过、ZOrder、布隆过滤器等相结合，使查询非常方便高效。

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

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

Answer 2

这并不是一个真正的问题，但很有趣。

当然，Databricks 等人正在销售他们的云解决方案 - 我对此很满意。

考虑此视频https://go.incorta.com/recording-death-of-the-star-schema - 无论是付费的还是 Imhoff 的真实意见：

• 以更低的成本获得更高的计算能力 - 如果你管理好它，你就可以即时处理更多事情。
• 也就是说，SAP Hana 也是如此，您可以在其中即时进行 ETL。我不知道为什么每次我都想虚拟创建一个 2 型维度。
• 星型模式需要思考和维护，但显示出重点。性能不再是问题。
• 确实，即席查询不能很好地处理多个事实表上的星型模式。尝试一下。
• Databricks 在与 SCALA 共享集群时存在问题，如果您按照 pyspark 的方式进行操作，那就没问题。
• 通过 Tableau 进行查询是否在 Delta Lake 上运行良好还有待观察 - 我需要亲自看看。过去我们有 Thrift 服务器等，但它不起作用，但现在情况不同了。

我现在所在的地方，我们在 HDP 上有增量格式的数据湖 - 以及 维度 SQL Server DWH。后者由于本地方面的原因 HDP 的。

没有星型模式意味着人们需要更多的技能来查询。

如果我进行临时查询，那么我会选择 Lakehouse，但是 实际上我认为你两者都需要。这类似于你的讨论 如果您有 Spark，则需要 ETL 工具。

Answer 3

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

然而，考虑到 parquet 文件的列式性质和分区修剪等也会减少每个查询的数据量，我可以想象在没有星型模式的情况下合理设置可以工作的场景。