BigQuery measures is now GA, unifying BI metrics and knowledge graphs for AI accuracy

BigQuery 指标 GA：统一商业智能指标与知识图谱 | Google Cloud 博客

数据与分析

BigQuery 指标现已正式发布，统一 BI 指标与知识图谱以提升 AI 精准度

2026年10月29日

##### 李贝

Google 首席工程师

##### Deepak Dayama

产品管理总监

##### 11月4日：自主代理数据云活动

与我们的产品负责人共同构建自主代理的未来

注册

要回答一个复杂的企业问题，AI代理必须理解两件事：发生了什么，以及为什么。"发生了什么"是一个受管控的指标，例如风险收入；"为什么"则是产生该结果的关系网络。由于指标定义（即度量）传统上存在于商业智能（BI）平台，而关系则存在于知识图谱中，AI代理只能看到问题的一半。它只能猜测其余部分，导致答案看似自信却可能错误。为了解决这种幻觉问题，我们在 BigQuery 中引入了指标，现在已正式发布。

历史上，需要同时使用 BI 和知识图谱的组织必须运行两个孤立的技术栈：一个用于计算可靠指标，另一个用于绘制实体关系。连接这两个系统需要脆弱的数据管道，以及分析师和 AI 代理在运行时进行手动协调，他们需要在脑海中或冗长的提示中维护这些连接。这种拼凑方法不仅缓慢且昂贵——这也是数据治理崩溃的地方，因为每个分析师和提示可能以不同的方式定义连接和指标。

图1：统一模型，用于在一处定义 BI 指标和知识图谱，为 AI 代理、SQL、GQL 和仪表板提供支持。

要替代人工协调，您需要一个能够同时理解企业结构和度量数学的单一模型。BigQuery 指标直接构建在 BigQuery 图之上，提供这种统一的基础。通过在描述的图实体上直接定义指标，您的 BI 仪表板和 AI 代理不仅能获得可信赖的数字，还能获得其背后的关联上下文。最终，它们可以可靠地回答"发生了什么"和"为什么"这两个问题。

"借助 BigQuery 指标，我们现在可以交付自文档的数据产品。在 BigQuery 中原生定义指标，确保 Looker 仪表板、对话代理和我们的数据团队查询基于相同的逻辑运行，从而在领导层之间实现指标对齐，并显著减少数据团队的维护工作量。"——Amanda Reelick，Woolworths NZ 数据赋能负责人

一个模型解答"发生了什么"和"为什么"

让我们通过一个示例来说明。假设您的零售银行风险分析团队在布拉格地区发现交易活动突然激增。您需要知道这是否代表健康的客户增长，还是集中风险暴露。回答需要两方面的证据：实际移动了多少钱（发生了什么），以及资金流经了哪些具体账户（为什么）。在大多数银行，获得这个答案需要两个团队、两套工具和两个很少被对齐的数字。

使用 BigQuery 时，您的底层数据已经就绪——无论是原生表还是无边界的 Lakehouse。通过单一模式，您可以直接在现有的交易、账户和区域表上定义语义模型——无需数据移动，也无需二次系统：

加载中...

-- 在一个模型中声明实体、关系和度量 CREATE OR REPLACE PROPERTY GRAPH retail_banking.BankingGraph NODE TABLES ( retail_banking.trans AS Trans KEY (trans_id) PROPERTIES (trans_id, account_id, amount, MEASURE(SUM(amount)) AS total_trans_amount), retail_banking.account AS Account KEY (account_id) PROPERTIES (account_id, district_id, stmt_frq, MEASURE(COUNT(account_id)) AS account_count), retail_banking.district AS District KEY (district_id) PROPERTIES (district_id, city, state) ) EDGE TABLES ( retail_banking.trans AS POSTED_TO KEY (trans_id) SOURCE KEY (trans_id) REFERENCES Trans (trans_id) DESTINATION KEY (account_id) REFERENCES Account (account_id) NO PROPERTIES, retail_banking.account AS LOCATED_IN KEY (account_id) SOURCE KEY (account_id) REFERENCES Account (account_id) DESTINATION KEY (district_id) REFERENCES District (district_id) NO PROPERTIES );

为判断布拉格激增是反映整体增长还是集中暴露，团队需要确认交易量是否分布在多个账户中，还是仅由少数账户驱动。使用 GRAPH_EXPAND 展开图结构，并通过 AGG() 函数聚合两个度量：

-- 按城市统计交易量及背后账户数量（每个账户仅计数一次） SELECT District_city, AGG(Trans_total_trans_amount) AS total_volume, AGG(Account_account_count) AS accounts_involved FROM GRAPH_EXPAND("retail_banking.BankingGraph") GROUP BY District_city;

通过使用“粒度锁定”的度量可确保报告准确性——即为事实和维度的建模分配固定粒度层级。由于单个账户可能包含数千笔交易，表连接可能导致账户行重复。标准 SQL 的 COUNT(account_id) 会高估账户数量，使风险和财务团队得出矛盾数据。BigQuery 度量保留每个实体的原生粒度，无论表如何连接，每个账户仅计数一次。

调查的第二部分聚焦于连接性：哪些账户推动了布拉格的交易？可通过 GQL（ISO 标准图查询语言）在相同模型上进行遍历分析：

-- 哪些账户在布拉格进行了资金转移 GRAPH retail_banking.BankingGraph MATCH (:Trans)-[:POSTED_TO]->(a:Account)-[:LOCATED_IN]->(d:District) WHERE d.city = 'Prague' RETURN DISTINCT a.account_id

两个查询均无需依赖独立系统，且均基于相同受控定义进行评估。

BigQuery 度量的新特性

尽管预览版已将粒度锁定度量与 BigQuery 图深度集成，但实际生产分析需要更多功能——企业级 AI 代理需要程序化方式发现和解释这些指标。BigQuery 度量 GA 版聚焦两大核心领域：更丰富的复杂业务逻辑建模与可视化，以及为代理生态系统原生语义发现能力。

#### 更完善的建模、查询与 BI 可视化

为实现更富有表现力和灵活性的指标定义，MEASURE() 支持复合表达式和派生指标；该功能已正式发布（GA）。您无需在多个查询中重复条件逻辑，而是可以使用 AGG() 在同一张表中定义一次基线聚合，再将其组合到更高阶的计算中。BigQuery 会在模式编译时验证这些公式依赖关系，从而尽早发现循环引用或无效的聚合。下游仪表板和 AI 代理随后可以以任何粒度维度查询复杂比率和净指标，并保持计算一致性。

例如，在您的 Trans 节点上，您可以同时定义已结算交易量和总交易量，然后直接通过这些基础模块推导出未结算交易量和未结算比例：

-- 组合自定义计算、条件表达式和派生比率 PROPERTIES ( trans_id, account_id, amount, fee, is_settled, MEASURE(SUM(amount)) AS total_trans_amount, MEASURE(SUM(CASE WHEN is_settled = TRUE THEN amount ELSE 0.0 END)) AS settled_volume, MEASURE(AVG(CASE WHEN amount > 10000 THEN amount ELSE NULL END)) AS avg_large_trans, -- 派生指标：基于上述指标定义 MEASURE(AGG(total_trans_amount) - AGG(settled_volume)) AS unsettled_volume, MEASURE( SAFE_DIVIDE(AGG(total_trans_amount) - AGG(settled_volume), NULLIF(AGG(total_trans_amount), 0)) * 100.0 ) AS unsettled_pct )

跨多张事实表查询

企业数据模型通常涉及多个业务流程。传统上，将共享共同维度的独立事实表（如与同一银行账户关联的交易和信用卡）进行关联时，会导致"鸿沟陷阱"，即跨事实表的乘法运算会同时夸大两个指标。

新引入的 GRAPH_EXPAND 的 start_node 参数通过将每个事实表隔离到独立的扩展树中解决了这个问题。BigQuery 会在关联共享实体之前，先在每个事实表的原生粒度上计算每个指标：

-- 每个事实表从自身根节点展开，保持精确粒度 SELECT ET.Account_account_id, AGG(ET.Trans_settled_volume) AS settled_volume, AGG(EC.Card_card_count) AS total_cards_issued FROM GRAPH_EXPAND("retail_banking.BankingGraph", start_node => "Trans") AS ET LEFT JOIN GRAPH_EXPAND("retail_banking.BankingGraph", start_node => "Card") AS EC ON ET.Account_account_id = EC.Account_account_id GROUP BY ET.Account_account_id;

通过从各自的根节点（Trans 和 Card）展开每个事实表，即使账户仅有交易而没有发卡，每个分支仍能保持精确的粒度。

在 Data Studio 中可视化

使用 Data Studio 的 BigQuery 连接器更新后，您现在可以直接连接 BigQuery 图表并构建由原生指标驱动的交互式可视化。Data Studio 会遵循图表模型中定义的聚合逻辑，确保复杂计算在图表间保持一致，同时防止客户端意外重新聚合。

#### 为智能体时代而构建

为指标附加业务含义

在大型企业架构中，能够为指标附加业务含义非常有用，因为多个指标经常共享相似名称。仅在我们的银行模型中，total_trans_amount、settled_volume 和 unsettled_volume 这三个指标就可能被业务用户统称为"volume"。这种歧义可能会让构建报告的分析师和将自然语言提示转换为 SQL 的 AI 代理都产生困惑。

通过 GA（一般可用性），您可以使用 OPTIONS 子句将丰富的语义元数据直接嵌入到每个度量定义中，包括自然语言描述字符串、领域同义词和自定义键值扩展：

-- 业务含义和治理元数据与度量 MEASURE(SUM(CASE WHEN is_settled = TRUE THEN amount ELSE 0.0 END)) AS settled_volume OPTIONS ( description = '已结算的交易价值。不包括费用。', synonyms = ['已结算金额', '已清算数量'], extensions = [('unit', 'USD'), ('owner', 'finance-analytics'), ('reporting_tier', 'executive')] ) 一同传递

由于这种业务上下文与 SQL 公式一起存在于模式中，您的语义定义会随着度量的查询传递到任何位置。

#### 让度量对人类和 AI 代理都可发现

BigQuery 与 Knowledge Catalog 直接集成，为人员和机器创建统一的发现和消费循环：

• Knowledge Catalog 中的企业级上下文发现：BigQuery 图和度量元数据会自动被摄入并作为原生资源在 Knowledge Catalog 中进行搜索，与表、视图和例程并列。数据管理员、分析师和 AI 代理可以通过业务同义词或描述进行跨目录搜索，检查治理标签，并查看底层度量的 SQL 定义（例如 SUM(CASE WHEN is_settled = TRUE...)），在使用前验证每个指标的计算方式。在 Knowledge Catalog 中，您还可以使用业务术语表和管理上下文丰富图元数据，将资产发现、业务含义和数学度量统一在单个界面中，使用户和代理能够基于相同的上下文进行操作。

• BigQuery 中的运行时模式内省：调用 BQ.SHOW_GRAPH_EXPAND_SCHEMA 会以 JSON 格式返回扩展后的图模式，而无需扫描底层表，同时标记带有 "is_measure": true 的指标及其描述和同义词。将 flatten_results => FALSE 作为参数传递可保留实体层次结构为嵌套的 ROW (STRUCT) 类型，使代理能够检查关系树并直接查询如 Account.District.city 这样的路径。

跨数据和 AI 生态系统进行连接

最后，BigQuery 度量与 Google Cloud 数据和 AI 堆栈集成，使您可以在现有工具中创建、重用和查询语义：

• 使用 AI 进行创作：在 Data Agent Kit 中使用图技能，通过首选的 AI 编码环境中的自然语言提示来构建、编写和验证 BigQuery 度量定义。

• 重用现有 LookML 模型：如果您已经在 Looker 中建模业务指标，可以使用基于 LookML 的派生分析模型进行一次建模，直接将探索、连接和度量编译为原生 BigQuery 图模型。

• 使用自然语言进行查询：Conversational Analytics 原生支持统一的图和度量定义，使业务用户和 AI 代理能够通过自然语言直接对受控指标提出复杂问题。

开始使用 BigQuery 度量

这种统一模型的主要优势在于，您可以基于现有基础进行构建。如果您已经运行 BI 语义层，请直接在描述该度量的实体上定义受控指标；如果您的基础是知识图谱，请将统一度量附加到最常使用的遍历路径上。无论从哪一侧开始，您都在为 BI 仪表板和 AI 代理构建单一事实来源。

要了解统一语义的实际应用，可以观看BigQuery measures介绍视频，或深入阅读BigQuery measures文档和BigQuery Graph概览。当您准备动手实践时，可以尝试我们的音乐流媒体分析分步教程。

Posted in

• Data Analytics
• BigQuery