Star Schema(数据建模)是否仍然与使用 Databricks 的 Lake House 模式相关?

Is Star Schema (data modelling) still relevant with the Lake House pattern using Databricks?

我对 Lake House 架构模式的了解越多,并关注 Databricks 的演示,我几乎看不到像传统数据仓库(Kimball 方法)中那样围绕维度建模的任何讨论。我知道计算和存储要便宜得多,但是在没有数据建模的情况下,在查询性能方面是否有更大的影响?在 spark 3.0 之后,我看到了所有很酷的特性,比如自适应查询引擎、动态分区修剪等,但是维度建模是否因此变得过时了?如果有人使用 Databricks 实现了维度建模,请分享您的想法?

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

然而,考虑到 parquet 文件的柱状性质和分区修剪也会减少每次查询的数据量,我可以想象在没有星型模式的情况下合理设置的情况。

这里不是真正的问题,但很有趣。

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

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

  • 以更低的成本获得更高的计算能力 - 如果您管理好它,您可以即时处理更多事情。
  • 也就是说,SAP Hana 也是如此,您可以在其中即时执行 ETL。我不确定为什么每次我都想虚拟创建一个类型 2 维度。
  • 星型图需要思考和维护,但要显示重点。性能不是问题。
  • 的确,临时查询不能很好地处理多个事实表上的星型模式。试试吧。
  • Databricks 在与 SCALA 共享集群方面存在问题,如果您按照他们的方式使用 pyspark 就可以了。
  • 通过 Tableau 查询在 Delta Lake 上是否运行良好还有待观察 - 我需要亲自看看。过去我们有 thrift server 等来做这个,但它不起作用,但现在情况不同了。

Where I am now we have Data Lake on HDP with delta format - and a dimensional SQL Server DWH. The latter due to the on-premises aspects of HDP.

Not having star schemas means people need more skills to query.

If I took ad hoc querying then I would elect the Lakehouse, but actually I think you need both. It's a akin to the discussion do you need ETL tools if you have Spark.