資料平台已經在發展超過三十年。一開始,該行業由內部部署、集中和結構化 (大多是關聯式)、營運/OLTP 資料庫所主控。此擴展以包含主要用於分析處理的資料倉庫 OLAP/大型資料平台,且保持關聯性和集中。雲端儲存空間會驅動散佈式結構,例如資料倉庫、湖家和分類儲存空間。不過,作業平台與分析平台保持獨立。今天,雲端計算和 AI 革命正在徹底改變資料平台結構。

企業已經投資於成熟的 Big Data 平台,例如 Snowflake、Databricks、BigQuery 和 Redshift。但這些平台會作為資料孤島使用。客戶不會從其資料中衍生業務價值,因為無法直接在業務流程與應用程式內對資料採取動作。這些解決方案缺乏生成式工作人員 AI 處理,且無法即時提供資料存���,因此無法在客戶參與和其他業界領先的功能時提供 AI 驅動的個人化。

資料平台的未來特點為統一、彈性、可存取和開放的資料基礎結構。此新結構以現代運算和儲存趨勢為基礎—GPU、大型記憶體、NVMe SSD 和雲端儲存—以與雲端運算和 AI 整合。他們能夠提供即時洞察、強化自主決策,並驅動即時應用程式。這包括工作人員 AI、預測式 AI、分析、即時大規模 OLTP 資料庫、資料湖和湖頭的崛起。這些現代資料平台的設計目的為簡化、擴展性、靈活性、效能、安全性、可用性和成本效率。

下列資料趨勢會推動下一代資料平台結構。

• 核心的 AI、機器學習和 Analytics:「工作人員 AI」的崛起將徹底改變資料平台的開發、部署和使用/存取。工作人員 AI 將會瞭解對話/查詢意圖、規劃、產生工作流程,以及自動化決策。工作人員 (短期與長期) 記憶體會從對話歷程記錄建構,用於個人化工作人員規劃和決策、即時對話建模和資料平台中重要個人化支援。工作人員將協助自動化作業「功能」,例如資料管理 (例如安全性、合規性、Trust)、效能 (例如自動調整同時、輸送量和延遲)、故障切換和可用性,以及可觀察性與維護。AI 技術支援的分析、預測、分析問答的自然語言處理 (NLP),以及非結構化資料 (例如 PDF、影像、音訊、視訊等文字) 的分析將成為標準,可讓企業從各種資料來源衍生更深入的洞察。
• 資料去中心化但統一資料存取權:工作人員需要企業資料來衍生洞察、進行決策,以及自動化業務活動。在企業、不同的應用程式和資料平台中,資料本質上為去中心化。但透過企業內的不同業務單位和與企業外部的合作夥伴來順暢統一單位並不容易。統一資料涉及資料共用,無論是透過從來源中提取或與資料來源聯合;資料準備、調和和建模中的原始資料,用於分析和 AI 處理;大規模資料儲存和管理,以有效地使用低 CTS 存取資料;以及透過各種查詢和分析機制和工具來存取資料,並與基礎儲存和資料存取平台深度整合
• 雲端型未結束湖家:雲端型大型資料 (OLAP) 平台正在合併採用開放式檔案格式 (Parquet) 和表格格式 (Iceberg),以啟用資料聯合 (資料進入) 和共用 (資料外出)。
• 非結構化資料處理:隨著生成式 AI 的出現、進步和採用,企業開始從構成大量文字文件、音訊文字記錄、視訊錄音和其他媒體的企業資料庫中衍生寶貴的洞察和業務價值。非結構化資料處理 (包括切分、向量化、語意搜尋和 Knowledge 圖表) 可讓這些洞察可供使用。如 RAG (取得擴充產生) 和 CAG (快取擴充產生) 等技術正在成為資料整體快速且有機搜尋的主要驅動因素。
• Knowledge Management 超出原始內容本身 (文件、文章、影片) 之外。其代表透過衍生意義、精密設計中繼資料,並將內容放置在內容中,以開發跨組織或企業內容的共用瞭解,來擴大該內容。Knowledge 本身通常是結構化。Knowledge 管理涉及內容管理、Knowledge 提取、透過模型 (例如圖形) 表示和瀏覽。
• 豐富資料存取權:豐富的資料存取權表示資料、分析和 AI 工具必須可供各種角色存取,包括一般使用者、業務使用者、管理員和分析師。透過如集合查詢 (包含關聯性、關鍵字和語意查詢)、自然語言到 SQL (NL2SQL) 查詢、即時存取等機制達成無障礙。
• 即時處理:工作人員應用程式會根據目前狀態,並根據新事件、個人化回應和動作做出即時決策,這需要存取、處理和處理即時資料。即時處理需要最新的資料 (資料延遲) 和互動式存取權 (存取延遲)。此類資料和存取延遲需要基礎資料平台來支援來自營運和分析商店的最新資料存取、低延遲存取 (點對應和查詢) 處理、高資料規模和高輸送量。
• 資料安全性、管治與存留權:工作人員和對話式 AI 可簡化應用程式 UI,允許任何人 (從消費者到員工到其他 AI 工作人員) 以對話方式使用說話或寫入的自然語言與應用程式互動。必須針對 Agenttic 應用程式儲存並建模的寶貴客戶和個人資料必須使用完全定義的存取與共用原則來保護並管理。越來越多的客戶必須遵循要求資料落地於其國家或地區的法規,特別是政府或與政府合作的客戶。

Salesforce Data 360 是針對未來解決這些資料趨勢而設計。Data 360 是雲端原生中繼資料驅動的資料平台,可統一整個企業中的隔離資料,讓組織儲存、建模和處理其資料,以啟用分析、AI、機器學習和代理程式應用程式。

此文件是企業結構設計師和 CTO 的重要指南。其中詳細說明 Data 360 的結構、功能、設計原則和使用個案。其會以準備方式介紹 Data 360 架構的基本概念,接著一系列深入探索其關鍵區分因素,例如與現有資料平台的互通性,包括多組織策略、安全性、管治與隱私權、即時啟用和資料清除空間。

Salesforce Data 360 是根據一組核心原則所設計,可使企業資料運作、信任且即時。

• 開放與互通性:針對多重雲端生態系統建立。與如 Snowflake、Databricks、BigQuery 和 Redshift 等資料平台聯合,無須重複,同時延伸 Customer 360 並保留現有的投資。
• 儲存空間計算分隔:獨立調整儲存和處理 (批次、串流和互動) 的規模。為大量高效能工作負載提供彈性與效率。
• 多型號儲存與處理:支援結構化和各種非結構化資料類型,例如文字、影像音訊和視訊。提供高效率的儲存空間、即時和批次處理、可擴充的索引、統一搜尋、查詢和分析。
• 中繼資料驅動的設計:應用程式是由中繼資料而非程式碼所定義。系統會將中繼資料視為一流的資產,讓統一的管治、彈性和深度整合至 Salesforce 平台。
• 即時混合式處理:支援低延遲查詢和立即決策,以及批次處理和分析工作量。
• 智慧型和已啟用資料:持續地深入瞭解、分析和推送至業務工作流程。使用最新的內容支援無程式碼、低程式碼、專業程式碼和 AI 驅動的自動化。
• 依設計的管治與隱私權:屬性、存取控制、落地、資料加密和合規性皆內建。Trust 和監管信任在每個層級都會加強。
• 一對多租戶:集中的 Data 360 組織可作為 Customer 360 的單一事實來源,順暢支援 Salesforce 客戶廣泛使用的多組織 salesforce 環境。

這些原則可確保 Data 360 讓資料開放、智慧化且可即時採取動作。

Salesforce Data 360 是以處理目前資料趨勢的設計原則為基礎的現代資料平台。其結構功能可確保企業資料可信任、統一且即時運作,並符合其指導原則。

• Cloud-Native Foundation:在 Hyperforce 上執行,部署在「超級級」 (如 AWS) 上,並使用固定的微型服務基礎結構。提供彈性調整、零 Trust 安全性、連續傳送和全域合規性。
• 以 Salesforce (核心) 中繼資料為導向:中繼資料的設計、建模和儲存為 Salesforce 中繼資料,可讓所有 Salesforce 應用程式立即使用。此類中繼資料會儲存在完全符合 ACID 的 RDBMS 中。確保監管、生命週期一致,以及與 Salesforce Lightning Platform 的深度整合。
• 湖畔儲存空間:建立在 Apache Iceberg 和 Parquet 上,結合資料湖規模與倉庫管理,支援結構描述演變、時間旅行和大量更新。Data 360 會儲存、模型和處理結構化和非結構化資料,並使用極大規模的儲存,並使用現代的開放標準,並針對批次和以事件為導向的工作量提供豐富的轉換和資料處理功能。
• 具有彈性的端對端資料銷售管道:涵蓋完整的生命週期,分類、準備、建模、統一、分析和啟用,以減少對分割點解決方案的依賴。支援批次、近乎即時,以及具有 270 個以上連接器和 MuleSoft 的串流。ELT 優先方法可透過下游轉換彈性實現快速的資料可用性。
• 企業資料與開放架構和聯合的互通性:使用雙向「零複製」聯合整合整個企業的單機資料,並使用 Snowflake、Databricks、BigQuery 和 Redshift 避免資料移轉或重複。
• 資料分類、建模和組織 360 會將資料組織為原始的摘要資料、已清除和儲存的資料,以及依照常見資訊結構描述所知的 SSOT (單一事實來源) 所建模的資料。這類 SSOT 物件會構成定義語意資料模型 (SDM) 和其他精密設計和應用程式特定模型的基礎。
• 使用開放式語意查詢 API 進行可擴充分析、推動 Tableau Next 並啟用應用程式特定分析的內建語意資料建模。
• 支援跨結構化、非結構化和圖形資料統一 Data 360 SQL 查詢的 高效能 SQL 查詢引擎。
• 低延遲資料存放區:具有毫秒回應時間之熱資料的金鑰值儲存空間。即時啟用個人化和以事件為導向的情境。即時收集並處理客戶參與資料。將身分、互動和對話統一至單一信任的 Customer 360 設定檔和內容圖表。
• 非結構化資料處理管道,可彈性和可擴充支援非結構化資料儲存、切分、內嵌產生 (向量化)、中繼資料提取 (擴大)、摘要、索引、Knowledge 提取、智慧文件處理、短期與長期 (對話) 記憶體建立等。
• 原生關鍵字、向量和混合索引,可精確且有效率地存取非結構化資料,例如快速與代理搜尋、RAG、Knowledge 解壓縮、代理性記憶衍生等。
• 啟用 AI/ML 和 Agenttic 應用程式的「設定檔」、「個人化」、「內容」服務。
• 在每個層級均有內建的管治與安全性,可追蹤歷程、資料遮蔽、資料落地和零 Trust 安全性,以確保合規性和 Trust。
• 彈性計算面板 原生、多重租戶的計算模型。執行散佈處理的 Spark 和 Hyper for SQL 工作量。在各種工作中彈性調整規模,並支援執行不受信任程式碼的隔離。

所有這些都會在 Salesforce 的雲端基礎 Hyperforce 上執行。Hyperforce 提供:

• 含加密、隔離與最低權限原則的 零 Trust 安全性。
• 透過多區域部署提供的 彈性。雖然 Salesforce Data 360 受益於 Hyperforce 的多區域彈性和平台層級錯誤容忍,但真正的企業級災害復原 (DR) 需要更廣泛的架構,類似於任何具有關鍵功能的資料平台:所有相依生態系統之間可重複播放的吸收管道、複製和中繼資料驅動的重新水化。
• 內建的監視、度量和追蹤功能可觀察 性。
• 自動調整規模與 FinOps 認知,以確保效率不受成本溢出。

Data 360 不會取代現有的企業投資。Data 360 會改為讓您已信任、管理且可採取行動的資料,在最重要的位置提供即時 AI 驅動的參與。簡而言之,Salesforce 會將所有企業資料 (包括外部資料) 轉換為 (Salesforce) 中繼資料驅動的物件,並啟用工作人員應用程式以供探索、決策和採取動作。

下圖說明 Data 360 參考結構:

讓我們思考一下在 Data 360 上分層的假設 Agentforce Loan Agent,以描述結構流程範例。假設「貸款工作人員」是面向客戶的工作人員,客戶 (消費者) 可在此申請貸款並取得立即貸款批准。

Data 360 會依排程執行這些步驟,準備資料供「貸款工作人員」使用。

• Data 360 會從 CRM 取得結構化「客戶帳戶」資料,並將其儲存在資料湖中。
• Data 360 會處理非結構化公司貸款與財務保單資料。
• Data 360 會從外部資料來源 (例如 Snowflake) 聯合個人資料。
• Data 360 會轉換和模型化已採取和聯合的資料。
• Data 360 會建立與維護設定檔資料圖表。

每次客戶申請貸款時,都會執行這些動作。

• 客戶登入「貸款工作人員」,這會以即時層級開始客戶工作階段。客戶的統一設定檔會提取至即時層。
• 客戶透過提供必要資訊完成貸款申請。
• 客戶會將財務文件 (例如稅報單、投資、銀行對帳單) 上載至 Data 360 以進行非結構化資料處理。
• 系統會切分和向量化上載的資料 (產生內嵌),並建立索引 (關鍵字和向量)。
• 接著,客戶填寫貸款申請文件並將其上載。Data 360 會即時提取貸款金額與持續期間。
• 「貸款工作人員」會使用 Data 360 查詢,並使用設定檔和其他預先建立索引進行混合式搜尋,來提取相關財務資料。
• 「貸款工作人員」會啟用具有貸款資料和其他財務設定檔資料的「批准工作人員」,以做出貸款批准決策。
• 「貸款工作人員」會透過決策回應客戶。
• 系統也會將客戶與貸款工作人員之間的整個互動儲存在 Data 360 中。

上述範例提供用來建立 Agent 應用程式 (例如 Loan Agent) 的 Data 360 結構元件概觀。在下一個區段中,我們會描述 Data 360 結構的圖層與元件。

在此區段中,我們將深入探討 Salesforce Data 360 的基礎建構區塊,從其強大的儲存模型開始,然後探索用於連線、提取和準備資料的機制。接著,我們會檢查結構化與非結構化資料的儲存、建模和處理方式,進而瞭解其調和、統一、提取和智慧啟用功能。

Salesforce Data 360 以分層但整合的儲存模型為基礎,此模型結合湖家與即時儲存的優勢。Lakehouse 圖層為大量歷程記錄與批次資料提供可調整且具成本效益的儲存空間,以啟用進階分析與機器學習使用個案。另一方面,即時儲存空間針對低延遲存取和高頻率更新最佳化,確保客戶互動、設定檔和參與訊號一律處於最新狀態。這些層級共同運作順暢,讓資料在歷程記錄與即時環境之間流暢移動,在統一的資料基礎中提供深度與立即性,以進行個人化、AI 和啟用。

Data 360 採用以 Iceberg/Parquet 為基礎的原生湖家結構,專為處理批次、串流和即時案例的大規模資料管理和處理而設計,支援結構化與非結構化資料,這對 AI 和分析應用程式至關重要。

在雲端式資料湖 (例如 Azure、AWS 或 GCP) 中,基本儲存單位是檔案,通常會組織成資料夾和階層。Lakehouse 透過導入更高層級的結構與語意抽象來增強此結構,以協助查詢和 AI/ML 處理等作業。主要抽象是具有中繼資料的表格,其中定義其結構和語意,並納入來自如 Iceberg 或 Delta Lake 等開放程式碼專案的元素,以及 Data 360 新增的其他語意層。

Lakehouse 中的抽象圖層:

1. Parquet 檔案摘要:在基礎上,儲存空間包含 Parquet 格式的資料湖檔案 (例如 AWS 中的 S3 或 Azure 中的 Blob)。來源表格的資料會儲存在多個分割區中,作為 Parquet 檔案,每個表格皆為這些檔案的集合。
2. Iceberg 表格摘要:表格會組織為資料夾,資料分割會在這些資料夾中儲存為 Parquet 檔案。對分割進行的修改會導致新的 Parquet 檔案成為快照。Iceberg 會管理每個表格的中繼資料檔案,詳細列出結構描述、分割規格和快照。
3. Salesforce Cloud 表格摘要:此層建立在 Iceberg 上,會新增如欄名稱與關係等語意中繼資料,以及如目標檔案大小與壓縮等組態。它會在各種平台 (例如 Snowflake 和 Databricks) 中摘要表格,藉此保護 Data 360 應用程式免受基本儲存平台的特定資訊。
4. 湖端存取庫:此文件庫提供 Salesforce Cloud 表格的存取權、處理資料和中繼資料,並為應用程式開發人員摘要基本的儲存機制。
5. 大型資料服務抽象:這包括處理架構 (例如 Hyper 用於查詢),以及處理任何雲端表格平台的 Spark。

為了支援即時分析和代理應用程式,Data 360 使用低延遲商店增強了 Lakehouse 大型資料儲存空間。Data 360 即時層會在記憶體中處理即時訊號和參與資料。不過,由於以記憶體為基礎的儲存容量受到限制,因此無法符合所有資料,且可能無法即時完成處理。Data 360 新增低延遲存放區 (LLS),以移除此類限制,以啟用可調整的即時處理。

低延遲存放區是 Lakehouse 上的 petabyte 級 NVMe (SSD) 儲存層。並非所有的資料都需要保存在低延遲存放區中。這是永久的快取。大多數資料最終都會進入 Lakehouse 以取得長期保留。即時層中的工作階段中資料可以清洗至低延遲存放區,以便後續快速存取。例如,在工作人員對話中,最近的訊息可在記憶體中處理;舊的訊息可在低延遲存放區中清洗。如果需要先前的交談,則可以從低延遲商店在幾毫秒內存取該交談。以 NVMe 為基礎的儲存空間允許大量資料以毫秒延遲儲存和存取。資料可能會移至 Lakehouse 雲端儲存空間,以獲得長期的持續性。此外,Lakehouse 中實時處理或擴充即時體驗所需的資料會從低延遲存放區中提取並保留。例如,「客戶設定檔內容」會從「Lakehouse」預先提取或帶入,並在低延遲存放區中快取。此外,任何在工作階段處理期間即時處理所需的湖家物件和其他物件也可在低延遲存放區中快取。

Data 360 低延遲存放區會在具有記憶體 (SSD) Lakehouse 儲存層的真儲存階層上啟用「即時器」圖層,並在這些圖層之間順暢移轉資料。我們稍後會在此文件中討論 Data 360 Real Time 圖層。

Salesforce Data 360 是針對標準化、協調和啟用所有客戶資料 (結構化與非結構化) 的設計,遵循嚴格的生命週期,將原始輸入轉換為統一的目前資料模型。

生命週期著重於取得各種外部資料輸入,並將其建構為永久的已建模物件。模型化資料可協調為 Customer 360 統一設定檔。

原始取用資料與初始轉換

流程會從原始資料從來源系統 (CRM、行銷、檔案等) 進行原始資料。這包括完整的資料載入和持續變更事件 (delta),這些事件會受管理並與持久資料合併以維持目前狀態。

內嵌轉換 (例如,修整、正規化、串連) 會立即套用於取用期間,以確保初步的資料品質和清理。

資料湖物件 (DLO):持續層

DLO (資料湖物件) 形成 Data 360 中的核心永久性儲存層。它們會儲存乾淨且轉換的資料,並作為所有客戶資訊的組織、長期存放庫。

系統會將 進階資料轉換 (例如聯結、彙總、已計算洞察) 套用至來源 DLO,以產生精密設計的新衍生 DLO。

透過 Zero Copy Data Federation 提供的資料會直接表示為 DLO。

非結構化資料與中繼資料組織

針對非結構化內容 (例如文字、媒體、文件),Data 360 會透過在名為「非結構化資料湖物件 (UDLO)」的特定 DLO 中,將其結構化中繼資料解壓縮並保留,以納入資料。

這些專用 DLO 會作為目錄表格運作,提供對應至非結構化資產的實體位置和內容。此功能可讓結構設計師將非結構化資料的中繼資料與其餘結構化客戶資料無縫建立關聯,進而啟用統一的查詢和調和。

資料模型物件 (DMO):協調層級

DMO (資料模型物件) 代表最終、協調和結構化資料層。

它們是透過將 DLO 欄位 (來自來源、衍生和非結構化中繼資料 DLO) 對應至標準 Customer 360 資料模型來建立。

DMO 圖層可作為所有客戶資料的單一事實來源,在整個生態系統中啟用統一設定檔建立、區隔和啟用。

資料空間是組織 Data 360 內所有資料和中繼資料 (包括所有 DLO (結構化與非結構化) 和 DMO) 的基礎邏輯容器。資料空間提供安全且隔離的資料處理與建模環境。

資料空間會作為邏輯與管治界限,透過分隔不同實體 (例如業務單位、區域或品牌) 的資料來啟用內部多租用,同時維持企業範圍的可視性、歷程和合規性,作為定義粗體粒紋存取控制的基礎。

資料空間內的隔離會在平台的多個層級強制執行:

• 資料層級隔離:每個 DLO/DMO 都屬於單一資料空間,以確保查詢、轉換和物件對應不能跨越資料空間的邊界,除非有明確授權。
• 存取控制整合:權限集原生繫結至資料空間,可控制讀取、寫入和管理作業。這可確保只有經過授權的使用者和服務才能存取資料空間內的物件、洞察和啟用。
• 管治與稽核:資料空間內的所有作業都會使用企業級稽核追蹤來記錄,以啟用合規性、管理和法規報告的可追蹤性。

透過「權限集」管理存取權與權限,以確保細微可視性、控制更新,以及防止跨網域資料洩漏。透過將資料空間邊界與 Data 360 的安全性與管治結構整合,結構設計師可以自信地實作集中化與去中心化管治策略,同時在多個雲端與業務網域之間保持一致性。

Data 360 運算模組提供統一的層級來管理和執行所有大型資料工作負載,簡化基礎結構的複雜性。其核心元件是資料處理控制項 (DPC)。

DPC 是全方位、多工作量資料處理協調流程服務,可在各種雲端運算環境中提供「工作方式服務」(JaS) 功能。其會抽出基礎結構複雜性,並統一 Spark (在 EC2 上為 EMR,在 EKS 上為 EMR) 和 Kubernetes Resource Controller (KRC) 工作負載等架構的工作執行。透過作為集中控制平面門戶,DPC 可協調、排程和監視跨多個資料平面的工作,以確保可靠性、可擴充性、成本效率和一致的開發人員體驗。

DPC 的需求源自直接與如 EMR 等原生叢集管理系統互動的限制。

基礎結構與雲端抽象

雖然 EMR 為叢集、工作和步驟提供 API,但仍會為用戶端小組負擔重要基礎結構管理工作,例如佈建、調整規模、效能調整和成本最佳化。DPC 透過針對工作提交提供簡化的平台層級 API,來解決此問題。它支援自動失敗處理、重試和動態負載平衡。透過以點和重點為基礎的節點提供成本效率。透過 TLS、PKI、IAM 隔離和自動修補功能提供強大的安全性。管理 Spark 和 EMR 執行階段版本升級,以提供效能改善、安全性修補程式和功能增強功能。

此外,DPC 提供一個統一的雲端無效介面,用於提交和管理資料工作,從���礎雲端基底 (AWS, future 提供者) 的複雜性和專屬 API 中抽取。這可確保用戶小組只會與常見的 Data 360 API 型工作提交介面互動,此工作介面會移除基本資源管理員 (例如 Kubernetes 和 YARN) 的複雜性。這可讓用戶小組透過簡單且統一的 API 提交 Spark 工作,而無須直接管理 pods、節點集區或 Spark 叢集組態。

手動調整 Spark 參數需要專業技能,而不正確的組態可能會導致工作執行速度變慢。DPC 小組集中此專業知識,提供最佳化組態以避免常見的效能問題。此專門的小組持續整合開放程式碼社群的 Knowledge,以確保在控制器管理的所有工作量之間提供最佳效能。

DPC 不僅限於 Spark;它支援廣泛的工作量陣列。這些包括:

• 即時處理工作量
• 「資料動作」功能的事件傳送
• 管理 Milvus (非結構化資料索引的向量資料庫)
• 低延遲儲存基礎結構

DPC 也利用 Kubernetes Resource Controller (KRC) 架構,其支援如 Trino for Query、Event Delivery for Data Actions、Data Extraction Jobs for Connectors 和即時處理等工作量。針對所有 KRC 工作負載,DPC 提供中心的「工作即服務」功能,在高層級工作抽象中處理運算佈建、部署和管理。

JaaS 優點與結構

DPC 提供的「工作方式服務」模型可確保符合成本效益且有彈性的工作處理管道。

使用者提供簡單的叢集規格,專注於所需的 CPU、記憶體、儲存空間、例項計數,以及用於叢集比對的「最小/最大」叢集計數和標記。接著,DPC 會自動管理抽象的基礎結構詳細資料,包括選取最佳 VM SKU、管理「例項車隊」,以及決定「核心」與「核心」比率。工作節點和管理隨選與。根據輸入找出例項。它也會處理 EMR 和元件版本管理和升級,而不會發生停機。

重要的是,DPC 本身支援多租用,其設計目的為瞭解並強制執行 Data 360 租用範圍邊界和資源分隔。其也透過強制執行 Salesforce 認證的電腦影像、管理服務特定 IAM 角色,以及保證傳輸和靜態加密來確保安全性和合規性。針對路由和容量控制,會使用「叢集標記」管理工作對叢集比對,以容量為基礎的路由會使用工作同時設定上限,以有效控制資源利用率。

Cloud Agnostic Client Experience 是核心優點,因為基本雲端環境的複雜性會對用戶端服務隱藏,讓他們能夠專注於純粹的業務邏輯。這可達成「雲端提供者抽象」的目標。最後,DPC 可啟用輕鬆的「使用狀況」和「成本追蹤」,允許依服務區隔叢集利用率和成本,以進行準確的會計。整體而言,DPC 採用可插入的結構,可讓新執行引擎 (例如 Flink、Ray) 和雲端基底 (GKE/Dataproc) 順暢整合,而無須向使用者顯示基礎結構詳細資料。此設計會將控制平面與執行層分離,以確保無論後端為何皆有一致的 API 與作業體驗。

Data 360 可精簡及豐富原始資料,藉此彌補原始資訊與可運作業務耗用之間的差距。其透過準備複雜的資料以進行精密的啟用和分析,來補充資料物件生命週期。Data 360 支援各種處理類型,包括批次和串流資料轉換、批次和串流計算洞察、非結構化資料處理和身分解析。若要有效率地啟用這些多樣化的作業,特別是在近乎即時且跨大量資料集的作業中,需要精密機制才能有效處理資料變更。

若要達成高效率且近乎即時的資料處理,特別是使用 TB 大小的表格和數百萬個潛在更新的資料,Data 360 需要突破。需要一種方法,才能在資料變更時精確通知系統,然後有效識別哪些資料已變更,以便只處理相關更新,且僅在更新時處理。此挑戰導致兩種互補的創新:「儲存原生變更事件」(SNCE) 以在變更時通知,以及「變更資料摘要」(CDF) 以識別變更的項目。

儲存原生變更事件 (SNCE)

SNCE 已將 Data 360 徹底改變為反應性且增量資料平台。此轉換涉及使用標準化事件格式和高流量訊息傳送系統,從主動輪詢資料湖移至被動監視原子認可事件。

每個對 Iceberg 表格的成功寫入作業 (INSERT、UPDATE、DELETE) 都會在目錄中原子交換表格目前中繼資料檔案指標。基礎物件儲存層 (例如 S3) 設定為每當新中繼資料快照寫入至表格目錄時,會發出原生通知事件 (例如 S3 事件)。

SNCE 程式庫提供用來取用這些事件的標準化方法,並可根據要求以快照中繼資料來增強這些事件。

這可讓下游資料銷售管道 (例如串流已計算洞察、身分解析和區隔) 僅在資料變更時訂閱並採取動作,進而避免成本高昂的完整表格掃描,大幅提升效率。

變更資料摘要 (CDF)

以 SNCE 為基礎,「變更資料摘要」(CDF) 提供耗用變更及逐步處理變更的簡化機制。

CDF 利用 Iceberg 快照有效地產生變更串流。重要的是,Data 360 的最佳化 Iceberg 寫入器會將變更計算並維持為寫入作業本身的一部分,讓 CDF 產生效率高,並將額外的額外負擔降到最低。這可讓處理工作 (例如串流轉換或串流已計算洞察) 僅選擇性地處理已變更的記錄,避免耗費快照的差異計算。

此增量策略為大型資料集提供數個優點,包括節省成本、減少延遲和改善效率。它會啟用如串流轉換和增量身分解析等功能,進而導致更快的洞察、更可預測的系統負載、增強的效能和更低的營運費用。

Data 360 透過原生對 Salesforce 產品的支援,提供強大取用功能,確保資料流程順暢。針對外部來源,其透過超過 270 個連接器、API、SDK 和 MuleSoft 提供廣泛的連線能力。此外,Data 360 具備零複製聯合功能,允許 BI 和分析,而不需要資料重複。

Data 360 連接器架構 (DCF) 是大多數 Data 360 連線的基礎。其可透過統一結構來啟用採取、聯合和輸出。DCF 會定義建立和管理連接器的標準,從設定和管理的 UI 到中繼資料持續性、資料提取和傳送至 Lakehouse 或透過對外部來源的即時查詢。它也支援私人連線選項 (例如私人連結、VPN 和安全隧道),以確保在連線至客戶或合作夥伴環境時的企業級資料安全性和合規性。透過提供所有連接器的一致方法,DCF 可透過確保可擴充性、可靠性和安全整合,讓 Data 360 順暢連線至更廣泛的生態系統。

Data 360 可提供對資料來源的廣泛生態系統強大連線,同時支援原生 Salesforce 產品和許多外部系統。此廣泛的連線對於統一隔離的企業資料,以及啟用 AI/ML 和 Agenttic 應用程式而言至關重要。

Data 360 原生或透過 MuleSoft、API 和 SDK 提供超過 270 個連接器,以支援其端對端資料銷售管道功能,包括批次、串流或即時提取。這些連接器可依其整合的來源系統類型廣泛分類。

Salesforce 原生連接器

這些連接器可確保 Salesforce 產品的原生資料流流順暢。

範例包括 Salesforce CRM、Data Cloud One、Marketing Cloud Engagement、Marketing Cloud Account Engagement 和 B2C Commerce 的連接器。

外部應用程式與 SaaS

各種業務應用程式和雲端服務的連接器允許從外部軟體平台提取資料。

範例包括 Adobe Marketo Engage、Microsoft Dynamics 365、Mailchimp 和 Airtable。

資料庫與資料倉庫

Data 360 可連線至各種關聯式和雲端式資料儲存平台。

範例包括 Amazon Redshift、Amazon DynamoDB、Amazon RDS (MySQL、PostgreSQL、Oracle)、Google BigQuery 和 Microsoft SQL Server。

雲端物件儲存和檔案系統

這些連接器會與結構化與非結構化資料的超大規模儲存解決方案整合。

範例包括 Amazon S3、Google Cloud Storage (GCS) 和 Azure Blob Storage。

串流和傳訊服務

處理連續即時資料串流的連接器對於以事件為導向的案例和即時處理而言至關重要。

範例為 Amazon Kinesis 連接器。

整合平台

MuleSoft Anypoint 連接器透過 Anypoint Exchange 將 Data 360 與更廣泛的應用程式和資料庫整合,藉此擴充 Data 360 的接觸範圍。

非結構化資料與雲端物件儲存連接器

這些連接器對於將非結構化資料 (缺少預先定義的模型資料) 採取和參照至關重要,以增強生成式 AI 功能。

所有這些連接器皆以 Data 360 連接器架構為基礎,提供一致的體驗。

資料轉換是 Data 360 中的基礎結構元件,其設計目的為清除、增強原始資料,並將其塑造為符合 Customer 360 資料模型的正規化且可運作的資料資產。此流程對於資料調和、品質改善,以及確保資料已準備好供下游使用個案 (例如設定檔統一、區隔和啟用) 使用而言至關重要。轉換會利用來源資料湖物件 (DLO) 和資料模型物件 (DMO) 作為輸入,分別為新的 DLO 或 DMO 產生結果。

Data 360 提供兩種主要轉換範例以滿足不同的資料速度需求:批次資料轉換和串流資料轉換。

批次資料轉換

「批次資料轉換」是針對根據定義的排程或隨選觸發進行大量處理而設計。此引擎已針對處理複雜且具有資源密集性的重新結構作業最佳化。

「批次轉換」流程使用視覺化低程式碼管道畫布進行設定,讓使用者定義多階段轉換���輯。此引擎唯一支援對於標準資料模型對齊的重要複雜重組作業:資料結構與正規化。這包括樞紐 (將反正規化記錄拆分為多個正規化記錄) 和壓平 (將階層資料 (例如 JSON) 重新結構化為結構化表格)。系統的執行模式支援完整同步化 (處理所有記錄) 和高效率的增量處理模式。增量模式僅處理自上次成功執行後變更的記錄,以大幅減少處理時間和資源消耗。批次轉換適用於不需要即時更新的工作,例如定期彙總和複雜資料重新結構。

串流資料轉換

串流資料轉換會在資料流入系統時,以近乎即時的方式持續且以增量方式處理資料,使其在低延遲使用個案中至關重要。

主要介面是 SQL 優先方法,其中的轉換會定義為 SQL SELECT 查詢,會根據記錄變更的傳入串流持續執行。此引擎支援核心轉換功能,包括資料清除和標準化 (例如,驗證 PII 和標準化資料格式),以及資料增強和合併 (使用聯結和聯結)。重要的是,其支援串流對應 JOIN,以針對靜態或緩慢變化的參考資料啟用即時資料增強和對應,以確保立即設定檔更新。為了最佳化服務成本,結構使用高密度 (HD) 工作設計,將單一租戶的多個串流轉換定義封裝到單一基礎運算工作中,最大化資源利用率。串流轉換對於如事件監視、立即個人化和即時設定檔更新等使用個案而言至關重要。

Data 360 透過支援「零複製」聯邦與資料共用來徹底改變資料管理,因此無須移動或重複資料。此功能可讓使用者順暢直接從各種外部來源存取資料,並與外部環境共用資料,大幅減少複雜性、降低儲存成本,並確保所有決策皆以最新的、最可靠的資訊為基礎。

Data 360 支援與外部資料倉庫 (Snowflake、Redshift)、湖家 (Google BigQuery、Databricks、Azure Fabric)、SQL 資料庫和許多其他來源的零複製聯合。其抽象層可讓您直接查詢外部資料,而無須重複,進而減少提取時間、儲存成本,並確保最新資訊。

Data 360 透過提供抽象化 Salesforce 和外部物件的統一中繼資料層,來簡化對外部和聯合資料的存取。這可讓整個 Salesforce 平台及其應用程式順暢地使用此資料。

Data 360 支援檔案和以查詢為基礎的聯合,以及即時查詢和存取加速,如圖所示。

標籤 (1) 和 (2) 說明 Data 360 的查詢 (包括即時查詢推送),以及從外部資料湖/倉庫/資料來源存取資料的檔案型同盟;標籤 (3) 醒目提示從外部資料湖/資料來源加速聯合存取。

查詢聯合

Data 360 的聯合功能核心在於其查詢聯合層,可管理存取外部資料和執行智慧查詢推送的複雜流程 (如標籤 1 所示)。Data 360 使用 JDBC 通訊協定連線至來源,並從來源提取資料,並增強額外的邏輯以提升效率。「查詢聯合層」負責瞭解和翻譯不同的 SQL 方言,並找出要推送至外部系統的查詢最佳部分,以有效處理結果,並執行任何必要的進一步處理以衍生最終洞察。

快取 (查詢加速)

針對增強型公用程式,Data 360 為其聯合功能提供選用的加速功能。

啟用「加速」時,Data 360 會快取聯合資料,以達到更快的存取和更低的成本,因為它會避免重複直接存取外部來源。此快取會視為加速層,並會逐步更新以快速反映外部來源資料中的任何變更,以確保加速檢視保持近乎即時。

檔案聯合

Data 360 支援檔案型聯合 (以標籤 2 說明),用於從外部資料湖和來源存取資料。此零複製功能的技術基礎依賴標準化:基礎資料必須是 Apache Parquet 檔案格式,並使用 Apache Iceberg 表格格式。Data 360 可以聯合為公開「Iceberg REST 目錄」(IRC) 的任何來源,以取得中繼資料和儲存空間存取權,以確保流暢且受管理地存取位於平台外的檔案。

透過檔案型聯合,Data 360 計算會處理所有資料處理,因為其可直接存取基本儲存空間。這可消除查詢推送功能表和管理各種 SQL 方言的需求,這在查詢型聯合中通常是必要的。

除此之外,「零複製」功能也擴充至非結構化資料來源,例如超大規模儲存解決方案 (S3/GCS/Azure 儲存空間)、Slack 和 Google Drive,可由 Data 360 的非結構化處理管道存取。

Data 360 可協助與外部資料湖和倉庫共用其管理的以查詢為基礎與以檔案為基礎資料 (原始圖例內容中的標籤 4 和 5 說明)。

以查詢為基礎的共用

針對以查詢為基礎的資料共用,Data 360 會使用外部引擎和應用程式來公開 JDBC 驅動程式,以安全地存取資料。此機制允許外部系統直接針對 Data 360 內的資料連線、驗證和執行即時查詢。

檔案共用 (資料共用與 DaaS)

檔案式共用的主要機制包含兩個概念:資料共用和資料共用目標,其利用 DaaS (資料作為服務) API。

• 細微控制:資料共用概念可讓客戶精確定義要在外部共用的物件 (DLO、DMO、CIO 等),以防止非預期的資料曝光。
• 安全目標:它也會控制資料共用目標,確保資料僅可供明確授權的外部環境、帳戶或合作夥伴組織使用 (例如與特定 Redshift 或 Databricks 例項共用)。

DaaS API 提供安全且受管理的介面,讓外部引擎取用資料。其會授與基本中繼資料和基本表格儲存空間的存取權,同時保留所有 Data 360 語意。這可確保外部引擎以安全的方式,在一致且有意義的內容中存取資料。

許多安全性敏感的客戶,特別是大型企業、受監管產業和公共部門組織,會限制對其資料湖的所有網際網路存取權,作為其安全性狀況的一部分。此原則對於合規性和降低風險而言至關重要,但也會防止 Salesforce Data 360 和 Agentforce 透過公用網際網路連線至這些環境。

大多數資料湖都會部署在超大規模環境中,例如 AWS、Azure 或 Google Cloud。由於 Data 360 本身在 AWS 上執行,因此存取在不同雲端提供者上主控的客戶資料湖需要跨雲端網路連線。若沒有略過公用網際網路的安全私人連線選項,客戶通常無法或不願意為依賴這些資料湖的使用個案採用 Data 360 或 Agentforce。

為了解決此問題,Data 360 支援跨雲端與客戶管理資料來源的專用網路層級連線。在 AWS 上,此功能透過 AWS PrivateLink 啟用,可讓 Data 360 直接連線至客戶提供的端點,無論是在其自己的帳戶內或在第三方資料湖環境 (例如 Snowflake) 中,而無須周遊公用網際網路。

此結構會使用私人 IP 位址和非可建立路線網路路徑,確保所有流量完全保留在 AWS 架構上,從而滿足嚴格的安全性和合規性需求,同時讓客戶資料的存取流暢。

針對具有多雲端結構的客戶,Data 360 透過跨雲端互連支援,將私人連線延伸至 AWS 之外。這可啟用從 Data 360 到 Azure 或 Google Cloud 中所主控資料湖和服務的安全、僅限後端網路路徑,並保留與 AWS PrivateLink 相同的原則—私人 IP 位址、非公用路由和零網際網路曝光。

客戶可以選擇兩種部署模型:

• 客戶管理的互連:將現有私人電路 (例如 Azure ExpressRoute、Google Cloud Interconnect 或 Equinix Fabric) 直接與 Data 360 的 VPC 整合。

• Salesforce 受管理的互連:使用完全受管理的整合式連線,其中 Salesforce 會佈建和作業跨雲端連結,以在目標雲端中公開私人端點。

在這兩個模型中,體驗一致 360 服務會在超級規模之間連線至外部資料來源,如同在本機一樣,無須周遊公用網際網路即可啟用安全的取用、啟用和查詢。

針對企業結構設計師,強大的資料管理不只是合規性核取方塊,而是建立可信任、可調整且可運作客戶智慧的基礎支柱。Salesforce Data 360 以全方位的管治架構結構設計,可確保在整個資料生命週期中達到資料品質、安全性和法規要求。

Data 360 可作為集中式管治中心運作,確保完整且控制的管理所有資料,從原始摘要到已啟用的洞察。

雖然 dataspace 提供粗略的粒紋式存取控制,可決定資料空間內所有物件的存取權,但以 ABAC 為基礎的原則可提供資料空間內個別物件、欄位和列的細微粒紋式存取控制。Data 360 已採用「以屬性為基礎的存取控制」(ABAC) 作為微調存取控制的核心授權模型。與傳統「以角色為基礎的存取控制」(RBAC) 相比,此策略選擇提供卓越的彈性與延展性,這對於具有大量資料和各種存取需求的動態、複雜企業環境而言特別重要。ABAC 允許根據使用者的屬性 (例如部門、角色、位置)、資料 (例如 PII、敏感度、資料空間) 和環境 (例如當天時間) 進行存取決策,而不只是預先定義的角色。這可啟用高度細微且內容相關的存取原則,以在資料和使用者屬性變更時進行調整。

• CEDAR 原則語言 360 的 ABAC 實作核心是使用 CEDAR 原則語言。此用途建立的正式原則語言提供定義複雜授權規則的精確且可驗證方法,確保原則是明確的,且可在規模上一致評估。

Data 360 中的監管系統遵循標準且強大的 ABAC 結構:

• 標記、分類和原則編寫 (原則資訊點 - PIP):
  • Data 360 提供自動標記和分類機制,利用 LLM (大型語言模型) 和 ML (機器學習) 來識別結構化資料 (例如連絡人表格) 和非結構化資料 (例如 Google Drive) 中的敏感資料種類 (例如 PII.Email、PII.Phone、PII.Name) 和其他用途建立的分類 (PHI、FinancialData)。
  • 重要的是,「標記傳播」會沿著「資料歷程」(DLO -> DLO -> DMO) 進行,以確保分類會自動遵循資料轉換和衍生,從原始資料到協調的 DMO 圖層,以及透過從程序定義建立的衍生資料。
  • 最後,原則編寫窗格提供簡單的體驗,可利用資料和使用者屬性為組織定義動態存取規則。
  • 此豐富的中繼資料 (包括標記、分類、原則和歷程) 會摘要至「原則資訊點」(PIP)。
• 授權服務 (原則執行點 - PEP):
  • 「授權服務」會作為「保單強制執行點」(PEP)。其會從各種耗用層 (混合結構化/非結構化查詢、GenAI RAG 取得器和提示、CRM 增強) 攔截所有資料存取要求,並諮詢「原則決策點」以判斷是否允許存取。
• 原則評估引擎 (原則決策點 - PDP):
  • 此引擎會作為「保單決策點」(PDP)。它會從 PEP 取得存取要求內容,以及來自 PIP 的原則定義 (在 CEDAR 中) 和屬性,以做出權威權限的存取決策。

• 細微安全性原則:在 CEDAR 中定義的原則會強制執行各種安全性層級,包括:
  • 物件級安全性:根據與這些物件相關聯的標記,控制整個 DLO 或 DMO 的存取權。
  • 欄位級安全性:根據標記限制物件內特定敏感欄位的存取權。
  • 列層級安全性:篩選特定物件的資料,以根據使用者屬性僅顯示相關資料列。
  • 動態資料遮蔽:在存取點動態遮蔽特定資料 (根據標記),而不變更基本資料。這可確保敏感資訊受到保護,同時允許廣泛的公用程式。這適用於結構化資料中的遮蔽欄位,以及非結構化資料中的內容。
• 一致強制執行:整個 ABAC 架構都能確保在所有 Data 360 耗用模式之間一致強制執行原則,無論是直接資料查詢、針對生成式 AI 應用程式 (RAG),或是透過相關清單增強 Salesforce CRM 體驗,例如。
• 與 Salesforce Platform 的深度整合 360 的監管功能會直接在 Salesforce 核心平台中定義與管理。此整合可讓管理員使用熟悉的 Salesforce 工具來管理存取原則、使用者身分和屬性管理,以確保整個 Salesforce 生態系統的統一與一致的管治層。

透過使用 CEDAR 原則建立此複雜的 ABAC 架構,Data 360 為結構設計師提供無可比擬的控制層級和彈性,確保客戶資料不僅可運作,而且在整個企業中也安全、合規且值得信賴。

在各個產業中,組織正在加強對端對端資料安全性的重視,以確保防止資料洩漏、未經授權的存取、篡改或破壞。大多數資料平台 (包括今天的 Data 360) 使用廠商管理的加密金鑰來提供靜態加密。然而,企業 (尤其是受監管產業的企業) 越來越強制要求客戶為靜態與傳輸中的資料提供受管理加密功能。

此模型可讓公司控制自己的加密金鑰,以確保即使在平台層級缺口或未經授權存取的極少見情況下,資料仍會受到加密保護。若沒有客戶的專屬金鑰,則沒有任何實體 (包括平台提供者) 可以解密或重建資料,進而維持完全機密性和控制。

Data 360 支援在整個資料提取、處理、索引和查詢機制中順暢地儲存和管理結構化 (表格)、半結構化 (JSON) 和非結構化資料。Data 360 支援文字以外的各種非結構化資料類型,包括音訊、視訊和影像,擴大資料處理和分析的範圍。下圖說明基礎的兩個側面 (取用與提取)。

Data 360 會透過將資料儲存在資料欄中作為文字,或儲存在較大資料集的檔案中來管理非結構化資料。它支援非結構化內容的資料聯合,這允許整合和管理來自多個來源的資料。

接著會準備資料並切分、產生內嵌,並處理用於關鍵字索引和向量索引。Data 360 主控多個立即可用的可插入模型,用於分割和內嵌產生。Data 360 支援自動且可設定的音訊和視訊內容文字記錄,以供後續處理和編製索引。搜尋服務用於關鍵字索引。針對向量索引,Data 360 同時支援原生索引 (含 Hyper),並利用如開放原始碼 Milvus 等向量資料庫。Data 360 也會與 Salesforce 搜尋平台整合,以支援對非結構化資料的關鍵字索引。Data 360 中此類整合的多重模式索引可搜尋任何非結構化資料,如同在文件中稍後的「代理企業搜尋」一節中所討論。

Data 360 會提供要搜尋的 API 以取得。我們的超級型統一查詢可協助跨結構化、關鍵字索引和向量索引的集合查詢,維持嚴格的可視性和權限,進而增強 RAG 和搜尋。

Data 360 的非結構化資料索引管道設計為模組化、可擴充的結構,包含五個核心階段:

1. 剖析
2. 預先處理
3. 切分
4. 後續處理
5. 內嵌

所有階段也支援以 LLM 為基礎的處理,可讓客戶提出自訂提示。預先處理與後續處理階段皆可包含多個連續步驟,讓複雜轉換有彈性的撰寫方式。每個階段皆完全以中繼資料為導向,無須變更程式碼即可順暢設定與擴充。

預先處理的範例包括作業,例如消除雜訊、語言正規化和影像瞭解 (光學字元辨識和標題),而後續處理階段可能包括中繼資料的增強、語意分組或進階技術,例如 Raptor 切分。

管道完全支援 Data 360 Code Extension,可讓客戶和內部小組在任何階段插入自訂邏輯。程式碼擴充元件是輕量型 Python 函數,其生命週期 (執行、調整規模和失敗處理) 由 Data 360 完全管理。此方法可確保可快速導入創新和網域特定處理,同時維持整個平台的營運一致性和管治。

內容索引

針對使用非結構化處理來設定 RAG,有兩個關鍵因素:

1. 快速迭代:能夠使用範例測試查詢快速驗證。
2. 角色特定的內容:為耗用角色量身打造內容的容量。

「內容索引」是使用者易用的工具,專為解決這兩個方面而設計。此互動式 UI 由執行前述全部五個階段的即時 (RT) 管道提供技術支援。當需要時,管道會針對如內嵌產生和光學字元辨識 (OCR) 等工作使用 GPU。此外,其可讓客戶在部署組態以進行全方位內容處理之前,使用工作人員快速測試 RAG 管道。

文件 AI

Data 360 文件 AI 可讓您從如發票、履歷、實驗室報告和購買訂單等文件中讀取及匯入非結構化或半結構化資料。此功能支援臨時互動式處理以及大量批次處理。這是可為客戶啟用業務流程自動化的關鍵功能。這是由人工智慧 (包括 LLM 和 ML 模型) 所支援。

企業擁有大量的 Knowledge 散佈在不同系統中,例如維基百科、檔案共用、內容管理系統、內部資料庫等。此分割使得員工 (尤其是服務工作人員和銷售代表) 和客戶難以快速且有效地找到相關資訊。主要問題包括:缺少所有 Knowledge 來源的單一統一搜尋體驗;不同來源的內容呈現與呈現不一致;缺乏跨系統散佈敏感資訊的存取管理;以及在核心業務工作流程中難以利用權威 Knowledge 來源 (例如,將相關文章附加至個案)。

Enterprise Knowledge 代表從更廣泛的企業資料集區中手動或自動精密設計的內容。手動精密設計涉及刻意的動作,例如建立 Salesforce Knowledge 文章,或在外部系統中開發 Knowledge,此知識便會接著被提取。我們預期自動化精密設計會利用流程 (例如 Salesforce 工作人員和轉換),這些流程會執行於已提取的資料上,以產生精簡且精密設計的圖層,進而可能混合結構化和非結構化內容。無論是手動或自動精密設計、在 Salesforce 內部或外部精密設計,此結果都是與原始資料不同的加值內容。

Enterprise Knowledge Hub 解決方案利用 Data 360 功能達成以下目標:

• 取用與儲存空間:「CRM 連接器」正在取用 Salesforce Knowledge 文章,而資料連接器架構 (DCF) 非結構化連接器會從外部來源取用原始內容和中繼資料。內容會在 SFDrive 上對應至內容的來源特定非結構化資料湖物件 (UDLO) 中 (若為零複本,則為來源)。
• 調和與結構:調和管道會處理 UDLO 和檔案資料,執行清除、正規化、增強 (NLP 等)、PII 遮蔽和轉換為已協調的中間格式,儲存在 SF Drive 和對應至其的已協調 UDLO (HUDLO)。
• 索引:「非結構化銷售管道」(UDS) 會在協調的內容上觸發,且會為每個 HUDMO 設定搜尋索引。
• 消耗:耗用應用程式包括搜尋、提取、呈現和連結至如「個案」等業務物件。系統會收集耗用應用程式的參與以提供用量分析 (例如點擊、檢閱等)。

Data 360 中的已計算洞察 (CI) 可讓客戶從其資料定義和產生彙總度量。接著,這些度量會用於及時的客戶參與、分析、區隔和啟用。CIs 計算的彙總資料會寫入 Lakehouse,並以已計算洞察物件 (CIO) 表示。

已計算洞察有兩種主要類型:

• 批次已計算洞察:針對複雜的大量資料彙總而設計,可定期計算度量 (例如每日或每週)。
• 串流洞察:提供從即時事件資料產生度量和動作的能力,以便立即啟用低延遲的客戶參與。

已計算洞察是在資料模型物件 (DMO) 上定義,也可以在其他已計算洞察物件上定義。已計算洞察服務可管理批次和串流工作的協調流程。

批次與串流洞察計算都使用 Spark。主要差異在於串流洞察使用「Spark 結構化串流」,而批次 CI 使用定期排程的批次 Spark 工作執行。為了提高成本效率,已計算洞察服務會根據如來源資料物件的相依性和重疊等因素,將 CIs 組合在相同的批次 CI 工作或串流 CI 工作中進行計算。

SNCE 和 CDF 在「串流洞察」計算中扮演重要角色。

身分解析負責將多個來源的不同資料轉換為單一的全方位「統一設定檔」。

務必瞭解統一設定檔並非「金級記錄」,且身分解析不會在統一設定檔時挑選成交值或覆寫任何現有資料。「統一設定檔」可作為一組金鑰,透過識別與相同實體相關的所有相符記錄,在一個資料來源內或跨多個來源,來解除鎖定來源資料。透過此資訊,您可以選取適合用於指定業務使用個案的來源系統資料。

身分解析可合併各種記錄類型,包括「個人」、「帳戶」和「家庭」。也可以用來將商機與現有帳戶進行比對。統一流程對於達成完整的 Customer 360 檢視,並在 B2C 和 B2B 案例中促進個人化即時參與至關重要。

身分解析銷售管道以可高度調整的雲端原生架構為基礎,專為持續處理大量資料而設計。此流程包含三個關鍵階段,依賴強大的搜尋索引來管理比對流程:

• 比對 (候選項目選取項目):比對流程的目標是搜尋可能屬於相同實體的記錄。系統會根據可自訂的規則集分析記錄,每個規則都包含一組條件,定義要在哪個嚴格層級比對的資料。為了有效地從資料存放區中提取潛在相符項目,系統會產生索引,以使用兩種技術尋找可能相符的記錄:
  • 封鎖金鑰:封鎖索引鍵是從記錄的資料和比對規則 (例如名稱的前幾個字母、正規化電話號碼等) 產生的值,可將可能類似的記錄分組在一起。每個記錄有多個封鎖索引鍵,這些索引鍵會編製索引並儲存為反向索引,以確保系統僅對小型記錄群組執行詳細比較,而非整個資料集。
  • 本地敏感雜湊 (LSH):針對具有模糊比對的比對規則,會根據已訓練模型中的內嵌產生雜湊。
• 深度比對:在候選項目選取步驟建立較小的潛在符合項目群組後,系統會開始更詳細的比較。在此階段中,AI 模型和進階演算法會分析每個記錄配對,以計算機率比對分數。此分數會透過智慧地比較經常包含拼字錯誤、變化或格式差異的欄位,來量化兩筆記錄參照相同實體的可能性。
• 叢集與統一:從候選項目識別相符記錄後,這些記錄會分組為叢集。此流程重要包括解析傳動比對。例如,如果記錄 A 符合記錄 B,而記錄 B 符合記錄 C,則即使 A 與 C 從未直接比較,這三個記錄皆會連結至相同的叢集。這些完整叢集形成「統一設定檔」的基礎結構。此叢集流程可確保在單一永久識別碼下正確連結所有相關來源記錄。
• 協調:系統會使用定義的協調規則 (例如,最常見、_最近_或 來源優先順序) 來評估來自所有叢集來源記錄的資料值,以便將設定檔資料摘要填入產生的「統一設定檔」。協調不會覆寫任何現有資料,因為所有來源資料皆可使用連結至統一設定檔的金鑰。

此結構支援多個實體類型的解析度,以滿足各種使用個案。

• 個人比對:專注於建立「統一個人」設定檔,其會將所有已知個人識別碼 (電子郵件、電話號碼、忠誠度識別碼、Cookie) 連結至一個人員。
• 帳戶比對:專注於建立「統一帳戶」設定檔,其會連結帳戶的相關資料。比對公司名稱時,引擎會在模糊比對時使用微調的模型。
• 家庭比對:擴充比對邏輯,將「統一個人」記錄彙總到相關個人的群組中。
• 跨實體比對:除了統一之外,身分解析也會使用相同的比對規則,在設定檔物件之間建立連結。例如,可使用「帳戶名稱」上的模糊比對,將「商機」連結至「帳戶」。

為了確保「統一設定檔」一律為最新狀態,身分解析引擎使用近乎即時的時間結構運作。此雲端最佳化的結構專為持續處理而設計,以達到快速的處理時間。雖然處理速度會根據接收來源資料的方式而有所不同,但身分解析可每 15 分鐘處理一次的小批次變更。

系統會維護身分連結物件,這些物件會將每個來源記錄識別碼對應至其對應的「統一設定檔識別碼」。此基礎資料結構可讓引擎有效追蹤關係,並快速將變更和更新移入「統一設定檔」,確保客戶體驗 (例如網站個人化、 Next Best Action 建議和區隔) 始終利用最新的可用客戶資料。

區隔是將統一的客戶設定檔轉換為可運作受眾的核心流程。此功能對於在整個行銷、商務和服務管道中提供個人化體驗而言至關重要。Salesforce Data 360 Segmentation 平台是針對大規模作業而設計。它會管理複雜的中繼資料,並使用包含數千個物件和關係的資料模型。平台支援複雜的規則、彙總式篩選條件和視窗式排名,同時確保以 petabyte 規模進行快速且可靠的計算。

Data 360 支援各種區段類型,以符合不同業務需求的速度、複雜性和階層:

1. 標準區段:主要批次處理區段類型。其會依自訂排程發佈,其「標準發佈」步調至少為 12 小時至 24 小時,或較快的「快速發佈」步調為 1 到 4 小時,其針對最近參與資料最佳化。
2. 即時區段:此區段會依需求完成,以毫秒為單位,以根據最近事件和設定檔資料立即採取動作。其針對立即個人化高度最佳化,但無法使用排除條件或巢狀區段。
3. 瀑布圖區段:子區段的階層結構,用於將客戶的優先順序設定為單一且最有價值的區段 (如果其符合多個條件)。
4. 巢狀區段:這允許重複使用現有區段作為新更具體區段的篩選條件 (基本區段的精簡),繼承父系區段的排程。

區隔引擎使用強大的雲端原生結構來確保速度、規模和彈性。

核心流程由工作協調流程服務管理,其可控制區段的生命週期,產生必要的工作組態並觸發執行。此協調流程層會在分割資料庫中維護狀態和中繼資料,以便擴充性。

雖然 Data 360 查詢會處理區隔計數計算,但 Spark 計算層負責計算實際的「區段」成員資格。Spark 應用程式會對大量客戶資料執行 Spark SQL 查詢。此資料可以位於 Data 360 Lakehouse、透過 Zero Copy 資料聯邦的外部系統,或兩者的組合。

系統透過智慧查詢產生高度最佳化,進而精簡基本的 Spark SQL 查詢。這包括智慧分割等技術,以將資料掃描降到最低,並消除冗餘子運算式。為了確保服務可靠性,結構有自適應資源管理功能,會根據工作量與複雜度動態調整運算資源。此外,系統會使用自適應持續時間和重試邏輯主動管理「SLO 符合度」。為了獲得快速的使用者體驗,加速區段計數會使用以取樣為基礎的方法,在建立區段期間提供快速大小估計值,避免完整執行查詢。

最後,透過全方位的 Spark 執行度量和自動化錯誤分類 (例如客戶端與系統問題),深度專注於可觀察性和根本原因歸因,大幅減少診斷時間並確保高度彈性的資料平台。

啟用是 Data 360 生命週期的關鍵最後一個步驟。其核心功能是將靜態、區隔且統一的客戶設定檔轉換為可運作且豐富的資料,並將此資料傳送至內部和外部端點 (例如 Marketing Cloud、Commerce Cloud 和 Adtech 平台)。此流程的設計目的���觸發個人化的客戶旅程和近乎即時的互動。其支援如相關屬性、啟用成員資格篩選、同意篩選、限制和排名等進階功能。

啟用針對外部傳送與管道合規性提供三種不同的方法:

• 批次啟用:針對大量排程作業設計,例如大規模電子郵件行銷活動和廣告受眾重新整理。資料會透過將資料暫存至「安全內部分類」(雲端物件儲存) 或透過「安全檔案傳輸」來傳送,後面接著是目標系統起始的 API 採取流程。批次啟用可利用特殊重新整理模式 (增量) 來減少 Salesforce 合作夥伴傳送和處理的量。
• 串流啟用:針對需要事件驅動自動化的近乎即時使用個案最佳化。傳送可透過傳送至目的地端點的直接 API 呼叫達成。
• 啟用觸發流程:此高度平台化管道提供無程式碼/低程式碼方法,可將「受眾資料」與數百個已啟用客戶 API 的參與平台整合。啟用完成時,Data 360 會填入「受眾 DMO」,然後觸發「大規模流程」。「流程」引擎接著會耗用���眾資料,並利用如「外部服務」和「模擬輸出目的地」等平台功能來呼叫最終 API 型目的地。此方法會大幅減少上線新啟用目標所需的時間。

啟用會針對工作管理、分散式執行和監視使用與區隔相同的模式。這包括用於生命週期管理的工作協調流程服務和用於處理的運算層 (Spark) 原則,並依賴工作距離測量來瞭解效能可觀察性和服務層級目標 (SLO) 符合度。

除了這些項目之外,啟用還具有:

啟用目標管理會監視所有目的地端點的安全連線、認證和組態。這可保證資料格式和安全性通訊協定已標準化,確保可靠的輸出傳送至各種平台,包括 Marketing Cloud、Adtech 合作夥伴和其他外部應用程式。

啟用會為特定目標量身打造裝載。針對 Salesforce Marketing Cloud,這包括業務單位 (BU) 感知篩選、多重 EID 支援和交叉污染控制。

「通訊管理」 會作為門管,確保資料用量與通訊符合客戶偏好與法律需求。集中同意模式會統一所有客戶偏好設定,從全域選擇���出到管道和用途特定同意,並儲存在「統一個人設定檔」上。執行期間,平台會使用排除篩選來從最終裝載中自動移除不同意的個人,以嚴格執行這些原則。此外,系統會套用連絡點選取規則,以確保在傳輸任何資料之前,針對預期的管道使用單一、最合規且偏好的連絡點。此強制執行機制由基礎管理架構保護,此架構使用如動態資料遮蔽和存取控制等保護措施,以在整個啟用流程中保護敏感資料欄位。

統一資料平台的真正價值在於其能夠輕鬆且一致地存取其所有資料資產,無論其來源或結構為何。Salesforce Data 360 的「統一查詢」功能精確設計,可提供此功能,從多元化資料存放區的基本複雜性中摘要以提供單一強大的查詢介面。

「統一查詢」層提供各種耗用模式的精密存取權:

• 混合結構化與非結構化查詢:其提供廣泛的 SQL 支援,可順暢地查詢結構化資料和非結構化資料的結構化中繼資料。此功能透過表格函數增強運算子擴充性,可在文字、影像和空間類型之間啟用專用搜尋。
• 使用 Hyper 加速效能 360 利用高效能記憶體內引擎 Hyper 加速複雜的分析查詢和互動式顯示面板,透過大量資料集提供近乎即時的回應。
• AI 與個人化的統一方法:此統一存取權對於產生目標化和個人化結果至關重要,透過在豐富的企業資料中奠基 AI 模型,直接使用「取得增強型產生」(RAG) 來促進更精確的 LLM 回應。
• 與下游耗用整合:其可作為 UI 驅動體驗、強大的 API、生成式 AI 工作流程和 CRM 增強的基礎資料存取層,以順暢地將資料連線至啟用。

透過提供單一、智慧且高效能的查詢介面,Data 360 的統一查詢可讓結構設計師建立敏捷、資料驅動的應用程式,以充分利用其完整的客戶資訊範圍。

Data 360 是啟用的平台,支援針對資料事件啟用銷售管道。例如,重要事件 (例如客戶的帳戶餘額下降) 會觸發 Salesforce 流程來協調對應的動作。同樣地,主要度量的更新 (例如終身使用) 可以自動移入相關應用程式。

「資料動作」會使用儲存空間原生變更事件 (SNCE) 和變更資料摘要 (CDF) 持續監視變更的增量資料。系統會根據客戶設定的動作規則來評估此資料,例如到度值監視或狀態變更。符合這些規則時,會產生資料動作事件。此事件會以其他資訊 (例如客戶忠誠度狀態) 增強,並立即傳送至設定的目的地,例如 Salesforce 流程或外部應用程式,以觸發業務協調流程。

Data 360 支援原生 CDP (Customer Data Platform) 功能,包括進階身分解析功能,以及建立統一個人識別碼和設定檔以及全方位參與歷程記錄。此平台擅長處理公司對公司 (B2B) 和公司對消費者 (B2C) 架構,透過支援使用完全和模糊比對規則的身分解析和身分圖,如上所述。這些身分圖以來自各種管道的參與資料來增強,這有助於建立含有寶貴分析洞察和區段的詳細設定檔圖表。

支援客戶設定檔的重要概念是資料圖形。Data 360 提供 JSON 格式的企業資料圖表,這是衍生自各種 Lakehouse 表格及其相互關係的反正規化物件。這包括由 CDP 建立的「設定檔」資料圖表,其中包含人員的購買和瀏覽歷程記錄、個案歷程記錄、產品用量和其他已計算洞察,且客戶和合作夥伴可以擴充。這些資料圖是針對特定應用程式量身打造,並透過提供相關的客戶或使用者內容來增強生成式 AI 提示準確度。Data 360 的即時圖層使用「設定檔」圖表進行即時個人化和區隔。我們會將「對話」、「工作階段」和「工作人員記憶體」作為資料圖包含的建模 Agentforce Context。

此外,CDP 可在不同平台之間 (例如 Salesforce 的 Marketing Cloud、Facebook 和 Google) 啟用有效的區隔和啟用。它會批次、近乎即時和即時處理客戶設定檔,以便立即進行決策和個人化。此功能可增強 B2C 和 B2B 案例中的互動,確保公司可以快速且準確地回應客戶的需求和行為。

Data 360 的即時階層由 Data 360 CDP 支援,並針對即時使用個案擴充其概念。Data 360 的即時層設計為以毫秒延遲處理如網路和行動點擊串流、造訪、手推車資料和結帳等事件,以增強客戶體驗個人化。其會持續監視客戶參與度,並使用即時參與資料、區段和計算來更新 Customer 360 的客戶設定檔,以立即個人化。

例如,當消費者在購物網站上購買項目時,即時圖層會快速偵測並取用此事件、識別消費者,並以更新的終身支出資訊增強其設定檔。這可讓使用子秒的方式個人化其在網站上的體驗。此外,此層包含即時觸發和回應的功能,以根據客戶互動啟用立即動作。

Sub-Second Real-Time 平台透過數個重要功能來強化此轉換:

1. 即時資料圖 360 設定檔使用反正規化圖表建立,其中包含與品牌最相關的關鍵物件和欄位。這些資料圖可啟用即時資料處理,並在毫秒內提供可運作的內容和洞察
2. 即時採取和轉換:從 Web 和行動來源以毫秒為單位的速度,來取用使用者事件和設定檔。
3. 即時身分解析:在裝置之間合併客戶設定檔,立即統一未知與已知使用者。
4. 即時已計算洞察:計算如終身價值 (LTV) 或使用者造訪歷程記錄等度量 (以毫秒為單位),以啟用「個人化」或「Web 的優惠」、「聊天機器人」或服務代理程式。
5. 即時區段:隨時將受眾區隔,即時個人化訊息和互動。
6. 即時動作:讓品牌能夠評估每個使用者參與,並透過 Salesforce 流程或其他相關的通訊管道採取行動。

在 Data 360 中,我們建立了包含即時管道、低延遲儲存和子秒資料處理層的新即時平台。隨著從 Web 和行動管道中快速取用互動式資料,其會經過一系列快速流程。

我們的 Web 與行動 SDK 和即時 API 會從 Web/行動應用程式收集資料 (在未來 Agenttic 互動中),並將其傳送至我們的指標伺服器。接著,系統會將此資料路由至「即時層」以進行毫秒處理,並將其路由至「Lakehouse 層」以與批次/串流資料整合。「即時」層會在使用者設定檔內容 (匿名或已登入) 中處理傳入即時資料,例如更新使用者總支出或終身價值等,以進行工作階段中即時個人化。「即時層」受主要記憶體和 NVme (SSD) 儲存空間支援,用於儲存即時資料和客戶設定檔。資料在「即時層」中後,會先經過下列流程,再更新為「即時資料圖表」:

• 簡易採取與轉換:系統會為進一步的處理取用並轉換資料。
• 身分解析:系統會套用完全符合比對規則,以將設定檔與所有現有比對規則集統一,因此資料感知專家不必特別為即時建立新的身分解析規則集。
• 已計算洞察:系統會評估每個參與、執行如加總和毫秒計數等簡單計算,並在即時資料圖表中更新資料。
• 即時區段:系統會評估每個參與資料,以判斷其是否符合已定義即時區段的條件,且使用者會以毫秒新增至合格區段。
• 即時動作和觸發:系統會根據定義的規則評估每個參與,以在符合規則時,即時針對一系列目標觸發動作。
• 即時資料圖形與 API:即時資料圖表 (也包含即時 API) 可讓品牌針對每個使用者提取更新後的 JSON 格式資料,以確保所有客戶互動皆以最新的資料通知。

個人化就是瞭解要鎖定目標的人員、何時及何處傳送相關內容和建議、要說什麼以及什麼頻率。「個人化服務平台」可協調透過個人化體驗來最佳化目標達成率所做的決策。

個人化服務提供下列功能:

• 一致的模型集與解譯 Data 360 中設定檔、活動和資產資料的方式
• 平台整合的試驗 (A/B/n、多臂詐騙)
• 設計時間 (組態)、ML 訓練時間和執行階段 (ML 推斷) 的整合目標
• B2C 規模即時和批次互動支援 (匿名使用者、大量即時/互動式外部、大量內部批次)
• 透過 Data 360 驅動的 Analytics
• 整合其他廠商 AI 模型與服務的模式 (內部與外部)
• 整合至核心中繼資料生態系統 (PLATE 特性)
• 高價值 AI 驅動使用個案的 OOTB 實作 (具有各種 ML 演算法的建議/決策,包括促銷/內容選取、產品建議、定價決策等的內容違約)。

• 決策管道
  • 提供個人化決策的外部要求,包括設定檔擴充、試驗和建議。
• 建議引擎
  • 以規則或 ML 為基礎之建議的執行階段服務。
• 索引���理員
  • 管理/協調非同步流程的工作流程,包括建議模型的 ML 訓練
• 流程物件服務
  • 負責在核心與非核心之間同步化個人化中繼資料
• 歸屬引擎與試驗
  • 個人化建議的 Analytics 歸屬與試驗

Data 360 專為支援新興工作人員體驗而設計為強大且豐富的平台。我們透過建立各種現有的 Data 360 服務,並透過與 Agentforce 的深度整合來達到這些功能。

我們對「代理企業搜尋」的方法以下列原則為基礎:

• 企業資料會保存在隔離的服務或商店中,且具有存取所需的安全權限。能夠在維護來源權限的同時存取和處理此資料,對於確保 Trust 而言至關重要。
• 跨資料整體的跨排名和相關性可提供更好的結果,進而為工作人員體驗提供更好的內容。

為了提供這些體驗,「代理企業搜尋」以這些關鍵結構元件為基礎建立:

• 連接器 360 提供一組廣泛的連接器,讓您能夠從各種來源中存取和取用資料。
• 非結構化資料處理:這是處理非表格內容的基礎,讓系統能夠從各種資料衍生意義和內容。
• 監管:確保搜尋所耗用所有資料的企業級安全性、合規性和存取控制。針對簡單搜尋與工作人員體驗,支援來源可視性權限可確保只有已授權的使用者可以存取資料。為了確保快速取回,搜尋後端會在資料存取的最早階段原生評估和強制執行安全性權限。
• 統一檢索層:為了解決隔離資料的挑戰,連接器會摘要為全方位「統一檢視」層。此圖層提供所有資料的單一存取點,無論其是否保留在透過聯合搜尋存取的外部系統中,或透過零複製與已提取資料的進階索引進行原生管理。
• 智慧查詢瞭解:提取前,系統會使用 AI 技術支援的機制解讀使用者的意圖。除了內嵌用於語意向量比對的查詢表示外,它還可以重寫和展開以關鍵字為基礎的搜尋,以改善準確性。
• 混合式搜尋和進階查詢:為了尋找最相關的資訊,平台會並列使用多個策略。混合式搜尋會在最佳化區塊的資料上,提供與語意向量搜尋相符的精確關鍵字,而「完整記錄」搜尋會同時檢取整個文件。兩者皆結合在一起,以確保語意相關性和完整的內容涵蓋範圍。
• 階層排名:取得資料後,多階段階層排名結構會為每個來源和方法的結果進行評分、合併和重新排名。此流程會建立單一的統一清單,以呈現與使用者或工作人員最相關的資訊。

生成式 AI 將企業搜尋的主要消費者從人類使用者移至大型語言模型 (LLM)。Data 360 搜尋是從頭開始設計的,可提供這兩種服務。其已最佳化以處理來自工作人員的較長且更複雜的查詢,並傳回程式設計耗用與推理迴圈所需的完整內容結果。同時,系統可以處理人類使用者通常較短且經常不明確的查詢,提供如程式碼片段等功能,並醒目提示 UI 中的快速評估。

最終提供工作人員搜尋體驗結合以下兩種方法:

1. 直接搜尋結果:應用程式可以使用以 Data 360 統一搜尋基礎建立的中繼資料驅動 API,顯示傳統的排名結果清單。
2. 代理、多輪對話回答:代理回答透過與 Agentforce 的原生整合來實作。此對話體驗由主要工作人員驅動,主要工作人員可協調動作和查詢,並將所有資訊尋找工作委派給專門的內部搜尋工作人員。

此專門的「搜尋工作人員」已最佳化以用於取得企業資訊。它會使用推斷迴圈來制定並執行並列搜尋,以探索使用者要求的不同層面。它利用一組強大的工具,包括 Data 360 統一搜尋所有資料類型和結構化查詢語言,以從表格和實體中提取精確的資料。

透過此結構合併,Data 360 可讓您建立高智慧、感知內容且可運作的代理企業搜尋體驗。

擴充功能是 Salesforce Platform 中的關鍵功能。「程式碼延伸模組」可在 Data 360 中提供擴充功能,允許專業程式碼使用者直接在 Data 360 環境中執行自訂 Python 邏輯,以補充其豐富的陳述性與低程式碼功能。使用程式碼擴充功能,使用者可以安全地擴充 Data 360 核心功能,例如轉換和非結構化資料銷售管道 (自訂切分)。

我們的「程式碼延伸模組」設計優先考量彈性、安全性、效率和簡化的開發人員體驗。其支援兩個主要執行模型,每個模型皆為特定結構需求量身打造:

• 指令檔模型:
  • 目的:適用於需要與 Data 360 Lakehouse 直接互動的全方位自訂邏輯。
  • 功能:客戶使用 Code Extension SDK 撰寫完整的 Python 指令檔,透過 SDK API 啟用 Lakehouse 的讀取與寫入存取權。適用於自訂/複雜資料準備或自訂資料操作的理想選擇。
  • 隔離與安全性:當指令檔存取 Lakehouse 時,其執行僅限於 Data 360 執行階段內的安全隔離環境,以防止其他程序或未經授權的系統存取遭到干擾。
• 函數模型:
  • 目的:類似無伺服器函數,適用於從現有 Data 360 管道叫用的模組化無狀態計算 (例如「非結構化管道」中的自訂切分)。
  • 功能:客戶提供的函數會取得輸入、計算和傳回輸出。
  • 隔離與安全性:這些函數是為了嚴格的隔離而設計;它們沒有直接的 Lakehouse 存取權。其執行為 Sandbox、無狀態和資源限制,使其適合專注的無狀態處理步驟,確保安全性、可預測的執行,並將爆炸半徑降到最低。

「指令檔」與「函數」模型都旨在安全執行客戶程式碼,防止某個租戶的程式碼影響其他租戶,或未經授權存取其他租戶資料、Salesforce 資源或外部資源。此安全性可透過層級式 (深度防禦) 結構來達成。此結構為每個租戶的自訂程式碼提供隔離執行環境,並納入各種護欄。其中包括 Kubernetes (K8s) 層級的邏輯隔離、網路隔離、執行階段 Sandbox 和最低權限權限,所有這些權限都會由作業監視和偵測和回應的事件回應整備補充。

為了支援強大的開發生命週期,Code Extension 提供:

• 外部編寫與除錯:開發人員可以在熟悉的環境 (例如 VSCode) 中建立和除錯 Python 程式碼,以利用 SDK。
• 彈性部署:您可以使用 SDK 公用程式、Data 360 UI 或 API 來封裝和部署自訂程式碼,以啟用整合至 CI/CD。

營運記錄:詳細執行記錄的存取權可提供透明度,並協助在生產環境中進行疑難排解。

透過提供這些安全且彈性的程式碼擴充功能,Data 360 可讓結構設計師量身打造平台以滿足其最獨特且複雜的資料處理需求,真正強化其作為可擴充企業資料架構的角色。

隨著企業加速採用 AI,大多數都會維護不同的 ML 生態系統,包括 Amazon SageMaker、Google Vertex AI 和以 Python 為基礎的自訂環境,以主控推動任務關鍵預估的模型,例如信用風險評分、流失傾向、產品建議和 Next Best Action 決策。

傳統上,將這些外部模型整合至 Salesforce 需要自訂 API 圖層、ETL 管道或中間軟體協調流程,並導入資料重複、管治負擔、延遲和營運複雜性—這些挑戰與統一、合規和即時 Customer Data Platform (CDP) 願景衝突。

自帶模型 (BYOM):透過 Einstein Studio in Data 360 提供,透過在 Salesforce 工作流程、Apex 邏輯和自動化工具中啟用直接叫用外部訓練的模型來解決這些挑戰,而無須移動或複製資料。透過零複製聯合,Data 360 會作為受管理的單一事實來源,以在外部端點公開協調的 Customer 360 資料來推斷。預估輸出會即時返回流程,以可調整的情報為業務流程提供動力。

BYOM 透過分離模型開發、受管理的資料和耗用層級,有效地清除資料科學與作業執行之間的差距。其可保留平台獨立性、減少整合複雜性、加速 AI 部署,並維持敏感資料的管理。

結構的運作方式如下 360 提供統一的 Customer 360 資料基礎,而 Einstein Studio 會協調外部 ML 平台 (SageMaker、Vertex AI 或自訂端點) 的連線。外部模型會以即時、批次或串流模式執行推斷。Salesforce 圖層 (流程、Apex 和查詢 API) 會耗用輸出,以跨 Sales、Service、Marketing 和 Industry Cloud 提供個人化、自動化和分析洞察。

從企業的角度來看,BYOM 會提供:

• 資料完整性和管治:去除未受控制的資料複本並強制遵循原則。
• AI 民主化:透過 Salesforce 工具讓非技術使用者可存取複雜模型。
• 時間對值的加速:外部模型會立即在 Salesforce 程序內啟用。
• 延展性和混合式結構支援:啟用 AI 工作量的多雲端部署。
• 準備未來的 AI 結構:支援可編輯 AI 策略,將資料、模型和耗用層分離以獲得作業靈活性。

自帶 LLM (BYO-LLM):提供相同的擴充機制,但適用於生成模型。透過啟用外部 LLM 的直接叫用,我們允許客戶在 Agentforce Platform 中使用外部 LLM,而非 Salesforce 提供的模型。針對企業,BYO-LLM 可:

• 存取微調的模型
• 目前未由 Salesforce 提供的模型整合
• 模型用於客戶提供的帳戶

現代企業在具有兩個主要結構挑戰的複雜資料環境中運作:

1. 企業內區段:大型組織經常利用多個 Salesforce 組織 (通常依區域、業務單位或歷程記錄取得區隔) 和許多其他資料系統。此分割會建立內部資料孤島,因此無法建立客戶的單一、信任且統一檢視,以便在整個業務中即時參與。挑戰是統一此資料,而不實際整合或複製所有系統中的資料,以確保監管保持不變。
2. 跨企業協同合作:公司通常需要與合作夥伴和供應商共用資料,以進行聯合行銷、測量和業務情報。挑戰是啟用此協同合作,同時保護敏感、專屬的資料,並遵循如 GDPR 和 CCPA 等隱私權法規,以及競爭阻礙。

Salesforce Data 360 透過以共用存取與洞察原則為基礎的零複製、每個 Trust 設計架構來解決這些挑戰,而非移動或複製資料。

Salesforce Data 360 透過 Data Cloud One、Data 360 之間的資料共用和隱私權優先的資料清除空間,解決資料片段和協同合作的挑戰。這些解決方案可統一客戶資料、啟用安全資料交換,並提供保密洞察。透過零複製、 Trust 每個設計方法,組織可以開放資料潛力,以實現即時參與、增強合作夥伴關係和智慧決策。每個資料協同合作選項都有不同的用途。

使用 Data Cloud One 進行內部企業啟用

Data Cloud One 是針對營運多個 Salesforce 組織的企業所提供的基礎結構解決方案。其用途超出簡單的資料共用範圍;其設計目的為建立單一信任的客戶檢視,並在整個組織中啟用完整的 Data 360 平台功能。

此機制著重於指定的 Home Org Data 360 例項,其會作為資料管理和建立統一客戶設定檔的中心授權機構。「首頁組織」是佈建 Data 360 的組織。Data 360 與其他 Salesforce 組織 (稱為「伴侶組織」) 之間建立 Data Cloud One 連線。作為 Data Cloud One 連線的一部分,Data 360 會與每個伴侶組織共用一或多個資料空間,以在每個共用資料空間中提供資料與中繼資料的存取權。這可透過零複製聯邦模型和跨組織中繼資料同步化來達成。

Data Cloud One 也允許「伴隨組織」利用「首頁組織」的 Data 360 例項,以滿足自己的啟用、個人化和情報需求。此策略對於消除內部資料分片,並確保所有業務單位根據相同、受管理且統一的客戶設定檔進行啟用至關重要,以最大化核心 Data 360 實作的 ROI。

Data 360 組織之間的資料共用

針對散佈內部環境 (無法完全集中化),以及與受信任的外部合作夥伴協同合作,Data 360-to Data 360 資料共用會連線獨立的 Data 360 例項。

此零複製共用模式會在不同 Salesforce 組織上佈建的個別 Data 360 租戶之間建立連線,以安全地交換資料物件 (DLO、DMO 和 CIO)。連線後,整個資料物件會在 Data 360 收件者中可供存取。接著,收件者的 Data 360 管理員可以設定管治規則來管理此資料的使用者存取權。

與 Data 360 Clean Room 合作的隱私權優先合作

當協同合作需要最高層級的隱私權與合規性時,或當競爭問題禁止共用原始資料時,Data 360 Clean Rooms 是結構上必要的。

在結構上,Data 360 Clean Room 協同合作是建置在 Data 360-to-Data 360 資料共用所使用的零複製共用架構之上,但套用了額外層級的管治與運算限制。Data 360 Clean Room 提供安全且受控制的計算環境,讓使用者可以根據匿名金鑰加入其資料集。其核心目的是允許共同分析和洞察產生,而無須公開基本專屬資料。環境會強制執行嚴格且可程式設計的規則,例如最小彙總值和不可匯出的識別碼。這些規則可確保只衍生和共用已批准、增強隱私權和彙總洞察。這使得 Clean Rooms 對於跨平台行銷活動度量和敏感受眾重疊分析等使用個案至關重要。

Data 360 設計為智慧、可擴充且值得信賴的資料架構,以支援下一代 AI。其結構設計可解決分割資料的問題,讓組織能夠大規模統一、處理和啟用所有客戶資料,並使用「零複製資料聯合」確保效率。

其強大的「資料組織」可建立從 DLO (包含非結構化資料) 到 DMO 的協調檢視,這些檢視都會在分割資料空間內保護。Data 360 的靈活資料處理功能 (包括批次和串流轉換、已計算洞察、非結構化資料處理和身分解析) 由增量 SNCE 和 CDF 結構提供技術支援,可確保高效率、近乎即時的處理並大幅節省成本。

擴充功能由「程式碼延伸模組」結構提供,可透過指令檔或單獨的功能安全地啟用自訂 Python 邏輯,以滿足獨特的需求。此外,以含 CEDAR 原則的屬性型存取控制 (ABAC) 為基礎建立的全方位資料管理架構,可保證細微的安全性、動態資料遮蔽,以及所有資料耗用的一致強制執行。這會達到複雜的區隔和啟用功能,將統一的客戶設定檔轉換為動態的多管道參與策略,並具有即時回應性。

重要的是,Data 360 能夠統一廣泛、多元化的資料、透過統一查詢提供即時內容 (包括混合式結構化/非結構化搜尋和超級加速),並強制執行嚴格的管治,這對強化智慧 AI 工作人員而言至關重要。其提供必要的信任、新鮮且相關的資料,以奠基生成式 AI 工作流程 (RAG),並為 Agentforce 提供的工作人員提供多輪、以動作為導向的功能,以確保其精確且準確地作業。

透過提供一個未來的平台,讓來源資料轉換為可運作洞察,Data 360 可作為組織建立 Agent 客戶體驗的不可或缺的結構基礎。這是將客戶資料轉化為精密且個人化的客戶體驗的重要支柱,為現代組織帶來成功。