企业数据平台长期面临一个两难选择：复制 SAP 数据可以方便分析，却会引入延迟、重复存储、语义丢失和治理成本；不复制，则很难让云端分析与 AI 工具及时访问核心业务数据。SAP Business Data Cloud Connect for BigQuery 的正式可用，提供了第三种路径：在 SAP Business Data Cloud 与 BigQuery 之间建立安全、双向的零复制连接，让数据产品、元数据和业务语义可以跨平台使用。
这项能力的重点不只是减少 ETL。它试图让 BigQuery、Gemini Enterprise、SAP Joule 以及多智能体工作流直接建立在当前、受治理且带有业务含义的数据之上。
零复制改变了什么
传统集成通常需要从 SAP 抽取数据，经过转换后写入云数据仓库。每增加一份副本，就会多出一套调度、存储、权限、血缘和故障恢复机制。源系统字段变化后，下游模型还可能继续运行，却产生语义错误。
SAP BDC Connect for BigQuery 采用查询原位数据的方式，减少复制和迁移需求。BigQuery 可以访问 SAP 的表、元数据及业务语义，SAP 环境也可以使用在 Google Cloud 中加工的数据产品。相关资产还可通过 Knowledge Catalog（原 Dataplex）发现和治理。
这带来几项直接变化：
- 数据新鲜度不再主要受批量复制周期限制。
- 已定义的业务语义可以随数据产品一起共享，而不是只暴露孤立字段。
- 团队不必为同一份数据反复支付复制、存储和维护成本。
- Google Cloud 数据可以与 SAP 数据组合，并把丰富后的结果发布回 SAP。
- 原有 SAP BW/4HANA 等资产可以继续作为业务数据基础，BigQuery 则承担扩展分析层的角色。
“零复制”并不等于“零成本”或“零治理”。数据共享本身可以避免额外的数据共享费用和重复存储，但 BigQuery 查询计算、跨区域设计、并发负载以及源系统能力仍需要纳入成本和容量评估。
AI 需要业务语义，而不只是字段
让智能体读到 MATNR、WERKS 或 LABST 这样的字段并不困难，困难的是让它理解这些字段对应物料、工厂和可用库存，并知道库存单位、时间范围、组织权限以及业务规则。
BDC Connect 的价值在于把 SAP 数据产品及其语义上下文带入 Google 的数据和 AI 生态。这样，智能体可以围绕“哪些工厂可能在未来七天缺料”之类的业务问题工作，而不是猜测数据库列名。Gemini Enterprise Agent Platform 与 SAP Joule 还可以分别承接 Google 和 SAP 环境中的智能体编排。
一个典型供应链流程可以由多个角色协作：
- 库存智能体读取当前 SAP 库存与未结采购订单。
- 风险智能体在 BigQuery 中结合供应商表现、Google Trends 或地理空间数据。
- 采购智能体生成改道、拆单或替代供应商建议。
- 审批步骤检查金额、供应商合规性和人员权限。
- 获批结果通过受控流程回到 SAP 执行。
这里最重要的边界是“建议”和“执行”不能混为一谈。即使数据实时且语义完整，高金额采购、付款、主数据变更等动作仍应设置明确的授权、审计与人工审批规则。
可以这样验证共享数据
下面是一个可改造的 BigQuery 验证流程。示例假设管理员已经完成 BDC Connect 配置，并把共享的数据产品暴露为项目 enterprise-analytics 下的 sap_shared 数据集。表名和字段名是演示约定，需要替换成组织实际发布的数据产品。
先确认当前账号能够发现共享资产：
# 修改为实际 Google Cloud 项目和区域。
export PROJECT_ID="enterprise-analytics"
export LOCATION="us"
gcloud config set project "$PROJECT_ID"
bq --location="$LOCATION" ls --datasets "$PROJECT_ID"
bq show --format=prettyjson \
"$PROJECT_ID:sap_shared.inventory_position"
随后可以把 SAP 库存与 BigQuery 中维护的需求预测组合起来：
-- 假设：sap_shared.inventory_position 是通过 BDC Connect 暴露的数据产品；
-- demand_forecast.next_7_days 是 BigQuery 本地预测表。
WITH inventory AS (
SELECT
material_id,
plant_id,
available_quantity,
quantity_unit,
snapshot_timestamp
FROM `enterprise-analytics.sap_shared.inventory_position`
),
forecast AS (
SELECT
material_id,
plant_id,
SUM(forecast_quantity) AS demand_next_7_days
FROM `enterprise-analytics.demand_forecast.next_7_days`
WHERE forecast_date BETWEEN CURRENT_DATE()
AND DATE_ADD(CURRENT_DATE(), INTERVAL 7 DAY)
GROUP BY material_id, plant_id
)
SELECT
i.material_id,
i.plant_id,
i.available_quantity,
f.demand_next_7_days,
i.available_quantity - f.demand_next_7_days AS projected_balance,
i.quantity_unit,
i.snapshot_timestamp
FROM inventory AS i
JOIN forecast AS f
USING (material_id, plant_id)
WHERE i.available_quantity < f.demand_next_7_days
ORDER BY projected_balance ASC;
把查询保存为文件后，可以从 CI、运维终端或原型工作流中执行：
bq query \
--project_id="$PROJECT_ID" \
--location="$LOCATION" \
--use_legacy_sql=false \
--format=prettyjson \
< supply_risk.sql
在接入智能体前，建议先把这类查询封装成受治理的视图，只提供完成任务所需的字段。这样既能稳定业务接口，也能避免模型直接探索包含敏感财务、员工或供应商信息的底层资产。
从分析原型走向生产工作流
预览阶段的案例表明，这种架构适合生产、库存、本地化报表和供应链风险分析。ElringKlinger 的验证方向尤其有代表性：保留 BW/4HANA 作为既有报告基础，在不复制、不迁移数据的前提下，将 BigQuery 作为分析层，并为对话式分析和后续智能体流程打基础。
但生产落地不应从“让智能体访问全部 SAP 数据”开始。更稳妥的顺序是：
- 选择一个可衡量的问题，例如缺料预警时间、库存周转或采购改道响应时间。
- 发布边界清晰的数据产品，明确负责人、语义、刷新行为和质量指标。
- 检查 SAP BDC、BigQuery 与调用方身份之间的最小权限映射。
- 确认数据驻留区域和跨云架构。SAP BDC Connect for BigQuery 面向 Google Cloud 客户全球可用，可连接托管在 Google Cloud 和 AWS 上的 SAP BDC；Azure 托管实例支持仍在规划中。
- 为 BigQuery 设置查询预算、配额、审计日志和敏感字段策略。
- 先让 AI 生成只读分析和建议，再逐步开放带审批的业务动作。
- 用延迟、准确率、人工驳回率、节省金额和查询成本共同评估效果。
零复制解决的是数据移动问题，而不是自动解决数据质量、权限设计和组织流程。真正值得采用的架构，是让 SAP 的业务上下文、BigQuery 的分析能力和 AI 的执行能力在同一套治理边界内协作。做到这一点，企业才能从一次性的 AI 演示走向可审计、可扩展的业务工作流。