你列出的这组术语，共同描绘了 SAP 正在从“数据仓库”向“以数据产品为核心的 AI 就绪型数据平台”转型的路径。其核心载体是 SAP Business Data Cloud (BDC)，而 SAP Datasphere 是其中的数据集成与语义建模骨干。下面逐层拆解这些方法论之间的关联。
---
平台基座：BDC 与“融合数据平台 / 湖仓一体”
过去 SAP 的数据栈是分散的：BW 做数仓，Datasphere 做云上集成，分析在 SAC。BDC 的定位是把它们整合成一个完全托管的 SaaS 层，统一 SAP 与非 SAP 数据。
在这个基座中，“converged data platform”（融合数据平台）与“lake house”是同一架构目标的两面：Datasphere 提供治理、语义与建模能力，Databricks 的 Lakehouse 提供大规模处理与 AI/ML 算力，两者通过 BDC 连接，而不是互相复制数据。
数据进入方式：“data pipelining”与“zero-copy share”
数据进入 Datasphere 空间有两条根本不同的路径，理解这个区分是关键：
· Data Pipelining（复制流） ：物理搬运。Replication Flow 把源系统数据（初始快照 + 增量变更）写入 Datasphere 的本地表（file space），适合需要物理落地、精细转换的场景。
· Zero-Copy Share（零拷贝共享） ：逻辑访问。通过 Delta Sharing，数据留在源端，消费方（Databricks、Snowflake、Fabric 等）直接查询，不产生 ETL 开销和数据重复。
SAP 的方向明确是“少复制、多共享”，零拷贝协议正在成为跨平台集成的主流方式。
核心单元：“数据产品”与“DPG / DPCA / DPG”
BDC 的集成单元不再是原始表，而是受治理的数据产品。SAP 应用（S/4HANA、SuccessFactors 等）把自己的业务数据发布为带有语义的数据产品，Datasphere 负责协调与建模，SAC 负责消费。
你提到的 DPG（Data Product Generator） 在这里承担具体的技术转换角色：
· 功能：把本地 BW/BW/4HANA 的 InfoProvider（InfoObject、aDSO、CompositeProvider、MultiProvider 等）发布为 BDC 中的数据产品，或通过数据订阅将数据抽取到 Datasphere 的托管对象存储中。
· 前提：BW 系统需要先被“lift”到 BDC 的私有云组件中（BW 7.5 SP24+ / BW/4HANA 2021 SP04+ / 2023 SP00+），并有一个包含 Datasphere 的 BDC cockpit 租户。
· 价值：把 BW 几十年的建模资产从“手动管道”转为“自动化快车道”，直接生成可被 AI/ML 场景消费的零拷贝数据产品。
DPCA：在 SAP 官方语境中，并未出现与“Data Product Creation Ability”直接对应的标准缩写；公开搜索结果多指向汽车行业项目中的“DPCA”（神龙汽车），而非 SAP 产品能力。它可能是内部或特定语境下的简称。如果指的是“数据产品创建能力”这一通用概念，其实现载体就是 Datasphere 内的数据产品目录、建模空间，以及 DPG 的自动化生成能力。
语义层与 AI：“知识图谱 / 本体 / 代理记忆”
这是 BDC 区别于传统数仓的关键：不只是存数据，还要存“关系”和“含义”。
· Knowledge Graph（SAP 知识图谱） ：基于图论，从 SAP Virtual Data Model 中提取元数据，自动构建反映 S/4 业务关系的本体（Ontology）。它存储在 HANA Cloud 的 Triple Store（RDF 三元组存储） 中，可通过 SPARQL 查询。
· Ontology Manager（本体管理器） ：计划随 BDC 推出（目标 2027 Q1），让客户跨 SAP 与第三方数据构建本体，把知识图谱的通用业务上下文聚焦到具体任务上。
· Cloud Ontology：指的就是上述在云上管理、可扩展的本体层，它是 AI Agent 做准确决策的“语义护城河”。
· Agent Memory（代理记忆） ：HANA Cloud 的 knowledge graph engine 与 agentic memory 结合，让 AI Agent 能记住对话上下文，并随模型变化持续同步知识，实现“有记忆的学习”。简言之，知识图谱提供结构化的业务关系，代理记忆提供运行时的经验积累，两者共同支撑 BDC 上可推理、可审计的 AI 工作流。
BW 现代化迁移路径
你提到的“BW from on-prem to BDC”有一条阶梯式的工具链：
· DPG：处理数据层——把 InfoProvider 转为数据产品。
· Query Template Generator：处理报表层——自动把 BW 查询及其依赖对象转换为 Datasphere 中的分析模型（维度、事实视图、分析模型），可直接被 SAC 消费，大幅降低报表重写工作量。
· BW Bridge：提供云上的 BW 功能过渡，允许逐步下线本地仓库，而不是“一刀切”迁移。
“Datasphere - Consolidate in BDC of lake house”
这句话概括了 Datasphere 在 BDC 湖仓架构中的角色：它是“整合点”（consolidation point） 。非 SAP 和 SAP 的原始数据可以在 Datasphere 空间中被建模、赋予业务语义、施加治理，然后以受治理的数据产品或零拷贝共享的形式，供 Databricks 等 Lakehouse 引擎消费；反过来，Lakehouse 的处理结果也可以回流到 Datasphere 的治理层。Datasphere 不取代 Lakehouse，而是充当语义与治理的汇聚层。
整体逻辑串联
把这些概念串起来，SAP 的方法论脉络是：
BDC 作为统一 SaaS 基座 → 数据通过复制流或零拷贝进入 → 以“数据产品”为集成单元 → DPG 把 BW 资产产品化，Query Template Generator 把报表云化 → Datasphere 做语义整合与治理 → 知识图谱/本体提供 AI 所需的业务上下文 → 代理记忆让 Agent 在上下文中持续学习 → 最终在湖仓一体的算力上运行可审计的 AI 与分析。
---
如果你希望进一步展开其中某一条线——例如 DPG 的具体配置步骤、零拷贝 Delta Sharing 与 Databricks 的对接方式，或者知识图谱在 Agent 工作流中的实际使用模式——可以告诉我，我再做针对性梳理。
No comments:
Post a Comment