很多企业在用 Power BI 搭建企业级报表时，Azure Databricks 几乎是绕不开的数据源。但一个早期决策往往被低估了难度：该用哪种存储模式（Storage Mode）去连接这些 Delta 表？ 这个选择直接决定了后续的成本、安全边界、建模复杂度，以及最要命的——报表打开速度。慢报表是业务用户抱怨的头号来源，可现实里，这个决定常常靠“拍脑袋”或团队惯性，而不是靠数据说话。
为了改变这种状况，微软发布了一份新的白皮书，专门针对 Azure Databricks 上的 Power BI 报表架构做了性能基准测试。它把同一份 Delta 表用四种方式喂给 Power BI，对比了端到端的用户体验差异。这四种方式分别是：Direct Lake on OneLake（在 Fabric 湖仓或仓库中直接查询 Delta 表）、Direct Lake on mirrored Unity Catalog tables（通过快捷方式镜像 UC 表，零拷贝）、DirectQuery（直连 Databricks SQL 仓库）、以及 Composite Model on Databricks（DirectQuery 混合导入模式聚合）。测试结果没有绝对的赢家，但规律非常清晰。
Direct Lake：均衡之选，但上限不在云端
如果你正在为大多数企业级报表选型，Direct Lake on OneLake 是本次基准测试中适应性最强的方案。在中小数据量场景下，它的性能极具竞争力；对于典型的 Power BI 工作负载——也就是报表在一天内被反复刷新、多人并发访问——它能在几乎不需要额外建模调优的情况下，提供流畅的交互式体验。这意味着你的开发团队可以把精力放在 DAX（数据分析表达式）和可视化上，而不是去折腾分区分片或聚合表。
但 Direct Lake 的短板也恰恰藏在它的优势里。它本质上是把 Power BI 的 VertiPaq 引擎直接架在 OneLake 的 Delta 文件上，省去了导入数据的步骤。当数据量冲到几十亿行甚至更高时，这种“按需加载”的架构在查询延迟上会开始出现抖动。基准测试显示，在数据量的顶端，Direct Lake 不再是性能最好的那个。
Composite Model：金字塔尖的加速器，但有前提
当数据量达到数十亿行级别时，测试结果出现了明显的反转：Composite Model（复合模型）配合聚合表，是查询速度最快且最稳定的模式。对于聚合表能覆盖的查询，响应时间可以稳定控制在 100 毫秒以内。这个成绩非常惊人，几乎感觉不到数据在远端。
不过，这个优势有一个非常苛刻的附加条件：它只对聚合表能“接住”的查询有效。一旦用户的筛选条件或钻取路径超出了聚合表的预定义范围，查询就会穿透到底层的 DirectQuery 源，性能会瞬间回落到直连数据库的水平。换句话说，这种模式的收益完全取决于你的聚合设计是否精准匹配了真实用户的行为路径。如果业务用户的探索性分析很强，聚合表覆盖不住，那这个方案反而会带来更差的体验——因为你要么忍受穿透查询的慢，要么被迫频繁调整聚合表结构。
DirectQuery 与镜像 UC 表：场景化工具，别用错地方
至于传统的 DirectQuery 模式，它在本次测试中表现中规中矩，适合对数据实时性要求极高、且查询模式相对固定的场景。但它的性能天花板明显，一旦遇到复杂 DAX 或高并发，延迟会显著上升。而 Direct Lake on mirrored Unity Catalog tables 则是一个更轻量的变体——它通过快捷方式直接引用 Databricks 的 UC 表，省去了数据复制到 OneLake 的环节。这个方案在数据新鲜度上是最好的，但性能表现受限于底层 Databricks 仓库的并发能力和网络延迟，更适合作为辅助模式，而不是主力架构。
别把基准当真理，把它当测试框架
这里必须泼一盆冷水：这份白皮书是 2026 年 6 月到 7 月之间的一个时间点快照。Power BI 和 Databricks 都在快速迭代，今天的性能瓶颈可能下个季度就被优化掉了。更重要的是，它测量的是 Power BI 端到端的用户查询体验，而不是数据库引擎的裸执行速度。这意味着网络延迟、网关配置、Power BI 容量大小都会影响最终结果。
所以，正确的打开方式是：把白皮书里的测试方法论当成一套可复用的性能测试框架，而不是直接照搬结论。你需要用自己的数据量、自己的报表查询模式、自己的并发压力，去跑一遍这四种模式。重点观察三个维度：冷缓存下的首次加载时间、热缓存下的交互延迟、以及高并发下的性能衰减曲线。
回到最初的问题——没有放之四海而皆准的架构。如果你面对的是典型的部门级报表（几千万行以内），Direct Lake on OneLake 是最省心的起点。如果你在做企业级财务或销售分析，数据量动辄几十亿行且查询模式高度固化，那花时间设计一套精准的 Composite Model 聚合表，回报会非常可观。最忌讳的是从一开始就锁死某一种模式，然后试图用硬件或调参去弥补架构上的错配。白皮书的完整版提供了按数据量、缓存状态、筛选场景和查询类型拆分的详细结果，值得在动手前仔细读一遍。
