---
schema_version: "1"
id: 3ac51a3759451a8afbc7e33c331caf34b5fac3c9c12402abdd0bef5094e025e6
title: Salesforce 数据虚拟化
collection: architect
version: current
locale: zh-cn
portal_url: https://docs.salesforce.com/architect/current/zh-cn/fundamentals/guides/data-virtualization.md
canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/fundamentals/guide/data-virtualization.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: b0c577742e6e141b05930748f45fd1282c36958b243e0fd7b344d508f38e84ae
products:
  - 基本知识
  - Architect Site Content Repo
updated_at: 2026-05-01T00:00:00Z
---
## 概览

企业数据架构很少存在于一个系统中。Salesforce 管理客户参与、漏斗和服务交互。Snowflake 等分析平台包含历史交易、财务记录、使用数据和运营度量。传统上，连接这两个世界意味着构建和维护 ETL 漏斗：从源提取数据、转换数据并将副本加载到 Salesforce 的计划作业。由于这些漏斗，数据延迟到达，治理策略在系统中成倍增加，漏斗需要持续的操作护理。

Salesforce 数据虚拟化提供了不同的模型。它使 Salesforce 能够在运行时直接在源位置查询数据，而无需复制，而不是将数据移动到 Salesforce 中。用户通过标准 Salesforce 界面查看实时外部数据。数据从不离开其权威主页。本文档以 Snowflake 为具体工作示例，解释了模式的工作方式、何时使用以及如何开始。

## 什么是数据虚拟化？

Salesforce 数据虚拟化是一种集成架构模式，它使 Salesforce 能够在运行时直接从外部系统查询数据，而无需将数据复制或复制到 Salesforce 存储中。平台不是将数据移入，而是发送查询。

因此，Salesforce 用户通过熟悉的 Salesforce 界面（例如页面布局、相关列表、报表或流）与外部数据进行交互，而数据仍保留在权威源系统中。治理、访问控制和数据驻留应保持不变。

这种模式建立在单一的架构原则之上：数据保留在源位置。计算移到数据。

## 为何如此重要

大多数企业 Salesforce 部署通过复制漏斗与外部数据平台（例如数据仓库、操作数据库或分析存储）集成。漏斗会按计划提取、转换数据并将其加载到 Salesforce。这种方法有效，但复制会引入结构性权衡：

* 复制的数据总是被延迟。漏斗引入滞后和过时的数据导致糟糕的决策。
* 每个数据副本都会扩展合规范围。多个系统中的敏感数据（例如个人身份信息、财务记录或健康数据）需要维护多个治理策略。
* 漏斗需要持续的操作投资、监控、故障处理、模式漂移管理和后处理逻辑。

数据虚拟化直接解决了这些权衡问题。它完全删除了读取量大的用例的漏斗，将数据保存在其权威位置，并为 Salesforce 用户提供外部数据的实时受管视图，而没有复制开销。

## 范围内的产品

<table style="border:none;width:100%">
  <tbody>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Connect logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://architect.salesforce.com/ns-assets/data-sync-virtz-images/salesforce-connect.png" alt="Salesforce Connect"></td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://help.salesforce.com/s/articleView?id=platform.platform_connect_about.htm&type=5">Salesforce Connect</a> 是一种平台功能,可在 Salesforce 中启用数据虚拟化。它提供了适配器框架，可以将 SOQL 查询翻译成外部系统的查询语言，管理经过身份验证的标注，并将结果集映射回 Salesforce 字段类型。它支持外部对象，即 Salesforce 元数据结构，将外部数据显示为可查询的平台本地实体，而无需将数据复制到 Salesforce 存储中。外部对象的行为类似于标准 Salesforce 对象 — 在页面布局、相关列表和报表中可见，并且可以通过 SOQL 和标准 API 访问 — 但不保留数据。外部对象是源系统上的模式投影。</td>
    </tr>
  </tbody>
</table>

## 核心概念

### 外部对象

外部对象是数据虚拟化在 Salesforce 中显示外部数据的主要机制。它们的行为类似于标准 Salesforce 对象：可以通过 SOQL 查询，在页面布局和相关列表中可见，并且可以通过标准 Salesforce API 访问。关键区别在于 Salesforce 中没有数据存储。外部对象是模式投影：外部数据的外观定义，而不是数据本身的副本。

当用户加载页面或运行引用外部对象的报表时，Salesforce 会对外部系统执行实时查询，并仅返回该交互的结果集。

### 查询下拉

当 Salesforce 对外部对象执行 SOQL 查询时，它会将筛选器（WHERE 子句）、排序顺序（ORDER BY）和限制（LIMIT）翻译成等效的 SQL，并将其发送到外部系统。外部系统在自己的计算引擎上执行查询，并只返回筛选的结果集。工作发生在数据存在的地方，只有答案会传回 Salesforce。

### 双重治理

数据虚拟化同时强制实施两个独立的安全层。外部系统在查询执行时应用自己的访问控制，包括行级安全性、列屏蔽和基于角色的访问。Salesforce 会在上面应用自己的安全模型：简档、权限集、字段级安全性和共享规则。两个图层在每个查询上都处于活动状态。两者都不能取代另一个。

## 零复制区别

架构师经常将数据虚拟化描述为“零复制”模式。零复制意味着没有持久复制到 Salesforce 存储中。没有将记录写入 Salesforce 对象的 ETL 漏斗。没有计划的同步创建本地副本。外部对象不保留行。

零复制并不意味着零数据传输。每次用户查询外部对象时，结果集都会通过网络从外部系统传输到 Salesforce。对于大型结果集或高查询频率，数据出口成本和网络延迟是架构师设计的真正因素。这不是隐藏的限制：这是要考虑的设计约束。

如果您的用例需要高用量、频繁访问或低延迟，请考虑这些架构差异。

## 使用 Snowflake 进行数据虚拟化：工作示例

Snowflake 是通过数据虚拟化连接到 Salesforce 的最常见的外部系统之一。它是模式如何端到端工作的具体示例。

在此配置中，Salesforce 使用 Salesforce Connect 与适用于 Snowflake 的 SQL 适配器连接到 Snowflake。Snowflake 表格和视图在 Salesforce 中显示为外部对象。当用户查询外部对象时，Salesforce 会将 SOQL 翻译成 SQL，并通过经过身份验证的 HTTPS 标注将其提交给 Snowflake 语句 API。Snowflake 对其虚拟仓库执行查询，应用自己的行级安全性和列屏蔽，并仅返回结果集。任何时候都不会将数据写入 Salesforce 存储。

![数据虚拟化架构](https://architect.salesforce.com/ns-assets/data-sync-virtz-images/data-virtualization-architecture.png)

### 身份验证模型

Salesforce Connect 使用委派 OAuth 2.0 模型，以对 Snowflake 进行身份验证。关键组件是：

* **身份验证提供商：**管理与 Snowflake 的 OAuth 握手。处理令牌请求，并将返回的令牌映射到 Salesforce 凭据。
* **外部凭据：**在 Salesforce 加密凭据存储中安全保存 OAuth 访问和刷新令牌，并将其注入出站标注。
* **命名凭据：**定义 Snowflake 端点 URL 并引用外部凭据。
* **Snowflake 安全集成：**在 Snowflake 中将 Salesforce 注册为受信 OAuth 客户端。定义允许的重定向 URI、OAuth 流和令牌 TTL。

这些组件构成了依赖链：外部数据源引用命名凭据，命名凭据引用外部凭据，外部凭据引用身份验证提供商。在排除连接或访问故障时，了解此链至关重要。

### 身份模型：命名主体与每用户主体

Salesforce 在使用 Snowflake 进行身份验证时支持两种身份委派模型：

* **命名主体：**一个共享服务帐户针对 Snowflake 对所有 Salesforce 用户进行身份验证。这配置更简单，但没有每个用户的可审计性或细粒度 Snowflake 访问控制。
* **每个用户主体：**每个 Salesforce 用户使用自己的 OAuth 令牌进行身份验证。这将启用 Snowflake 行级安全性和完整的每用户审计跟踪，并权衡更高的令牌管理开销（每用户 OAuth 流、刷新、撤销）。

**决策指导：**将每个用户主体用于受管数据或个人身份信息 (PII)。当 Salesforce 共享规则提供足够的访问控制且简单是首要时，使用命名首要。

### 关键平台约束

在将外部对象与 Snowflake 一起使用时，这些 Salesforce 调控器限制会直接决定解决方案设计：

* **标注限制：**每个 Apex 事务 100。具有多个外部对象查询的页面或流可以快速达到此限制。
* **标注超时：**最多 120 秒。长时间运行的 Snowflake 查询会导致运行时异常。
* **SOQL 行限制：**50,000 行。分页大型结果集。
* **异步约束：**批处理 Apex 和大多数异步上下文会限制标注。将外部对象的访问权限保持在同步事务边界内。对于查询外部对象的异步用例，请考虑用户发起的异步交互的继续标注，或构建流，以在同步事务中执行外部数据访问并异步移交结果。

**设计指导：**请勿在循环中查询外部对象。将 WHERE 子句筛选器推送到 Snowflake，以减少结果大小和标注频率。

### 可观察性

Salesforce 发送到 Snowflake 的每个查询都记录在 Snowflake 查询历史记录中，其中包含完整的执行元数据：延迟、扫描的行数、使用的仓库和执行身份。此历史提供了从 Salesforce 用户操作到 Snowflake 执行的端到端可审计性，并且是性能调整和访问验证的主要诊断工具。

## 何时使用数据虚拟化

数据虚拟化非常适合实时访问、治理和减少复制开销超过联合查询时间访问模型约束的用例。

**在以下情况下使用：**

* **读取繁重的分析访问权限是主要要求。**如果用户需要在 Salesforce UI、报表或流中查询和显示外部数据，而无需回信，数据虚拟化会消除只读场景的漏斗开销。
* **数据新鲜度至关重要。**当过时的复制数据产生业务风险（例如过时的财务余额、库存水平或合规状态）时，联合模型保证每个查询都反映实时数据。
* **治理和数据驻留要求严格。**当法规或合同约束禁止将敏感数据复制到 Salesforce 时，虚拟化将数据保存在其权威位置，同时使其在 Salesforce 中可访问。只有一个系统保存数据。
* **需要双层访问控制。**当外部系统的本地访问控制和 Salesforce 安全模型同时应用时，联盟模型会强制执行两者，而不会造成数据重复。
* **外部系统已经是权威的记录系统。**如果数据已在源系统中清理、管理和可查询，则对其进行虚拟化可避免冗余转换、存储成本和分歧风险。

**在以下情况下避免：**

* **需要低延迟写入。**外部对象是只读的。写回用例需要不同的集成模式。
* **需要复杂的多对象连接。**跨多个外部对象的 SOQL 不支持连接。在源系统中将连接的数据预具体化为单个视图。
* **Salesforce AI或Agentforce功能需要本地数据。**目前，Einstein 和 Agentforce 功能（包括 Einstein Copilot驾驶基础、预测评分和 Agentforce 操作）在本机 Salesforce 对象上运行。这些功能不支持外部对象作为基础或激活数据源。如果 AI 激活在此数据的范围内，**Salesforce Data 360 是推荐的补充解决方案。**
* **高频、高用量访问模式。**外部对象专为按需访问而设计。每分钟触发数百个查询的工作量会限制排气调节器，并降低性能。

## 用例：实践中的模式

以下用例说明了 Salesforce 数据虚拟化如何在常见的企业场景中应用。每个示例都使用 Snowflake 作为外部系统，但基础模式适用于 Salesforce Connect 支持的任何 SQL 兼容数据源。

### 用例 1：来自外部数据仓库的客户支持度量

**挑战：**支持团队需要将 Salesforce 个案数据与存储在 Snowflake 中的票证数量、解决时间和升级度量结合起来的统一报表。为这些数据构建和维护复制漏斗会引入滞后，并增加只读报表用例的操作开销。

**解决方案：**团队在 Salesforce 中将包含票证度量的 Snowflake 视图公开为外部对象。该团队配置了 Salesforce 报表，将本地个案对象与外部票证数据结合起来。

**结果：**

* 报表始终反映实时 Snowflake 数据。没有漏斗延迟。
* 敏感支持度量的治理仍在 Snowflake 中。
* 无需构建、监控或维护 ETL 漏斗。

### 用例 2：销售代表的实时信用状态

**挑战：**一个财务团队在 Snowflake 中维护了权威的信用额度和余额数据。通过反向 ETL 将这些值复制到 Salesforce 会引入复制滞后，导致销售代表根据过时的信用信息提交交易。合规团队还标记了在 Salesforce 存储中保存敏感财务数据的风险。

**解决方案：**团队将 Snowflake 财务视图虚拟化为外部对象，并将其显示在客户页面布局中。现在，销售代表在 Salesforce 中将实时信用状态视为标准客户视图的一部分。

**结果：**

* 每个客户页面上的实时信用数据。没有滞后。
* 为财务数据消除了反向 ETL 漏斗。
* 敏感财务数据从未复制到 Salesforce 存储。合规范围保留在 Snowflake 中。

### 用例 3：并购期间的跨组织运营报告

**挑战：**在合并期间，收购公司需要让 Salesforce 用户查看 6 个高用量 Snowflake 数据集的运营数据，涵盖交易、开单和使用。将 TB 的数据复制到 Salesforce 在合并时间线上不可行，并且为每个数据集构建自定义 ETL 漏斗需要大量的工程投资。

**解决方案：**该团队使用 Salesforce Connect 为所有 6 个 Snowflake 数据集配置了外部对象，并具有最低权限的集成角色。不需要自定义代码。查询直接在 Snowflake 中执行，所有活动都记录在 Snowflake 查询历史记录中，以便进行合规报告。

**结果：**

* 完全声明性配置。无需自定义代码或漏斗。
* 保证数据新鲜度。每个查询都会反映执行时的实时 Snowflake 数据。
* Snowflake 查询历史记录中的完整审计跟踪，适用于监管和合规报告。

## 设计注意事项和失败模式

数据虚拟化引入了不同的运营简档。设计这些失败场景：

* **OAuth 令牌过期：**令牌的生存时间有限 (TTL)。过期令牌会导致标注失败。监控 401 个未经授权的响应并实施刷新逻辑。
* **仓库冷启动（雪花专用）：**自动暂停仓库会在第一个查询上添加 5–30 秒。对于具有延迟要求的面向用户的用例，在工作时间使用计划的轻量级查询进行预热。
* **角色不匹配：**外部系统中配置错误的角色可能会静默返回零行，而不是错误。独立于 Salesforce 验证外部系统中的角色到对象权限。
* **结果集溢出：**超大负载超过 API 限制。始终应用 LIMIT 子句，并公开筛选视图，而不是原始表。
* **外部系统中断：**不存在回退或缓存。在尝试/捕获中换行标注，并在 UI 中显示信息性错误状态。对于任务关键型数据，请考虑分层方法：虚拟化以实现实时访问，并为最重要的字段维护轻量级的复制回退，以保证在源系统停机期间的可用性。

## 结构良好的定线

Salesforce 数据虚拟化与 Salesforce 良好架构框架的以下支柱保持一致。

* **Trust:**委派 OAuth 2.0 模型和最低权限角色指导与 Trust 保持一致。双层访问控制（源系统 + Salesforce）深入实施防御。
* **可靠性（容错）：**故障模式部分直接涉及可靠性：令牌过期、冷启动、角色错误配置、结果集溢出和中断处理，每个代表不同的故障类，都有文档化的解决路径。
* **可靠性（可扩展性）：**查询推送、仓库规模指导和标注限制意识优化了 Salesforce 调控器约束中的执行效率，这是大规模运营的解决方案的可靠性问题。
* **卓越运营：**Snowflake 查询历史作为主要可观察性工具支持卓越运营：架构师谨慎地做出可跟踪的选择，使用平台原生工具进行端到端的可审计性和性能诊断，而不是构建自定义日志记录基础设施。

## 架构师快速入门

本节为架构师和设计者提供了在 Sandbox 环境中构建数据虚拟化模式的结构化起点。它不是完整的实施指南 — 将其视为经过验证的决策和配置步骤序列，以指导您的第一个概念验证。

### 开始之前

在开始任何配置工作之前，请确认以下事项：

* **许可证权利：**Salesforce Connect 未包含在所有 Salesforce 版本中。除了基本 Salesforce Connect 权利之外，适用于 Snowflake 的 SQL 适配器需要单独的加载项许可证。在继续之前，请在您的组织中验证两者。
* **先使用 Sandbox：**在将您的配置升级到生产之前，请在 Sandbox 环境中完成所有阶段。
* **Snowflake 访问权限：**请确认您拥有在 Snowflake 中创建安全集成的权限，以及对目标数据库、方案和对象的访问权限。
* **适配器版本：**请确认适用于 Snowflake 的 SQL 适配器在您的组织版本中可用，并且您的 Snowflake 帐户 URL 不包含下划线（如果包含，请用连字符替换）。这是 Salesforce 平台对标注主机名解析的约束）。

使用 Snowflake 等外部 SQL 系统设置数据虚拟化是一个声明性、配置驱动的过程，不需要自定义代码。设置遵循三个顺序阶段：建立 Identity and Trust、配置数据表面以及向最终用户公开数据。

### 阶段 1：Identity 和 Trust 配置

此阶段在 Salesforce 和外部系统之间建立安全的委派 OAuth 2.0 Trust 链。在开始任何数据表面配置之前，请完成此阶段。

1. **在 Salesforce 中创建身份验证提供商。**使用 OpenID Connect 类型。在此阶段使用占位符值 — 从外部系统检索值后返回以完成。保存后，Salesforce 会生成回调 URL。保留此值。
2. **在外部系统中将 Salesforce 注册为 OAuth 客户端。**在 Snowflake 中，这意味着创建安全集成（OAuth、机密客户端类型）。提供 Salesforce 回调 URL 作为重定向 URI。创建后，从集成中检索客户端 ID、客户端密码、授权 URL 和令牌 URL。
3. **完成身份验证提供商配置。**返回 Salesforce 身份验证提供商，并使用从外部系统检索的值进行填充：使用者密钥、使用者密码、授权 URL 和令牌 URL。
4. **创建外部凭据。**将协议设置为 OAuth 2.0，将其链接到身份验证提供商，并添加主体（根据您的身份模型决定，命名或按用户）。此对象管理 OAuth 令牌生命周期。
5. **创建命名凭据。**将端点设置为外部系统的 API URL（例如 `https://<account>.snowflakecomputing.com/api/v2/statements/`），并将其链接到外部凭据。
6. **授予对外部凭据的简档访问权限。**如果没有此步骤，即使所有其他配置都正确，用户也无法调用联合查询。
7. **启动 OAuth 流以完成身份验证。**从 Salesforce 触发 OAuth 握手。平台重定向到外部系统登录，验证凭据，并将生成的令牌安全地存储在外部凭据中。此步骤将用户上下文绑定到有效令牌。所有聚合查询都会失败，直到此步骤完成。

### 第 2 阶段：Data Surface 配置

此阶段将 Salesforce 连接到外部数据模式，并创建用户和平台查询的外部对象定义。

1. **创建外部数据源。**选择适当的适配器（例如，适用于 Snowflake 的 SQL 适配器），将其指向目标数据库和方案，并将其链接到您在阶段 1 中创建的命名凭据。
2. **验证连接。**使用外部数据源上的内置验证。成功的结果确认 OAuth Trust 链完整，并且外部系统可访问。
3. **同步元数据。**从外部数据源启动元数据同步。Salesforce 自检目标模式并生成外部对象定义，将外部列映射到 Salesforce 字段类型。
4. **选择并显示所需的表或视图。**选择哪些外部表或视图显示为外部对象。作为最佳实践，公开策划视图，而不是原始表。视图允许预筛选列、行级限制，并更严格地控制 Salesforce 层可以访问的内容。

### 阶段 3：UI 和访问权限配置

此阶段使外部对象对 Salesforce Lightning Experience 中的最终用户可见和可用。

1. **创建外部对象的选项卡。**选项卡使外部对象可在 Lightning 应用程序中直接导航。
2. **将外部对象添加到页面布局。**在本机 Salesforce 记录旁边显示相关的外部数据（例如，将 Snowflake 财务视图添加到客户页面布局）。
3. **添加到相关列表。**在相关列表中包括外部对象，以为用户提供上下文中本地和外部数据的统一视图。
4. **验证端到端查询联盟。**加载页面或运行引用外部对象的查询。然后，检查外部系统的查询历史（例如 Snowflake 查询历史），以确认查询在源位置执行。验证运行查询的角色、仓库和身份是否正确。

在所有三个阶段完成后，Salesforce 用户可以通过标准 Salesforce 界面与实时外部数据进行交互，而不会意识到数据来自 Salesforce 外部。

## 结论

Salesforce 数据虚拟化使用查询时间联合取代了基于复制的集成。数据保留在权威来源中；Salesforce 用户通过标准平台界面与其交互。没有要构建的漏斗，没有要治理的副本，也没有要管理的延迟。

当重读访问、实时数据新鲜度、严格治理和双层访问控制是主要驱动因素时，这种模式是正确的选择。当需要写入时，当 AI 或自动化功能依赖于本地 Salesforce 对象时，或者当访问模式过于频繁以至于调控器限制无法容纳时，这是一个错误的选择。

Snowflake 很好地说明了该模式：以声明方式建立的受管查询时间联合连接，没有自定义代码，通过 Snowflake 查询历史记录可以端到端地观察到，并且可以通过 Snowflake 本地访问控制和完整的 Salesforce 安全模型来执行。

在提交到此架构之前，请验证许可证权利，根据您的预期访问模式评估调控器限制暴露，并确认 Sandbox 环境中的 OAuth 准备情况。该模式奖励了深思熟虑的前期设计：正确对待身份模型、凭据链和查看策略，并且运营足迹最小。

## 关于作者

**Yugandhar Bora** 是 Salesforce 的软件工程架构师,专门从事数据和智能应用程序平台中的数据架构。他领导企业架构审查委员会 (EARB) 专注于数据治理和统一数据模型的举措，同时为自动化平台配置解决方案做出贡献。