Databricks SAP 集成从数据共享扩展至企业 AI

Databricks 与 SAP 于 10 月 30 日宣布扩大合作，旨在为 SAP 客户带来更多企业 AI 能力，但尚未明确发布日期。Databricks SAP 集成如今覆盖更广泛的工作流程，将业务记录与数据准备、AI 辅助、治理及应用开发连接起来。

核心问题在于，企业能否复用业务含义，而不是每次启动 AI 项目时都重新构建。订单记录需要具备关系、定义和权限信息，助手才能负责任地解读它。此次合作对传统的定制化提取模式提出挑战；在这种模式下，各个团队不得不自行重建这些细节。

SAP 也与 Snowflake 合作，为买方提供了另一种平台合作关系可供考量。但眼下的压力主要落在企业架构团队身上。他们必须决定哪些集成工作应交由托管平台承担，以及哪些业务责任仍由自身保留。

Databricks SAP 集成实际改变了什么

此次公告将双方合作的预期范围，从数据共享扩展至使用这些数据的应用和 AI 系统。

SAP Databricks 将 Databricks 嵌入 SAP Business Data Cloud——SAP 用于连接业务数据和分析功能的托管环境。10 月的公告推出 SAP Application Data Foundation，作为通往云端及本地系统中应用数据的路径。

Databricks 将 Genie、Lakeflow、Unity Gateway 和 Lakebase 列为扩展产品中即将推出的能力。其预期角色涵盖 AI 辅助、数据工程、AI 控制和运营应用。

该公司还介绍了 Genie 与 Joule（SAP 的 AI 助手）之间的计划连接。关键在于，其 SAP Databricks 扩展公告区分了现有产品与计划新增功能，但并未提供逐项功能的发布时间表。

这一区别会立即影响采购决策。买方可以评估现有连接，但不应假设整套已宣布的工作流程已在其环境中可用。

SAP 单独发布的企业 AI 公告印证了此次合作扩展。该公告将此项工作置于一项更广泛的努力之中，旨在连接 AI 开发、业务语境和企业控制能力。

SAP 将 lakehouse 描述为该项工作的基础架构；它结合了灵活的数据存储与受管理的分析能力。其公告还将 Agent Bricks 与其他 Databricks 能力一并列出。

这些表述确立了战略方向，但并不意味着每个被点名的组件都在 SAP Databricks 内具有相同的可用性、配置要求或支持安排。

实际变化在于拟议中的分工。更多集成责任将由平台提供商承担，而客户则会在此基础上构建业务应用。

这不同于将 SAP 视为源系统、由各团队分别从中提取另一份数据集的做法。它让 SAP 的业务定义在下游 AI 工作中持续发挥作用。

不过，产品公告无法说明多少定制工作会真正消失。客户特有的扩展、组织定义以及与外部系统的连接，仍需要进一步研究。

对于希望通过这一事件了解 SAP Databricks 的读者而言，有用的区别在于范围。现有合作关系连接的是平台；此次扩展旨在连接更多在这些平台上完成的工作。

因此，这项公告值得作为一项架构承诺加以关注。其运营意义将取决于客户能在何种条件下部署哪些能力，以及取得怎样可衡量的结果。

企业数据团队面临不同的自建或采购决策

此次扩展迫使企业说明，为何仍要重建那些平台提供商愈发愿意托管的集成工作。

定制化提取有其合理吸引力。团队可以选择目标系统、控制转换过程，并围绕特定的报告需求塑造数据集。

难点会在该数据集成为共享基础设施时显现。曾经只服务于仪表盘的定义，开始影响预测、自动化推荐和业务决策。

设想一个用于评估供应商可靠性的采购助手。它所需的不只是采购订单列表，还必须区分请求日期、确认日期、实际收货日期及后续修正。

模型即使不理解这些区别，也能生成解释。由此产生的答案可能听起来令人信服，却衡量了不同的业务问题。

托管数据基础改变了企业期望这些区别从何处产生。团队不必在下游重建每一种关系，而是可以评估受支持的业务数据是否已携带必要语境。

这并不会消除对数据工程师的需求，但会改变他们必须论证和优先处理的工作。

维护提取脚本，与验证交付定义是否符合采购政策，是两类不同的工作。随着助手直接面向业务用户，后者变得更重要。

这一压力同样波及 SAP 管理员和业务负责人。先前仅限于报告使用的数据集，可能会成为服务于陌生受众的系统输入。

届时，访问决策需要的不只是技术连接。负责人必须决定谁可以使用某条记录、用于何种目的，以及应遵循何种业务解读。

对于 SAP 企业 AI 项目而言，这使组织所有权成为部署架构的一部分。模型团队无法仅靠更好的提示词解决所有不确定性。

因此，买方面临更具体的自建或采购决策。他们需要区分可复用的平台管道与企业特有的业务逻辑。

当托管连接能够减少重复工程、又不模糊责任归属时，它具有吸引力。当客户无法解释定义如何流转，或由谁维护时，它的吸引力便会下降。

这也涉及人员配置。将常规集成迁入平台，并不意味着会自动释放能力，除非现有流程确实能够退出。

一家同时运行旧提取栈和新托管路径的企业，在初期可能反而增加复杂性。商业案例部分取决于哪些维护义务能够被取消。

这项分析并不意味着托管集成在任何情况下都更可取。它指出了该公告所迫使企业做出的比较：在集成的整个运营生命周期中，谁拥有它。

更有力的采购问题关乎完整工作流程。一个可用应用需要多少工程工作、业务审查和持续支持？

这个问题为企业架构团队提供了比一份新功能清单更清晰的评估基础。

业务含义是 AI 叙事背后的机制

该集成的技术价值在于，将可用语境与记录一同保留，而不仅仅是让记录变得可访问。

Databricks 记录了语义元数据——即有关数据含义和关系的描述性信息——如何从 SAP Business Data Cloud 进入 Unity Catalog。Unity Catalog 是 Databricks 的目录和治理系统。

受支持的信息包括表描述、列描述、键以及 SAP 治理标签。键用于标识记录和关系；治理标签则用于按策略目的对信息进行分类。

这份语义元数据文档也明确了边界。不同共享中的表之间的关系不受支持，而同步到 Databricks 的 SAP 元数据仍为只读。

这些细节之所以重要，是因为企业 AI 必须先识别正确的记录，才能对其进行有用的推理。

在一个示例性的财务工作流程中，回答收入问题的助手必须选择恰当的度量。已预订订单、已开具发票和已确认收入分别服务于不同目的。

描述和关系有助于确定问题涉及的是哪类数据。它们可以在模型生成解释之前减少歧义。

但元数据并不是完整的业务规范。对收入列的描述，并不必然编码一家企业会计政策中的每一种例外情况。

这形成了清晰的评估边界。买方应审视哪些含义能够自动传递，哪些仍依赖经维护的定义或人工审查。

记录之间的关系也是如此。共享数据集内受支持的关系，并不意味着复杂的跨领域问题已具备所有必要语境。

一个比较客户承诺与供应商表现的助手，可能依赖分布在不同业务领域中的信息。应用必须考虑这些边界。

这正是 SAP 企业 AI 项目超越演示阶段的地方。当业务条件引入例外情况时，一个令人信服的答案仍必须保持正确。

取消订单、部分交付、变更标识符和延迟调整，都是有用的评估示例。这些是说明性的测试条件，并非关于此集成的已报告发现。

这一基本原则同样见于 AI 知识库：获取信息与获取可用语境是两个不同的问题。企业交易系统还对权限和一致性提出了更严格的要求。

对开发者而言，这意味着模型选择应当在数据解读之后进行。更强的模型无法可靠地弥补未定义的业务指标。

对业务用户而言，这一含义同样务实。答案应披露足够的语境，以说明它衡量了什么，以及为何这种解读是恰当的。

因此，评估 Databricks SAP 集成的最佳方式，是提出能够揭示含义的问题。记录访问是必要条件，但解读决定了应用是否值得获得运营信任。

这正是双方合作 AI 叙事背后的机制，也是技术文档比宽泛转型主张更有用的领域。

零复制共享改变了工作方式，但并未消除工作

减少复制可以简化数据路径，但访问、策略和应用行为方面的重大责任依然存在。

OpenSharing 是 Databricks 的数据共享平台。其 SAP 连接器文档描述了零复制访问，这意味着共享数据保留在原处，而不会通过共享连接被复制。

这一说法涉及架构中的特定层面。不应将其解读为承诺每一个下游应用都无需创建新资产。

预测、转换后的数据集或应用数据库都可能带来新的存储和管理需求。买方需要评估完整应用，而不能仅根据连接本身推断。

SAP BDC connector还要求 SAP 与 Databricks 管理员之间进行协调。访问权限取决于已配置的共享方式以及相应权限。

文档还提到另一项运营细节：Databricks 可能会与 SAP 共享某些工作负载使用情况和运营信息，用于计费和管理。

这些信息可能识别出某个组织，并描述涉及共享 SAP 数据的工作负载。客户应将这一有文档说明的安排纳入其架构和供应商评估之中。

这些细节并不否定托管连接器的价值。它们说明，在实际部署中，“托管”一词需要涵盖哪些内容。

企业仍需要有人对访问请求、不断变化的业务定义、应用事件和服务连续性负责。更短的数据路径不会自动分配这些责任。

同样，获准读取信息并不意味着获准对其采取行动。解释供应商延迟情况的助手，与修改采购订单的应用程序，拥有不同的权限级别。

随着合作关系延伸至应用和智能体——即使用工具完成任务的软件系统——这种区别会变得更加重要。

企业可能接受由助手起草建议，但要求任何运营变更均须经过批准。这个边界应当体现在应用的设计和评估中。

因此，已宣布的平台扩展应分别接受数据访问、回答质量和行动授权方面的测试。某一领域的成功并不代表其他领域同样成功。

性能声明也需要同样严谨的态度。Databricks 在其公告中援引了客户改进案例，但这些案例不应被视为任何计划中集成项目的隐含基准。

现有客户的采用情况可以证明底层平台能够服务业务工作负载，但无法证明尚未公布发布日期的功能具备何种性能。

因此，审慎视角是具体的。该架构提供了一种减少重复集成工作的合理路径，但公告并未量化每一项仍需承担的实施义务。

如果以采购术语解释 SAP Databricks，核心警示是：应一并评估受支持的工作流、其限制以及所有权模型。

成功的部署应减少应用周边运营体系中的工作量。若只是将这些工作转移到不那么可见的管理流程中，实际收益就会被削弱。

Snowflake 表明，仅有 SAP 访问权限并非差异化因素

由于 SAP 已宣布与其他平台建立合作关系，Databricks 必须在客户能够利用 SAP 数据构建和运营什么方面展开竞争。

SAP 于 2025 年 11 月宣布与 Snowflake 开展合作。该公告介绍了 SAP Snowflake 解决方案扩展，以及面向现有 Snowflake 环境的连接器。

拟议架构包括无需复制的双向共享，以及可访问带有业务上下文的 SAP 数据。这些主题与 Databricks 当前强调的核心价值主张有所重叠。

因此，SAP 的 Snowflake 数据协作提供了一个相关的竞争参考。若未核查后续文档，其最初的可用性目标不应被视为当前已交付的证明。

这一比较之所以重要，是因为它限制了对 Databricks 公告的宽泛解读。SAP 数据访问并非仅通过单一的外部分析平台提供。

这让买方有理由比较实际工作负载，而不是假定集成访问权已足以决定平台选择。

拥有成熟数据工程实践的公司，可能重视与既有环境的一致性。另一些公司则可能优先考虑特定的应用模式或业务用户体验。

这些是分析层面的考量，并非任何一方供应商具有普遍优势的证据。本文审阅的来源并未提供对竞争性实施方案的受控比较。

有价值的竞争问题，关乎共享数据与可维护业务应用之间的距离。

团队在获得访问权限后还需要完成多少工作？业务用户能够多轻松地审查答案？当某些内容发生变化时，管理员能够多清晰地追溯责任？

这些问题使比较始终围绕文章的核心议题：托管的业务上下文，与反复重建的上下文之间的区别。

一个平台可以提供广泛能力，却仍让客户管理复杂的交接环节。相反，如果边界被充分理解，范围更窄的部署也可能交付显著价值。

SAP 的多合作伙伴策略还带来了一个长期互操作性问题。当工作负载跨越平台边界时，客户需要知道哪些定义仍可复用。

开放共享机制有助于建立连接性。应用逻辑、业务定义和运营流程的可移植性，则需要另行审查。

对企业买方而言，这意味着在评估采用条件的同时，也要评估退出条件。数据连接只是生产应用所形成依赖关系的一部分。

对 Databricks 而言，此次扩展提高了预期。该公司正围绕更广泛的开发与运营体验定位其合作关系，因此也将面临更广泛的评估。

对 SAP 而言，挑战在于如何在不断扩大的平台合作关系中维持清晰易懂的选择。买方需要了解受支持能力和责任归属的明确边界。

因此，竞争意义在于实际效果，而非戏剧化叙事。更多供应商提供了通往业务数据的路径；差异化转向客户能够通过这些路径完成多少可靠的工作。

下一个信号将是可用性、语义保真度与运营结果

下一批证据应将已宣布的架构与可部署能力及可衡量的业务工作流联系起来。

第一个信号是功能层面的可用性。在未来数月中，发布文档应阐明客户可以使用哪些扩展能力，以及这些能力在何处获得支持。

一项有价值的更新应区分正式可用与预览访问，并说明相关依赖项。它还应明确计划中的助手连接的交付状态。

这些信息将通过把架构方向转化为可评估的部署选项来强化公告。持续的模糊性将限制短期规划。

第二个信号是语义保真度，即业务定义和关系在跨系统使用时能够多准确地保留下来。

客户需要能够揭示受支持边界、而非掩盖这些边界的示例。跨领域问题和不断变化的业务定义尤其值得审查。

若应用能够透明地处理这些条件，就能支持托管业务基础的论点。频繁的人工重建则会缩小其收益。

这并不要求供应商宣称实现了完美理解。明确的限制和可重复的评估，能够提供比关于上下文智能的宽泛保证更有力的证据。

第三个信号是来自完整客户工作流的运营结果。相关报告应区分更快的分析、更快的实施、更低的维护成本或更高的决策质量。

这些结果回答的是不同问题。更快的查询可能很有用，但并不能证明一家公司已经淘汰了其自定义集成技术栈。

同样，助手可以为用户节省时间，同时带来新的审查义务。运营评估应包括维持其回答可靠性所需的工作量。

买方应寻找明确的基线、具名的业务流程，以及对人工参与情况的清晰说明。当这些细节未被说明时，比较将变得困难。

最有力的客户证据应说明部署后发生了什么变化：哪些任务消失了，哪些控制措施得以保留，以及组织如何衡量结果。

这也将澄清谁最先受益。数据工程师、管理员、业务分析师和运营用户会体验同一架构的不同部分。

合作关系的重要性取决于能否连接这些体验。当更好的开发环境所带来的优势能够延续到日常业务使用中时，其价值才更大。

Databricks SAP 集成建立了朝向这种连接迈进的可信方向。其已记录的基础也让剩余问题足够具体，便于买方调查。

在做出承诺前，选择一个你的团队已经难以稳定回答的业务问题。要求供应商通过拟议架构追溯其记录、定义、权限和审批边界。索取每项所需能力的发布状态，包括头条公告以外的依赖项。然后将由此产生的工作负载与现有流程进行比较，包括维护和业务审查。有价值的结果，是更清楚地说明谁拥有每项决策，以及哪些工作确实消失。对于 Databricks SAP 集成而言，这些证据将使已宣布的扩展对正在评估下一项 AI 投资的企业具有实际意义。贵组织可以利用哪项业务工作流来检验这些主张？