BI Serving Pointers; Maximizing for Performance and TCO

标题：BI 提供指针；最大化性能和 TCO

URL 源：https://www.databricks.com/blog/bi-serving-pointers-maximizing-performance-and-tco

发布时间：2026-05-27T20:15:00+0000

Markdown 内容： 您的 BI 仪表板运行缓慢，优化它们花费了太多时间和金钱。

这是一个常见的模式。一个仪表板查询需要 30 秒，所以有人构建了一个聚合表来加快速度。这个表需要一个刷新管道。管道需要监控。然后第二个 BI 工具需要相同的数据以稍微不同的形状，所以有人使用单独的管道构建了另一个聚合表。很快，您就管理着一堆聚合、提取和工具特定的语义层——每个都有自己的过时窗口、治理差距和计算账单上的单独项目。

BI 工作负载与其他分析工作负载不同。它们高度并发、延迟敏感，并且查询模式重复。这种组合需要对数据建模、存储、优化和提供服务的精心方法。好消息是，Databricks 提供了完整的 BI 提供栈——从物理数据布局到受管的语义层——每一层都会增加底层层的性能提升。

本文将从下往上介绍该栈，并提供有关在查询性能和成本方面获得最大改进的实用指导。

BI 提供栈

在深入每一层之前，这里是整体情况：

Unity Catalog 提供了全面的治理——从原始数据通过语义到消费的所有血缘和访问控制。每一层解决性能和成本的不同方面。让我们逐一介绍它们。

优化物理层

物理层是大多数 BI 性能赢得或失去的地方。正确处理这一点，每个查询都会受益——在触及语义层之前。

从维度建模开始

星型模式仍然是 BI 查询性能的黄金标准。宽、反规范化维度表通过代理键连接到事实表，为查询优化器提供了干净、可预测的连接路径。

Databricks 完全支持您需要的关系建模构造：主键和外键约束（带有 RELY 用于优化器提示）、代理键的身份列以及 CHECK 和 NOT NULL 约束。如果您遵循中等奖牌架构，请将规范化或数据仓库模型保留在 Silver 中，并在 Gold 中构建反规范化星型模式以供 BI 消费。

有关详细实现模式——SCD 类型 1 和类型 2 处理、使用 MERGE 的事实表 ETL、迟到到达的维度——请参阅 在 Databricks SQL 中实现维度数据仓库 博客系列。

使用受管表

Unity Catalog 受管表 是此堆栈中的基础。Unity Catalog 管理受管表的所有读取、写入、存储和优化责任。这解锁了您在外部表中无法获得的自动功能：默认启用 预测性优化（如下所述）。自动液态聚类 选择聚类键，这些键会随着查询模式的变化而适应。元数据缓存 始终开启，减少云存储请求并加快查询规划。

在整个平台上使用受管表——不仅用于 BI 提供，而且跨越 Bronze、Silver 和 Gold 层。它们是 Unity Catalog 中的默认表类型，性能和治理优势会在此堆栈中的每个其他优化中累积。

应用液态聚类

Liquid 聚类 替换了静态分区和手动 Z-ORDER——与这些方法不同，您可以在不重写现有数据的情况下重新定义聚类键。在表创建时添加 CLUSTER BY (col1, col2) 或对现有表使用 ALTER TABLE。如果您不确定选择哪些列，CLUSTER BY AUTO 让预测性优化根据观察到的查询模式选择键。

对于 BI 工作负载，按最常用的过滤和连接列进行聚类——日期键、地区、产品类别。您可以选择最多四列，如果两列高度相关，则只包含一列。当仪表板按聚类列进行过滤时，液态聚类通过数据跳过提高查询性能。

让预测性优化处理其余部分

预测性优化自动对受益于这些操作的表运行 OPTIMIZE、VACUUM 和统计收集——因此您不需要自己调度这些作业。它在 Photon 写入期间收集 Delta 数据跳过统计信息和查询优化器统计信息，并为现有表回填统计信息。在观察到的工作负载中，这带来了 平均 22% 的性能改进。对于具有重复过滤模式的 BI 工作负载，影响尤为显著——更好的统计信息意味着更好的数据跳过和更高效的查询计划。

在目录级别启用预测性优化并让其运行。使用预测性优化是您可以做出的回报最高、投入最少的优化之一。

结果： BI 查询扫描的数据更少，连接更高效，运行成本更低——您还没有触及语义层。

指标视图：定义一次您的指标

这里事情变得有趣了。大多数组织在多个地方定义了相同的业务指标——一个 BI 工具中的收入计算，另一个稍微不同的计算，以及某人去年写的一个 SQL 笔记本中的第三个变体。每个定义独立漂移。没有人确定哪个是正确的。

度量视图 在 Unity Catalog 中通过提供一个无头的 BI 层来解决这个问题——一个单一的、受管理的语义层，在这里你可以定义数据模型和 KPI，而无需依赖任何特定的 BI 工具。你可以在 Unity Catalog Explorer 中使用 SQL 或点选界面集中定义它们。AI/BI 仪表板、Genie、SQL 笔记本和第三方 BI 工具都会从相同的定义中解析指标。定义一次指标，每个人类或 AI 消费者都会得到相同的结果。

度量视图不仅限于集中化的指标定义——语义元数据是它们的区别所在。字段如 display_name、comment 和 synonyms 给 AI 系统提供了正确解释业务问题所需的上下文。当用户问 Genie“我们上周的收入是多少？”时，这些注释就是 Genie 将自然语言映射到正确度量和维度的方式。无需自定义提示，无需单独的词汇表。同样适用于基于 Databricks 构建的 AI 代理——任何有权访问 Unity Catalog 的代理都可以通过语义层发现和查询受管理的指标，而不是硬编码的 SQL。元数据越丰富，AI 提供的答案就越准确。

以下是一个使用系统表的示例，因为每个 Databricks 客户都可以访问——但相同的模式也适用于业务 KPI 如收入、订单量或客户保留率。这个度量视图计算 DBSQL 仓库指标：

消费者使用 MEASURE() 查询度量视图以引用受管理的指标定义：

度量在度量视图中定义一次。每个查询 metv_dbsql_metrics 的仪表板、Genie 空间或笔记本都会得到相同的结果。以下是使用度量视图作为数据源的仪表板。

这是 Genie 使用相同的度量视图。

对于在多个 BI 工具中分散指标定义的团队，度量视图提供了一条将语义层整合到 Databricks 的路径。而不是在每个工具中维护独立的度量逻辑，你可以在 Unity Catalog 中定义一次，并将 BI 工具连接到该受管理的源。

核心实现是开源的，基于 Apache Spark™（SPARK-54119），并且 Unity Catalog OSS 支持即将推出——因此你是在构建一个开放标准，没有供应商锁定。随着 AI 承担越来越多的 BI 工作负载，查询数据的代理需要每个指标的一致、机器可读定义，开放标准允许任何工具或代理——而不仅仅是供应商特定的工具——对相同的受管理指标进行推理。

度量视图物化：OLAP 性能，无额外开销

传统上，当 BI 仪表板太慢时，答案是构建聚合表。你将在星型模式之上创建物化视图或自定义预聚合表，设置刷新管道，并将 BI 工具重新指向新表。它有效，但它增加了一整层对象和管道来维护——每次聚合逻辑更改时，你都需要更新 BI 工具查询以匹配。

度量视图物化提供了一个更简单的替代方案。当你在度量视图上启用物化时，平台会自动维护与 BI 工具已经查询的相同度量定义后面的预聚合结果——无需构建单独的聚合表，无需重构 BI 工具查询。以下是幕后发生的事情：

• 自动预聚合： 度量结果预先计算并存储
• 增量刷新： 度量保持最新，无需完全重新计算
• 智能查询重写： 引擎将查询路由到最佳可用物化
• 透明路由： 用户以相同方式查询指标——系统提供最快的路径

以前扫描完整事实表的仪表板查询现在命中预聚合物化——具有更低的延迟和更低的计算成本。上面的仪表板和 Genie 示例都查询了相同的度量视图，并且两个查询都被透明地路由到物化。Genie 中的查询计划显示了这一点。

实际的 TCO 指南

更快的查询和更低的成本不是相互竞争的目标——每个减少扫描数据的优化也会减少你支付的计算成本。而堆栈中的每个优化都会累积。液态集群和更好的统计信息可以提高数据跳过和查询计划。物化可以增量刷新，减少 SQL 仓库为仪表板服务所需的计算。以下是一些降低成本的其他方法：

• 合理调整你的 SQL 仓库大小。 使用具有自动扩展功能的无服务器 SQL 仓库来处理 BI 并发峰值。你只支付实际使用的部分，而不是峰值容量。
• 利用 DBSQL 的缓存层级。 磁盘缓存将热点数据保留在仓库附近，查询结果缓存（QRC）在不重新执行的情况下提供重复查询的服务。对于查询模式一致的仪表板，缓存将许多请求转换为毫秒级延迟响应，几乎零计算成本。
• 消除冗余的数据移动。 通过 DirectQuery 或实时连接直接从湖仓提供 BI，而不是使用提取或导入。
• 使用系统表进行监控。 系统表如 system.billing.usage 和 system.query.history 可用于按仪表板、用户和仓库跟踪 BI 使用情况。在系统表上构建度量视图和 AI/BI 仪表板以获得对 BI 使用情况的可见性。

开始使用

你不必一次性实施整个堆栈。从你看到最大影响的地方开始：

1. 使用托管表、主外键和液态聚类来构建（或验证）您的金层星模式架构
2. 在目录上启用预测优化功能，以自动管理 OPTIMIZE、VACUUM 和统计信息收集
3. 为您的核心业务 KPI 定义指标视图 — 可以从 SQL 或 UC 探索器 UI 开始
4. 启用最高流量指标的指标视图物化
5. 监控结果 — 将仪表板指向指标视图，并通过系统表跟踪查询性能

Databricks 在 BI 服务堆栈的每一层都提供优化。托管表、液态聚类和预测优化功能最小化了扫描的数据量和计算开销。指标视图将您的业务逻辑集中在一个受管的语义层中，该层一致地服务于仪表板、Genie 和 AI 代理。物化实现了亚秒级查询性能，而无需手动预聚合管道。这些层次相互作用，降低了查询延迟和总拥有成本。

首先，在现有的金层表上定义您的第一个指标视图并启用物化。请参阅以下资源以开始：

• Unity Catalog 指标视图概述
• 在 AI/BI 中呈现指标视图
• 使用 SQL 编辑器查询指标视图
• 在 Databricks SQL 中实现维度数据仓库