Data 360 架构 | Data 360 和集成 | 基本知识

此文本使用 Salesforce 的自动翻译系统翻译。参加我们的调查，提供有关此内容的反馈，并告诉我们您接下来想要查看的内容。

数据平台已经发展了三十多年。最初，该行业由内部部署、集中和结构化（主要是关系型）操作/OLTP 数据库主导。它扩展到包括数据仓库 OLAP/大数据平台，这些平台主要用于分析处理，并保持关系性和集中性。云存储推动了分布式架构，例如数据仓库、湖泊小屋和分类存储。但是，操作平台和分析平台仍然是分开的。如今，云计算和 AI 革命正在从根本上改变数据平台架构。

企业已经在成熟的大数据平台上投资，例如 Snowflake、数据块、BigQuery 和 Redshift。但这些平台充当数据孤岛。客户无法从数据中获取业务价值，因为数据不能直接在业务流程和应用程序中操作。这些解决方案缺乏生成式客服人员 AI 处理，无法实时提供数据访问，因此无法在客户参与时提供 AI 驱动的个性化和其他行业领先的功能。

数据平台的未来的特点是统一、灵活、可访问和开放的数据基础设施。这一新架构构建于现代计算和存储趋势（GPU、大内存、NVMe SSD 和云存储），与云计算和 AI 集成。他们能够提供实时见解，支持自主决策，并推动实时应用程序。这包括代理 AI、预测 AI、分析、实时大规模 OLTP 数据库、数据湖和湖泊小屋的兴起。这些现代数据平台旨在实现简单性、可扩展性、灵活性、性能、安全性、可用性和成本效益。

以下数据趋势推动了下一代数据平台架构。

AI、机器学习和 Analytics 是核心:客服人员 AI 的兴起将从根本上改变数据平台的开发、部署和使用/访问。客服人员 AI 将理解对话/查询意图，计划、生成工作流，并自动化决策。客服人员（短期和长期）记忆从对话历史记录中构建，用于个性化客服人员规划和决策、实时对话建模和在数据平台中至关重要的个性化支持。客服人员将帮助自动化操作“功能”，例如数据治理（即安全、合规、Trust）、性能（即针对并发、吞吐量和延迟的自动扩展）、故障转移和可用性以及可观察性和维护。AI 支持的分析、预测、自然语言处理 (NLP) 用于分析问答，以及对非结构化数据（PDF、图像、音频、视频等文本）的分析将是标准功能，使企业能够从各种数据源中获得更深入的见解。
数据分散化但统一数据访问:客服人员需要企业数据来获取见解和决策，并实现业务活动的自动化。数据在企业、不同的应用程序和数据平台中本质上是分散的。但无缝统一企业内不同业务部门之间的孤岛以及与企业外部合作伙伴之间的孤岛并不容易。统一数据涉及数据共享，或者通过从源接收数据，或者与数据源联合；来自数据准备、协调和建模的原始数据，用于分析和 AI 处理；大规模存储和管理数据，以便以较低的 CTS 实现高效的访问;通过各种查询和分析机制和工具进行数据访问，并与底层存储和数据访问平台深度集成
基于云的 Open Lakehouse:基于云的大数据 (OLAP) 平台正在采用开放文件格式 (Parquet) 和表格式 (Iceberg)，支持数据联合（数据输入）和共享（数据输出）。
非结构化数据处理:随着生成式 AI 的出现、进步和采用，企业开始从由大量文本文档、音频脚本、视频记录和其他媒体组成的企业数据集中获得有价值的见解和业务价值。非结构化数据处理，包括分块、矢量化、语义搜索和 Knowledge 图，使这些见解成为可能。像 RAG（检索扩充生成）和 CAG（缓存扩充生成）这样的技术正在成为整个数据集中快速和代理搜索的主流驱动因素。
知识管理 不仅仅是原始内容本身(文档、文章、视频)。它代表通过派生意义、策划元数据并将其放在上下文中来扩充该内容，以便在整个组织或企业中形成对内容的共同理解。Knowledge 本身通常是结构化的。Knowledge 管理涉及内容管理、Knowledge 提取、通过图形等模型表示以及导航。
富数据访问:富数据访问意味着数据、分析和 AI 工具必须由各种角色访问，包括最终用户、业务用户、管理员和分析师。可访问性通过集成查询（具有关系、关键字和语义查询）、自然语言到 SQL (NL2SQL) 查询、实时访问等机制来实现。
实时处理:客服人员应用程序根据当前状态和新事件做出实时决策，个性化响应和操作，这需要访问、处理实时数据并采取行动。实时处理需要最新数据（数据延迟）和交互式访问（访问延迟）。此类数据和访问延迟要求基础数据平台支持从运营和分析商店访问最新数据、低延迟访问（点查找和查询）处理、高数据规模和高吞吐量。
数据安全、治理和驻留:客服人员和对话式 AI 简化了应用程序 UI，允许任何人（从消费者到员工到其他 AI 客服人员）使用口头或书面自然语言与应用程序进行对话式交互。必须为客服人员应用程序存储和建模的宝贵客户和个人数据必须使用定义明确的访问和共享策略进行保护和治理。越来越多的客户必须遵守法规，要求数据驻留在自己的国家或地区，特别是那些在政府部门工作或与政府合作的客户。

Salesforce Data 360 专为未来解决这些数据趋势而设计。Data 360 是一个云原生的元数据驱动的数据平台，它统一了整个企业中孤立的数据，允许组织存储、建模和处理他们的数据，以支持分析、AI、机器学习和 Agentic 应用程序。

本文档是企业架构师和 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 是一个现代数据平台，构建于解决当前数据趋势的设计原则之上。其架构功能确保企业数据实时可信、统一和可操作，符合其指导原则。

云原生基础:在 Hyperforce 上运行，部署在 Hyperscaler（例如 AWS）上，具有不可变的、基于微服务的基础架构。提供弹性扩展、零信任安全性、持续交付和全球合规性。
Salesforce（核心）元数据驱动:元数据被设计、建模并存储为 Salesforce 元数据，允许所有 Salesforce 应用程序立即使用。此类元数据存储在完全符合 ACID 的 RDBMS 中。确保治理、生命周期一致性以及与 Salesforce Lightning 平台的深度集成。
Lakehouse Storage:构建于 Apache Iceberg 和 Parquet，将数据湖规模与仓库治理相结合，支持模式演进、时间旅行和高用量更新。Data 360 使用具有现代开放标准的极端大规模存储来存储、建模和处理结构化和非结构化数据，并且具有丰富的转换和数据处理能力来应对批处理和事件驱动的工作负载。
具有灵活接收能力的端到端数据漏斗:涵盖整个生命周期 — 摄取、准备、建模、统一、分析和激活 — 减少对零散点解决方案的依赖。通过 270 多个连接器和 MuleSoft，支持批量、近实时和流。ELT 优先方法通过下游转换灵活性实现了快速的数据可用性。
与开放框架和联盟的企业数据交互性:通过 Snowflake、数据块、BigQuery 和 Redshift 的双向 Zero Copy 联合，统一企业中的思洛存储器数据，避免数据迁移或重复。
数据分类、建模和组织 360 将数据组织为原始摄取数据、清理和存储的数据，以及符合称为 SSOT（单一真相源）的常见信息模式的建模数据。此类 SSOT 对象构成了定义语义数据模型 (SDM) 和其他特定于应用的模型的基础。
通过开放语义查询 API 实现可扩展分析的内置语义数据建模，推动 Tableau Next 并支持特定于应用程序的分析。
高性能 SQL 查询引擎支持跨结构化、非结构化和图形数据的统一 Data 360 SQL 查询。
低延迟数据存储:具有毫秒响应时间的热数据的键值存储。实时启用个性化和事件驱动的场景。实时收集和处理客户参与数据。将身份、交互和对话统一到一个受信任的 Customer 360 简档和上下文图表中。
非结构化数据处理漏斗,用于灵活和可扩展地支持非结构化数据存储、分块、嵌入生成(矢量化)、元数据提取(扩充)、汇总、索引、Knowledge 提取、智能文档处理、短期和长期(对话)记忆创建等。
**本地关键字、**向量和混合索引,用于准确和高效的非结构化数据访问,例如快速和代理搜索、RAG、Knowledge 提取、代理记忆派生等。
用于启用 AI/ML 和客服人员应用程序的简档、个性化、上下文服务。
每一层的内在治理和安全,用于谱系跟踪、数据屏蔽、数据驻留和零信任安全,确保合规和信任。
弹性计算结构 本地多租户计算结构。为分布式处理运行 Spark，为 SQL 工作负载运行 Hyper。在不同作业之间灵活扩展，并支持隔离运行不可信代码。

所有这些都在 Hyperforce 上运行，即 Salesforce 的云基础。Hyperforce 提供：

零信任安全 有加密、隔离和最低特权策略
通过多区域部署实现弹性。虽然 Salesforce Data 360 受益于 Hyperforce 的多区域弹性和平台级容错，但真正的企业级灾难恢复 (DR) 需要更广泛的架构，类似于任何具有关键功能的数据平台：可重放的接收漏斗、复制以及跨所有依赖生态系统的元数据驱动的补水。
内置监控、度量和跟踪的可观察性。
自动规模和 FinOps 感知，提高效率，而不会造成成本溢出。

Data 360 不会取代现有的企业投资。相反，Data 360 使您已经信任、治理和可操作的数据 — 在最重要的地方提供 AI 驱动的实时参与。简而言之，Salesforce 将所有企业数据（包括外部数据）转换为 (Salesforce) 元数据驱动的对象，并支持 Agent 应用程序进行发现、决策和采取行动。

下图说明了 Data 360 参考架构：

让我们考虑在 Data 360 上分层的假设 Agentforce 贷款代理，以描述示例架构流。假设贷款客服人员是面向客户的客服人员，客户（消费者）可在其中申请贷款并获得即时贷款批准。

Data 360 按计划执行这些步骤，准备贷款代理使用的数据。

Data 360 从 CRM 接收结构化客户客户数据，并将其存储在数据湖中。
Data 360 处理非结构化公司贷款和财务保单数据。
Data 360 从 Snowflake 等外部数据源整合个人数据。
Data 360 转换并建模摄取和聚合的数据。
Data 360 构建和维护简档数据图形。

每次客户申请贷款时，都会执行这些操作。

客户登录到贷款代理，这将在实时层开始客户会话。客户的统一简档被拉入实时层。
客户通过提供所需信息完成贷款申请。
客户将财务文档（例如纳税申报表、投资、银行对账单）上传到 Data 360，以便进行非结构化数据处理。
上传的数据被分块和矢量化（嵌入生成），并创建索引（关键字和矢量）。
接下来，客户填写贷款申请文档并上传。Data 360 会实时提取贷款金额和期限。
贷款客服人员使用 Data 360 查询和简档及其他预创建索引的混合搜索检索相关财务数据。
贷款代理使用贷款数据和其他财务简档数据激活批准代理，以做出贷款批准决策。
贷款代理以决策回应客户。
客户和贷款代理之间的整个交互也会被捕获并存储在 Data 360 中。

以上示例概述了用于构建代理应用程序（例如贷款代理）的 Data 360 架构组件。在下一节中，我们将介绍 Data 360 架构层和组件。

在本节中，我们将深入了解 Salesforce Data 360 的基础构建块，从强大的存储模型开始，然后探索连接、接收和准备数据的机制。然后，我们将检查结构化和非结构化数据的存储、建模和处理方式，最终了解其协调、统一、检索和智能激活功能。

Salesforce Data 360 构建在分层但集成的存储模型上，该模型结合了湖库与实时存储的优势。Lakehouse 层为大量历史数据和批处理数据提供了可扩展的经济高效的存储，支持高级分析和机器学习用例。另一方面，实时存储针对低延迟访问和高频更新进行了优化，确保客户交互、简档和参与信号始终是最新的。这些层一起无缝工作，允许数据在历史和实时上下文之间流畅移动，在统一数据基础中为个性化、AI 和激活提供深度和即时性。

Data 360 采用基于 Iceberg/Parquet 的本地 Lakehouse 架构，旨在处理批量、流和实时场景的大规模数据管理和处理，支持结构化和非结构化数据，这对 AI 和分析应用程序至关重要。

在 Azure、AWS 或 GCP 等基于云的数据湖中，基本存储单元是文件，通常组织成文件夹和层次结构。Lakehouse 通过引入更高级别的结构和语义抽象来促进查询和 AI/ML 处理等操作来增强这种结构。主要抽象是一个带有元数据的表，它定义了其结构和语义，包含了来自开源项目的元素，例如冰山或三角洲湖，并由 Data 360 添加了额外的语义层。

Lakehouse 中的抽象图层：

Parquet 文件摘要:在基础部分，存储由 Parquet 格式的数据湖文件（例如 AWS 中的 S3 或 Azure 中的 Blob）组成。源表的数据在多个分区中存储为 Parquet 文件，每个表是这些文件的集合。
冰山表摘要:表格被组织为文件夹，数据分区在这些文件夹中存储为 Parquet 文件。对分区的修改会生成新的 Parquet 文件作为快照。对于每个表，Iceberg 会管理元数据文件，并详细说明模式、分区规格和快照。
Salesforce Cloud 表摘要:该层构建于 Iceberg 之上，添加语义元数据，例如列名和关系，以及配置，例如目标文件大小和压缩。它抽象了各种平台的表，例如 Snowflake 和数据块，将 Data 360 应用程序与底层存储平台特定功能屏蔽在一起。
Lake Access 库:此库提供对 Salesforce Cloud 表的访问权限，处理数据和元数据，并为应用程序开发人员抽象底层存储机制。
大数据服务抽象:这包括处理框架，例如用于查询的 Hyper，以及用于跨任何云表平台的处理的 Spark。

为了支持实时分析和客服人员应用程序，Data 360 通过低延迟存储扩充了 Lakehouse 大数据存储。Data 360 实时层会在内存中处理实时信号和参与数据。但是，由于基于内存的存储容量有限，因此无法容纳所有数据，处理可能无法实时完成。Data 360 添加了低延迟存储 (LLS)，以消除此类限制，从而实现可扩展的实时处理。

低延迟存储是 Lakehouse 上的 NVMe (SSD) 存储层。并非所有数据都需要保存在低延迟存储中。它是一个耐用的缓存。大多数数据最终会进入 Lakehouse 进行长期保存。实时层中的会话数据可以刷新到低延迟存储，以便后续快速访问。例如，在客服人员对话中，最近的消息可以在内存中处理；较早的消息可以刷新到低延迟存储。如果需要之前的对话，可以在几毫秒内从低延迟存储中访问它。基于 NVMe 的存储允许以毫秒延迟存储和访问大量数据。数据可能会流向 Lakehouse 云存储，以便长期保留。此外，从 Lakehouse 获取实时处理或增强实时体验所需的数据，并将其保存在低延迟存储中。例如，客户简档上下文是预先提取的，或从 Lakehouse 获取，并缓存在低延迟存储中。此外，任何 Lakehouse 对象和会话处理期间实时处理所需的其他对象也可以缓存在低延迟存储中。

Data 360 低延迟存储支持具有内存 (SSD) Lakehouse 存储层的真正存储层次结构上的实时层，数据可在这些层之间无缝迁移。我们将在本文档的后面讨论 Data 360 实时层。

Salesforce Data 360 旨在标准化、协调和激活所有客户数据（结构化和非结构化），遵循严格的生命周期，将原始输入转换为统一的最新数据模型。

生命周期侧重于获取各种外部数据输入，并将其构建为持久的建模对象。建模数据可以协调到 Customer 360 统一简档中。

原始摄取数据和初始转换

该过程从按原样从源系统（CRM、市场营销、文件等）接收的原始数据开始。这包括完全数据加载和连续变更事件 (delta)，它们被管理并与持久数据合并以保持当前状态。

在摄取期间立即应用内联转换(例如修剪、规范化、连接 ) , 以确保初步数据质量和清洁度。

数据湖对象 (DLO)：持久层

DLO(数据湖对象)构成了 Data 360 中的核心持久存储层。它们存储干净、转换的数据，并作为所有客户信息的有组织、长期的存储库。

高级数据转换(例如连接、聚合、计算见解)应用于源 DLO，以生成新的、高度策划的派生 DLO。

通过 Zero Copy 数据联合提供的数据直接表示为 DLO。

非结构化数据和元数据组织

对于非结构化内容（例如文本、媒体、文档），Data 360 通过在特定 DLO 中提取和保留结构化元数据来合并数据，称为非结构化数据湖对象 (UDLO)。

这些专门的 DLO 充当目录表，提供非结构化资产的物理位置和上下文的映射。此功能允许架构师将非结构化数据的元数据与其他结构化客户数据无缝关联，从而实现统一查询和协调。

数据模型对象 (DMO)：协调图层

DMO(数据模型对象)代表最终的、统一的和结构化的数据层。

它们通过将 DLO 字段（从源、派生和非结构化元数据 DLO）映射到标准 Customer 360 数据模型来创建。

DMO 层充当所有客户数据的单一真实来源，支持在更广泛的生态系统中统一简档创建、细分和激活。

数据空间是用于组织 Data 360 中的所有数据和元数据的基本逻辑容器，包括所有 DLO（结构化和非结构化）和 DMO。数据空间为数据处理和建模提供了安全的隔离环境。

数据空间充当逻辑和治理边界，通过分离不同实体（例如业务部门、地区或品牌）的数据来实现内部多租户，同时保持企业范围的可见性、谱系和合规性，作为定义粗粒度访问控制的基础。

数据空间内的隔离在平台的多个层强制执行：

数据级隔离:每个 DLO/DMO 属于一个数据空间，确保查询、转换和对象映射不能跨越数据空间边界，除非明确授权。
访问控制集成:权限集本地绑定到数据空间，允许控制读、写和管理操作。这确保只有授权用户和服务才能访问数据空间中的对象、见解和激活。
治理和审计:数据空间中的所有操作都通过企业级审计跟踪进行记录，从而实现合规性、管理和监管报告的可追溯性。

通过权限集管理访问权限和权限，确保精细可见性、受控更新和防止跨域数据泄露。通过将数据空间边界与 Data 360 的安全和治理架构集成，架构师可以自信地实施集中和分散的治理策略，同时在多个云和业务域中保持一致。

Data 360 计算交换矩阵为管理和执行所有大数据工作负载提供了统一层，简化了底层基础设施的复杂性。其核心组件是数据处理控制器 (DPC)。

DPC 是一项全面的多工作负载数据处理编排服务，跨不同的云计算环境提供作业即服务 (JaaS) 功能。它抽象了基础设施的复杂性，并统一了 Spark（EC2 上的 EMR 和 EKS 上的 EMR）和 Kubernetes 资源控制器 (KRC) 工作负载等框架的作业执行。通过充当集中控制平面网关，DPC 跨多个数据平面编排、计划和监控作业，确保可靠性、可扩展性、成本效率和一致的开发人员体验。

对 DPC 的需求源于直接与本地群集管理系统（例如 EMR）交互的限制。

基础设施和云抽象

虽然 EMR 为集群、任务和步骤提供 API，但它仍然为客户团队带来重要的基础设施管理任务，例如配置、扩展、性能调整和成本优化。DPC 通过为作业提交提供简化的平台级 API 来解决这个问题。它支持自动故障处理、重试和动态负载平衡。通过基于二进制、点和重力的节点提供成本效率。通过 TLS、PKI、IAM 隔离和自动修补提供强大的安全性。管理 Spark 和 EMR 运行时版本升级，以提供性能改进、安全补丁和功能增强。

此外，DPC 提供了与云无关的统一界面，用于提交和管理数据作业，抽象了基础云基础（AWS、未来提供商）的复杂性和专有 API。这确保了客户团队仅与基于 Data 360 API 的通用作业提交界面交互，该界面抽象了基础资源管理器的复杂性，例如 Kubernetes 和 YARN。这允许客户团队通过简单、统一的 API 提交 Spark 作业，而无需直接管理 Pod、节点池或 Spark 群集配置。

手动调整 Spark 参数需要专业技能，不正确的配置会导致作业执行缓慢。DPC 团队集中了这些专业知识，提供了优化的配置来防止常见的性能问题。该专业团队不断集成开源社区的 Knowledge，以确保控制器管理的所有工作负载具有最佳性能。

DPC 不限于 Spark；它支持广泛的工作负载。其中包括：

实时处理工作负载
数据操作的事件递送功能
Milvus 的管理（用于非结构化数据索引的向量数据库）
低延迟存储基础架构

DPC 还利用 Kubernetes 资源控制器 (KRC) 框架,该框架支持 Trino for Query、Event Delivery for Data Actions、Data Extraction Job for Connector 和实时处理等工作负载。对于所有 KRC 工作负载，DPC 提供了集中的“作业即服务”功能，在高级别作业抽象中处理计算配置、部署和管理。

JaaS 优势和架构

DPC 提供的“作业即服务”模式可确保作业处理漏斗的经济高效且具有弹性。

用户提供简单的集群规范，重点关注所需的 CPU、内存、存储、实例计数以及集群匹配的最小/最大集群计数和标记。然后，DPC 会自动管理抽象基础设施详细信息，包括选择最佳虚拟机 SKU、管理实例车队、确定核心与任务节点和管理按需与根据输入发现实例。它还处理 EMR 和组件版本管理和升级，无需停机。

重要的是，DPC 本身支持多租户，旨在理解和强制执行 Data 360 租户边界和资源分离。它还通过强制执行 Salesforce 认证的机器映像、管理特定于服务的 IAM 角色以及保证传输中和静态的加密来确保安全性和合规性。对于路由和容量控制，使用集群标记管理作业到集群的匹配，基于容量的路由使用最大作业并发设置来有效控制资源利用率。

与云无关的客户端体验是一项核心优势，因为基础云环境的复杂性对客户端服务隐藏，允许他们纯粹专注于业务逻辑。这实现了云提供商抽象的目标。最后，DPC 实现了简单的使用情况和成本跟踪，允许按服务对集群利用率和成本进行细分，以实现准确的核算。总体而言，DPC 遵循可插拔的架构，允许新的执行引擎（例如 Flink、Ray）和云基板 (GKE/Dataproc) 无缝集成，而不会向用户公开底层基础设施的详细信息。此设计将控制平面与执行层分离，确保一致的 API 和操作体验，而不论后端如何。

Data 360 优化和丰富原始数据，弥合原始数据和可操作业务消费之间的差距。它通过为复杂的激活和分析准备复杂的数据来补充数据对象生命周期。Data 360 支持各种处理类型，包括批处理和流数据转换、批处理和流计算见解、非结构化数据处理和身份解析。要高效地实现这些不同的操作，特别是在近乎实时和跨大规模数据集的情况下，需要一个复杂的机制来有效地处理数据变化。

为了实现高效、近乎实时的数据处理（尤其是使用 TB 大小的表和数百万个潜在更新），Data 360 需要突破。它需要一种方法来准确通知系统数据何时更改，然后高效地识别哪些数据发生了更改，以便只处理相关的更新，并且只更新它们。这一挑战导致了两项相辅相成的创新:存储本地更改事件 (SNCE)，以在更改时通知，并更改数据摘要 (CDF)，以确定更改的内容。

存储本地更改事件 (SNCE)

SNCE 已将 Data 360 从根本上改变为反应式增量数据平台。这种转变涉及从主动轮询数据湖转向被动监控原子提交事件，使用标准化的事件格式和高吞吐量的消息传递系统。

对 Iceberg 表的每次成功写入操作（插入、更新、删除）都最终导致对目录中该表的当前元数据文件指针进行原子交换。基础对象存储层（例如 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 和安全隧道），以确保连接到客户或合作伙伴环境时的企业级数据安全性和合规性。通过为所有连接器提供一致的方法，DFC 通过确保可扩展性、可靠性和安全集成，使 Data 360 能够无缝连接到更广泛的生态系统中。

Data 360 提供了与庞大的数据源生态系统的强大连接，支持本地 Salesforce 产品和大量外部系统。这种广泛的连接对于统一孤立的企业数据以及支持 AI/ML 和客服人员应用程序至关重要。

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 的覆盖范围。

非结构化数据和云对象存储连接器

这些连接器对于接收和引用非结构化数据（缺少预定义模型的数据）至关重要，有助于生成式 AI 功能。

所有这些连接器都构建在 Data 360 连接器框架上，提供一致的体验。

数据转换是 Data 360 中的基本架构组件，旨在清理、丰富原始接收的数据并将其塑造成与 Customer 360 数据模型一致的标准化、可操作的数据资产。此流程对于数据协调、质量改进以及确保数据为简档统一、细分和激活等下游用例做好准备至关重要。转换利用源数据湖对象 (DLO) 和数据模型对象 (DMO) 作为输入，分别向新的 DLO 或 DMO 生成结果。

Data 360 提供两个主要转换模式，以满足不同的数据速度要求：批处理数据转换和流数据转换。

Batch Data Transforms

批处理数据转换专为基于定义的计划或按需触发器的高用量处理而设计。该引擎针对处理复杂的资源密集型重组操作进行了优化。

批处理转换流程使用可视化的低代码漏斗画布进行配置，使用户能够定义多阶段转换逻辑。该引擎独特地支持对规范数据模型对齐至关重要的复杂重组操作：数据结构和规范化。这包括透视（将非规范化记录分解为多个规范化记录）和扁平化（将层次结构数据（例如 JSON）重组为结构化表）。系统的执行模式支持完全同步（处理所有记录）和高效的增量处理模式。增量模式仅处理自上次成功运行以来发生变化的记录，从而显著减少处理时间和资源消耗。批处理转换非常适合不需要实时更新的任务，例如定期聚合和复杂的数据重组。

流数据转换

流数据在数据流入系统时近乎实时地连续和增量地转换处理数据，使它们对于低延迟用例至关重要。

主要界面是 SQL 优先方法，其中转换被定义为针对传入的记录更改流连续执行的 SQL SELECT 查询。该引擎支持核心转换功能，包括数据清理和标准化（例如，验证 PII 和标准化数据格式）以及数据丰富和合并（使用联接和联合）。重要的是，它支持流查找联接，以根据静态或缓慢变化的参考数据实现实时数据丰富和查找，确保简档即时更新。为了优化服务成本，该架构采用了高密度 (HD) 作业设计，将单个租户的多个流转换定义打包到一个基础计算作业中，最大限度地提高了资源利用率。流转换对于事件监控、即时个性化和实时简档更新等用例至关重要。

Data 360 通过支持 Zero Copy 联合和数据共享彻底改变了数据管理，从而消除了移动或重复数据的需要。此功能允许用户从不同的外部来源无缝直接访问数据，并与外部环境共享数据，从而显著降低复杂性，降低存储成本，并确保所有决策都基于最新、最可靠的信息。

Data 360 支持与外部数据仓库（Snowflake、Redshift）、Lakehouses（Google BigQuery、数据块、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 或数据块实例共享）。

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）中，而无需通过公共互联网。

该架构确保所有流量完全保持在 AWS 主干上，使用专用 IP 地址和不可路由的网络路径，从而满足严格的安全和合规要求，同时实现对客户数据的无缝访问。

对于具有多云架构的客户，Data 360 正在通过跨云互连支持将专用连接扩展到 AWS 之外。这支持从 Data 360 到数据湖和托管在 Azure 或 Google Cloud 中的服务的安全、仅主干网络路径，并保留了与 AWS PrivateLink 相同的原则 — 专用 IP 地址、非公共路由和零互联网暴露。

客户可以在两种部署模式之间进行选择：

客户管理的互连:将现有专用电路（例如 Azure ExpressRoute、Google Cloud Interconnect 或 Equinix Fabric）直接与 Data 360 的 VPC 集成。
Salesforce 受管互连:使用完全受管的交钥匙连接，Salesforce 在其中配置和操作跨云链接，并在目标云中公开专用端点。

在这两种模型中，体验是一致的：Data 360 服务通过超大规模程序连接到外部数据源，就像它们在本地一样，无需通过公共互联网就可以实现安全的接收、激活和查询。

对于企业架构师来说，强大的数据治理不仅仅是合规复选框，还是构建可信、可扩展和可操作的客户智能的基础支柱。Salesforce Data 360 采用全面的治理框架构建，可确保数据质量、安全性，并在数据的整个生命周期中遵守监管要求。

Data 360 充当集中治理中心，确保所有数据（从原始摄取到激活的见解）都得到完整和控制的管理。

虽然数据空间提供了粗粒度的访问控制来确定对数据空间中所有对象的访问权限，但基于 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 获取访问请求上下文，以及策略定义（在 CEDAR 中）和来自 PIP 的属性，以做出权威的访问决策。

粒度安全策略 中定义的策略强制实施各种安全级别，包括：
- 对象级安全性:根据与这些对象关联的标记，控制对整个 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 的非结构化数据索引漏斗设计为模块化、可扩展的架构，包括五个核心阶段：

解析
预处理
块
后处理
嵌入

所有阶段还支持基于 LLM 的处理，这允许客户提出自定义提示。预处理和后处理阶段都可以包括多个顺序步骤，允许灵活地组成复杂的转换。每个阶段完全由元数据驱动，无需更改代码即可实现无缝配置和扩展。

预处理的示例包括噪声消除、语言规范化和图像理解（光学字符识别和字幕）等操作，而后处理阶段可能包括元数据丰富、语义分组或高级技术，例如猛禽分块。

漏斗完全支持 Data 360 代码扩展，允许客户和内部团队在任何阶段插入自定义逻辑。代码扩展组件是轻量级 Python 函数，其生命周期（执行、扩展和故障处理）完全由 Data 360 管理。这种方法确保可以快速引入创新和特定于域的处理，同时保持整个平台的操作一致性和治理。

上下文索引

对于使用非结构化处理设置 RAG，两个关键因素是关键：

快速迭代:使用示例测试查询快速验证的能力。
特定于个人的内容:配置针对消费角色定制的内容的能力。

上下文索引是一个用户友好的工具，旨在解决这两个问题。此交互式 UI 由实时 (RT) 漏斗提供支持，该漏斗执行之前概述的所有五个阶段。当嵌入生成和光学字符识别 (OCR) 等任务需要时，漏斗会使用 GPU。此外，它还允许客户在部署配置之前，通过客服人员快速测试 RAG 漏斗，以便进行全面的内容处理。

文档 AI

Data 360 文档 AI 支持从发票、简历、实验室报表和采购订单等文档中读取和导入非结构化或半结构化数据。此功能支持临时交互处理以及批量处理。这是为客户实现业务流程自动化的关键功能。它由人工智能提供支持，包括 LLM 和 ML 模型。

企业拥有分布在不同系统之间的大量 Knowledge，例如 wiki、文件共享、内容管理系统、内部数据库等。这种分散性使得员工（特别是服务客服人员和销售代表）和客户很难快速有效地找到相关信息。关键问题包括：所有 Knowledge 源之间缺乏单一、统一的搜索体验;来自不同来源的内容呈现和呈现不一致;对分散在系统中的敏感信息缺乏访问权限治理;以及难以在核心业务工作流中利用权威 Knowledge 源(例如将相关文章附加到个案)。

Enterprise Knowledge 代表从更广泛的企业数据池中手动或自动策划的内容。手动策划涉及有意操作，例如创建 Salesforce Knowledge 文章或在外部系统中开发 Knowledge，然后引入。我们设想的自动化策划利用流程（例如 Salesforce 客服人员和转换）运行引入的数据来生成细化的策划层，潜在地混合结构化和非结构化的内容。无论是手动还是自动策划，是在 Salesforce 内部策划，还是在摄取前外部策划，结果都是不同于原始数据的增值内容。

Enterprise Knowledge Hub 解决方案利用 Data 360 功能：

摄取和存储 连接器正在接收 Salesforce Knowledge 文章，数据连接器框架 (DCF) 非结构化连接器从外部来源接收原始内容和元数据。内容被接收到映射到 SFDrive 上的内容的特定于源的非结构化数据湖对象 (UDLO) 中（或者零复制情况下的源）。
协调和结构:协调漏斗处理 UDLO 和文件数据，执行清理、规范化、丰富（NLP 等）、PII 屏蔽，并转换为统一的中间格式，存储在 SF 驱动器和映射到它的统一 UDLO (HUDLO) 中。
索引:非结构化漏斗 (UDS) 通过协调的内容触发，搜索索引为每个 HUDMO 配置。
消耗:消耗应用程序包括搜索、检索、渲染和链接到业务对象，例如个案。收集消耗应用程序的参与度，以提供使用情况分析（例如点击、评论等）

Data 360 中的计算见解 (CI) 允许客户从他们的数据中定义和生成聚合度量。然后，这些度量用于及时的客户参与、分析、细分和激活。CI 计算的聚合数据被写入 Lakehouse，并代表为计算见解对象 (CIO)。

计算见解主要有两种类型：

批量计算见解:设计用于复杂的高用量数据聚合，其中度量可以定期计算（例如，每天或每周）。
流见解:提供从实时事件数据生成度量和操作的能力，实现即时、低延迟的客户参与。

计算见解在数据模型对象 (DMO) 上定义，也可以在其他计算见解对象上定义。计算见解服务管理批处理和流作业的编排。

批处理和流见解计算都使用 Spark。关键区别在于，流见解利用 Spark 结构化流，而批处理 CI 使用定期、计划的批处理 Spark 作业执行。为节省成本，计算见解服务会根据源数据对象的相关性和重叠等因素，将 CI 分组到同一批次 CI 作业或流 CI 作业中一起计算。

SNCE 和 CDF 在流见解计算中起着重要作用。

身份解析负责将来自多个来源的不同数据转换为单一、全面的统一简档。

重要的是要了解，统一简档不是“黄金记录”，身份解析不会在统一简档时选择赢得值或覆盖任何现有数据。统一简档作为一组密钥，通过识别与同一实体、一个数据源内或多个源间相关的所有匹配记录来解锁源数据。有了这些信息，您可以选择正确的源系统数据用于给定的业务用例。

身份解析可以整合各种记录类型，包括个人、客户和家庭。它还可用于将潜在客户与现有客户匹配。统一流程对于实现完整的 Customer 360 视图并推动 B2C 和 B2B 场景中的个性化实时参与至关重要。

身份解析漏斗构建在一个高度可扩展的云原生框架上，旨在连续处理大量数据。该过程包括三个关键阶段，依赖于强大的搜索索引管理匹配过程：

匹配（候选选择）:匹配过程的目标是搜索可能属于同一实体的记录。根据可自定义的规则集分析记录，每个规则包含一组条件，定义在哪个严格级别匹配哪些数据。为了高效地从数据存储中检索潜在的匹配项，系统生成索引，以使用两种技术查找可能的匹配记录：
- 阻止密钥:阻止密钥是从记录的数据生成的值，匹配规则（例如姓名的前几个字母、规范化电话号码等）将可能相似的记录分组在一起。每个记录有多个块密钥，这些密钥被索引并存储为反向索引，确保系统只对小组记录执行详细的比较，而不是在整个数据集上。
- 位置敏感哈希 (LSH):对于具有模糊匹配的匹配规则，哈希会根据训练模型中的嵌入生成。
深度匹配:在候选人选择步骤创建更小的潜在匹配组后，系统将开始更详细的比较。在此阶段，AI 模型和高级算法分析每对记录，以计算概率匹配分数。该分数通过智能比较经常包含拼写错误、变体或格式差异的字段来量化两个记录引用同一实体的可能性。
集群和统一:一旦从候选项中识别出匹配的记录，它们将被分组到一个集群中。此过程至关重要，包括解决传递匹配。例如，如果记录 A 匹配记录 B，而记录 B 匹配记录 C，则所有三个对象都会链接到同一个集群中，即使 A 和 C 从未被直接比较。这些完整的集群构成了统一简档的基础结构。此集群过程确保所有相关源记录在单个持久标识符下正确链接。
:对帐使用定义的调和规则(例如,最频繁、最近_或_源优先级)评估所有集群源记录中的数据值,以使用简档数据摘录填充生成的统一简档。协调不会覆盖任何现有数据，因为所有源数据都使用链接到统一简档的密钥可用。

该架构支持多种实体类型的解析，以满足各种用例。

个人匹配:专注于创建统一个人简档，将所有已知个人标识符（电子邮件、电话号码、忠诚 ID、Cookie）链接到单个人。
客户匹配:侧重于创建统一客户简档，该简档链接有关客户的数据。在匹配公司名称时，引擎会在模糊匹配时使用微调的模型。
家庭匹配:扩展匹配逻辑，将统一个人记录聚合到相关个人组中。
跨实体匹配:除了统一之外，身份解析还通过使用相同的匹配规则在简档对象之间创建链接。例如，潜在客户可以使用客户名称上的模糊匹配链接到客户。

为了确保统一简档始终是最新的，身份解析引擎使用近乎实时的架构运行。这种云优化的架构专为连续处理而设计，可实现更快的处理时间。虽然处理速度因源数据的接收方式而异，但身份解析可以每 15 分钟处理一次小批量更改。

系统会维护身份链接对象，将每个源记录 ID 映射到相应的统一简档 ID。这种基础数据结构允许引擎高效地跟踪关系，并将更改和更新快速传播到统一简档，确保客户体验（例如网站个性化、Next Best-Action 推荐和细分）始终利用最新鲜的可用客户数据。

细分是将统一客户简档转化为可操作受众的核心流程。此功能对于在市场营销、商业和服务渠道中支持个性化体验至关重要。Salesforce Data 360 Segmentation 平台专为大规模运营而设计。它管理复杂的元数据，使用包含数千个对象和关系的数据模型。该平台支持复杂规则、基于聚合的筛选器和基于窗口的排名，所有这一切同时确保以 PB 级进行快速可靠的计算。

Data 360 支持各种细分类型，以满足速度、复杂性和层次结构的不同业务需求：

标准分段:主要的批处理细分类型。它以可自定义的计划发布，标准发布节奏最少为 12 小时，最多为 24 小时，或更快的快速发布节奏为 1 到 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，然后触发大规模流。随后，流引擎会消耗受众数据，并使用平台功能，例如外部服务和 Mule Outbound 目的地，以调用最终基于 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（客户数据平台）功能，包括高级身份解析功能，创建统一个人标识符和简档以及全面的参与历史记录。如上所述，该平台通过支持使用精确和模糊匹配规则的身份解析和身份图，能够处理企业对企业 (B2B) 和企业对消费者 (B2C) 框架。这些身份图使用来自各种渠道的参与数据丰富，这有助于构建具有宝贵分析见解和细分的详细简档图。

支持客户简档的一个关键概念是数据图。Data 360 提供 JSON 格式的企业数据图，这是一个从各种 Lakehouse 表及其相互关系派生的非标准化对象。这包括 CDP 创建的“简档”数据图，其中包含人员的购买和浏览历史、个案历史、产品使用情况和其他计算见解，并且可由客户和合作伙伴扩展。这些数据图形专为特定应用程序定制，并通过提供相关的客户或用户上下文来增强生成式 AI 提示的准确性。Data 360 的实时层使用简档图进行实时个性化和细分。我们将 Agentforce 上下文建模为数据图形，其中包含对话、会话和客服人员记忆。

此外，CDP 支持跨不同平台的有效细分和激活，例如 Salesforce 的 Marketing Cloud、Facebook 和 Google。它批量、近乎实时和实时地处理客户简档，这允许立即做出决策和个性化。此功能增强了 B2C 和 B2B 场景中的交互，确保企业可以快速准确地响应客户需求和行为。

Data 360 的实时层由 Data 360 CDP 提供支持，并扩展了适用于实时用例的概念。Data 360 的实时层旨在以毫秒级延迟处理事件，例如 Web 和移动点击流、访问、购物车数据和结账，从而增强客户体验的个性化。它持续监控客户参与，并使用实时参与数据、细分和计算从 Customer 360 更新客户简档，以便立即实现个性化。

例如，当消费者在购物网站上购买商品时，实时层会快速检测和接收此事件，识别消费者，并使用更新的终身支出信息丰富他们的简档。这允许在几秒内个性化他们在站点上的体验。此外，该层包括实时触发和响应的功能，支持基于客户交互的即时操作。

亚秒级实时平台通过几个关键功能支持这种转换：

实时数据图形 360 简档使用非规范化图表构建，该图表包含与品牌最相关的关键对象和字段。这些数据图形支持实时数据处理，并在毫秒内提供可操作的内容和见解
实时摄取和转换:从 Web 和移动源接收用户事件和简档（以毫秒为单位）。
实时身份解析:跨设备合并客户简档，立即统一未知和已知用户。
实时计算见解:以毫秒为单位计算终身价值 (LTV) 或用户访问历史等度量，以启用适用于 Web、Chatter 或服务代理的个性化或优惠。
实时细分:实时细分受众，个性化消息和交互。
实时操作:授权品牌评估每个用户参与，并通过 Salesforce Flow 或其他相关沟通渠道采取行动。

在 Data 360 中，我们构建了一个新的实时平台，它具有实时漏斗、低延迟存储和亚秒数据处理层。由于从 Web 和移动渠道接收快速交互式数据，因此它会经过一系列快速流程。

我们的 Web 和移动 SDK 以及实时 API 从 Web/移动应用程序（在未来的客服人员交互中）收集数据，并将其发送到我们的信标服务器。然后，这些数据被路由到实时层进行毫秒级处理，并路由到 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 中快速评估。

客服人员搜索体验的最终交付结合了两种方法：

直接搜索结果: 应用程序可以使用基于 Data 360 统一搜索基础构建的元数据驱动的 API 显示传统的排名结果列表。
客服人员、多轮对话回答:客服人员回答通过与 Agentforce 的本机集成来实现。这种对话体验由主要客服人员推动，该客服人员编排操作和查询，将所有信息检索任务委派给专门的内部搜索客服人员。

此专用搜索代理专为企业信息检索优化。它使用推理循环来制定和执行并行搜索，以探索用户请求的不同方面。它使用了一套强大的工具，包括对所有数据类型和结构化查询语言的 Data 360 统一搜索，以从表和实体中检索精确数据。

通过这种架构综合，Data 360 支持创建高度智能、上下文感知和可操作的代理企业搜索体验。

可扩展性是 Salesforce 平台中的一项主要功能。代码扩展在 Data 360 中提供可扩展性，允许专业代码用户直接在 Data 360 环境中运行自定义 Python 逻辑，补充其丰富的声明性和低代码功能。使用代码扩展，用户可以安全地扩展 Data 360 核心功能，例如转换和非结构化数据漏斗（自定义分块）。

我们的代码扩展设计优先考虑灵活性、安全性、效率和简化的开发人员体验。它支持两个主要的执行模型，每个模型都针对特定的架构需求定制：

脚本模型:
- 目的:适用于需要与 Data 360 Lakehouse 直接交互的综合自定义逻辑。
- 功能:客户使用代码扩展 SDK 编写完整的 Python 脚本，通过 SDK API 启用对 Lakehouse 的读写访问权限。非常适合自定义/复杂数据准备或定制数据操作。
- 隔离和安全:当脚本访问 Lakehouse 时，它们的执行被限制在 Data 360 运行时的安全、隔离的环境中，防止干扰其他进程或未经授权的系统访问。
函数模型:
- 目的:类似于无服务器函数，适用于从现有 Data 360 漏斗调用的模块化、无状态计算（例如，在非结构化漏斗中自定义分块）。
- 功能:客户提供的函数接收输入、计算和返回输出。
- 隔离和安全:这些功能专为严格隔离而设计；它们没有直接的 Lakehouse 访问权限。它们的执行是 Sandbox 的、无状态的和资源受限的，使它们适合专注的、无状态的处理步骤，确保安全性、可预测的执行，并最小化爆炸半径。

脚本和函数模型都旨在安全执行客户代码，防止一个租户的代码影响其他租户或未经授权访问其他租户的数据、Salesforce 资源或外部资源。这种安全性是通过分层（深度防御）架构实现的。此架构为每个租户的自定义代码提供了隔离的执行环境，其中包含各种防护。这些包括 Kubernetes (K8) 级别的逻辑隔离、网络隔离、运行时 Sandbox 和最低权限，所有这些都由用于检测和响应的操作监控和事件响应准备来补充。

为了支持强大的开发生命周期，代码扩展提供了：

外部编写和调试:开发人员可以使用 SDK 在熟悉的环境中（例如 VSCode）创建和调试 Python 代码。
灵活部署:自定义代码可以使用 SDK 实用程序、Data 360 UI 或 API 打包和部署，从而集成到 CI/CD 中。

操作日志:访问详细的执行日志提供了透明度，并有助于生产中的故障排除。

通过提供这些安全和灵活的代码扩展功能，Data 360 使架构师能够根据最独特和复杂的数据处理要求定制平台，真正巩固其作为可扩展企业数据结构的角色。

随着企业加速采用 AI，大多数企业会维护异构的 ML 生态系统，包括 Amazon SageMaker、Google Vertex AI 和基于 Python 的自定义环境，托管模型来推动关键任务预测，例如信用风险评分、流失倾向、产品推荐和 Next Best-Action 决策。

传统上，将这些外部模型集成到 Salesforce 中需要定制的 API 层、ETL 漏斗或中间件编排，从而引入了数据重复、治理开销、延迟和操作复杂性 — 这些挑战与统一、合规和实时的客户数据平台 (CDP) 愿景相冲突。

自带模型 (BYOM):通过在 Data 360 中通过 Einstein Studio 交付，无需移动或复制数据即可在 Salesforce 工作流、Apex 逻辑和自动化工具中直接调用外部训练的模型，从而解决了这些挑战。通过零复制联合，Data 360 充当受管的单一真相来源，公开统一的 Customer 360 数据，以便在外部端点进行推理。预测输出实时返回，通过可扩展的智能为业务流程提供支持。

BYOM 通过解耦模型开发、受管数据和消费层，有效地弥合了数据科学和运营执行之间的差距。它保留了平台独立性，降低了集成复杂性，加快了 AI 部署，并保持了对敏感数据的治理。

该架构的工作方式如下：Data 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 平台中使用它们，而不是 Salesforce 提供的模型。对于企业 BYO-LLM 允许：

访问微调的模型
集成目前 Salesforce 未提供的模型
在客户提供的客户中使用模型

现代企业在一个复杂的数据环境中运营，其特点是两大架构挑战：

企业内碎片化:大型组织经常使用多个 Salesforce 组织（通常按地区、业务部门或历史获取细分）和许多其他数据系统。这种碎片化造成了内部数据孤岛，使得无法建立客户单一、可信和统一的视图来实时参与整个业务。挑战是统一这些数据，而不在所有系统中进行物理整合或复制，确保治理保持不变。
跨企业协作:公司通常需要与合作伙伴和供应商共享数据，以便进行联合营销、测量和业务智能。挑战是如何在保护敏感专有数据并遵守 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 Cloud One 连接在 Data 360 和其他 Salesforce 组织之间建立，称为同伴组织。作为 Data Cloud One 连接的一部分，Data 360 与每个伴随组织共享一个或多个数据空间，提供对每个共享数据空间中数据和元数据的访问权限。这通过零复制联盟模型和跨组织元数据同步来实现。

Data Cloud One 还允许同伴组织利用家庭组织的 Data 360 实例来满足自己的激活、个性化和智能需求。此策略对于消除内部数据碎片化至关重要，并确保所有业务部门针对相同、受管和统一的客户简档进行激活，从而最大限度地提高核心 Data 360 实施的投资回报率。

Data 360 组织之间的数据共享

对于分布式内部环境（完全集中化不可行）以及与可信外部合作伙伴的协作，Data 360 到 Data 360 数据共享连接独立的 Data 360 实例。

这种零复制共享模型建立了在不同 Salesforce 组织上配置的不同 Data 360 租户之间的连接，目的是安全交换数据对象（DLO、DMO 和 CIO）。连接后，整个数据对象可以在收件人 Data 360 中访问。然后，收件人 Data 360 的管理员可以设置治理规则，以管理用户对此数据的访问权限。

隐私优先与 Data 360 洁净室协作

当协作需要最高级别的隐私和合规性时，或者当竞争问题阻止共享原始数据时，Data 360 Clean Room 在架构上是强制性的。

在架构上，Data 360 Clean Room 协作构建在 Data 360 到 Data 360 数据共享使用的零复制共享框架之上，但应用了额外的治理和计算约束层。Data 360 Clean Room 提供了一个安全、可控的计算环境，各方可以在其中根据匿名密钥加入他们的数据集。其核心目的是允许联合分析和见解生成，而不会暴露底层专有数据。环境强制实施严格的可编程规则，例如最小聚合阈值和不可导出的标识符。这些规则确保仅派生和共享批准的、增强隐私的和聚合的见解。这使得 Clean Room 对于用例至关重要，例如跨平台市场活动测量和敏感的受众重叠分析。

Data 360 被设计为支持下一代 AI 所必需的智能、可扩展和可信的数据结构。其架构设计解决了碎片化数据的问题，使组织能够大规模统一、处理和激活所有客户数据，使用零复制数据联合来确保效率。

其强大的数据组织建立了从 DLO（包括非结构化数据）到 DMO 的统一视图，所有这些都在分区的数据空间中受到保护。Data 360 的多功能数据处理功能（包括批处理和流转换、计算见解、非结构化数据处理和身份解析）由增量 SNCE 和 CDF 架构提供支持，确保高效、近乎实时的处理并显著节省成本。

扩展性由代码扩展架构提供，通过脚本或隔离函数安全地启用自定义 Python 逻辑，以满足唯一要求。此外，基于基于属性的访问控制 (ABAC) 和 CEDAR 策略构建的全面数据治理框架可以保证粒度安全性、动态数据屏蔽以及所有数据消耗的一致性实施。这最终导致复杂的细分和激活功能，将统一的客户简档转化为具有实时响应的动态、多渠道参与策略。

重要的是，Data 360 能够统一海量、多样的数据，通过其统一查询提供实时上下文（包括混合结构化/非结构化搜索和超加速），并实施严格的治理，这对于支持智能 AI 客服人员至关重要。它提供必要的可信、新鲜和相关数据来基础生成式 AI 工作流 (RAG)，并促进 Agentforce 支持的客服人员的多轮、面向操作的功能，确保他们准确无误地工作。

通过提供面向未来的平台，将源数据转化为可操作的见解，Data 360 成为构建客服人员客户体验的组织不可或缺的架构基础。它是将客户数据转化为复杂、个性化的客户体验的重要支柱，推动了当今现代组织的成功。