采用Databricks的Lake House模式时星型模型（数据建模）是否仍具备实用性？

我所在的团队在Databricks平台落地零售行业数仓已经有3年时间，全程用了Kimball维度建模的思路，结合实际经验给你解答相关疑问：

• Databricks官方的演示内容更多聚焦湖仓的差异化能力，比如流批一体入湖、半结构化数据处理、数仓与机器学习打通等特性，维度建模是通用的数仓设计方法论，不属于湖仓独有的功能，所以不会被当做宣传重点，不代表湖仓不支持或不需要维度建模。
• 早期湖仓的讨论重点集中在底层存储格式、数据一致性保障等基础能力，上层建模的公开讨论相对少，很容易给人造成湖仓不需要做维度建模的误解。

• 即使存储和计算成本大幅下降，没有合理建模的情况下，临时多表关联查询的性能会比预构建的星型模型低30%到80%，尤其是高并发的BI自助分析场景，性能差异会被进一步放大。
• 没有统一的维度建模规范，不同业务团队取数会产生大量重复计算，反而会拉高整体的计算资源开销，成本下降不等于可以无意义地消耗资源。

答案是完全不会，两者是互补关系而非替代关系：

• Adaptive Query Execution（AQE）、Dynamic Partition Pruning（动态分区裁剪）这些特性属于底层执行优化能力，作用是给已经完成合理建模的表进一步提升查询效率，完全替代不了建模的设计价值。比如动态分区裁剪生效的前提是你提前按照常用过滤维度做了分区设计，这本身就是维度建模里的常规操作。
• 维度建模的核心价值从来都不只是性能优化，更重要的是统一业务口径、降低数据使用门槛，让非技术的业务人员也能快速理解数据结构、获取所需数据，这个价值是引擎特性永远替代不了的。

• 我们基于Delta Lake完全实现了Kimball的星型模型，处理缓慢变化维（SCD）的时候用Delta的MERGE INTO语法非常便捷，比传统数仓的SCD实现逻辑简化了至少一半。
• 常用的公共维度表我们会开启Databricks的缓存，搭配Photon引擎的话，星型模型多表关联查询的性能比我们之前用的传统MPP数仓还要高1.5到2倍。
• 落地的时候不需要完全照搬传统Kimball的规范，可以适配湖仓的特性做适度优化，比如把常用的低基数维度属性适当冗余到事实表，减少关联次数，进一步提升查询效率。

内容的提问来源于stack exchange，提问作者Satya Azure