企业数据里最难回答的问题，往往不是“某一行是什么”，而是“它和什么有关”：两个账户如何关联，一笔付款经过了哪些节点，某个客户订单延迟背后的供应商是谁。BigQuery Graph 正式进入 GA，把这类关系分析能力直接带进数据仓库，让团队可以在 SQL 旁边使用 ISO 标准 Graph Query Language（GQL），不必先把数据抽取到独立图数据库。
这意味着同一个 BigQuery 引擎可以同时承担大规模图分析和 AI Agent 的关联上下文构建。图数据不再是单独维护的系统，而可以继续使用 BigQuery 的计算、权限、机器学习和 AI 能力。
从关系表到关系网络
传统 SQL 很适合过滤、聚合和明确的多表连接，但当问题变成多跳路径、环路或网络结构时，查询会迅速变得难以维护。例如：
- 找出与高风险账户相距三跳以内的账户和设备；
- 追踪一笔资金经过的完整路径；
- 找出供应商、零部件和配送路线之间的潜在单点故障；
- 把邮箱、设备、Cookie 和行为事件拼成统一客户身份；
- 为 AI Agent 提供文档、实体和业务事件之间的可追溯上下文。
BigQuery Graph 使用属性图模型表达这些关系：节点来自节点表，边来自边表，属性仍然保留在原有数据中。图查询直接在 BigQuery 内执行，因此不需要为图分析额外维护一套 ETL 管道和数据副本。
GA 版本重点增强了两个方面。查询执行针对无环和无向遍历进行了优化。根据官方公开基准，GQL 相比预览阶段最高可达到约 2 倍速度提升，无向遍历最高达到约 100 倍提升；ACYCLIC 和 TRAIL 路径模式下的环检测也更加节省资源。与此同时，新的 CALL 语句和更完整的子查询支持，让复杂图问题可以拆成可复用的查询单元。
一个跨云的虚拟知识图谱
BigQuery Graph 的一个重要方向是 borderless Lakehouse。一个属性图可以映射 BigQuery 原生表，也可以映射其他云上的开放 Iceberg 表，并通过 Databricks Unity Catalog、AWS Glue 或 Snowflake 等目录访问数据。数据不需要先复制到一个集中式图数据库中。
下面的示例假设客户和购买记录位于 Google Cloud 的 lakehouse，产品和供应商数据位于 AWS 上的 Databricks 联邦目录。具体项目、目录和表名需要替换成自己的环境，并确保跨云连接和权限已经配置完成。
-- 假设相关表已通过 BigQuery 的跨云 lakehouse 能力可访问
CREATE OR REPLACE PROPERTY GRAPH `my_project.retail.virtual_kg`
NODE TABLES (
`my_project.gcs_lake.retail.customers` AS Customer
KEY (customer_id),
`my_project.dbx_fed_catalog.retail.products` AS Product
KEY (product_id),
`my_project.dbx_fed_catalog.retail.suppliers` AS Supplier
KEY (supplier_id)
)
EDGE TABLES (
`my_project.gcs_lake.retail.purchases` AS Bought
KEY (purchase_id)
SOURCE KEY (customer_id) REFERENCES Customer (customer_id)
DESTINATION KEY (product_id) REFERENCES Product (product_id),
`my_project.dbx_fed_catalog.retail.products` AS Supplied_By
SOURCE KEY (product_id) REFERENCES Product (product_id)
DESTINATION KEY (supplier_id) REFERENCES Supplier (supplier_id)
);
定义图之后，可以用一条多跳 GQL 查询回答“客户购买的产品由谁供应、供应商位于哪里”：
GRAPH `my_project.retail.virtual_kg`
MATCH (c:Customer {customer_id: 'C1'})-[:Bought]->
(p:Product)-[:Supplied_By]->(s:Supplier)
RETURN
c.customer_id AS customer_id,
p.product_id AS product_id,
s.name AS supplier,
s.country AS supplier_country;
实践中应为节点键建立稳定的数据契约，并在建图前检查键的唯一性、边两端的匹配率和跨云访问延迟。图查询能够消除数据搬运，但不会消除数据质量问题；错误的实体匹配会把错误关系传播到所有多跳结果中。
图是 Agent 的上下文层
BigQuery Graph 的价值不只在于让分析师写出更短的路径查询，也在于为 Agent 提供结构化、可解释的上下文。
BigQuery conversational analytics 可以让用户直接用自然语言探索图。系统会根据图模式中的节点、边、描述和同义词，将问题转换为 SQL 或 GQL，并为路径型答案提供可视化结果。图模式中的关系信息能够减少自由文本查询中的歧义：Agent 不只是检索相似文本，而是在明确的实体和关系上进行遍历。
团队也可以通过 MCP Server 将 BigQuery Graph 接入 Gemini Enterprise，或者直接发布 conversational data agent。对于需要写代码的工作流，Google Cloud Data Agent Kit 提供了面向 Antigravity、Visual Studio Code、Claude Code 和 Codex 等工具的 BigQuery Graph agent skill。它可以帮助 Agent 设计节点表和边表、编写 GQL，并把图查询与 SQL 组合起来。
一种实用的 Agent 工具接口可以把高风险关系查询封装成固定函数，而不是让模型每次自由拼接完整查询：
-- 示例：将“查找账户附近的可疑关系”封装为可复用图函数
CREATE OR REPLACE TABLE FUNCTION
`my_project.security.suspicious_neighbors`(account STRING, max_hops INT64)
AS (
SELECT
account AS seed_account,
other.account_id,
other.risk_score
FROM `my_project.security.accounts` AS other
WHERE other.account_id != account
AND other.risk_score >= 80
);
上面的函数只是可改造的接口示意，实际多跳遍历应根据项目启用的 GQL 语法和图模式实现。核心原则是把权限、最大跳数、返回字段和审计字段固化在工具边界内，让 Agent 只负责提出问题和解释结果。
让 Agent 的行为可审计
Agent 能否回答问题只是第一步。当 Agent 开始选择供应商、批准流程或执行操作时，团队还需要知道它为什么这样做：使用了哪些事实，命中了哪条政策，考虑过哪些备选方案，最终结果是什么。
BigQuery Agent Analytics 中的 context graph 将 Agent 的行为记录为类型化、可查询的上下文图，并存储在 BigQuery Graph 中。由于决策轨迹本身也是图，“为什么采取这个动作”可以转化为一次路径遍历；随后还可以把实际结果连接回原始决策，用于评估和改进后续策略。
这条链路适合建立以下审计字段：
- Agent、会话、任务和动作的标识；
- 使用过的文档、表、节点和边；
- 触发的政策或规则版本；
- 被拒绝的候选方案及原因；
- 动作结果、人工修正和后续业务影响。
适用场景与落地检查表
BigQuery Graph 特别适合关系密集、需要多跳分析且数据规模较大的场景，包括威胁检测和反欺诈、供应链数字孪生、Identity Resolution、Customer 360、网络拓扑、基础设施依赖、数据血缘和知识图谱。
落地时可以按以下顺序推进：
- 选择一个明确的关系问题，例如资金环路、设备关联或供应商依赖，而不是一开始重建整个企业知识图谱。
- 为节点和边定义键、方向、属性、描述和同义词，并验证实体匹配率。
- 用 SQL 做数据质量检查，再用 GQL 验证一跳、两跳和异常路径结果。
- 为 Agent 暴露有限、可审计的图查询函数，设置跳数、扫描范围和超时边界。
- 在上线前验证行级和列级安全策略是否覆盖节点属性、边属性和跨云目录。
- 把 Agent 的输入、检索路径、决策和结果写入 context graph，形成可回放的审计记录。
BigQuery Graph 的 GA 不代表所有工作负载都应该迁移到图模型。高频单行事务、严格低延迟的在线写入和复杂实时状态管理，仍然可能更适合专门的操作型图或事务数据库。对于需要同时处理实时事务和海量分析的系统，可以进一步评估 Spanner Graph 与 BigQuery Graph 的组合。更稳妥的采用方式，是从一个能用业务结果验证的多跳问题开始，让图模型、权限边界和 Agent 工具接口一起演进。