Salesforce 資料虛擬化 | 其他資源 | 基本概念

企業資料結構極少存在於一個系統中。Salesforce 管理客戶參與、銷售管道和服務互動。如 Snowflake 等分析平台包含歷程記錄交易、財務記錄、用量資料和營運度量。傳統上,橋接這兩個世界意味著建立和維護 ETL 銷售管道:排程工作,可從來源中提取資料、將其轉換,並將複本載入至 Salesforce。由於這些管道,資料傳送延遲、整個系統的管治原則會複製,且管道需要持續的營運照護。

Salesforce 資料虛擬化提供不同的模型。它可讓 Salesforce 在執行階段直接在資料來源中查詢資料,而無須複製。使用者可透過標準 Salesforce 介面查看即時外部資料。資料永遠不會離開其權威性首頁。此文件說明模式的運作方式、使用時機,以及如何開始使用,使用 Snowflake 作為具體工作範例。

Salesforce 資料虛擬化是一種整合結構模式,可讓 Salesforce 在執行階段直接從外部系統查詢資料,而無須將該資料複製或複製到 Salesforce 儲存空間。平台不會將資料移入,而是會將查詢傳出。

因此,Salesforce 使用者會透過熟悉的 Salesforce 介面 (例如版面配置、相關清單、報告或流程) 與外部資料互動,而資料會保留在其權威來源系統中。監管、存取控制和資料落地會保持在其所在位置。

此模式以單一結構原則為基礎:資料會保留在來源。計算移至資料。

大多數企業 Salesforce 部署會透過複製銷售管道與外部資料平台整合 (例如資料倉庫、作業資料庫或分析商店)。銷售管道會依照排程將資料解壓縮、轉換和載入至 Salesforce。此方法可以運作,但複製會導致結構性權衡:

複製的資料一律延遲。銷售管道導致延遲,資料過時導致決策不佳。
每個資料複本都會展開合規範圍。多個系統中的敏感資料 (例如個人可識別資訊、財務記錄或健康資料) 需要維護多個管治原則。
銷售管道需要持續的營運投資、監視、失敗處理、結構描述漂移管理和重新處理邏輯。

資料虛擬化會直接解決這些權衡。它會針對嚴重的使用個案完全移除銷售管道、將資料保持在其權威位置,並為 Salesforce 使用者提供外部資料的即時受管理檢視,而不需要複製負擔。

外部物件是「資料虛擬化」在 Salesforce 內呈現外部資料的主要機制。其行為如同標準 Salesforce 物件:可透過 SOQL 查詢、可在版面配置和相關清單中看見,並可透過標準 Salesforce API 存取。主要差異在於 Salesforce 中不會儲存任何資料。外部物件是結構描述投影:外部資料外觀的定義,而非資料本身的複本。

當使用者載入參照「外部物件」的頁面或執行報告時,Salesforce 會對外部系統執行即時查詢,並僅傳回該互動的結果集。

當 Salesforce 針對「外部物件」執行 SOQL 查詢時,會將篩選條件 (WHERE 子句)、排序順序 (ORDER BY) 和限制 (LIMIT) 轉換為等同的 SQL,並將其傳送至外部系統。外部系統會在自己的計算引擎上執行查詢,並僅傳回篩選後的結果集。工作會在資料所在的位置發生,只有回答會返回 Salesforce。

資料虛擬化會同時強制執行兩個獨立的安全性層級。外部系統會在查詢執行階段套用自己的存取控制,包括列層級安全性、資料欄遮蔽和以角色為基礎的存取權。Salesforce 會在頂端套用自己的安全性模型:設定檔、權限集、欄位級安全性和共用規則。兩個圖層都會在每個查詢上啟用。兩者都不會取代另一個。

結構設計師經常將資料虛擬化描述為「零複製」模式。複製零表示不會永久複製到 Salesforce 儲存空間。沒有 ETL 管道將記錄寫入至 Salesforce 物件。沒有已排程的同步化建立本機複本。外部物件不會保留任何列。

零複製不表示零資料傳輸。每次使用者查詢「外部物件」時,結果集會透過網路從外部系統前往 Salesforce。針對大型結果集或高查詢頻率,資料輸出成本和網路延遲是結構設計師設計的實際因素。這不是隱藏的限制:這是要考慮的設計限制。

如果您的使用個案需要大量、頻繁存取或低延遲,請考量這些結構差異。

Snowflake 是透過資料虛擬化連線至 Salesforce 的最常見外部系統之一。此範例可作為模式從結尾運作的具體範例。

在此組態中,Salesforce 使用 Salesforce Connect 與適用於 Snowflake 的 SQL 轉接器連線至 Snowflake。Snowflake 表格與檢視會在 Salesforce 中呈現為「外部物件」。當使用者查詢外部物件時,Salesforce 會將 SOQL 翻譯為 SQL,並透過已驗證的 HTTPS 呼叫將其提交至 Snowflake 陳述式 API。Snowflake 會對其虛擬倉庫執行查詢、套用自己的列層級安全性和資料欄遮蔽,並僅傳回結果集。任何時間都不會將任何資料寫入 Salesforce 儲存空間。

資料虛擬化結構

Salesforce Connect 使用委派的 OAuth 2.0 模型來使用 Snowflake 進行驗證。關鍵元件包括:

**驗證提供者:**使用 Snowflake 管理 OAuth 處理常式。處理權杖要求,並將傳回的權杖對應至 Salesforce 認證。
**外部認證:**在 Salesforce 加密認證存放區中安全保留 OAuth 存取和重新整理權杖,並將其注入輸出呼叫。
**已命名認證:**定義 Snowflake 端點 URL 並參照「外部認證」。
**Snowflake 安全性整合:**在 Snowflake 中將 Salesforce 註冊為信任的 OAuth 用戶端。定義允許的重新導向 URI、OAuth 流程和權杖 TTL。

這些元件形成一個相依性鏈:外部資料來源參照「已命名認證」,其參照「外部認證」,其參照「驗證提供者」。當疑難排解連線或存取失敗時,瞭解此鏈結十分重要。

使用 Snowflake 進行驗證時,Salesforce 支援兩種身分委派模型:

**已命名主體:**一個共用的服務帳戶會針對 Snowflake 驗證所有 Salesforce 使用者。此設定較簡單,但沒有每位使用者的稽核能力或精細的 Snowflake 存取控制。
**每位使用者主體:**每個 Salesforce 使用者都會使用自己的 OAuth 權杖進行驗證。這可啟用 Snowflake 列層級安全性和完整的每位使用者稽核追蹤,並權衡更高的權杖管理超額 (每位使用者 OAuth 流程、重新整理、撤銷)。

**決策指引:**將「每位使用者主體」用於受監管的資料或個人可識別資訊 (PII)。當 Salesforce 共用規則提供足夠的存取控制,且簡化是優先考量時,請使用「已命名主體」。

這些 Salesforce 管理員會在將「外部物件」搭配 Snowflake 使用時,直接限制形狀解決方案設計:

**呼叫限制:**每個 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 相容資料來源。

**挑戰:**支援小組需要統一報告,將 Salesforce 個案資料與儲存在 Snowflake 中的票證量、解決時間和升級度量結合在一起。建立與維護此資料的複製管道會導致延遲,並為唯讀報告使用個案增加營運負擔。

**解決方案:**小組在 Salesforce 中將包含票證度量作為「外部物件」的 Snowflake 檢視公開。小組設定 Salesforce 報告以將原生個案物件與外部票證資料聯結。

結果:

報告一律反映即時 Snowflake 資料。沒有銷售管道延遲。
敏感支援度量的管理會保留在 Snowflake 中。
沒有可建立、監視或維護的 ETL 銷售管道。

**挑戰:**財務小組在 Snowflake 中維護具有權威性的信用額度與餘額資料。透過反向 ETL 將這些值複製到 Salesforce 會導致複製延遲,導致銷售代表根據過時的信用資訊認可交易。合規小組也標記在 Salesforce 儲存空間中保留敏感財務資料的風險。

**解決方案:**小組將 Snowflake 財務檢視虛擬化為「外部物件」,並在「帳戶」版面配置上呈現。銷售代表現在會將即時信用狀態視為其在 Salesforce 中標準「帳戶」檢視的一部分。

結果:

每個「帳戶」頁面上的即時信用資料。沒有延遲。
已針對財務資料去除反向 ETL 銷售管道。
敏感財務資料從未複製到 Salesforce 儲存空間。規範範圍會保留在 Snowflake 中。

**挑戰:**在合併期間,取得公司需要讓 Salesforce 使用者能夠從涵蓋交易、帳單和使用量的 6 個大量 Snowflake 資料集中看見作業資料。在合併時程表上將資料的 TB 複製到 Salesforce 並不實用,為每個資料集建立自訂 ETL 銷售管道需要大量的工程投資。

**解決方案:**小組使用具有最低權限整合角色的 Salesforce Connect,為所有 6 個 Snowflake 資料集設定「外部物件」。不需要自訂程式碼。查詢會直接在 Snowflake 中執行,且所有活動都會記錄在 Snowflake 查詢歷程記錄中,以進行合規性報告。

結果:

完全陳述性組態。不需要自訂程式碼或管道。
資料更新保證。每個查詢都會在執行階段反映即時的 Snowflake 資料。
適用於法規與合規性報告的 Snowflake 查詢歷程記錄完整稽核追蹤。

資料虛擬化導入不同的作業設定檔。設計這些失敗案例:

**OAuth 權杖到期:**權杖有有限的存留時間 (TTL)。到期權杖會造成呼叫失敗。監視 401 未授權回應並實作重新整理邏輯。
**倉庫冷啟動 (Snowflake 特定的):**自動暫停的倉庫會在第一個查詢上新增 5–30 秒。針對具有延遲需求的使用者面向使用個案,請在營業時間內使用排程的輕量化查詢進行預先暖化。
**角色不相符:**外部系統中設定錯誤的角色會無訊息傳回零列,而非錯誤。獨立於 Salesforce 在外部系統中驗證角色對物件權限。
**結果集溢出:**超大裝載超過 API 限制。一律套用 LIMIT 子句,並且顯示篩選的檢視,而非原始表格。
**外部系統中斷:**不存在回復或快取。以 try/catch 括住呼叫,並在 UI 中呈現資訊性錯誤狀態。針對重要任務資料,請考慮使用分層方法:虛擬化以供即時存取,並針對最重要欄位維護輕量型複製回復,以保證來源系統中斷期間的可用性。

Salesforce 資料虛擬化符合 Salesforce 良好結構架構的下列支柱。

**Trust:**委派的 OAuth 2.0 模型和最低權限角色指引符合 Trust。雙層存取控制 (來源系統 + Salesforce) 會深入強制執行防禦。
**可靠性 (錯誤容忍):**失敗模式區段直接處理可靠性:權杖到期、冷啟動、角色錯誤組態、結果集溢出和中斷處理皆代表具有已記錄解析路徑的不同失敗類別。
**可靠性 (延展性):**查詢推送功能表、倉庫大小指引和呼叫限制感知可在 Salesforce 管理員限制內最佳化執行效率,這是大規模作業解決方案的可靠性考量因素。
傑出作業:「Snowflake 查詢歷程記錄」作為主要可觀察性工具支援最佳作業:結構設計師可謹慎且可追蹤地選擇使用平台原生工具來進行端對端稽核性和效能診斷,而非建立自訂記錄基礎結構。

此區段為結構設計師和設計師提供在 Sandbox 環境中建立「資料虛擬化」模式的結構化起點。這並非完整的實作指南,會將其視為一系列經過驗證的決策和組態步驟,以引導您第一次證明概念。

開始任何組態工作之前,請先確認下列事項:

**授權權益:**Salesforce Connect 不包含在所有 Salesforce 版本中。適用於 Snowflake 的 SQL 轉接器需要基本 Salesforce Connect 權益以外的個別附加元件授權。繼續之前,請先在您的組織中確認兩者。
**Sandbox 優先:**先完成 Sandbox 環境中的所有階段,再將您的組態升級至生產環境。
**Snowflake 存取權:**確認您有權限可在 Snowflake 中建立「安全性整合」,並可存取目標資料庫、結構描述和物件。
**轉接器版本:**確認您的組織版本提供適用於 Snowflake 的 SQL 轉接器,且您的 Snowflake 帳戶 URL 不包含底線 (若有的話,請以連字號取代)。這是呼叫主機名稱解決的 Salesforce 平台限制)。

使用外部 SQL 系統 (例如 Snowflake) 設定資料虛擬化是一種宣告式且以組態為導向的程序,無須自訂程式碼。設定會依序進行三個階段:建立身分與 Trust、設定資料表面,並向一般使用者公開資料。

此階段會在 Salesforce 與外部系統之間建立安全且委派的 OAuth 2.0 Trust 鏈結。請先完成此階段,再開始任何資料表面組態。

**在 Salesforce 中建立驗證提供者。**使用 OpenID Connect 類型。在此階段使用預留位置值 — 從外部系統取得值後返回完成。儲存之後,Salesforce 會產生「回呼 URL」。保留此值。
**在外部系統中將 Salesforce 註冊為 OAuth 用戶端。**在 Snowflake 中,這表示建立安全性整合 (OAuth、機密用戶端類型)。提供 Salesforce 回呼 URL 作為重新導向 URI。從建立後的整合中取用戶端識別碼、用戶端密碼、授權 URL 和權杖 URL。
**完成驗證提供者組態。**返回 Salesforce 驗證提供者,並在其中填入從外部系統取得的值:「取用者金鑰」、「取用者密碼」、「授權 URL」和「權杖 URL」。
**建立外部認證。**將通訊協定設定為 OAuth 2.0、將其連結至驗證提供者,然後新增「主體」(根據您的身分模型決策,名稱或每位使用者)。此物件會管理 OAuth 權杖生命週期。
**建立已命名認證。**將端點設定為外部系統的 API URL (例如,https://<account>.snowflakecomputing.com/api/v2/statements/),並將其連結至「外部認證」。
**授與設定檔對「外部認證」的存取權。**若沒有此步驟,即使其他所有組態皆正確,使用者仍無法叫用聯合查詢。
**起始 OAuth 流程以完成驗證。**從 Salesforce 觸發 OAuth 接觸。平台會重新導向至外部系統登入、驗證認證,並安全地將產生的權杖儲存在「外部認證」中。此步驟會將使用者內容繫結至有效的權杖。在此步驟完成前,所有聯合查詢都會失敗。

此階段會將 Salesforce 連線至外部資料結構描述,並建立使用者與平台查詢的「外部物件」定義。

**建立外部資料來源。**選取適當的轉接器 (例如,Snowflake 的 SQL 轉接器)、將其指向目標資料庫和結構描述,並將其連結至您在階段 1 中建立的已命名認證。
**驗證連線。**在「外部資料來源」上使用內建驗證。成功結果會確認 OAuth Trust 鏈結已完成且可到達外部系統。
**同步中繼資料。**從「外部資料來源」起始中繼資料同步。Salesforce 會自我檢查目標結構描述並產生「外部物件」定義,將外部欄對應至 Salesforce 欄位類型。
**選取並顯示所需的表格或檢視。**選擇要呈現為「外部物件」的外部表格或檢視。最佳作法是,公開精密設計的檢視,而非顯示原始表格。檢視允許預先篩選資料欄、列層級限制,以及更嚴格地控制 Salesforce 圖層可以存取的內容。

此階段可讓 Salesforce Lightning Experience 內的一般使用者看見外部物件並使用。

**建立「外部物件」的索引標籤。**索引標籤可讓「外部物件」在 Lightning 應用程式中直接瀏覽。
**將外部物件新增至版面配置。**在原生 Salesforce 記錄旁呈現相關的外部資料 (例如,將 Snowflake 財務檢視新增至「帳戶」版面配置)。
**新增至相關清單。**在相關清單中包含「外部物件」,讓使用者能夠在內容中統一檢視原生與外部資料。
**驗證端對端查詢聯合。**載入頁面或執行參照「外部物件」的查詢。接著檢查外部系統的查詢歷程記錄 (例如 Snowflake 查詢歷程記錄),確認查詢已在來源執行。確認角色、倉庫和身分正確執行查詢。

完成所有三個階段後,Salesforce 使用者可以透過標準 Salesforce 介面與即時外部資料互動,而不會意識到資料源自 Salesforce 外部。

Salesforce 資料虛擬化會以查詢時間聯合取代以複製為基礎的整合。資料會保留在其授權來源中;Salesforce 使用者可透過標準平台介面與其互動。沒有要建立的管道、沒有要管理的複本,也沒有要管理的延遲。

當讀取繁重的存取、即時資料更新、嚴格的管治和雙層存取控制為主要驅動因素時,此模式是正確的選擇。當需要寫入、當 AI 或自動化功能取決於原生 Salesforce 物件時,或當存取模式太頻繁而無法容納管理員限制時,此為錯誤的選擇。

Snowflake 可說明此模式:以宣告的方式建立且沒有自訂程式碼的受管理、查詢時間聯合連線,可透過 Snowflake 查詢歷程記錄觀察端對端,且可透過 Snowflake 原生存取控制項與完整 Salesforce 安全性模型強制執行。

認可此結構之前,請先驗證授權權益、根據預期的存取模式評估管理員限制曝光,並確認 Sandbox 環境中的 OAuth 整備。模式獎勵謹慎的前置設計:正確取得身分模型、認證鏈和檢視策略,且營運足跡最小。

Yugandhar Bora 是 Salesforce 的軟體工程結構設計師,專門在「資料與情報應用程式」平台內進行資料結構。他負責企業結構檢閱委員會 (EARB) 專注於資料管理和統一資料模型的計畫,同時為自動平台佈建解決方案做出貢獻。