--- schema_version: "1" id: c7c21ef19f33e3d2ab015ab6ad921b705881ed0716db642f6186ac1a0d53320f title: Data 360 集成模式 collection: architect version: current locale: zh-cn portal_url: https://docs.salesforce.com/architect/current/zh-cn/fundamentals/guides/data360_integration_patterns_and_practices.md canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/fundamentals/guide/data360_integration_patterns_and_practices.html source_site: architect.salesforce.com content_type: documentation content_hash: f418e0d3493b28511ff39463a9cd2b68408204815c215052ca0af03e470cc8ab products: - 基本知识 - Architect Site Content Repo updated_at: 2026-02-01T00:00:00Z --- # 概览 现代 Salesforce 集成必须支持远远超过简单的数据交换。它们有望支持实时客户体验，协调多个系统之间的操作，并在企业级可靠地运行，同时满足严格的安全和合规要求。因此，选择正确的集成方法是一项关键的架构决策，而不是实施细节。 考虑常见的企业场景。客户在移动应用程序中完成购买，触发个性化优惠的实时资格检查。同时，必须在 ERP 系统中记录交易数据，在 Salesforce 中更新客户属性，并将分析流式传输到数据湖，而不会引入延迟、数据重复或合规风险。像这样的场景现在在现代 Salesforce 环境中很常见，Salesforce 很少孤立地运行，必须与更广泛的应用程序和数据平台生态系统无缝集成。 本指南旨在帮助架构师和开发人员清晰自信地设计这些集成。它提供了一组经过**验证的集成模式**,用于解决重复性的企业场景,例如流程编排、数据同步和实时数据访问,而不是专注于点对点的实施。每个模式都强调架构意图、权衡和执行模型，使团队能够做出明智的设计决策，并不断扩展。 在本文档中，您将找到： * 代表跨流程、数据和虚拟访问场景的通用企业“文件类型”的集成模式 * 模式选择框架，帮助根据集成意图和执行时间确定正确的方法 * 关于可扩展性、弹性、治理和安全注意事项的实用指导 * 从实际 Salesforce 和 Data 360 实施中提取的最佳实践 本文档的目标是为集成提供共享架构语言，帮助团队设计平衡性能、灵活性和 Trust 的解决方案，同时与企业数据和治理战略保持一致。 ## 目的和范围 本文档适用于需要将企业中其他应用程序的数据与 Salesforce Data 360（以前的 Data Cloud）集成的设计者和架构师。此内容是 Salesforce 架构师和合作伙伴许多成功实施的提炼。 要熟悉大规模采用 Data 360 可用的集成功能和选项，请阅读以下模式汇总和模式选择指南部分。架构师和开发人员应该在 Data 360 的数据交互项目的设计和实施阶段考虑这些模式详细信息和最佳实践。 如果实施正确，这些模式使您能够尽快投入生产，并拥有尽可能稳定、可扩展和免维护的应用程序集。Salesforce 自己的咨询架构师在架构审查期间将这些模式用作参考点，并积极维护和改进它们。 与所有模式一样，本内容涵盖了大多数集成场景，但不是全部。例如，虽然 Salesforce 允许用户界面 (UI) 集成，但此类集成不属于本文档的范围。 ### 模式模板 每个集成模式遵循一致的结构。这使得每个模式中提供的信息具有一致性，也使得比较模式更加容易。 * **名称**:模式标识符，也指示模式中包含的集成类型。 * **上下文：**模式解决的整体集成场景。上下文提供有关用户尝试完成什么以及应用程序如何行为以支持要求的信息。 * **问题：**用问题表示，这是模式设计解决的场景。阅读本节，了解模式是否适合您的集成场景。 * **强制：**使所述场景难以解决的约束和环境。 * **解决方案：**解决集成场景的推荐方式。 * **草图：**UML 序列图，向您展示了解决方案如何解决场景。 * **结果：**解释如何将解决方案应用到集成场景的详细信息，以及它如何解决与该场景相关联的因素。本节还包含应用模式后可能出现的新挑战。 * **侧栏：**与模式相关的其他部分包含关键技术问题、模式的变体、特定于模式的注意事项等。 * **示例：**真实场景，描述了如何在真实 Salesforce 场景中使用设计模式。该示例解释了集成目标以及如何实施模式来实现这些目标。 ## 模式汇总 将此表用作本文档中所含集成模式的目录。 ### 模式列表
模式级别 1 模式级别 2 模式 场景
数据接收模式 - 数据入站 批量摄取模式 从云存储批量接收数据 数据以大量原始数据（例如交易或产品日志）的形式从 Amazon S3、Azure Blob 或 Google Cloud Storage 等企业云存储源接收到 Data 360 中。
从 Salesforce Cloud 批量接收数据 Data 360 从多个 Salesforce 组织（例如 Sales Cloud、Service Cloud）批量接收 CRM 数据，以构建统一的客户简档。
流和实时接收模式 通过摄取 API 的事件驱动摄取 - 流 Data 360 订阅流接收端点，这些端点从企业系统接收连续的事件负载（例如，购买事件、IoT 遥测），用于实时简档更新。
实时 Web 和移动行为摄取 Data 360 通过 SDK 收集和处理实时网站和移动应用程序行为数据，以丰富参与度量和个性化模型。
通过流实现近乎实时的 CRM 同步 Data 360 通过事件流近乎实时地接收 CRM 数据更新（例如联系人、个案、业务机会变更），以保持连续同步的 Customer 360 视图。
从云消息传递平台接收事件流 - Kinsis 和 MSK Data 360 直接从云事件平台（例如 AWS Kinesis 或 Kafka (MSK)）使用流数据，以处理高频运营或 IoT 事件。
零复制模式 - 入站和出站 入站零复制 — Data 360 的外部平台 Data 360 通过零复制接收按需查询外部数据集（例如 Snowflake、BigQuery），而无需将数据物理地移动到 Salesforce 中。
出站零复制 — Data 360 到外部平台 外部系统（例如数据块或 Tableau）通过零复制出站连接访问 Data 360 中的丰富细分和见解，而无需数据复制。
使用 Data Cloud One 的统一多组织数据平台 Data Cloud One 将多个 Salesforce 组织和外部数据源统一在一个共享元数据和语义模型下，提供一致的 Customer 360，没有数据重复。
数据激活模式--数据出站 批量激活模式 市场营销和广告平台的细分激活 Data 360 将策划的客户细分直接激活到 Marketing Cloud、Meta、Google Ads 或其他广告平台，以实现个性化市场活动交付
数据导出到云存储 Data 360 将统一或筛选的数据集（例如，同意的客户记录）作为 CSV 或 Parquet 文件导出到 Enterprise Cloud Storage，用于分析或合规归档。
基于按需 API 的激活 通过 Connect API 进行自定义应用程序集成 外部应用程序实时调用 Data 360 Connect API，根据当前客户数据检索或触发个性化操作（例如，忠诚度余额检查或 AI 优惠生成）。自定义构建的 Web 或移动应用程序通过 Connect REST API 安全地检索协调的 Data 360 见解，以在企业或合作伙伴 UI 中显示。
通过数据图 API 完成客户简档检索 系统使用数据图 API 检索客户的统一简档，并返回完整 360° 视图的预连接实时 JSON 表示，以供决策或个性化。
实时数据操作 将客户信号转化为即时操作的实时数据操作 Data 360 检测并处理实时事件（例如同意更新、购买触发器），并立即调用连接的系统或 Salesforce 流进行下游操作。Data 360 中的客户活动信号（例如检测到的流失风险）会触发即时实时操作，例如更新 CRM、调用 Einstein 评分或启动保留过程。
### **模式方法** 本文档中的集成模式分为三个类别：数据、流程和可视集成。 #### **数据集成** Data 360 中的数据集成模式解决了数据跨系统的移动和同步问题，以确保 Data 360 和外部平台都保存一致、及时和可信的信息。这些模式通常处理大规模、高用量的数据流，并依赖于强制实施模式一致性、谱系跟踪和主规则的受管漏斗。 * **批量接收模式**代表企业数据加入的基础层。从 AWS S3、Azure Blob 或 Google Cloud Storage 等云存储服务中批量接收数据，允许将大型历史数据集定期加载到 Data 360 中，以进行身份解析、细分和分析。同样，从 Salesforce Cloud （例如 Sales、Service 或 Marketing Cloud）批量接收使用本机连接器和数据流将 CRM 数据导入统一数据层，确保参与系统之间的协调和连续性。 * **流和实时接收模式**通过捕获高速事件数据来扩展这一点。通过摄取 API 的事件驱动摄取使外部系统能够持续将客户活动流式传输到 Data 360。实时 Web 和移动行为摄取直接从数字接触点捕获点击流和交互数据，以推动即时个性化。通过流 API 进行近乎实时的 CRM 同步可确保客户属性和同意更新在系统中快速反映。从 Amazon Kinesis 或 Confluent MSK 等消息传递平台接收事件流支持连续的高吞吐量漏斗，使 Data 360 与企业事件架构保持一致。 * **通过 Data Cloud One 统一**多组织数据平台进一步说明了数据集成,它提供了一个整合的环境,将来自多个 Salesforce 组织和外部来源的数据统一到一个共同的治理和语义层之下。这使组织能够实现企业范围的数据一致性、共享数据模型和可扩展的分析。 * 在激活阶段，**批量激活模式**遵循相同的数据集成原则。Data 360 中策划的细分在计划作业中导出到下游营销和广告平台，例如 Marketing Cloud、Meta Ads 或 Google Ads，它们触发市场活动执行。同样，数据集可以导出到云存储目标，以便为外部分析和数据科学漏斗提供支持。在所有这些用例中，Data 360 充当同步和策划的客户数据的真实来源。 #### **流程集成** Data 360 中的流程集成模式涉及近乎实时地触发或编排跨系统的业务流程。这些模式允许 Data 360 积极参与企业工作流，实现上下文响应和动态数据激活。 * **基于按需 API 激活**支持实时参与场景。通过 Connect API，自定义应用程序可以直接从 Data 360 查询或激活客户简档，作为操作流程的一部分，例如在客户交互期间客服人员控制台检索统一简档见解。**通过数据图 API 完整客户**简档检索支持依赖于 API 驱动的客户完整实体图访问的复合应用程序和微服务，允许没有预阶段细分的动态体验。 * 通过支持即时响应，**实时数据操作**进一步推动了这种集成方法。当检测到客户信号（例如购买、表单提交或阈值事件）时，Data 360 可以触发操作，例如更新 CRM 记录、调用外部 Webhook 或启动个性化优惠工作流。这些模式体现了真正的流程编排，将实时客户智能与自动化运营执行联系起来。 #### **虚拟集成** Data 360 中的虚拟集成模式支持对外部或联合数据源的实时访问，而无需物理复制或复制数据。这些对于在查询时需要受管最新信息，同时最大限度地减少数据移动的企业至关重要。 * **入站零复制数据**联盟允许外部系统（例如数据仓库或数据湖）通过安全的受管连接（例如 Snowflake 安全数据共享）与 Data 360 共享数据集。这确保了 Data 360 可以虚拟地访问和操作外部数据，保持了新鲜感并消除了不必要的复制。 * 通过安全的数据联合和实时查询机制，**出站零复制**数据共享 (Data 360 到外部平台) 使 Data 360 能够公开经过策划的数据集供外部使用，例如 AI 建模、商业智能或高级分析。 为您的系统选择最佳集成策略并非易事。需要考虑很多方面，可以使用很多工具，有些工具比其他工具更适合某些任务。每个模式都解决了特定的关键区域，包括每个系统的功能、数据量、故障处理和事务性。 ## 模式选择指南 在选择集成模式时，首先回答两个影响集成整体设计和行为的基本问题。 **您要集成什么？ — 流程、数据或虚拟访问** 此维度定义了集成的主要目的。 * **流程集成**侧重于编排业务工作流和协调系统之间的操作。 * **数据集成**侧重于在系统之间同步、丰富或传播数据。 * **虚拟集成**侧重于实时访问外部数据，而无需在 Salesforce 或 Data 360 中复制或保留它。 了解此意图有助于确定系统之间所需的编排、数据移动和耦合级别。 * **如何执行？ — 同步或异步**方法定义了集成的执行模型。 * **同步**集成是实时和阻止的，调用者需要立即响应，通常用于用户驱动或验证场景。 * **异步**集成是非阻塞和解耦的,旨在处理大规模、长时间运行的进程、重试和高数据量。 这两个维度 — **— 集成意图**和**执行时间** — — 共同为选择合适的集成模式提供了一个清晰一致的框架,同时平衡了用户体验、可扩展性和运营弹性。 **注意：**集成可能需要外部中间件或集成解决方案（例如，Enterprise Service Bus），这取决于哪些方面适用于您的集成场景。 ### 将 Data 360 与其他系统集成 此表列出了模式及其关键方面，以帮助您确定在从 Salesforce 集成到另一个系统时哪个模式最适合您的要求
类型 时间 出站注意事项
数据集成 异步 市场营销和广告平台的细分激活
流程/数据集成 同步 通过 Connect API 进行自定义应用程序集成
通过数据图 API 完成客户简档检索
数据集成 同步 将客户信号转化为即时操作的实时数据操作
虚拟集成（使用 Zero Copy） 异步 出站零复制 — Data 360 到外部平台
虚拟集成 异步 使用 Data Cloud One 的统一多组织数据平台
### 将另一个系统与 Data 360 集成 此表列出了模式及其关键方面，以帮助您确定从另一个系统集成到 Salesforce 时最适合需求的模式。
类型 时间 入站注意事项
数据集成 异步 从云存储批量接收数据
从 Salesforce Cloud 批量接收数据
数据集成 异步 从云消息传递平台接收事件流 - Kinsis 和 MSK
通过流实现近乎实时的 CRM 同步
流程集成 同步 通过摄取 API 的事件驱动摄取 - 流
实时 Web 和移动行为摄取
虚拟集成 异步 入站零复制 — Data 360 的外部平台
### 中间件术语和定义 此表列出了一些与中间件相关的关键术语，以及这些模式的定义。
术语 定义
事件处理 事件处理是指从源系统或应用程序接收、路由和响应可识别的事件。中间件通过识别目标端点、转发事件和触发所需的业务操作（例如，记录、重试或激活下游服务）来处理事件。在 Data 360 架构中，事件处理对于实时数据接收、激活触发器和发布/订阅模式至关重要。事件可能来自外部系统（Kafka、AWS Kinesis）或 Salesforce 平台事件，由中间件或 Data 360 事件总线路由，以便立即处理。
协议转换 协议转换允许使用不同的数据传输标准在系统之间进行通信。中间件将专有或传统协议（例如 AMQP、MQTT、FTP）转换为支持的 Data 360 协议（REST、gRPC 或 HTTPS）。这确保了异构系统之间的互操作性。由于 Data 360 不本地处理协议转换，中间件提供适应层，将消息封装或转换为 Data 360 API 和连接器可以解释的格式。
翻译和转换 翻译和转换通过将一种数据格式或模式映射到另一种格式或模式来确保互操作性。中间件执行这些转换，将各种数据负载（CSV、XML、JSON）与 Data 360 数据模型对象 (DMO) 和统一数据层对象 (UDLO) 保持一致。这包括在摄取前清理、丰富和应用基于语义或本体的映射。虽然 Salesforce 提供转换工具，例如数据准备模式，但复杂的转换（特别是语义协调）最好在中间件中处理。
排队和缓冲 队列和缓冲依赖于异步消息传递，以确保弹性、解耦的通信。中间件平台（例如 MuleSoft、Kafka 或 Azure Event Hub）提供持久队列，在 Data 360 或下游系统繁忙或无法访问时临时存储数据。这可以防止数据丢失，并支持近乎实时的接收或激活重试。Data 360 支持流接收和基于流的出站消息传递，但持久排队和保证交付通常由中间件处理。
同步传输协议 同步传输协议涉及阻止、实时请求/响应操作。发件人在继续之前等待回复。在 Data 360 中，它们用于基于按需 API 的激活、实时丰富或简档查找，其中需要立即响应。中间件确保连接的可靠性，并管理同步 Data 360 API 调用的重试或后备处理。
异步传输协议 异步传输协议支持非阻塞、解耦通信，其中发送方继续处理，无需等待响应。中间件处理异步流，用于批量激活、流接收和事件驱动的激活。这允许高吞吐量和弹性 — 对于 Data 360 中的事件流和近乎实时的数据接收模式至关重要。
调解路由 中介路由定义了系统之间的复杂消息流，确保正确的数据或事件到达正确的消费者。中间件充当中介，根据规则、标题、内容或事件类型处理路由逻辑。在 Data 360 集成中，中介确保事件和简档更新从多个系统正确路由到数据接收 API、激活端点或外部消费者。这简化了编排，并支持多系统数据同步。
流程编排和服务编排 流程编排和协调多系统流程。编排支持自主、异步的事件驱动流，其中系统基于共享规则运行，无需中央控制器。编排是指导服务执行的集中受管流。在 Data 360 架构中，中间件管理跨系统的接收和激活编排，而 Salesforce 工作流或流处理平台中的轻量级编排。建议在中间件层进行复杂的编排，需要事务协调或状态管理。
事务性(加密、签名、可靠交付、事务管理) 事务性确保跨系统的原子、一致、隔离和持久 (ACID) 操作。Salesforce 和 Data 360 在其边界内是事务性的，但不支持跨外部系统的分布式事务。中间件处理全局事务控制，包括加密、消息签名、回滚、补偿和可靠交付。对于任务关键型数据流（例如财务或同意更新），中间件可确保 Data 360 和外部系统的端到端完整性和恢复。
路由 路由指定组件之间的受控消息或数据流。它可以基于标题、内容类型、优先级或规则。中间件处理涉及 Data 360 的事件和激活的路由逻辑，例如将丰富的受众细分定向到不同的下游系统（广告平台、仓库、CRM 应用程序）。虽然路由可以在 Salesforce（Apex、流）中实施，但中间件路由是可扩展性、灵活性和治理的首选。
提取、转换和加载 (ETL) ETL 包括从源系统提取数据，将其转换为一致的模式，并将其加载到目标中（例如 Data 360）。中间件或 ETL 工具会在数据接收前处理这些操作。Data 360 可以通过 API、连接器或批量接收漏斗接收 ETL 输出，还支持变更数据捕获 (CDC) 实现近乎实时的同步。在 Data 360 中统一之前，中间件 ETL 流程对于集成原有系统和确保数据质量至关重要。
长期投票 长轮询 (Comet 编程) 是一种保持系统之间开放通信的方法，用于实时更新。客户端发送请求，服务器保持该请求，直到事件发生，然后响应并重新打开新连接。Salesforce 在流 API 和 CometD/Bayeux 协议中使用此协议进行事件驱动的数据同步。中间件可以订阅这些事件，并将其转发到 Data 360 进行实时接收或激活触发器，确保跨企业系统最小化延迟。
## 数据接收模式--数据入站 数据接收是 Salesforce Data 360 数据生命周期中的第一步，也是最重要的一步。这是来自多个外部系统（CRM、ERP、Web、移动或第三方 API）的原始信息如何进入平台并成为统一客户视图的一部分。 正确的摄取模式取决于业务需求： * **数据量** — 一次移动多少数据 * **延迟** — 数据必须有多新 * **源系统功能** — 系统如何连接和传递数据 Data 360 支持多种接收模式来满足这些需求：批量处理高用量负载，流式处理近乎实时的更新，基于事件的事务即时性，以及零复制接收，无需物理移动即可即时访问外部数据。 这些模式共同确保每个客户信号（无论是购买事件、点击流日志还是忠诚度更新）都高效、安全地在正确的时间范围内流入 Data 360，从而推动可信的分析和 AI 驱动的体验。 ### 批量摄取模式 批量接收模式是 Data 360 中大规模数据引入的支柱。它们针对批量处理数据（通常是定期或定期处理）而不是连续处理的情况进行了优化。 这些模式最适合： * 使用现有企业记录初始化平台的**历史数据加载** * 与 ERP、数据仓库或专有数据库等记录系统**定期同步** * **实时新鲜不是关键**，但一致性、完整性和可审计性是关键 批量接收提供了可预测的性能和操作简便性，使其成为管理 TB 结构化或半结构化数据的企业值得信赖的选择。 Data 360 提供一组生产就绪且普遍可用的**[连接器](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&type=5)**，支持本地批量接收。这些连接器简化了集成设置，减少了自定义 ETL 开发，并确保了每次导入的数据质量和安全性。下表突出显示了用于企业级批量接收的最常见的连接器。 #### 从云存储批量接收数据 ##### 上下文 此模式专为涉及从集中数据湖或计划的文件删除接收大量结构化数据（例如 CSV 或 Parquet 文件）和非结构化资产的企业场景而设计。数据源通常包括云存储平台，例如 Amazon S3、Google Cloud Storage (GCS) 和 Microsoft Azure Blob Storage，其中文件作为上游数据漏斗或批量导出的一部分定期交付。 ##### 问题 组织如何建立可靠、安全和高吞吐量的过程，以可预测的重复计划将基于文件的海量数据集从主云存储平台引入 Data 360，而不牺牲治理、可扩展性或性能？ ##### 部队 将基于文件的海量数据集引入 Data 360 不是简单的数据传输工作，而是受规模、治理和平台约束形成的架构挑战。 **数据量和规模：**Data 360 接收连接器针对可靠性和治理进行了优化，而不是任意批量吞吐量。例如，Amazon S3 连接器支持最多 1 亿行或每个对象 50 GB，以先达到的限制为准。对于拥有运行数十亿条记录的历史数据集的企业，此边界成为关键的设计约束。单文件、升降式方法很快变得不可行，需要智能的数据分区、分块和编排策略来实现规模，而不会达到连接器的限制。 **模式定义和维护：**Data 360 需要为每个摄取漏斗定义明确的模式，以确保语义和结构的完整性。在 S3 接收的情况下，csv 文件必须定义列标题和单个代表数据行。此文件充当源系统（即云存储和 Data 360）之间的规范契约。字段名称、数据类型或编码中的任何不一致都会导致接收失败或静默数据损坏。在版本控制中维护此模式文件并通过 CI/CD 或数据治理工作流强制验证成为生产环境的最佳实践。 **严格的命名约定 :**Data 360 强制实施**严格对象和字段命名规则**，以保持元数据图形的一致性。 * 对象名称必须以字母开头，并且只能包括字母、数字或下划线。 * 字段名称必须遵循相同的模式。 违反这些约定的文件（例如，包含空格、特殊字符或不支持的符号的字段）将在接收期间无法通过模式验证。企业必须实施**摄取前数据卫生**流程，对传入的文件结构进行消毒和标准化。 **身份验证和安全态势：**与外部存储的每个连接都必须符合企业级安全和合规标准。 * 身份验证通常通过 AWS 访问/密钥或联合身份提供商 (IdP) 身份验证来处理。 * IAM 角色必须限定范围，以强制执行最低权限，仅允许对指定存储路径的读取访问权限。 * 对于安全访问，出站 IP 地址必须直接添加到源系统的允许列表中。 这些分层控制确保每个文件传输都在零信任、可审计的外围环境中运行，平衡了企业合规性与大规模接收所需的灵活性。 ##### 解决方案 此表包含此集成问题的解决方案。
解决方案 适合 评论
使用本地云存储连接器（Amazon S3、Google Cloud Storage、Azure Blob Storage） 最佳 这是对 Data 360\ 进行大规模、重复的基于文件的接收的推荐和最可靠的模式。本地连接器提供受管身份验证、模式映射，以及将数据直接移动到 Data 360 的数据湖对象 (DLO) 的安全性。非常适合延迟不重要的计划批处理加载（例如，每小时或每天计划）。
处理大型数据集（超出连接器限制） 最适合预处理 每个连接器强制实施接收限制（例如，S3：100 万行或每个对象 50 GB）。对于较大的数据集，实施 ETL 预处理步骤，将数据分区到属于这些阈值的较小的文件/文件夹中。然后，配置多个数据流以并行接收每个分区，并在 Data 360 中使用批处理数据转换中的附加节点）将分区重新组合成统一的数据集。
安全和治理 最佳 所有连接器都支持通过云本地方法（IAM 角色、服务帐户或访问密钥）进行安全身份验证。为增加控制，请通过云提供商的允许列表限制对 Data 360 IP 范围的访问。数据传输通过加密渠道进行，文件在接收期间存储在临时的安全暂存层中。
何时不使用 次优 此模式不适用于：
  • 实时或接近实时的事件摄取。
  • 事务性低延迟集成。
  • 没有模式定义功能的源 在这种情况下，请使用流连接器（Kafka、Kinesis、Pub/Sub）或 Zero Copy 数据联合。
##### 素描 此图说明了将数据从云存储接收到 Data 360 的步骤顺序 UML 图显示了实施云存储集成的流 在这种情况下： * 管理员通过 Data 360 设置界面配置与云存储的连接（指定身份验证、存储桶详细信息、IAM 角色和白名单）。 * Data Cloud 设置界面使用云存储平台进行身份验证，验证凭据和访问权限。 * 管理员在 Data 360 中创建数据流，将数据流链接到云存储中的对象/文件夹，并定义接收计划。 * 在计划触发器上，数据流会从云存储平台请求源文件（例如 CSV、Parquet）。 * Cloud Storage 平台提供文件，包括所需的有效 schema_sample.csv 和其他符合命名约定的数据文件。 * 数据流将文件传输到 Data 360 中的内部暂存环境。 * Data 360 漏斗处理文件：使用 schema_sample.csv 中的模式定义验证结构、字段名称，如果高于摄取阈值（每个文件 1 亿行/50 GB），则划分负载。如果检测到大文件，将在外部执行预处理分区步骤（通知管理员下次运行）。 * 记录从暂存导入数据湖对象 (DLO)。 * 如果需要，并且对数据进行分区，请在批处理数据转换中使用附加节点来组合多个 DLO。 * Data 360 记录成功/失败，更新监控状态，并指示数据已准备好进行映射、协调和统一。 ##### 结果 此模式的应用支持安全、按计划和大规模地将结构化或非结构化文件从 Enterprise Cloud Storage 平台接收到 Data 360。该过程是自动化、可扩展和具有弹性的 — 将原始数据交付到数据湖对象 (DLO) 中，该对象充当协调和映射到 Customer 360 数据模型的基础。 ###### 摄取机制 接收机制取决于 Data 360 中定义的连接器和计划策略。
摄取机制 描述
本地云存储连接器（Amazon S3、GCS、Azure） 建议从企业的云数据湖中直接接收 CSV 或 Parquet 格式的文件。这些连接器支持增量和完全刷新计划。例如，银行可以将客户交易文件从 S3 存储桶配置为每日同步到 DLO。
分区文件策略 对于非常大的数据集（超过 1 亿行或每个对象 50 GB），数据被划分为更小的逻辑集（例如，按月或地区）。每个分区都作为一个单独的数据流来管理，然后使用带有附加节点的批处理数据转换进行重新组合。
自动计划同步 Data 360 提供声明性调度程序（每小时、每天或自定义节奏），可自动触发接收作业，确保数据新鲜，无需手动干预。
###### 错误处理和恢复 错误处理和恢复对于确保高用量接收操作的可靠性至关重要。 * **错误检测：**每个数据流运行都会记录 Data 360 Monitoring 中的接收错误（例如，模式不匹配、文件损坏或命名违规）。管理员可以查看和重新处理失败的批次。 * **恢复机制**:Data 360 维护检查点，以确保失败的批次不会损坏先前的摄取。在更正源问题（例如，格式错误的 CSV）后，可以配置重试。 * **模式验证**:schema_sample.csv 文件定义了数据类型和结构。任何更改都会触发验证，以避免静默模式在运行中偏移。 ###### 幂等设计注意事项 从设计上来说，摄取是无效的 — 重新处理相同的文件不会导致重复记录。 关键策略包括： * **文件指纹：**Data 360 计算校验和，以识别和跳过之前处理的文件。 * **事务性接收：**数据被暂存，并仅在成功处理所有记录后提交到 DLO。 * **附加与替换：**根据业务逻辑，流可以附加到目标 DLO 或完全替换目标 DLO；这确保了确定性结果，并防止部分数据重叠。 ###### 安全注意事项 在整个接收漏斗中，从身份验证到加密和访问控制，安全性都是不可或缺的。 * **身份验证和授权：**连接器使用 Salesforce 的安全集成框架，利用命名凭据和外部凭据进行身份验证，而不会暴露秘密。 * **加密：**数据在传输 (TLS 1.2+) 和静态 (AES-256) 中加密。 * **网络控制：**源存储系统（例如 S3 存储桶）必须将 Data 360 IP 列入允许列表。 * **合规性一致性：**在与客户受管密钥 (CMK) 配对时，支持企业数据保护框架，例如 GDPR、HIPAA 和 FFIEC 准则。 * **可审计性：**每个接收作业和凭据访问权限都会被记录下来，以便进行可追溯性和合规性报告。 ##### 侧栏 ###### 及时性 及时性取决于摄取计划和数据量。 * 大型企业数据集（100 万行以上）可能需要分区来实现并行接收。 * 根据文件大小和转换复杂性，典型的摄取延迟从几**分钟到几小时**不等。 * 对于近乎实时的接收，Data 360 串流或基于 API 的连接器可能会补充基于文件的模型。 ###### 数据量 * 最适合高用量、周期性的批量摄取。 * 通过 S3 连接器处理的每个对象支持最多 1 亿行，或每个文件 50 GB。 * 对于 PB 级系统，使用数据分区和多流编排。 ###### 端点功能和标准支持 端点的功能和标准支持取决于您选择的解决方案。
连接器类型 端点要求
Amazon S3 连接器 S3 存储桶包含适当的 IAM 策略和定义模式的 schema\_sample.csv 文件。
Google Cloud Storage 连接器 具有统一命名约定的服务帐户凭据和存储桶访问权限。
Azure Storage 连接器 访问密钥或基于 SAS 令牌的身份验证；blob 或文件夹结构必须遵循 Data 360 约定。
###### 状态管理 通过数据流及其上次成功运行的时间戳跟踪状态。 * Data 360 自动维护同步状态和偏移，确保在后续运行时仅处理新的或修改的文件。 * 与外部 ETL 工具集成时，建议使用唯一的文件标识符（例如 UUID 或时间戳），以避免重复。 ###### 复杂集成场景 在高级企业架构中，此模式可以集成： * **中间件 ETL 漏斗(例如 Informatica、MuleSoft ) :** 在切换到 Data 360 之前，协调预处理、验证和文件分区。 * **AI/ML 工作流:** 处理后的 DLO 数据可以通过 DMO 发布到模型训练环境，或通过 Data 360 激活目标发布 RAG 索引。 * **事务系统:** 统一的 DMO 可以通过数据操作或平台事件触发 Salesforce CRM 或外部系统中的下游更新。 ##### 示例 一家全球金融机构将客户和交易数据存储在 AWS S3 数据湖中，其中分区 Parquet 文件每晚按地区生成（例如美国、欧盟和亚太地区）。数据架构团队在 Data 360 中配置多个数据流，每个数据流连接到区域文件夹，并使用共享 schema_sample.csv 确保所有分区的标题和数据类型一致。夜间摄取计划会自动将数据加载到 DLO 中，之后，批处理数据转换会将所有区域分区附加到统一的 Customer_Transactions_DLO 中。然后，这个协调的数据集被映射到 Customer 360 数据模型，实现了下游分析和 AI 激活。该方法提供了从现有数据湖的自动和可靠的接收，强制执行了与企业 IT 策略一致的强身份验证和加密，并提供了一个可扩展的模块化基础，支持未来的扩展和方案发展。 #### 从 Salesforce Cloud 批量接收数据 ##### 上下文 Data 360 的主要和关键用例是统一整个 Salesforce 生态系统的客户数据。此模式涵盖了从核心 Salesforce 平台 — Sales Cloud 和 Service Cloud（统称为 Salesforce CRM）以及 Marketing Cloud Engagement 本地接收数据。来源包括标准和自定义 CRM 对象（例如，客户、联系人、个案、业务机会）以及保存参与事件、电子邮件发送和跟踪数据的 Marketing Cloud 参与数据扩展。 ##### 问题 组织如何高效可靠地将标准和自定义 CRM 对象以及 Marketing Cloud Engagement 数据扩展引入 Data 360，以便数据可用于构建统一的客户简档（身份解析、Customer 360），同时保持性能、治理和对源系统的最小中断？ ##### 部队 本地连接器简化了工作，但必须管理一些操作和架构力量： * **综合源权限：**专用连接用户（集成帐户）必须具有适当的对象和字段级读取权限。无法分配所需的权限集（例如，预构建的 Data 360 连接器权限集）是接收失败的常见原因。 * **数据刷新模式和成本：**连接器支持完全和增量/增量刷新模式。完全刷新在性能和信用上更重；增量提取减少了负载，但取决于源系统中可靠的变更跟踪。 * **自定义模式和字段映射：**CRM 实例通常包括自定义对象/字段。需要准确的模式映射和处理自定义字段（名称、类型），以避免映射错误或语义偏差。 * **入门数据包与自定义映射：**入门数据包通过预选典型对象/字段来加速入门，但高度自定义的组织将需要定制流定义。 * **吞吐量和 API 限制：**源组织 API 限制和 Marketing Cloud 提取率限制了您计划刷新的力度。 * **数据卫生和命名约定：**源字段名称、空行为和数据类型必须在接收前标准化，以防止下游映射问题。 * **安全和最低权限：**连接器依赖于安全身份验证，并且必须遵守最低特权的 IAM 模式、可审计性和网络控制。 ##### 解决方案 此表包含此集成问题的解决方案。
解决方案区域 适合 评论/实施详细信息
解决方案拟合 最佳 在 Data 360\ 中使用本机 Salesforce CRM 连接器和 Marketing Cloud Engagement 连接器。从标准用例的入门数据包开始，并加快入门。对定制或特定于域的数据模型使用手动流自定义。
处理高度自定义的 CRM 实例 最适合映射研讨会 将入门软件包视为基准，并执行映射研讨会，以确定：自定义对象和关系。公式或计算字段。受管软件包扩展。对于繁重的公式字段，在前期 ETL 或 Data 360 转换中计算值，以最大限度地减少源组织上的 API 负载。
何时不使用 次优情况 如果出现以下情况，请避免此模式：您需要高频或实时事件接收（相反，使用流连接器、平台事件或零复制联合）。源组织的 API 容量有限，无法在没有限制或队列延迟的情况下保持计划的提取。
安全和治理 强制控制 最低权限原则 - 使用具有最低读取权限的专用集成用户。请勿使用组织范围的管理员。
身份验证 — 使用 OAuth 2.0 和连接的应用程序；定期轮换客户端密码并监控刷新令牌的使用。
审计和跟踪 — 记录所有接收运行、模式更改和连接器事件。将日志转发到 SIEM 或合规系统，以便审计就绪。
数据分类 — 使用 CEDAR 策略在发布后立即应用 PII/PHI 标记和基于属性的访问控制 (ABAC)，以强制执行屏蔽、同意和下游合规性。
##### 素描 此图说明了将数据从云存储接收到 Data 360 的步骤顺序 UML 图显示了实施 CRM 连接器的流 在这种情况下： * **管理员配置集成用户**，并在源组织中分配连接器权限集。 * **管理员配置** Data 360 设置中的连接器（通过 OAuth/连接的应用程序连接到 Salesforce CRM 和 Marketing Cloud）。 * **管理员创建数据流**，选择对象和数据扩展，选择完全或增量刷新，并设置计划。 * **在计划运行**时，Data 360 会从源请求模式和增量令牌。 * **源系统返回记录**（增量或完整负载）。Marketing Cloud 可能会提供提取；CRM 可能会返回 JSON/Query 结果。 * **Data 360 将文件**暂存到内部安全暂存区域，并根据映射的模式进行验证。 * **如果验证失败**，接收日志错误，提醒管理员并停止提交。如果验证成功，Data 360 会将记录原子性地提交到目标 DLO。 * 通过谱系、运行持续时间、行数和凭据使用情况更新**监控和审计日志**。如果触发阈值或错误，将向管理员发出警报。 ##### 结果 核心客户关系和市场营销参与数据作为数据湖对象 (DLO) 引入 Data 360。这会产生： * 包含简档、个案、业务机会和电子邮件/参与度量的**统一数据集**。 * **身份解析的基础**和统一个人简档的构建。 * 为下游协调、丰富、人工智能建模和激活做好**业务准备**,同时保持治理和可审计性。 ###### 摄取机制 接收机制取决于 Data 360 中定义的连接器和计划策略。
机制 何时使用
Salesforce CRM 连接器（本地） 最适合标准/自定义 CRM 对象；支持完全刷新和增量刷新。
Marketing Cloud 参与连接器（本地） 最适合数据扩展、发送和跟踪提取；支持完全/增量模式。
入门数据包 加快常见销售/服务/市场营销对象的入门。
自定义流 + 预处理 在需要复杂转换或繁重模式规范化时使用。
###### 错误处理和恢复 错误处理和恢复对于确保高用量接收操作的可靠性至关重要。 * **每次运行日志：**每次数据流运行都会提供成功/失败详细信息和行级错误。 * **重试和检查点：**修复源或模式问题后，可以重试失败的运行；Data 360 使用暂存和原子提交语义。 * **提醒：**为模式偏差、重复失败或增量序列差距配置警报。 ###### 幂等设计注意事项 从设计上来说，摄取是无效的 — 重新处理相同的记录不会导致重复记录。 关键策略包括： * **变更检测：**增量提取依赖于源系统变更指标 (LastModifiedDate/系统变更数据捕获获)。验证源是否提供可靠的时间戳/标记。 * **重复数据消除：**使用唯一的业务密钥（例如 Contact.ExternalId）对 DLO 进行重复数据消除或更新插入。 * **事务提交：**记录将被暂存，并且仅在批处理成功完成时提交。 ###### 安全注意事项 在整个接收漏斗中，从身份验证到加密和访问控制，安全性都是不可或缺的。 * **身份验证和授权：**连接器使用 Salesforce 的安全集成框架，利用命名凭据和外部凭据进行身份验证，而不会暴露秘密。 * **加密：**数据在传输 (TLS 1.2+) 和静态 (AES-256) 中加密。 * **网络控制：**源存储系统（例如 S3 存储桶）必须将 Data 360 IP 列入允许列表。 * **合规性一致性：**在与客户受管密钥 (CMK) 配对时，支持企业数据保护框架，例如 GDPR、HIPAA 和 FFIEC 准则。 * **可审计性：**记录每个接收作业和凭据访问权限，以便进行可追溯性和合规性报告 ##### 侧栏 ###### 及时性 及时性取决于摄取计划和数据量。 * **理想的节奏**取决于业务需求 — 对于近乎实时的市场营销触发器，每小时一次，对于大型对帐，每晚一次。 * **增量模式**减少了负载和成本；完全刷新更重，可用于初始负载或主要模式更改。 ###### 数据量 * CRM 连接器针对事务和中容量数据集（数百万条记录）进行了优化。 * 对于非常大的历史卷，请考虑分阶段 ETL 进行分区和分阶段加载。 ###### 端点功能和标准支持 端点的功能和标准支持取决于您选择的解决方案。
连接器 端点要求
Salesforce CRM 连接器 源组织必须允许连接的应用程序、OAuth 令牌和具有读取权限的专用集成用户。
Marketing Cloud 连接器 Marketing Cloud API 凭据或已安装软件包；数据扩展必须通过提取/API 公开数据。
###### 状态管理 * **连接器状态：**数据流维护上次成功的同步时间戳和增量偏移。 * **主键策略：**首选一致的业务标识符（外部 ID），以便下游协调和更新插入具有确定性。 ###### 复杂集成场景 在高级企业架构中，此模式可以集成： * **混合拓扑：**将 CRM 接收与流（平台事件）相结合，实现近乎实时的更新。 * **中间件编排：**当需要复杂的编排、丰富或转换前摄取时，请使用 MuleSoft 或 ETL 工具。 * **激活反馈循环：**协调的 DMO 可以通过数据操作或平台 API 触发源系统的下游更新（小心 SoD 控制）。 ##### 示例 跨国零售商将客户、联系人、个案、业务机会和 Marketing Cloud 参与度量整合到 Data 360 中，以创建统一的客户视图。入门数据包初始化核心销售和服务对象，而团队使用自定义字段（例如 Loyalty_Membership__c 和 Customer_Tier__c）扩展模型，以获取忠诚度上下文。CRM 数据流在增量模式下每小时运行一次，Marketing Cloud 参与每天使用参与事件的增量提取进行同步。这些数据集通过 DLO 和身份解析进行处理，从而产生统一的客户简档，该简档结合了 CRM 和参与信号，以支持个性化和下游 AI 模型。 #### 流和实时接收模式 这些模式专为毫秒级重要场景构建，即客户交互、交易或信号必须触发即时见解或操作时。它们超越了传统的计划批量接收，实现了事件驱动的数据流，其中的信息在生成时就得到了处理。 在 Salesforce Data 360 生态系统中，“实时”不是单一模式，而是延迟模型的连续体。一端是近乎实时的同步，其中来自记录系统的更新（例如 CRM 或 ERP）在几秒钟或几分钟内反映在 Data 360 中。另一方面是真正的实时事件捕获，客户端的行为信号（例如点击、购买或移动交互）在毫秒内被接收和激活。 对于架构师来说，区别不仅仅是语义。它定义了如何设计漏斗、如何调用 API 以及如何做出下游决策。选择正确的模式（无论是近乎实时的同步还是事件流接收），都可以确保系统满足业务的操作延迟目标，同时保持数据的完整性、可扩展性和治理性。 #### 通过摄取 API 的事件驱动摄取--流 ##### 上下文 这种模式使任何外部系统（例如自定义应用程序、物联网 (IoT) 平台、销售点 (POS) 系统或第三方服务）能够在离散事件发生时以编程方式近乎实时地将事件数据推送到 Data 360 中。 ##### 问题 开发人员如何以低延迟可靠地将单个记录或小的异步事件批量从外部应用程序发送到 Data 360，以便数据可以快速用于处理、细分和激活？ ##### 部队 这种模式提供了低延迟和更好的开发人员控制，但引入了一些技术约束和操作依赖性： * **开发人员依赖性：**需要开发人员努力实施经过身份验证的 REST API 客户端和错误/重试逻辑 — 它不是指点单击式连接器。 * **严格的写入模式：**摄取 API 强制实施写时模式。必须定义精确的模式，并将其上传到连接器配置；所有负载必须完全合规，否则将被拒绝。 * **双重交互模式：**相同的连接器支持低延迟、逐记录更新的流 (JSON) 和较大定期同步的批量 (CSV)，架构师必须根据用例进行选择。 * **身份验证和安全：**调用必须通过 Salesforce 连接的应用程序使用 OAuth 2.0 进行身份验证（例如，服务器到服务器的 JWT 不记名流）。令牌管理、轮换和最低权限范围是强制性的。 * **运营可见性：**开发人员和平台团队必须实施响应代码、重试、死信队列和模式偏差警报的监控。 * **实时图形要求：**对于真正的即时激活（即时细分、实时 DMO 映射），目标数据模型对象 (DMO) 必须是实时数据图形的一部分；否则，事件会穿过稍微高的延迟漏斗。 ##### 解决方案 此表包含此集成问题的解决方案。
解决方案区域 适合 评论/实施详细信息
解决方案拟合 最适用于低延迟事件捕获 使用 Data 360 接收 API (串流 JSON) 推送单个事件或微型批处理。使用严格的 OAS 3.0 模式 (.yaml) 配置摄取 API 连接器。将批量 CSV 摄取用于更大、更不频繁的同步。
处理模式更改 严格/受管 模式更改正在中断：更新 OAS .yaml，对连接器进行版本化，并执行合同测试。如果生产者不能同时更改，实施滚动模式迁移。
何时不使用 次优 如果需要预处理（例如：重复数据消除、保证订单等），或对于非常大的批量负载（使用本机批量连接器或批量 ETL），则不理想。如果源无法生成模式有效的负载或无法进行安全身份验证，请使用替代接收方法。
安全和治理 强制性 将 OAuth 2.0 用于最低权限范围、更迭密钥、记录令牌使用情况。强制执行 TLS 1.2+，验证客户端 IP（如果需要），并确保负载 PII 标记。所有事件必须携带来源元数据（源、时间戳、模式版本、兑换密钥）。
##### 素描 此图表说明了将数据从摄取 API 摄取到 Data 360 的步骤顺序 UML 图表显示了实施摄取 API 的流 **在这种情况下：** * 外部系统通过 OAuth/JWT 向身份验证服务器请求身份验证。 * 身份验证服务器向外部系统返回访问令牌。 * 外部系统向 Data 360 接收 API 发送带有授权和 JSON 负载的数据接收 POST 请求。 * 摄取 API 通过暂存和验证模块验证请求模式和身份验证。 * 在方案/身份验证失败时： * 错误返回到外部系统。 * 记录拒绝以进行监控和提醒。 * 成功验证时： * 暂存并提交到数据湖对象 (DLO) 中的记录。 * 为监控记录的成功。 * 如果启用，数据会传播到实时数据图 (DMO)，触发下游工作流。 * 否则，通过标准批次或高延迟漏斗处理的数据。 * 接收 API 向外部系统确认成功。 * 监控组件会提醒管理员死信队列、拒绝率或延迟问题。 ##### 结果 外部事件数据以低延迟被接收到 Data 360 DLO 中。当目标 DMO 是实时图表的一部分时，数据可用于即时细分、客服人员工作流、AI 模型和操作激活。这使得业务能够快速响应来自任何连接的系统的事件。 ###### 摄取机制 接收机制取决于 Data 360 中定义的连接器和计划策略。
机制 何时使用
串流 JSON (摄取 API) 单个事件、微型批处理、行为事件、点击流、IoT 遥测 — 在需要低延迟时。
批量 CSV（摄取 API 批量模式） 较大的定期上传，延迟要求放宽。
边缘/中间件 在推送到摄取 API 之前，当您需要验证、转换、丰富或限制速率时使用。
###### 错误处理和恢复 * **即时(同步)错误：**模式/身份验证错误的 4xx 响应 — 客户端必须修复负载或令牌并重试。 * **瞬时(异步)故障：**5xx 响应 — 具有指数后退和抖动的客户端重试。 * **死信队列 (DLQ)：**持续故障会降落在 DLQ 中进行手动检查和重放。 * **监视：**跟踪模式拒绝率、身份验证失败、延迟百分比和 DLQ 待办事项。阈值警报。 ###### 幂等设计注意事项 * **幂等密钥：**每个事件应包含唯一的幂等密钥/消息 ID。 * **更新插入策略：**使用业务密钥 (ExternalId)，以避免重放时出现重复。 * **重复数据消除窗口：**架构师应定义重复数据消除窗口和保留，以便进行幂等跟踪。 ###### 安全注意事项 在整个接收漏斗中，从身份验证到加密和访问控制，安全性都是不可或缺的。 * **身份验证：**推荐用于服务器到服务器的 OAuth 2.0（JWT 不记名）。将范围限制为仅摄取。 * **加密：**TLS 1.2+ 用于传输；Data 360 强制静态加密。 * **最低权限：**连接的应用程序凭据具有最低权限；轮换密码和仪器访问日志。 * **有效负载治理：**在事件元数据中包含同意/消费标志；在摄取后立即应用 ABAC/CEDAR 策略。 * **IP 控制/专用连接：**必要时，通过允许列表限制访问，或将专用连接用于专用网络。 ##### 侧栏 ###### 及时性 及时性取决于摄取计划和数据量。流 JSON 会产生亚秒到秒的延迟，这取决于处理和图形配置。批量 CSV 是几分钟到几小时。根据业务 SLA 进行选择。 ###### 数据量 单个事件的大小应小（<几 KB）。对于高吞吐量生产者，在调用 API 之前，请考虑在生产者处批处理或使用流缓冲 (Kafka/Kinesis)。 ###### 状态管理 * **模式版本：**在事件元数据中维护模式版本，并在更新 OAS 合同时使用连接器版本。 * **连接器偏移：**Data 360 处理提交语义；生产者应跟踪幂等密钥和最后一次成功的顺序，以便安全重放。 ###### 复杂集成场景 在高级企业架构中，此模式可以集成： * **边缘验证层：**使用中间件将异构生产者格式转换为所需的 OAS 合同，执行速率限制和预丰富。 * **混合架构：**将事件的接收 API 和连接器结合起来，以便进行批量协调。 * **客服人员激活：**映射到实时 DMO 的事件可以触发 Agentforce 工作流和 Einstein 模型进行自动决策。 ##### 示例 零售链将销售点 (POS) 购买事件实时流式传输到 Data 360，以支持即时的客户参与。每个商店运行一个轻量级服务器组件，收集交易，使用位置和设备元数据丰富交易，并使用 JWT 不记名 OAuth 和幂等密钥安全地发布 JSON 事件，以避免重复。管理员通过上传 OAS **销售点**模式和配置摄取 API 连接器来定义事件结构。传入事件被接收到 **pos_sale DLO** 中，映射到**销售 DMO**，并添加到实时图表中。因此，高价值购买会立即被检测到，触发 Agentforce 中的 VIP 工作流，并更新客户细分，以推动实时个性化。 #### 实时 Web 和移动行为摄取 ##### 上下文 此模式支持实时从网站和移动应用程序捕获大量精细的用户交互数据，例如页面视图、按钮单击、产品印象和视频播放。它是提供即时个性化的基础，其中每个数字交互都可以动态影响用户体验并推动参与。 ##### 问题 企业如何从数字属性捕获和处理连续的行为事件流（每分钟数百万次用户交互），并使该数据在 Data 360 中立即可用，以支持实时细分、个性化和激活？ ##### 部队 此用例引入了一些需要专门构建的低延迟接收架构的设计挑战： * **极端吞吐量 :**高流量网站或移动应用程序每分钟可以发出数百万个事件。接收层必须水平扩展，以处理该容量，而不会造成事件损失或背压，从而确保在峰值负载下一致的延迟。 * **客户侧仪表:**与服务器驱动的集成不同，此模式取决于客户端 SDK。JavaScript 信标 (Salesforce 交互 SDK) 必须嵌入每个页面，或者集成到移动应用程序的本地 SDK。这需要强大的客户端部署、版本控制和事件模式治理。 * **低延迟事件处理：**用户操作（例如“添加到购物车”或“视频播放”）必须在几秒内到达 Data 360，从而启用实时激活和上下文响应（例如，有针对性的优惠、个性化推荐）。 * **数据协调和身份解析:**捕获的事件通常包括匿名标识符（Cookie、设备 ID、会话令牌）。要支持 Customer 360 用例，必须通过 Data 360 的身份解析将这些用例映射到已知简档，并协调到 Customer 360 数据模型。 ##### 解决方案 推荐的方法是使用 **Salesforce Marketing Cloud Personalization 连接器** — 专为高吞吐量行为接收设计的**本机完全受管流漏斗**。
解决方案区域 适合 评论/实施详细信息
基于 SDK 的事件捕获 最佳 部署 Salesforce 交互 SDK（Web）或本地 SDK（移动设备）。这些轻量级库实时捕获和序列化用户交互，并附加元数据（会话 ID、时间戳、上下文）。
事件流漏斗 最佳 事件通过安全的 HTTPS 发送到 Marketing Cloud Personalization 的事件流服务。该层可以水平扩展，并针对低延迟传输 (<2s) 进行了优化。
Data 360 集成 最佳 Data 360 的个性化连接器订阅流摘要，近乎实时地将每个事件接收到数据湖对象 (DLO) 中。
数据模型映射 最佳实践 接收的 DLO 映射到 Customer 360 数据模型对象 (DMO)。这允许通过身份解析链接匿名和已知用户。
实时图形启用 可选/推荐 在实时图形中包含映射的 DMO，以便进行即时细分，通过 Einstein 或 Agentforce 工作流触发个性化操作。
何时不使用 次优 在以下情况下，此模式不理想：源数据是 Web 客户端和事件（改用摄取 API）。组织缺乏对 Web/移动客户端的控制。不需要实时行为跟踪（使用批量接收）。
处理模式更改 受管演进 事件模式会随着新交互的添加而变化。SDK 应版本化事件定义。向后兼容的更改（添加可选字段）是安全的；中断更改需要连接器重新配置和合同测试。
##### 素描 此图表说明了将数据从移动和 Web 渠道接收到 Data 360 的步骤顺序 UML 图显示了实施实时摄取的流 **在这种情况下：** * 在 Web 或移动渠道中部署 SDK（用户交互捕获）。 * 使用租户 ID、环境和同意控制配置 SDK。 * 将捕获的 JSON 事件（元数据 + 属性）流式传输到 Marketing Cloud 流式端点。 * 在 Data 360 设置中，创建并配置租户的个性化连接器。 * 将事件引入 DLO，并在 Data 360 中映射 DLO → DMO。 * 在实时图形中启用 DMO，以便立即激活。 * 监控延迟、模式一致性、同意标志、吞吐量、错误率。 * 部署到生产环境，并持续监控。 ##### 结果 持续、低延迟的行为事件流从数字渠道流向 Data 360。在几秒钟内，每个用户操作都可用于实时细分、预测建模或触发的个性化，从而实现真正的自适应客户体验。 ###### 摄取机制 接收机制取决于 Data 360 中定义的连接器和计划策略。
机制 何时使用
交互 SDK（Web） 从 Web 浏览器和 SPA 实时捕获。
移动 SDK 从本地移动应用程序实时捕获。
个性化连接器 Marketing Cloud 和 Data 360\ 之间的受管订阅。
实时图形映射 在细分、Einstein 和旅程中启用即时激活。
###### 错误处理和恢复 * **分层容错：**实施多层验证和重试机制 - 客户端 SDK 通过指数回退处理瞬时故障，而接收层使用持久队列和可重放漏斗来防止数据丢失。 * **模式和数据治理：**持续地版本和验证事件模式；无效或演变中的事件被路由到模式拒绝或死信队列，以便安全地分类和重放。 * **帧余和重复数据消除：**使用稳定的事件标识符和更新插入语义来保证即使在重试或重放期间也能精确处理一次。 * **监控和恢复自动化：**连续监控吞吐量、延迟和错误率会触发自动恢复工作流，从而确保低延迟、可靠的交付和一致的实时个性化结果。 ###### 幂等设计注意事项 * 每个事件必须携带唯一的幂等密钥或消息 ID，以便重复提交可在下游进行重复删除。 * 在适当时使用业务密钥（例如，sessionID + eventTimestamp + userID）来识别重复项。 * 定义重复数据消除窗口（例如 24 小时），在该窗口中忽略或筛选重复事件。 * 在适当时使用更新插入策略（例如，更新计数器或标记，而不是插入重复项）。 ###### 安全注意事项 在整个接收漏斗中，从身份验证到加密和访问控制，安全性都是不可或缺的。 * **传输加密：**TLS 1.2+，适用于所有 SDK → 流服务连接。 * Data 360 和市场营销流中静态的数据加密。 * SDK 遵守**用户同意标志 (GDPR/CCPA)**，并在拒绝同意时禁止跟踪。 * **验证 SDK 流量:**确保只有批准的租户/客户端才能流式传输事件。 * **元数据:**每个事件必须包含源 ID、时间戳、模式版本、会话 ID、幂等密钥。 * **最低权限访问权限：**SDK 端点和连接器仅限于事件接收范围；定期轮换凭据。 * **数据分类：**在事件负载中注释 PII，在摄取后立即强制执行策略 ##### 侧栏 ###### 及时性 * 及时性取决于最终用户活动和事件流配置。 * 通过 Salesforce 交互 SDK 捕获并通过 Marketing Cloud Personalization 流传递的事件通常在 Data 360 实时图形中可用之前达到亚秒到 2 秒的延迟。 * 这将在活动用户会话中实现近乎即时的细分、个性化和激活。 ###### 数据量 单个行为事件（例如，单击、查看、添加到购物车）是轻量级的，通常每个负载为 1-5 KB。 对于大规模数字房地产，预计每分钟会有数千到数百万个事件。 要确保吞吐量和弹性： * 将 SDK 的内置批处理和重试机制用于高流量页面。 * 将突发处理卸载到 Marketing Cloud 流缓冲层。 * 使用连接器度量仪表板监控接收吞吐量和错误率。 ###### 状态管理 每个事件包含状态和版本控制的元数据： * **模式版本：**在每个事件中嵌入模式版本；在更新模式时版本化连接器。 * **重放处理：**因瞬时网络问题而失败的事件将由 SDK 自动重试，并带有指数回退。 * **幂等密钥：**唯一标识符（sessionId + eventType + 时间戳）确保重放的事件不会在 Data 360 中创建重复。 * **偏移管理：**Data 360 会跟踪成功提交；连接器会将任何未处理的事件重新排队，直到成功接收。 ###### 复杂集成场景 此模式无缝集成到高级企业架构中： * **边缘丰富层：**添加中间件（例如，反向代理或无服务器功能），以在事件到达 Marketing Cloud 之前注入其他上下文，例如地理位置、设备类型或市场活动元数据。 * **混合（流 + 批处理）：**将 Marketing Cloud 连接器用于实时流，并将其与批处理 ETL 作业（例如订单数据）组合，以便进行下游对帐。 * **客服人员激活：**映射到实时 DMO 的事件可以触发 Einstein 个性化、Agentforce 工作流或 AI 驱动的决策，以适应当前的数字体验。 * **多租户治理：**使用同意标志和租户感知元数据，以在多品牌或多地区环境中强制执行隐私和合规性。 ##### 示例 一家全球电子商务公司在购物者积极浏览基于反应的单页面应用程序 [**www.retailx.com**](http://www.retailx.com) 时，向他们提供个性化的产品推荐和动态内容。使用客户端的 Salesforce 交互 SDK，站点实时捕获页面视图、产品点击、购物车操作和视频交互。这些事件通过 Marketing Cloud Personalization 事件流和 Personalization 连接器流入 Data 360 DLO，在那里它们被建模到 DMO 中并集成到实时图形中。此架构使行为信号立即可用于细分、Einstein 驱动的个性化和 Agentforce 激活，从而实现响应式会话中客户体验 #### 通过流近乎实时地同步 CRM ##### 上下文 对于许多业务关键型流程，使 Data 360 与核心 CRM 系统中的最新更新完美保持一致至关重要。客户服务、销售和市场营销团队依赖最新信息来推动决策、触发过程和激活自动化。此模式提供了一种机制，以最小的延迟将对关键 Salesforce CRM 对象（例如联系人、客户和个案）的更改同步到 Data 360，而不会降低频繁批量轮询的效率或延迟。 ##### 问题 Data 360 如何与关键 Salesforce CRM 对象保持近乎完美的同步状态，确保下游分析、细分和 AI 驱动的激活始终根据最新可用数据运行？ ##### 部队 此模式引入了一些技术约束和架构注意事项： * **事件驱动架构：**同步必须是反应性的 — 由 CRM 源组织中的变化事件驱动，而不是由定期批处理作业驱动。 * **选择性对象支持：**并非所有 Salesforce 标准和自定义对象都支持实时流。架构师必须在设计期间引用支持的对象列表，以避免出现空白。 * **访问和权限：**启用流需要为源组织中的集成用户分配“为 CRM 流启用权限”系统权限。 * **数据新鲜度与处理成本：**虽然近实时同步提高了响应能力，但过高的事件吞吐量可能需要水平缩放和强大的错误恢复机制。 * **安全和信任层整合:**所有事件数据都必须符合 Salesforce 的Trust和安全框架 — 在传输中加密，验证模式合规性，并在组织的Trust边界内处理。 ##### 解决方案 推荐的方法是使用启用了流（变更数据捕获）的 Salesforce CRM 连接器。在为支持的 CRM 对象（例如联系人）创建数据流时，管理员可以切换“启用流”选项。在源 CRM 组织中每次创建、更新、删除或取消删除记录时，Salesforce 的变更数据捕获 (CDC) 平台都会发布一条 ChangeEvent 消息。 Data 360 CRM 连接器订阅这些 CDC 事件，并近乎实时地将相应的更改应用到 Data 360 中映射的数据湖对象 (DLO)。这将确保 CRM 和 Data 360 之间的持续同步，并最大限度地减少手动干预。
解决方案区域 适合 评论/实施详细信息
基于 CDC 的流连接器 最佳 本地 Salesforce 机制；完全受管并与平台事件基础设施集成。
事件订阅和交付 最佳 连接器通过耐用的重放 ID 订阅 ChangeEvent 渠道（例如 /data/ContactChangeEvent）。
数据映射和模式演变 最佳实践 将流负载映射到相应的 DLO；处理元数据中的模式版本，以防止摄取中断。
重放和故障恢复 推荐 利用重放 ID 和幂等密钥来避免重复并从暂时错误中恢复。
混合模式（流 + 批处理） 可选 对于不支持的对象或初始批量加载，将批量摄取与 CDC 流结合使用。
何时不使用 次优 在以下情况下，此模式可能次优：源对象未启用 CDC。用例不需要实时更新（批量即可）。源组织的网络出口受限或超出事件限制。
##### 素描 此图表说明了将数据从 CRM 近乎实时地接收到 Data 360 的步骤顺序 UML 图表显示了实施近实时 CRM 接收的流 **在这种情况下：** * Salesforce CRM 中发生更改（创建/更新/删除/取消删除）。 * CDC 将 ChangeEvent 发布到内部 Salesforce 事件总线。 * Data 360 CRM 连接器使用耐用的重放光标订阅事件总线。 * 事件负载会验证模式、权限和数据完整性。 * Data 360 将验证的事件写入映射的**数据湖对象 (DLO)**。 * 如果启用，映射的**数据模型对象 (DMO)** 会近乎实时地更新，从而支持细分和激活。 ##### 结果 Data 360 维护关键 CRM 数据的连续同步镜像。 这将启用： * 实时触发器（例如，在创建个案时启动 Journey）。 * 最新细分（例如，在客户状态更改时，将客户转移到“黄金”细分）。 * 基于实时 CRM 上下文进行更准确的分析和个性化。 ###### 摄取机制 此模式的接收机制通过启用变更数据捕获 (CDC) 的 Salesforce CRM 连接器进行本地管理。Data 360 充当 CDC 事件流的订阅者，确保源 CRM 组织和 Data 360 之间的可靠、低延迟同步。
机制 何时使用
通过 CDC 传输流（首选） 适用于需要近乎实时同步的所有支持的 Salesforce 标准和自定义对象。
混合模式（CDC + 批处理） 对于尚未启用 CDC 的对象，或需要初始历史加载的对象。
重放订阅模式 用于在停机或部署后重新同步。
错误隔离模式 适用于测试和验证环境。
###### 错误处理和恢复 * **自动故障恢复：**CRM 连接器使用指数回退自动重试暂时的网络或平台错误，并将持续故障路由到死信队列 (DLQ) 进行重放。 * **模式和身份验证弹性：**模式不匹配将被隔离在模式拒绝队列中，供管理员审查，而身份验证或权限错误会触发受控重试，并通过 Data 360 Monitoring 发出警报。 * **保证事件连续性：**耐用的 ReplayID 确保连接器停机期间不会丢失事件；错过的事件通过重放窗口或批量重新同步作业重新水化。 * **数据完整性和排序：**内置 idempotency (RecordID + SequenceNumber) 可防止重复，ChangeEventHeader.sequenceNumber 会为每个 CRM 记录保留正确的事件顺序。 ###### 幂等设计注意事项 * **事件唯一性：**每个 CDC 事件都带有 ReplayID 和 ChangeEventHeader.entityName，用于确定性重复数据消除。 * **更新插入策略：**根据记录 ID 实施更新插入逻辑，以确保重复事件不会创建重复。 * **重放处理：**使用连接器的重放光标，以在瞬时故障时从上次提交的偏移量恢复。 * **模式演变：在事件元数据中**维护模式版本，并在 CRM 模式更改时更新 DLO 映射。 ###### 安全注意事项 在整个接收漏斗中，从身份验证到加密和访问控制，安全性都是不可或缺的。 * **Encryption and Trust :**所有事件都使用 **TLS 1.2+** 传输，并以加密方式静态存储在 Data 360 中。 * **访问控制：**只有具有适当集成权限的经过身份验证的连接器，才可以订阅 CDC 渠道。 * **模式验证：**每个事件负载在接收前根据 DLO 方案进行验证。 * **同意传播：**同意和数据分类元数据与每个事件一起流向下游，以保护隐私和合规性（GDPR、CCPA）。 * **运营治理：**通过 Data 360 Trust 层记录、审计和监控事件，以进行重放、模式拒绝和吞吐量异常。 ##### 侧栏 ###### 及时性 * CDC 事件近乎实时地处理，通常在 CRM 更改后的几秒钟内。 * 延迟可能因事件量和连接器吞吐量而异，但 Data 360 会保证受支持对象的子分钟可用性。 ###### 数据量 * 每个事件负载都是轻量级的 (~1-5 KB)。 * 对于高更改率对象，例如个案或联系人，请确保吞吐量限制与 Salesforce CDC 事件分配保持一致。 ###### 状态管理 每个事件包含状态和版本控制的元数据： * **重放 ID：**用于顺序事件恢复。 * **模式版本：**维护版本元数据，以管理合同变更。 * **幂等密钥：**重试之间重复的重复重放。 * **偏移提交：**Data 360 在每个成功的事件批次后保持提交状态。 ###### 复杂集成场景 此模式无缝集成到高级企业架构中： * **混合（流 + 批处理）：**使用 CDC 进行增量更新，并使用批量作业进行完全刷新。 * **跨组织流：**多个源组织可以通过 DMO 映射统一流入同一个 Data 360 租户。 * **客服人员激活：**实时对象更新会触发 Einstein 或 Agentforce 自动化。 * **事件路由：**中间件（例如 MuleSoft 或事件中继）可以在接收前丰富或路由 CDC 消息。 ##### 示例 一家全球银行希望确保 Salesforce Sales Cloud 中的客户数据更改立即反映在 Data 360 中。当联系人的地址在 Sales Cloud 中更新时，更改数数据捕获制会发布 ContactChangeEvent。Data 360 CRM 连接器会使用此事件，将更新应用于 Customer DLO，并自动更新所有关联的 Customer 360 简档。这触发 Einstein Next Best Action 来验证新地址 — 在原始 CRM 更改后的几秒钟内完成反馈循环。 #### 从云消息传递平台接收事件流 - Kinsis 和 MSK ##### 上下文 现代数字企业依赖于实时事件流平台，例如 Amazon Kinesis 数据流和 Amazon MSK（适用于 Apache Kafka 的受管流），从分布式应用程序、IoT 设备和事务系统中捕获连续数据流。Data 360 支持通过本机第一方连接器从这些平台直接接收 — 无需自定义 ETL 或基于中间件的解决方案。此模式专为高吞吐量、低延迟的数据摄取而设计，支持近乎实时的见解、个性化和 AI 驱动的激活。 ##### 问题 企业如何安全高效地将 Data 360 连接到 AWS Kinesis 或 AWS MSK Kafka 主题，以持续接收结构化事件和简档数据，从而确保模式合规性、可扩展性和治理？ ##### 部队 此模式引入了多个架构和操作注意事项： * **本机连接器可用性：**Salesforce 为 Amazon Kinesis 和 Amazon MSK 提供普遍可用的本机连接器。这些连接器提供第一方支持，并消除对基于自定义 API 的漏斗的需求。 * **身份验证和安全：**每个连接器都需要 **AWS 级身份验证**。 * 对于 Kinesis，这使用 AWS 访问密钥和密钥，由 IAM 策略控制。 * 对于 MSK，身份验证可以通过访问密钥/密码或 OpenID Connect (OIDC) 进行配置。 * **模式定义：**Data 360 需要模式来解释流负载。 对于 Kinesis，模式文件在连接设置期间上传，定义事件结构和字段映射。 * **配置源：** * Kinesis 连接器订阅特定的 Kinesis 流名称。 * MSK 连接器订阅 MSK 群集中的 Kafka 主题。 * **网络访问：**对于安全环境，连接器可以配置为 PrivateLink 或 VPC 路由，确保数据不会通过公共互联网。 * **运营治理：**流吞吐量、模式验证和身份验证事件在 Data 360 Trust 层中监控，确保合规性和可追溯性。 ##### 解决方案 该解决方案利用 **Data 360** 中的**本地 Amazon Kinesis** 或 **Amazon MSK** 连接器。
解决方案区域 适合 评论/实施详细信息
Kinesis 本机连接器 最佳 与 AWS Kinesis 的第一方集成；支持持续的高吞吐量接收。
MSK 本机连接器 最佳 具有 OIDC 和基于密钥的身份验证支持的受管 Kafka 接收。
模式映射和验证 最佳实践 上传模式 (.json/.avro)，定义事件结构；在摄取期间强制执行一致性。
IAM 配置 推荐 分配对目标 Kinesis 流或 MSK 主题具有只读访问权限的最低权限 IAM 角色。
专用网络路由 可选 为安全的内部路由配置 PrivateLink/VPC 端点。
混合模式（流 + 批处理） 可选 将流用于增量，将批量摄取用于回填或历史加载。
错误隔离模式 推荐 将模式拒绝和暂时错误路由到 DLQ 进行重放
##### 素描 此图表说明了将数据从 Kafka 和 Kinesis 等事件平台近乎实时地接收到 Data 360 的步骤顺序 UML 图显示了实施事件平台的流 **在这种情况下：** * 应用程序或设备将事件发布到 Kinesis 流或 MSK 主题。 * Data 360 连接器使用 AWS 凭据或 OIDC 令牌进行身份验证。 * Connector 会持续轮询或订阅流。 * 事件被暂存，为模式和策略进行验证，然后提交到数据湖对象 (DLO)。 * 如果映射，数据模型对象 (DMO) 会近乎实时地更新以激活。 * 监控层跟踪度量、模式拒绝和延迟。 ##### 结果 将结构化数据直接从 AWS Kinesis 或 MSK 持续、低延迟地接收到 Data 360。数据立即可用于： * 身份解析 * 实时细分 * Einstein AI 激活 * Agentforce 驱动的触发器 消除了对批处理 ETL 的依赖，实现了与企业事件驱动的设计一致的基于流的架构。 ###### 摄取机制
机制 何时使用
Kinesis 连接器（首选） 适用于需要连续接收高用量结构化数据的 AWS 本地流源。
MSK 连接器 适用于在兼容 Kafka 的平台上运行事件漏斗的组织。
混合（流 + 批处理） 用于增量事件摄取与定期批量加载相结合。
###### 错误处理和恢复 * **自动重试：**连接器会使用指数回退重试瞬时网络或平台错误。 * **模式拒绝：**无效负载会路由到模式拒绝队列以供管理员审查。 * **DLQ 重放：**持续失败会捕获到死信队列中，以便进行重新处理。 * **幂等控制：**事件密钥或序列号可确保重复数据消除和有序接收。 * **监控集成：**所有失败、重试和吞吐量度量都显示在 Data 360 监控仪表板中。 ###### 幂等设计注意事项 * **事件唯一性和跟踪：**为每个事件分配一个确定性的唯一密钥（例如，Kinesis 的 PartitionKey + SequenceNumber，MSK 的 Topic + Partition + Offset），以确保精确接收一次。 * **连接器检查点：**Data 360 连接器保留上次处理的偏移或序列号，以在失败或重新启动后安全恢复接收。 * **重复数据消除和更新插入逻辑：**在 DLO 提交期间，会检测并跳过重复事件；使用唯一密钥更新插入有效记录，以保持一致性。 * **重放和恢复控制：**失败或延迟的事件通过死信和重放队列从存储的偏移中重放，确保可靠的恢复，而不会重复。 ###### 安全注意事项 在整个接收漏斗中，从身份验证到加密和访问控制，安全性都是不可或缺的。 * **身份验证：**使用 AWS IAM 策略或 OIDC 进行安全凭据交换。 * **加密：**在 Data 360 中加密**传输 (TLS 1.2+)** 和**静态 (AES-256)** 的数据。 * **访问控制：**强制实施最低权限角色；连接器的范围限定在特定流/主题。 * **治理：**谱系和分类元数据应用于每个记录，以实现完全可追溯性。 * **网络安全：**或者，使用 AWS PrivateLink 部署在**专用子网**中。 ##### 侧栏 ###### 及时性 * **近实时处理：**CDC 和流连接器在源更改后的几秒钟内处理事件，通常确保子分钟数据新鲜度。 * **确定性延迟：**端到端延迟取决于源吞吐量、事件批处理和网络条件，但 Data 360 保证支持对象的可预测的 SLA 驱动的延迟。 * **弹性缩放：**接收漏斗在高事件量下自动扩展，即使在数据突发高峰期间也能保持及时性。 * **运营可见性：**监控仪表板会显示事件滞后、提交时间戳和重放状态，以确保延迟和进行故障排除。 ###### 数据量 * **轻量级负载：**单个 CDC 或流事件紧凑（典型大小为 1-5 KB），针对高频更新进行了优化。 * **高变化对象：**对于易失性实体（例如个案、联系人、订单），架构师必须确保 CDC 分配和事件吞吐量与预期的更新率保持一致。 * **并行流：**Data 360 支持多流接收，以便在大型对象卷或多个源组织中水平扩展。 * **背压处理:**内置节流机制可在负载下保持摄取稳定性，而不会丢弃事件。 ###### 状态管理 每个事件包含状态和版本控制的元数据： * **重放和偏移跟踪：**每个事件都携带重放 ID 和序列元数据，支持有序交付和基于检查点的恢复。 * **模式版本：**事件标题中的版本标记可确保在源模式演变时进行向后兼容的处理。 * **幂等密钥：**每个事件都包括一个唯一的事务或提交密钥，允许 Data 360 安全地对重放和重试进行重复数据消除。 * **原子承诺：**接收漏斗仅在下游提交到 DLO 成功后将偏移标记为完成，从而确保一致性。 ###### 复杂集成场景 此模式无缝集成到高级企业架构中： * **混合摄取：**将增量增量的 CDC 与批量数据流结合起来进行完全刷新，同时保持新鲜和完整。 * **跨组织流：**多个 CRM 或 ERP 组织可以发布到同一个 Data 360 租户，通过 DMO 映射和本体对齐进行统一。 * **事件丰富：**中间件（例如 MuleSoft、事件中继）可以在流数据到达 Data 360 之前对其进行丰富、筛选或路由。 * **AI 和客服人员激活：**实时更新会在原始事件后的几秒钟内触发下游自动化，例如 Einstein 预测或 Agentforce 响应。 ##### 示例 一家全球零售企业使用 AWS Kinesis 来传输销售点和 Web 交互数据。Data 360 的 Kinesis 连接器通过 IAM 凭据进行身份验证，并不断将事件接收到事务 DLO 中。每个记录都经过模式验证，使用元数据丰富，并立即传播到客户 DMO。在几秒钟内，Einstein AI 模型就会更新客户细分，Agentforce 会触发实时 Next Best-offer 推荐 — 实现完全事件驱动的个性化循环。 ## 零复制模式 - 入站和出站 Zero Copy 不仅仅是一种集成方法 — 它是企业数据移动方式（或者更确切地说，不移动）的一个根本性转变。传统上，数据集成需要通过 ETL 漏斗复制大量记录，从而产生冗余数据存储、同步延迟和治理挑战。零复制消除了所有这一切。 在此模型中，Data 360 直接连接到 Snowflake 和数据块等外部数据平台，安全地读取和激活数据，而无需移动或复制数据。结果是在企业数据湖库和 Salesforce 生态系统之间架起无缝桥梁，提供即时访问、更低的运营开销和更强有力的数据治理。 #### 入站零复制 — Data 360 的外部平台 入站零复制功能允许 Data 360 在源位置查询和协调存储在 Snowflake 或数据块中的外部数据，例如客户简档、交易或产品数据。Data 360 不是接收文件，而是建立一个安全的元数据感知连接，利用外部仓库中的现有模式定义和安全策略。 * **直接联合：**Data 360 通过安全、优化的查询就地读取数据，无需复制。 * **统一治理：**数据仍处于源系统的安全性、访问控制和合规框架之下。 * **运营效率：**消除了 ETL 开销和存储重复，降低了成本和复杂性。 * **实时就绪：**启用按需协调 — 在 Snowflake 中更新数据时，它立即可以在 Data 360 中激活。 ##### 上下文 现代数据驱动的企业管理 Snowflake 和数据块等云规模数据湖库平台中的 PB 级客户、交易和遥测数据。这些环境是分析、AI 和合规的唯一真相来源。 Data 360 引入了 Zero CopyData Federation，允许 Data 360 直接查询和使用*现有*的外部数据集，而无需复制、转换或存储冗余数据。 这种模式使组织能够将 Customer 360 交换矩阵扩展到其现有的数据仓库或 Lakehouse 基础设施中 — 实现实时统一和激活，零重复、零延迟和零治理妥协。 ##### 问题 企业如何利用已经以 Snowflake、数据块或 Open Lake 格式（例如 Apache Iceberg）策划的丰富数据集 — 在 Data 360 中进行细分、身份解析和激活 — 而无需 ETL 漏斗或物理数据移动的成本、延迟和治理开销？ ##### 部队 此模式引入了多个架构、安全和性能注意事项： **网络和安全** * Data 360 必须与外部仓库或湖库建立安全的专用连接。 * 通常使用 Salesforce 专用连接或 PrivateLink/VPC 对等进行配置，确保流量永远不会离开客户的控制网络。 * 外部系统必须将 Data 360 IP 列入允许列表，并实施 TLS 1.2+ 加密。 **身份验证和访问控制** * 支持密钥对身份验证、OAuth 2.0 或基于身份提供商 (IdP) 的Trust委派（Data 360 充当受信客户端） * 外部系统中基于角色的访问控制 (RBAC) 对查询执行强制执行最低权限访问权限。 **性能和计算依赖性** * 查询联盟将 SQL 执行推送到 Snowflake 或数据块，利用其计算集群。 * 具有外部查询负载的性能和成本 — 细分延迟和成本与外部计算配置相关。 **不断发展的标准：文件联合** * 下一代模型文件联合利用 Apache Iceberg 或 Delta Lake 等开放表格式，使 Data 360 能够直接从对象存储中读取（例如 Amazon S3、Azure ADLS、Google Cloud Storage）。 * 通过绕过源计算层,文件联合大大减少了读取繁重的分析工作负载的延迟和成本,同时保持了模式的完整性。 **治理和合规** * 数据从不离开源平台 - 合规性、加密和保留策略仍在原始位置强制执行。 * 所有元数据、谱系和同意属性会传播到 Data 360 的 Trust 层，以确保端到端的可追溯性。 ##### 解决方案 推荐的方法是为 Snowflake、数据块或 Data 360 中的文件联合使用本机 Zero Copy 连接器。
解决方案区域 适合 评论/实施详细信息
Snowflake Zero Copy 连接器 最佳 第一方本地集成；通过 Snowflake 的数据共享或外部表 API 建立实时查询联盟。
数据块零复制连接器 最佳 支持直接实时访问增量湖中的表/视图；下拉查询在数据块运行时执行。
文件联合(Apache Iceberg/Delta/Parquet) 新兴最佳实践 Data 360 直接从对象存储中读取打开的表格式，无需外部计算依赖性。非常适合大规模数据集。
专用网络配置 推荐 使用 Salesforce 专用连接或 VPC 对等来实现安全的网络级联合。
身份验证和密钥管理 最佳实践 通过定期轮换和保管库管理，实施基于密钥或 OAuth 的安全身份验证。
模式注册 必填 Data 360 检索外部模式，并将其映射到外部数据湖对象 (外部 DLO)。
受管元数据 推荐 所有外部 DLO 继承分类、同意和谱系元数据，以实现合规性可见性。
##### 素描 下图说明了如何在 Data 360 中设置零复制连接并创建外部 DLO。 UML 图显示了实施零复制联盟的流 在这种情况下： * 管理员在 Data 360 设置（Snowflake、数据块或文件联合）中配置 Zero Copy 连接。 * 建立安全身份验证和网络路由（专用连接/OAuth/密钥对）。 * 管理员创建数据流，选择外部源 — 浏览实时数据库、模式和表格。 * Data 360 不是复制数据，而是创建外部 DLO（数据湖对象）——引用实时表或冰山文件的元数据指针。 * 外部 DLO 映射到 Customer 360 实体（例如，Customer、Transaction、Product）。 * Data 360 在细分、激活或见解计算期间查询源。 * 所有访问、查询谱系和元数据都在 Data 360 Trust 层中进行审计。 ##### 结果 * 外部数据保留在 Snowflake、数据块或 S3 中 — 没有 ETL、没有重复、没有额外的存储。 * Data 360 获得对企业级数据的实时读取访问权限，用于身份解析、计算见解和激活。 * 组织在现有治理、加密和合规框架下保持完全控制。 * 这种模式实现了真正的零复制体系结构 — 将本地访问的性能与联合存储的管理结合起来。 ###### 调用机制 调用机制取决于为实施此模式选择的解决方案。
机制 何时使用
Snowflake Federation（首选） 适用于具有受管企业数据仓库的实时高性能查询联盟。
数据块联盟 适用于具有增量或 Parquet 备份数据集的统一分析和湖滨环境。
文件联合 (Apache Iceberg / Delta Lake) 适用于对象存储中的大规模数据集，其中计算分离和成本优化是关键。
混合模式（零复制 + 摄取） 当历史数据需要一次性接收，但实时数据可以通过 Zero Copy 访问时。
###### 错误处理和恢复 * **自动重试和查询后退：**瞬态连接或查询超时使用指数回退自动重试。 * **模式不匹配隔离：**源模式（例如新列）中的更改被记录到模式拒绝队列中；管理员可以重新映射或刷新模式元数据。 * **身份验证故障转移：**如果凭据过期，Data 360 会使用存储的刷新令牌或密钥轮换策略重试连接。 * **计算可用性检测：**如果 Snowflake 或数据块群集暂停，Data 360 会暂停联合作业，并在计算恢复时重试。 * **监控集成：**所有连接运行状况、查询延迟和谱系元数据在 Data 360 监控仪表板中可见。 ###### 幂等设计注意事项 * **查询确定性：**聚合查询使用一致的快照语义，以确保在细分或激活期间读取稳定、可重复。 * **外部 DLO 版本：**每个聚合查询包含谱系跟踪的模式和时间戳元数据。 * **无偏移访问：**由于 Zero Copy 是只读的，因此它不依赖于事件偏移 — 一致性是通过外部系统的 ACID 保证（Snowflake/Delta Lake）强制执行的。 * **模式漂移管理：**在 Data 360 中维护版本化模式映射；刷新源演变的外部 DLO 元数据。 ###### 安全注意事项 在整个联盟模式中，安全性是不可或缺的 — 确保Trust或合规性不会受到损害。 * **加密：**所有数据交换使用 TLS 1.2+；外部仓库使用 AES-256 进行静态加密。 * **访问控制：**通过具有只读权限的最低权限角色访问外部表。 * **网络隔离：**专用连接或 VPC 路由可防止对公共端点的任何暴露。 * **受管数据流：**谱系、同意和分类元数据流入 Data 360 Trust 层，用于策略实施。 * **可审计性：**每个联合查询和模式访问事件都被记录下来，以实现合规性可追溯性（GDPR、CCPA、HIPAA）。 ##### 侧栏 ###### 及时性 * 针对外部仓库或存储实时执行查询，确保实时查看最新数据状态。 * 细分或激活运行反映了 Snowflake、数据块或 S3 支持的冰山表中的最新变化。 * 查询延迟取决于源系统的性能层 — 通常每个查询需要几秒到几十秒。 * 非常适合要求“全新而非复制”数据访问的分析和 AI 工作负载。 ###### 数据量 * 支持本地存储在 Snowflake 或数据块中的 PB 级数据集，无需复制。 * Data 360 仅检索结果，而非原始数据集，从而最大限度地减少网络和计算成本。 * 文件联合通过分区修剪和列下推优化大型分析扫描。 * 随仓库计算容量和 Data 360 的联合查询编排层线性扩展。 ###### 状态管理 * 外部 DLO 在 Data 360 中保留连接、模式和版本元数据。 * 模式演变通过元数据刷新周期自动管理。 * 查询谱系包含时间戳、用户身份和可追溯性执行度量。 * 没有状态摄取或偏移 — 一致性继承自外部源的 ACID 保证。 ###### 复杂集成场景 * **混合模式：**将 Zero Copy（适用于实时联盟）与摄取（适用于历史数据集）结合起来。 * **跨仓库访问权限：**Data 360 可以从一个组织内的多个 Snowflake 或数据块租户聚合。 * **AI/BI 互操作性：**外部系统（例如 SageMaker、Tableau、Power BI）可以通过反向 Zero Copy 查询 Data 360 的丰富简档。 * **文件联合扩展名:**采用开放湖格式（冰山/三角洲）的企业可以在一个联合模型下统一结构化和非结构化数据。 ##### 示例 一家全球金融企业将所有交易和交互数据存储在 Snowflake 中，同时在 Data 360 中维护客户属性和市场营销事件。使用 Zero Copy 数据联合，Data 360 通过专用连接安全连接到 Snowflake。例如，当细分作业运行时，例如“过去 30 天内支出 > 10 万美元的客户”，Data 360 会将查询推送到 Snowflake，检索聚合结果，并在 Journey Builder 中立即激活这些简档。无需复制或 ETL。此示例使用跨企业数据生态系统统一的实时聚合智能。 #### 出站零复制 - Data 360 到外部平台 出站零复制反向扩展了相同的原则。Snowflake 等外部系统可以直接查询 Data 360，而不是从 Data 360 导出或复制数据集，将其视为丰富的客户智能的联合源。 * **反向联合：**外部 Analytics 或 AI 平台可以访问 Data 360 的统一简档数据，而无需提取。 * **源位置的数据激活：**业务团队可以利用数据已经驻留的见解 — 无论是 AI 建模、报告还是客户个性化。 * **无延迟交互性：**无需批量导出或同步作业；见解可在平台之间即时流动。 * **一致的语义：**因为两个系统共享相同的本体和模式映射，所以上下文和意义在生态系统中保留。 Zero Copy 将 Data 360 的角色从*数据存储库*重新定义为*语义激活层*。它使组织能够将数据准确地保存在它属于的地方 — 在受管的高性能仓库中 — 同时仍然在 Salesforce Trust 边界内释放它的全部价值。 这种模式与现代数据网格和 AI 本地架构相一致：数据保持分散，但智能变得统一。现在，架构师可以构建更快、更精简和更合规的激活漏斗，无需复制。 ##### 上下文 现代企业越来越多地在多平台数据生态系统中运营，其中 Salesforce Data 360 支持统一的客户简档和激活，而 Snowflake 或数据块等企业数据仓库充当数据科学、机器学习和 BI 工作负载的分析主干。 Salesforce Data 360 的零复制出站共享功能无缝桥接这些环境 — 允许直接在 Snowflake 或数据块中受管、安全和实时地访问协调的 Data 360 数据，无需复制或 ETL。 这使分析师和数据科学家能够查询、可视化和建模支持市场营销、销售和服务激活的相同实时可信数据。 ##### 问题 企业如何安全高效地向外部分析系统公开 Data 360 的统一客户简档和计算指标（例如终身价值、流失风险），而不会通过传统的反向 ETL 漏斗复制数据、破坏治理或引入延迟？ ##### 部队 此模式引入了多个架构、治理和运营注意事项： * **受管安全性：**对 Data 360 数据的访问权限必须可控、精细和可审计。Zero Copy 共享使用明确的对象级访问权限，确保只有批准的数据模型对象 (DMO) 和计算见解对象 (CIO) 对指定的消费者可用。 * **显式对象选择：**管理员通过数据共享管理可共享数据，明确选择要公开的对象。这可以维护治理，并最大限度地减少风险。 * **双边配置：**Data 360 和外部仓库都需要设置。Data 360 定义了数据共享目标（雪花/数据块），而接收系统必须接受并实例化共享。 * **查询联盟模型：**接受后，外部平台通过聚合视图查询实时受管 Data 360 数据，消除了提取作业或手动刷新周期。 * **开放标准演变：**文件联合等新兴方法利用开放表格式(例如 Apache Iceberg)在存储层启用只读访问 — 提高了跨多云架构的可扩展性、性能和互操作性。 ##### 解决方案 该解决方案利用 Salesforce Data 360 的本机零复制共享与 Snowflake 或数据块等数据平台。
解决方案区域 适合 评论/实施详细信息
数据共享创建 最佳 管理员在 Data 360 中创建数据共享，添加选定的 DMO 和 CIO（例如，统一个人、客户健康得分）。
目标配置 最佳 创建数据共享目标，指定 Snowflake 或数据块帐户标识符和身份验证参数。
共享发布 最佳实践 将数据共享链接到数据共享目标，以安全地发布。
仓库验收 必填 外部管理员接受共享，将共享对象具体化为仓库中的只读视图/表。
粒度访问控制 推荐 在 Data 360 中应用基于对象和角色的权限；与基于仓库级别的访问控制保持一致。
联合查询访问权限 最佳 分析师通过标准 SQL 查询实时共享数据；与本地仓库数据结合，用于下游分析和 ML。
文件联合选项 可选 对于大型数据集，利用基于 Apache Iceberg 的联盟进行直接 S3 或增量湖读取，而不依赖于计算。
##### 素描 下图说明了从 Salesforce Data 360 到外部数据平台的调用。 UML 图表显示了实施零复制数据共享的流 **在这种情况下：** * Data 360 管理员定义的数据共享包括统一客户和计算见解对象。 * 数据共享目标（Snowflake 或数据块帐户）使用安全凭据和治理策略注册。 * Data 360 发布共享；Snowflake/Databricks 管理员接受它。 * 共享数据在仓库中显示为安全的只读表。 * 分析师、BI 工具或 ML 漏斗查询实时统一的客户数据，无需复制或同步。 * 所有访问权限都在 Data 360 Trust 层和仓库治理日志中进行审计。 ##### 结果 * 外部仓库可以实时、可查询地访问协调的 Data 360 数据。 * 消除了反向 ETL 漏斗，减少了操作负担和延迟。 * 直接在统一数据上启用 AI/ML 训练、预测建模和高级 BI。 * 保持零重复、强治理和按设计的安全访问控制。 * 完成双向零复制循环，其中入站联合和出站共享在单一治理模式下共存。 ###### 调用机制 调用机制取决于为实施此模式选择的解决方案。
机制 何时使用
Snowflake 安全数据共享（首选） 当您的企业仓库是 Snowflake 并且您需要实时、有控制地访问统一的 Data 360 数据集而没有数据移动或重复时，请使用。非常适合需要零延迟共享和本地谱系强制的分析、AI 和合规驱动的工作负载。
数据块增量共享 当下游消费者在数据块或增量湖环境中操作，需要通过开放的增量共享协议对统一或激活的数据集进行实时只读访问时使用。
外部表共享 (Apache Iceberg / Parquet) 当在对象存储（S3、ADLS 或 GCS）中维护开放格式的架构，并且需要跨分析引擎（例如 Athena、BigQuery 或 Snowflake-on-Iceberg）进行可互操作的低成本共享时使用。
数据共享 API（编程访问） 当自定义应用程序或中间件（例如 MuleSoft）必须通过 API 安全地发现、订阅或使用共享数据集时，使用基于事件的刷新通知和细粒度的访问控制。
混合共享（零复制 + 出站共享） 在实施双向交换模式时使用 - 将 Zero Copy 用于入站数据，将 Outbound Data Share 用于发布见解，确保跨企业数据平面的语义和治理一致性。
###### 错误处理和恢复 * **连接重试：**Data 360 和仓库之间的临时连接或身份验证失败的自动重试。 * **共享验证：**无效或未经授权的共享配置被隔离在**管理员审查队列**中。 * **同步健康监控：**Data 360 通过监控仪表板显示实时共享状态、查询延迟和访问日志。 * **访问权限撤销：**管理员可以立即撤销共享，禁用两端的访问，而无需残留数据副本。 * **受管审计跟踪：**记录所有配置和访问权限更改，以进行合规性验证。 ###### 幂等设计注意事项 * **一致的共享标识：**每个数据共享和数据共享目标对都有一个唯一的标识符，确保精确的治理和访问可追溯性。 * **不可更改的视图：**共享数据对象是只读的；使用者不能改变状态，确保确定性结果和合规性。 * **原子共享生命周期：**共享发布、撤销和更新是原子操作 — 完全完成或回滚。 * **重放一致性：**当 Data 360 数据刷新时，仓库侧查询总是返回最新的一致快照，消除了过时的读取。 ###### 安全注意事项 安全性是零复制共享各个方面的基础： * **身份验证**:使用 OAuth 2.0、私钥交换或身份联合 (OIDC) 建立的 Mutual Trust。 * **加密**:传输中 (TLS 1.2+) 和静态 (AES-256) 加密的数据。 * **访问控制**:对象级权限强制最低权限访问权限；由 Data 360 Trust 层管理。 * **网络安全**:数据交换通过专用网络链接进行，例如 Salesforce 专用连接或安全数据交换 API。 * **治理元数据**:每个共享对象都带有谱系、分类和同意属性，以实现完全可追溯性和监管合规。 ##### 侧栏 ###### 及时性 * **实时可用性：**共享数据反映了 Data 360 的最新状态，没有复制延迟。 * **查询新鲜度：**DMO 或 CIO 的变化会立即传播到共享仓库视图。 * **性能弹性：**查询下拉会动态适应仓库计算资源。 * **监视：**实时仪表板公开共享延迟和查询性能度量，以确保操作。 ###### 数据量 * **可扩展共享：**根据分析需求，支持粒度对象级或全域数据共享。 * **优化查询性能：**Snowflake/数据块会智能缓存共享数据，以最大限度地减少延迟。 * **存储效率：**零重复消除了冗余存储成本。 * **文件联合选项：**对于 PB 级别的数据集，基于冰山的直接共享会绕过计算并加速访问。 ###### 状态管理 * **模式演变：**当 Data 360 模型发展时，版本控制的模式确保兼容性。 * **访问状态跟踪：**在 Data 360 中维护的活动/非活动共享状态，用于生命周期治理。 * **元数据同步：**对共享对象定义的更新会自动反映在下游仓库目录中。 * **不可更改的状态保证：**仓库视图始终代表 Data 360 数据的一致时间点状态。 ###### 复杂集成场景 * **混合模式：**将 Zero Copy（适用于实时联盟）与摄取（适用于历史数据集）结合起来。 * **跨仓库访问权限：**Data 360 可以从一个组织内的多个 Snowflake 或数据块租户聚合。 * **AI/BI 互操作性：**外部系统（例如 SageMaker、Tableau、Power BI）可以通过反向 Zero Copy 查询 Data 360 的丰富简档。 * **文件联合扩展名:**采用开放湖格式（冰山/三角洲）的企业可以在一个联合模型下统一结构化和非结构化数据。 ##### 示例 跨云分析使组织能够将受管 Salesforce Data 360 数据与 Snowflake 和数据块等平台中的本地数据集结合起来，以提供完整的 360 度分析视图。通过多租户访问，不同的业务部门可以通过单独的共享安全地使用经过策划和策略控制的数据切片，而不会复制数据。然后，数据科学家可以通过直接在 Snowflake ML 或 Databricks MLflow 环境中的统一客户简档上训练模型来执行联合 AI 和机器学习。在整个过程中，内置的谱系、治理和审计功能确保所有数据访问和使用都符合企业政策和监管要求，例如 GDPR 和 HIPAA。 ## 带 Data Cloud One 的统一多组织数据平台 Data Cloud One 使具有多个 Salesforce 组织的组织（例如，由于业务部门、地区、产品线或收购）能够共享单个中央 Data 360 实例。该组织充当“家庭组织”，而其他组织（称为“伴侣组织”）可以访问该统一数据并对其采取行动，只需最少的工作、没有自定义代码和完整的治理控制。 ##### 上下文 企业通常运行多个 Salesforce 组织（例如，一个销售组织、一个服务组织、一个市场营销组织或不同区域）。每个组织可能都有自己的数据、配置和流程。在 Data Cloud One 之前，每个组织都需要自己的 Data 360 设置或复杂的自定义代码来在组织之间共享数据。Data Cloud One 通过允许具有 Data 360 的单个“主页”组织和通过低代码配置和元数据共享连接的多个“伴侣”组织来简化这一点。 ##### 问题 企业如何在所有 Salesforce 组织中一致使用统一的 Customer 360 数据(由总部组织的 Data 360 接收、协调和管理)(以便销售、市场营销、服务等都使用相同的基础数据),同时避免重复工作、自定义编码、每个组织单独的 Data 360 实例以及治理差距? ##### 部队 此模式引入了多个架构、安全和性能注意事项： * **多组织复杂性**:每个业务部门的组织可能有不同的数据、自定义对象、安全性和流程 — 保持一致的统一视图很困难。 * **重复和成本**:为每个组织运行单独的 Data 360 实例意味着额外的设置、额外的治理、额外的许可以及数据孤岛的风险。 * **治理和数据共享控制**:您需要决定每个伴侣组织可以查看和处理*哪些数据* — 您不能简单地共享“所有内容”而没有治理风险。 * **设置速度**:市场营销、销售或服务团队不能等待几周来等待自定义代码来提供跨组织的数据，他们需要点击配置解决方案。 * **数据驻留、区域注意事项**:如果家庭和陪伴组织位于不同区域，则数据存储位置或共享方式可能存在法律或监管约束。 ##### 解决方案 下表包含此集成问题的各种解决方案。
解决方案区域 适合 评论/实施详细信息
家庭组织配置 最佳 指定一个 Salesforce 组织作为配置 Data 360 的家庭组织；这将成为中央数据存储库和治理中心。
同伴组织连接 最佳 通过 Data Cloud One 应用程序，配置从家庭组织到一个或多个配套组织的配套连接，无需自定义代码。
数据空间定义 最佳实践 定义家庭组织内的数据空间，以逻辑地细分数据（例如，零售、服务、市场营销）并隔离访问边界。
数据空间共享 最佳 明确共享从家庭组织到同伴组织的选定数据空间，确保统一数据的受管、基于角色的可见性。
访问配置 必填 在同伴组织中，启用 Data Cloud One 应用程序，并为简档、见解和细分访问权限分配用户权限。
治理和策略控制 推荐 在家庭组织中集中所有接收、身份解析和 Trust 配置，维护端到端的治理。
多组织同步 最佳 家庭组织中的数据更改和计算见解通过受管同步漏斗实时反映在同伴组织中。
混合部署选项 可选 对于大型企业，多个同伴组织可以连接到一个家庭组织，同时保持本地上下文和合规边界。
##### 素描 下图说明了此模式中的事件顺序，其中 Salesforce 是数据主数据。 UML 图显示了实施 Data Cloud One 的流 **在这种情况下：** * **主页管理员**：创建数据空间并定义数据共享（选择 DMO/CIO、细分）。 * **主页管理员**:为同伴组织创建数据共享目标并配置 Trust(OAuth 客户端,允许的组织 ID)。 * **主页管理员**：将数据共享发布到目标；附加 ABAC 策略 (CEDAR) 和加密/密钥控制 (CMK，如果需要)。 * **同伴组织管理员**：接收邀请、验证身份映射并接受共享。 * **同伴组织**:Data Cloud One 网桥配置 Data Cloud One 用户，并应用权限集和数据空间可见性。 * **同伴组织应用程序(Flows/Einstein/Apex)**:查询数据图形或调用 Data Cloud One API，以读取共享 DMO 或细分。 * **激活**:同伴组织通过数据操作触发激活或写回（如果允许）。 ##### 结果 * 所有连接组织的客户数据(Customer 360)的**单一真实来源** -- -- 没有冗余的Data 360实例。 * **更快实现价值。** 伴随组织可以在几分钟内访问统一数据和 Data 360 支持的功能，而不是几周的自定义编码。 * **受控数据共享。**仅共享授权的数据空间，在保留安全和治理的同时实现业务灵活性。 * 业务功能（销售、服务、市场营销）在相同的统一数据基础上运行，在整个企业中实现一致的度量、激活和见解。 ###### 调用机制 调用机制取决于为实施此模式选择的解决方案。
机制 何时使用
Data Cloud One 本地共享（首选） 在多个 Salesforce 组织（销售、服务或 Industry Cloud）需要直接从 Data 360\ 实时访问统一客户数据时使用。这消除了复制，并实现了对 Golden Records、细分和计算见解的零延迟访问。
通过 Data Cloud One 网桥进行组织间共享 在多个业务部门或子公司在单独的 Salesforce 组织中运营，但需要从中央 Data 360 实例中共享访问常见客户数据和细分时使用。非常适合维护独立操作系统的多组织企业。
Einstein 1 平台查询 API 在 Salesforce 应用程序、Flow 或 Einstein Copilot 必须以编程方式查询或激活 Data 360 数据时使用。支持将统一简档、度量或激活结果实时检索到其他 Salesforce 应用程序，无需批量导出。
激活 Salesforce 渠道 在 Data 360 数据（细分、见解或属性）必须激活到 Marketing Cloud、Service Cloud 或 Commerce Cloud 以获得个性化、市场活动执行或客服人员帮助体验时使用。
数据图访问（语义查询层） 当您需要通过 Salesforce 数据图对统一数据模型进行语义级访问时使用 — 支持 Co pilot、AI 工作流和实时跨云分析，无需手动连接或转换。
###### 错误处理和恢复 * **跨组织同步弹性：**Data Cloud One 使用指数回退自动重试家庭和伴侣组织之间失败的同步作业，以处理暂时的网络或平台错误。 * **部分批次隔离：**失败的记录批次被隔离在家庭组织的重试队列中，直到协调成功，防止数据分歧。 * **方案拒绝治理：**模式或映射不匹配被路由到模式拒绝队列，供管理员审查和更正。 * **重放和恢复连续性：**每个同步作业都会维护偏移检查点，因此复制可以从上次成功提交开始，而不会重复。 * **集成监控：**所有失败、重试和恢复度量都在 Trust 层监控仪表板中捕获，以实现可见性和 SLA 保证。 ###### 幂等设计注意事项 * **确定性幂等密钥：**每个同步事件都带有一个唯一的密钥（组织 ID + 记录 ID + 版本号），以保证精确处理一次。 * **重放安全性：**在提交时筛选重复或重放的事件，确保一致的下游 DMO 和 CIO 更新。 * **原子提交语义：**伴随组织仅在成功下游写入后将数据标记为已提交，从而保持跨组织事务完整性。 * **冲突解决：**多源更新遵循上次写入成功或策略驱动的合并逻辑，保持谱系和一致性。 * **检查点持久性：**同步作业在 Trust 层中保留上次处理的偏移和状态，以实现安全恢复和重放。 ###### 安全注意事项 * **强身份验证：**家庭和同伴组织之间的连接使用相互 OAuth 2.0，带有通过连接的应用程序管理的自动轮换令牌。 * **粒度授权：**同伴组织只能访问通过受管数据共享策略明确共享的特定数据空间、DMO 或 CIO。 * **加密无处不在：**数据在家庭和伴侣组织之间传输 (TLS 1.2+) 和静态 (AES-256) 加密。 * **最低权限系列：**集成用户的范围仅限于所需的对象；不会传播管理或系统级权限。 * **审计与合规可见性：**所有同步事件、模式更改、凭据更新和访问权限授予都记录在 Data 360 Trust 层中，以实现完全可追溯性。 * **专用网络隔离：**可选的 Salesforce 专用连接或专用链接确保仅通过安全的内部渠道进行数据复制。 ##### 侧栏 ###### 及时性 * 主页和伴侣组织之间的同步近乎实时地发生，通常在源组织中的数据更改后的几秒钟内发生。 * Zero Copy 架构确保共享数据可在所有参与组织中即时查询 — 没有复制或批处理延迟。 * 激活和细分作业会自动反映来自任何连接组织的最新更新，保持操作新鲜度。 * 端到端延迟是确定性的，由 Data Cloud One 的编排漏斗控制，即使在负载下也能确保一致的跨组织及时性。 ###### 数据量 * 设计用于跨地区和业务部门的多租户、超大规模数据同步 — 能够管理每个组织数十亿条记录。 * 数据是引用的，而不是重复的，减少了存储空间，同时保持了全局可查询性。 * 流增量和元数据压缩优化了高更改率对象（例如联系人、订单）的带宽和提交开销。 * 通过 Trust 层的自适应负载平衡和编排，在多个同伴组织中水平扩展。 ###### 状态管理 * 每个同步数据集维护元数据谱系、版本和组织所有权上下文，以确保端到端的可追溯性。 * 检查点持久性捕获组织之间的上次同步偏移，允许在没有重复的情况下恢复。 * 跨组织的模式版本和语义对齐由 Trust 层自动控制。 * 无需手动状态重置 — 同步状态通过 Data Cloud One 编排服务维护。 ###### 复杂集成场景 * **跨组织联盟：**在统一治理模式下，支持跨多个 Data 360 租户或区域的无缝查询和激活。 * **混合同步：**将事务性更新的近实时复制与批量或归档数据的计划同步结合起来。 * **多区域治理：**支持地理上分布的数据共享，同时遵守居住、同意和合规边界。 * **AI 和自动化激活：**同步的数据立即支持 Einstein AI、Agentforce 或跨组织的自定义 ML 模型 — 实现跨组织的实时智能。 ###### 示例 全球零售组织有三个 Salesforce 组织：一个负责 Consumer Retail，一个负责 Premium Brands，一个负责 International Markets。他们在 Consumer Retail 组织中配置 Data 360（使其成为家庭组织）。通过 Data Cloud One，他们设置到高级品牌和国际市场组织的伴随连接。他们仅与每个伴随组织共享适当的数据空间（例如，“Customer 360 – Retail Profiles”和“Customer 360 – Premium Profiles”）。在 Premium Brands 组织中，市场营销团队可以查看统一的客户简档，根据计算见解（例如，高级客户终身价值）构建细分，并触发市场营销自动化 — 所有这些都由家庭组织的 Data 360 实例提供支持，没有自定义编码或数据重复。 ## 数据激活模式--数据出站 数据激活是 Salesforce Data 360 真正实现价值的地方。这是获取平台内部的统一、丰富和受管数据并使其在业务中运行的过程。实际上，这意味着安全地将策划的细分、计算见解和上下文属性从 Data 360 传递到吸引客户的系统，无论是营销自动化、服务控制台、销售支持、分析还是 AI 模型。 从技术角度看，激活模式定义了这些数据的移动方式：触发哪些渠道，发生哪些转换或映射，以及在此过程中如何实施策略。这些模式不仅仅是导出数据，而是编排实时的策略感知数据流，推动可衡量的业务结果。每个激活路线都会将 Customer 360 转化为实时运营资产 — 支持个性化、预测性决策和每个接触点的持续学习。 ### 批量激活模式 批量激活仍然是从 Data 360 导出数据最广泛使用和操作验证的方法。它以预定的节奏运行 — 定期将预定义的受众细分或属性集发布到下游平台。这种模式非常适合依赖于一致、高用量受众交付而不是即时更新的市场营销和参与工作流。 典型用例包括支持电子邮件旅程、直接邮寄市场活动或受众上传到数字广告网络。每次激活运行都会从 Data 360 的统一简档图表中提取合格的细分，应用治理和同意策略，并将输出安全地传输到目标系统。 从架构上讲，批量激活为数据分发提供了一种可预测、可审计且经济高效的方法 — 平衡了操作的简单性和企业级的可靠性。它是大规模市场活动执行的支柱，其中正确的数据在及时和控制下交付，推动了可衡量的业务影响。 #### 市场营销和广告平台的细分激活 ##### 上下文 现代营销人员跨多个参与渠道（电子邮件、广告、移动和 Web）运营，每个渠道都需要精确、及时和个性化的客户受众。Data 360 是这些受众的统一基础，将每个系统中的客户数据组合成丰富的可操作细分。 批量激活是用于将这些细分从 Data 360 导出到下游营销或广告平台的最常见的激活模式。典型目的地包括 Marketing Cloud Engagement、Google Ads、Meta 自定义受众或 LinkedIn Ads，在这些地方，可以直接针对这些策划受众执行市场活动。 ##### 问题 营销团队如何获取精确定义的受众（使用 Data 360 中统一和丰富的数据构建），并将其用于外部营销或广告系统以激活？ 例如，考虑分段：“在过去 90 天内没有购买但最近在网站上参与的高价值客户。” 营销人员需要确保准确转移这些受众，丰富相关属性（例如，忠诚度等级、地区或预测的 CLV），并定期刷新，以保持市场活动的相关性和有效性。 ##### 部队 一些技术和操作因素决定了批量激活模式： * **身份映射：**准确的受众交付需要将 Data 360 的统一个人 ID 映射到目标系统中的相应标识符，例如 Marketing Cloud 中的订阅者密钥或数字广告平台的散列电子邮件。这确保了精确匹配，并消除了定位错误。 * **属性选择和丰富：**营销人员必须超越 ID，并包含其他简档数据，例如名字、忠诚度状态、CLV 或其他个性化属性，以实现下游个性化和分析。 * **目标平台配置：**每个目标必须在 Data 360 中注册为激活目标，包括连接详细信息、身份验证和数据字段映射。这种一次性设置定义了安全连接，并控制哪些系统可以接收激活的数据。 * **治理和合规：**数据激活必须遵守同意元数据、隐私政策（例如 GDPR 或 CCPA）以及存储在统一简档中的市场营销权限。同意感知激活确保数据仅用于授权目的。 * **计划和性能：**激活通常安排在每天或每小时，以保持下游受众的最新信息。系统必须高效地处理大量和增量刷新，而不会造成重复或数据丢失。 ##### 解决方案 Data 360 中的**批量激活**流程遵循指导工作流，最大限度地减少营销人员的技术摩擦，同时保留治理和可扩展性：
解决方案区域 适合 评论/实施详细信息
细分创建 最佳 营销人员或分析师通过跨任何数据模型对象 (DMO) 或计算见解对象 (CIO) 应用筛选器，在可视细分画布中构建细分。这将定义激活的目标受众。
激活设置 最佳 用户创建激活，并选择他们刚刚构建的细分作为源。这定义了 Data 360 将导出到下游系统的受众。
激活目标选择 最佳实践 营销人员选择预配置的激活目标（例如 Marketing Cloud、Google Ads、LinkedIn Ads）。每个目标都使用身份验证凭据和字段映射在 Data 360 中注册。
有效载荷定义 必填 营销人员通过选择联系人标识符（例如电子邮件、手机、散列 ID）并选择其他简档属性（例如名字、忠诚度等级或 CLV）来定义有效载荷，以便在目标系统中丰富。
计划和频率 推荐 激活可以计划运行一次或定期运行（例如，每天或每周）。计划可确保下游受众保持同步和最新。
执行和导出 最佳 激活作业运行时，Data 360 会查询细分，收集选定属性，应用同意筛选器，并将数据导出到目标平台。对于 Marketing Cloud，这通常会导致创建或更新共享数据扩展。
治理和合规 必填 Trust 层强制实施模式验证、同意元数据和策略控制，以确保遵守数据保护和市场营销法规(例如 GDPR、CCPA)。
监控和可审计性 最佳实践 在 Trust 层监控仪表板中，通过成功/失败度量、执行日志和谱系可见性跟踪每个激活运行，从而实现操作透明度和 SLA 保证。
##### 素描 以下是步骤的摘要： * **构建分段：**营销人员或分析师使用可视细分工具创建细分，并组合任何统一数据对象的筛选器。 * **创建激活：**他们选择细分作为来源，并选择预配置的目标（例如 Marketing Cloud 或 Google Ads）。 * **定义有效载荷：**为受众导出和报告选择联系人标识符和其他简档属性。 * **计划交付：**激活计划运行一次或定期运行，使目标中的受众了解最新情况。 * **执行：**在触发时，Data 360 会查询细分，构建负载，应用同意筛选器，并将结果推送到目标系统。 UML 图显示了实施细分激活的流 ##### 结果 * Data 360 中有针对性的丰富受众细分直接在下游营销和广告平台中可用。 * 受众会自动刷新并与最新统一的客户数据同步，保持实时市场活动的相关性。 * 营销人员可以使用这些激活的受众作为 Marketing Cloud 旅程、电子邮件市场活动或 Google Ads、Meta 或 LinkedIn Ads 等数字广告平台中的自定义受众的入口来源。 * 每次激活运行都会维护端到端的谱系，确保 Data 360 与外部系统之间的合规性、可追溯性和一致性。 * 业务用户可以提供高度个性化的数据驱动体验，这些体验由完整和可信的 Customer 360 视图提供支持。 ###### 调用机制 调用机制取决于目标平台和激活目标配置。
机制 何时使用
Marketing Cloud 参与激活（首选） 在 Marketing Cloud 中执行需要动态细分、个性化属性和实时更新的电子邮件或跨渠道旅程时使用。Data 360 直接导出到共享数据扩展中，以便激活市场活动。
广告平台激活（Google Ads、LinkedIn Ads、Meta Ads） 在广告平台中激活 Data 360 细分作为自定义受众进行重新定向或类似建模时使用。支持散列标识符和同意感知交付。
CRM 激活（Sales 或 Service Cloud） 在向 CRM 用户共享丰富的客户数据、见解或倾向分数时用于个性化销售参与或服务交互。数据通过数据操作或统一简档组件作为丰富记录或见解提供。
通过 MuleSoft 或 API 进行外部激活 当激活需要到达非 Salesforce 系统（例如忠诚度、电子商务或第三方数据仓库）时使用。MuleSoft 或 Data 360 激活 API 通过基于事件的刷新选项确保安全、受策略控制的交付。
混合激活（批处理 + 事件触发） 在将计划的批量激活与基于事件的触发器组合时使用 — 为时间敏感的市场活动启用“始终开启”的个性化，例如放弃的购物车或流失风险提醒。
###### 错误处理和恢复 * **作业级故障隔离：**每个激活运行在 Data 360 编排层中作为不同的可跟踪作业执行。失败的运行会自动隔离，而不会影响其他激活或细分定义。 * **部分批处理恢复：**如果某些记录导出失败（例如，由于标识符不匹配或 API 速率限制），系统将使用具有指数回退和并行恢复的增量增量队列重试它们。 * **模式验证错误：**当出站负载属性不再与目标模式匹配时（例如，已删除的属性或重命名的字段），作业会将受影响的记录路由到模式拒绝队列，供管理员审查。 * **重放和恢复支持：**每个激活作业维护一个检查点标记 — 捕获上一个成功的批次。恢复后，处理从检查点恢复，确保没有重复或数据丢失。 * **全面监控：**所有激活事件、重试和交付度量都记录在 Trust Layer Monitoring 中，通过 Event Monitoring API 实现 SLA 跟踪、根本原因分析和自动提醒。 ###### 幂等设计注意事项 * **确定性激活密钥：**每次激活运行都使用组合幂等密钥（组合细分 ID、激活 ID 和目标系统 ID），以保证精确交付一次。 * **重放检测：**Data 360 激活服务根据先前的作业散列检查传入的有效负载，以检测和禁止重放。 * **原子导出提交：**有效负载仅在成功写入确认后提交到目标系统，防止部分更新或重复计算。 * **一致的身份解析：**由于激活取决于统一 ID（例如统一个人），因此重放或重试总是针对相同的黄金记录，以保持语义一致性。 * **激活状态持久性：**如果需要，编配层会保留激活状态元数据（时间戳、状态代码和序列令牌），以便进行确定性重新处理。 ###### 安全注意事项 * **强身份验证：**每个激活目标（例如，Marketing Cloud、Ads 或 CRM）使用 OAuth 2.0，带有令牌轮换和特定于租户的范围，以防止未经授权的数据导出。 * **属性级治理：**只有统一简档中批准的属性才有资格激活，由数据共享策略和激活模板强制执行。 * **传输中和静态加密：**所有负载在传输过程中使用 TLS 1.2+ 加密，在 Data 360 和目标平台中使用静态 AES-256 加密。 * **同意和政策执行：**激活作业遵守存储在 Data 360 Trust 层中的同意对象和数据策略。没有有效同意元数据的记录会自动从导出中排除。 * **审计和合规日志记录：**每次激活运行都会捕获发起者、发送的数据以及发送到的目标 — 在 Trust 层仪表板中启用完整的监管审计跟踪（GDPR、CCPA）。 * **最低权限访问权限：**每个目标的集成用户仅限于特定于激活的范围 — 没有管理权限或对不相关系统的写入访问权限。 ##### 侧栏 ###### 及时性 * 设计用于计划或近乎实时的批量导出（数小时延迟）。 * 支持与市场活动日历一致的时间窗口刷新。 * 激活作业可以使用数据就绪标记进行排序，以确保数据新鲜。 * 最适合数据准确性高于即时性的非交互式激活场景。 ###### 数据量 * 处理大规模数据集（每次运行数百万条记录）。 * 通过分段分区和并行导出渠道水平扩展。 * 使用基于块的批处理，以避免超时并优化吞吐量。 * 非常适合数据完整性至关重要的企业级数据漏斗。 ###### 状态管理 * 维护记录作业 ID、时间戳和序列令牌的激活状态对象。 * 使用检查点进行可重启性和故障恢复。 * 版本化的细分定义确保了激活周期之间的可重复性。 * 启用源细分、DMO 属性和目标负载之间的谱系可追溯性。 ###### 复杂集成场景 * 通过预构建的连接器与 Salesforce CRM、Marketing Cloud 和外部系统无缝集成。 * 支持多目标激活，将数据同时分发到不同的目标（例如，CRM + 广告）。 * 可以触发复合工作流，例如，批量导出，然后是下游 API 调用或 AI 评分。 * 通过数据模型治理层，优雅地处理模式演变。 ##### 示例 一个全球零售品牌想要重新吸引过去 90 天不活跃的客户。使用 Data 360，数据架构师定义了一个“休眠购物者”细分，其中包含购买历史、忠诚度等级和同意元数据。批量激活作业每晚运行，将此细分推送到 Marketing Cloud Engagement，以触发个性化的“我们想念您”电子邮件市场活动，并推送到 Ad Studio 进行重新定位。该作业利用幂等交付，确保重试之间没有重复，并且所有事件都记录在 Trust 层中，以实现审计合规性。 #### 数据导出到云存储 ##### 上下文 企业通常需要一种受管机制来将统一或细分的数据从 Salesforce Data 360 导出为标准的文件格式（例如，CSV 或 Parquet），以便进行归档、合规或下游集成。此模式支持 Data 360 到云存储导出 — 允许受信客户数据安全地流入托管在 Amazon S3、Azure Blob 或 Google Cloud Storage (GCS) 上的企业数据湖或分析漏斗。 典型用例包括： * 定期归档同意的客户数据集，以便进行监管保留。 * 导出非 Salesforce 分析工作负载的策划细分（例如 Tableau、数据块或 Power BI）。 * 启用需要结构化 CSV 或 Parquet 文件作为输入的外部机器学习模型。 ##### 问题 组织如何以受管、安全和自动化的方式将策划的细分或数据集从 Data 360 导出到云存储桶（例如 Amazon S3）中，同时保持模式完整性和合规性控制？例如，合规团队可能需要：“在有效同意的情况下提取欧盟地区所有活跃的客户，并每周将数据导出到 S3 位置进行外部审计和报告。”这需要一个可重复的、策略感知的导出漏斗，确保正确的文件格式、访问权限和交付计划，而无需手动干预或不受控制的数据移动。 ##### 部队 此导出模式由多个操作和架构因素决定： * **身份验证和授权**:导出必须遵守云提供商的 IAM 模型（例如，AWS IAM 角色或 Azure 服务主体），以确保只有授权的系统才能写入目标存储桶。 * **模式定线**:出站模式必须与目标系统的预期结构和格式相匹配（CSV、Parquet 或 JSON）。 * **数据隐私和同意**:导出的数据集必须筛选出任何缺少有效同意元数据的记录。 * **计划和新鲜度**:许多导出是定期的（每天、每周或每月），必须与企业数据刷新周期保持一致。 * **治理和监控**:每个出口都必须具有完整的谱系可见性，以确保符合数据保留和监管要求（例如 GDPR、CCPA）。 ##### 解决方案 文件导出激活模式重复使用用于接收但为数据出口配置的相同安全云存储连接器。管理员首先在 Data 360 中将云存储平台（例如 Amazon S3、Azure Blob Storage 或 GCS）注册为激活目标。然后，用户配置并执行激活工作流，将所需的细分导出到指定的文件存储路径中。
解决方案区域 适合 评论/实施详细信息
分段选择 最佳 分析师在 Data 360\ 中选择现有细分或查询定义。细分决定了导出哪些记录和属性。
激活设置 最佳 用户创建新的激活，将细分选择为源，将云存储目标（例如，S3）选择为目标。
激活目标配置 必填 管理员使用凭据、IAM 角色和输出路径预配置目标。支持的格式包括 CSV、Parquet 和 JSON。
有效载荷定义 最佳实践 通过选择所需属性（例如，ID、名称、电子邮件、区域、同意标志），定义导出模式。系统强制执行属性级治理。
计划和频率 推荐 导出可以计划以定义的节奏运行（每天、每周、每月），也可以根据需要手动触发。
执行和交付 最佳 在执行时，Data 360 会查询细分，编译导出文件，加密，并使用云提供商的 API 将其写入配置的存储桶/文件夹。
治理和合规 必填 Data 360 的 Trust 层确保所有导出遵守同意策略、模式验证和合规筛选器。
监控和可审计性 最佳实践 每个导出都在 Trust 层监控仪表板中跟踪，其中包含状态、执行日志和谱系元数据。
##### 素描 以下是步骤的摘要。 * **选择分段：**分析师或数据管理员选择要导出的统一细分。 * **创建激活：**他们创建新的激活作业，并选择注册的云存储目标。 * **定义有效载荷：**指定导出模式、属性列表和文件格式（例如 CSV）。 * **计划导出：**选择一次性或重复性计划。 * **执行作业：**Data 360 生成文件并将其安全地传递到指定的存储桶路径。 * **监控和验证：**结果和日志在 Trust 层中审查，以确保验证和合规。 UML 图显示了实施数据导出到云的流 ##### 结果 * Data 360 中有针对性的丰富受众细分直接在下游营销和广告平台中可用。 * 受众会自动刷新并与最新统一的客户数据同步，保持实时市场活动的相关性。 * 营销人员可以使用这些激活的受众作为 Marketing Cloud 旅程、电子邮件市场活动或 Google Ads、Meta 或 LinkedIn Ads 等数字广告平台中的自定义受众的入口来源。 * 每次激活运行都会维护端到端的谱系，确保 Data 360 与外部系统之间的合规性、可追溯性和一致性。 * 业务用户可以提供高度个性化的数据驱动体验，这些体验由完整和可信的 Customer 360 视图提供支持。 ###### 调用机制 调用机制取决于目标云存储平台和激活配置。
机制 何时使用
Amazon S3 激活 在 AWS 上托管企业数据湖时使用。Data 360 使用 IAM 角色或临时凭据直接写入 S3 存储桶，确保导出的安全性和可扩展性。
Azure Blob Storage 激活 当您的组织在 Microsoft Azure 上操作时使用。Data 360 使用 SAS 令牌或服务主体将加密文件写入 Blob 容器。
Google Cloud Storage (GCS) 激活 当您的数据科学或分析工作负载在 GCP 上运行时使用。Data 360 使用 OAuth 凭据，以 CSV 或 Parquet 格式将文件导出到 GCS 存储桶。
SFTP 或外部文件网关 当监管或传统系统需要通过 SFTP 端点或企业管理的文件传输平台进行安全的文件传输时使用。
混合导出（文件 + API） 当下游应用程序需要基于文件的导出进行分析和 API 触发器进行工作流编排（例如 MuleSoft 流）时使用。
###### 错误处理和恢复 * **作业级隔离：**每个导出会作为独立作业执行。失败的作业被隔离并独立重试。 * **部分文件重试：**如果某些批次上传失败（例如，由于网络中断），系统会使用指数回退重试这些块。 * **模式不匹配处理：**任何模式偏差或字段不匹配都会将记录路由到模式拒绝队列进行审核。 * **检查点和恢复：**导出作业维护检查点元数据，允许从上次成功写入开始恢复，而不会重复。 * **集成监控：**失败和重试记录在 Trust 层仪表板中，以了解可见性和 SLA 合规性。 ###### 幂等设计注意事项 * **确定性导出密钥：**每个导出作业都包括一个唯一的 ID，它由分段 ID + 目标 ID + 时间戳组成。 * **重放安全性：**使用作业散列检测重复作业执行，并跳过以防止冗余导出。 * **原子写入保证：**Data 360 仅在完全完成和校验和验证后将文件提交到目标存储桶。 * **一致的模式版本：**导出定义受版本控制，以确保运行之间的模式一致性。 * **检查点持久性：**如果需要，导出作业会保持确定性恢复和重新处理的状态 ###### 安全注意事项 * **强身份验证：**云连接器使用 OAuth 2.0、IAM 角色或服务主体进行身份验证写入。 * **加密无处不在：**数据在传输 (TLS 1.2+) 和静态 (AES-256) 中加密。 * **同意感知导出：**仅导出具有有效同意的记录，由 Trust 层策略强制执行。 * **最低权限关系：**导出用户和服务帐户仅限于指定的存储路径。 * **综合审计日志记录：**每个导出记录元数据，包括合规报告的启动器、模式、目的地和时间戳。 ##### 侧栏 ###### 及时性 * 设计用于事件驱动的即时激活，具有亚秒级延迟。 * 非常适合需要即时个性化、推荐或决策的场景。 * 以流模式操作 — 只要 Data 360 中出现合格的数据更改，就会触发触发器。 * 确保连续响应，无需等待批处理计划或分段重新计算。 ###### 数据量 * 处理大规模数据集（每次运行数百万条记录）。 * 通过分段分区和并行导出渠道水平扩展。 * 使用基于块的批处理，以避免超时并优化吞吐量。 * 非常适合数据完整性至关重要的企业级数据漏斗。 ###### 状态管理 * 每个事件操作维护自己的事件令牌和重放 ID，以便幂等处理。 * 支持检查点持久性，以在暂时失败时从上次提交的事件恢复。 * 包含内置重复数据消除逻辑和重放窗口，以确保精确激活一次的语义。 * 操作结果（成功/失败）会实时记录，并通过 Trust 层可观察性仪表板显示。 ###### **复杂集成场景** * 直接与 Salesforce 流、Einstein 1 平台事件或外部 Webhook 集成，实现即时响应链。 * 可以触发下游自动化 — 例如，即时 CRM 记录更新、AI 评分或 Marketing Cloud 消息发送。 * 支持可撰写编排：事件触发器可以调用 Data 360 操作、Apex 调用或外部 API。 * 设计用于环境感知响应必须即时发生的代理和自适应企业模式。 ###### 示例 全球零售企业需要每周提供“活跃忠诚会员”细分的出口，以便在数据块中进行分析。Data 360 管理员将 Amazon S3 配置为激活目标，并计划每周将 CSV 导出到s3://enterprise-analytics/loyalty/weekly\_exports/路径。导出作业每周日运行，生成带有 2M 以上记录的同意筛选文件。 所有事件、模式定义和谱系都记录在 Trust 层仪表板中，从而确保了透明度、可审计性和合规性。 ### 基于按需 API 的激活 基于按需 API 的激活是一种事件驱动的实时方法，可使 Data 360 见解在需要时立即可用，而无需等待批处理作业或计划导出。这种模式不是以固定的节奏发布预构建的细分，而是使外部系统、Salesforce 应用程序或 AI 客服人员能够直接调用 Data 360 API，按需获取或激活特定的受众切片、客户属性或见解。 此模式专为基于触发器的交互式体验设计，例如用户登录入口网站、客服人员打开客户记录或 AI 副驾驶启动 Next Best-Action 查询。系统不是依赖预先计算的导出，而是从 Data 360 实时动态查询或激活最新的受管数据。 关键优势是即时性和准确性： * 每个 API 调用都会访问 Data 360 的统一同意感知简档图中的最新客户智能。 * 激活功能卓越且可审计，符合 Enterprise Trust 和合规要求。 * 集成可以通过 Einstein 1 平台 API、Connect API 或激活 API 直接从 Salesforce 流、Apex 或外部系统触发。 此方法支持延迟和个性化最重要的用例，例如： * 在服务通话期间触发个性化产品优惠。 * 根据实时行为事件生成动态市场活动受众。 * 将实时决策导入在参与时刻运行的 AI 或 ML 模型。 #### 通过 Connect API 自定义应用程序集成 ##### 上下文 企业通常需要在自定义构建的应用程序（例如内部 Web 入口网站、移动应用程序或面向合作伙伴的 Web 体验）中显示协调的实时 Data 360 见解。这种模式使开发人员能够构建安全的、以 UI 为中心的解决方案，通过受管和基于 API 的访问，在 Salesforce CRM 和其他上下文系统之外使用和显示统一的客户数据。 典型用例包括： * 将 Data 360 见解嵌入内部员工仪表板或移动应用程序。 * 创建具有客户和交易可见性的合作伙伴或经销商入口网站。 * 将 Data 360 数据集成到第三方 Web 应用程序或体验层。 * 显示 Data 360 和 Einstein 1 支持的实时个性化推荐。 ##### 问题 开发人员如何构建以 UI 为中心的自定义应用程序，安全地访问和显示协调的 Data 360 数据，通常与其他 Salesforce 数据源并排使用，而不会复制或导出敏感信息？ 例如，企业可能需要构建客户入口网站，以显示来自 Data 360 的统一客户简档、交互和计算见解。 这需要单一、安全和高性能的 API 层，它可以支持前端体验、处理身份验证并确保治理，同时抽象出 Data 360 内部数据模型的复杂性。 ##### 部队 多个架构和操作注意事项会影响此模式： * **以 UI 为中心的访问权限：**主要目标是在自定义前端体验（Web 或移动设备）中显示数据，而不是执行批量提取或后端同步。 * **安全网关：**选定的 API 必须作为经过身份验证的应用程序和用户的安全和可扩展的入口点，强制执行企业级访问控制。 * **统一数据上下文：**应用程序应能够将 Data 360 数据（例如，统一简档、计算见解）与 CRM、ERP 或自定义对象数据无缝结合。 * **开发人员简单性：**API 应返回演示就绪的负载，最大限度地减少客户端层的后端处理或模式映射。 * **治理和可观察性 :**所有访问应通过具有明确谱系、身份验证和策略实施的可信、可审计渠道进行。 ##### 解决方案 解决方案是使用 Salesforce Connect REST API 作为主要集成网关，在 Data 360 的基础上构建自定义的数据驱动应用程序。 Connect API 以针对 UI 使用优化的响应格式（基于 JSON、轻量级和移动友好）提供对 Salesforce 数据的 REST 访问，包括 Data 360 的统一简档、细分和计算见解。 开发人员通过连接的应用程序进行身份验证，获取 OAuth 2.0 令牌，并调用 /query、/chatter 或 /data 等 Connect API 资源，以直接在应用程序界面中显示统一数据。 在后台，Connect API 充当其他 API 的传输基础，例如查询 API、数据图 API 和 Einstein 1 平台 API，允许开发人员在一个统一的访问模式下组合多个数据源。
解决方案区域 适合 评论/实施详细信息
身份验证和应用程序注册 必填 在 Salesforce 中为基于 OAuth 2.0 的身份验证创建连接的应用程序。配置 Data 360 API 访问权限的范围。
数据访问（简档、细分、见解） 最佳 使用 Connect API 端点 (/services/data/vXX.X/connect) 查询协调的 Data 360 数据、统一简档和计算见解。
UI 集成 最佳 前端应用程序（反应、Angular、iOS、Android）调用 Connect API，以在仪表板、入口网站或移动界面中呈现 Data 360 数据。
数据图查询 推荐 将连接 API 与数据图 API 结合起来，进行语义级查询，简化复杂的连接和关系。
实时刷新 可选 将 Connect API 与 WebSocket 或流扩展用于实时数据更新。
安全和治理 必填 使用 OAuth 范围、Data 360 策略和 Trust 层审计框架，强制执行数据可见性。
##### 素描 以下是步骤的摘要。 * **注册连接的应用程序** — 定义外部应用程序身份验证的 OAuth 范围和 API 权限。 * **获取访问令牌** — 外部应用程序执行 OAuth 2.0 身份验证，以接收 Data 360 访问的令牌。 * **调用 Connect API** — 应用程序进行 REST API 调用，以检索统一简档、细分或见解数据。 * **UI 中渲染数据** — 响应被解析并在品牌化入口网站或移动界面中呈现给用户。 * **处理错误和刷新令牌** — 应用程序实施重试逻辑和自动令牌刷新，以实现会话连续性。 * **监测和审计访问** -- -- 所有 API 调用都记录在 Trust 层中，以便可见和合规。 UML 图显示了实施 Connect API 的流 ##### 结果 开发人员可以创建与 Data 360 紧密集成的安全自定义品牌应用程序。这些应用程序可以： * 实时显示统一的客户简档和见解。 * 通过统一 API，在 CRM 或自定义对象旁边显示 Data 360 数据。 * 通过 Trust 层利用一致的身份验证、授权和审计控制。 * 为业务用户或合作伙伴提供跨体验的可信客户智能的无缝、受管访问。 ##### 调用机制 调用机制取决于目标云存储平台和激活配置。
机制 何时使用
连接 REST API（首选） 在构建需要以 UI 友好的 JSON 格式实时访问 Data 360 数据的 Web、移动或第三方应用程序时使用。
数据图形 API 在应用程序需要跨多个对象执行语义级查询时使用（例如，客户 → 交易 → 市场活动）。
查询 API 在执行类似 SOQL 的查询时使用，以高精度检索统一的数据集。
Einstein 1 Platform API 在自定义 UI 中集成 AI 驱动的见解或 Co pilot 生成的推荐时使用。
MuleSoft 或 Apex 网关包装程序 当应用程序和 Connect API 之间需要额外的编排、缓存或策略实施时使用。
###### 错误处理和恢复 * **请求限制：**自动后退，并在速率限制下重试 API 调用。 * **模式漂移保护**：使用 GraphQL 模式版本或 REST 元数据发现来适应模式更改。 * **令牌到期管理** – 应用程序自动刷新 OAuth 令牌，以避免会话中断。 * **API 故障隔离** – 在不影响并发会话的情况下，记录并重试失败的 API 调用。 * **Trust 层可观察**性 – API 成功/失败率和访问日志在 Trust 层仪表板中可见。 ###### 幂等设计注意事项 * **确定性请求 ID**:每个 API 请求都包括一个用于重放安全处理的相关 ID。 * **缓存验证标题：**ETag 和上次修改标题可防止冗余数据提取。 * **原子读取操作：**连接 API 确保每个响应反映统一数据的一致快照。 * **重放保护** – 使用请求签名和时间戳筛选重复的 API 调用。 ###### **安全注意事项** * **OAuth 2.0 身份验证：**所有 API 调用都通过连接的应用程序使用安全、短期的 OAuth 访问令牌。 * **最低权限访问权限：**API 范围仅限于必要的对象和字段。 * **加密无处不在：**TLS 1.2+ 正在传输；AES-256 加密处于静态，适用于缓存或存储的响应。 * **同意感知数据访问**:Data 360 确保所有检索的记录都遵守同意和治理策略。 * **综合审计日志记录：**每个 API 交互都与 Trust 层中的用户、应用程序和时间戳元数据一起记录。 ##### 侧栏 ###### 及时性 * 设计用于低延迟、实时 API 访问。 * 非常适合需要即时数据渲染的交互式应用程序。 * 通过缓存和索引 Data 360 源，支持近乎即时的查询响应时间。 * 不依赖于批处理计划或异步激活周期。 ###### 数据量 * 针对获取中小型数据集（例如简档、见解或最近事务）的交互式用例进行了优化。 * 通过基于光标的分页，优雅地处理分页结果。 * 不适用于高用量批量导出 — 将批量或文件导出模式用于大型数据集。 ###### 状态管理 * 应用程序通过 OAuth 令牌和本地缓存保持轻量级会话状态。 * Connect API 支持条件请求和部分刷新，以提高效率。 * API 响应包含版本标记，以实现不同版本的模式一致性。 ###### 复杂集成场景 * 将连接 API 与数据图 API 结合起来，进行跨多个域的语义查询。 * 与 Einstein 1 副驾驶或 AI API 集成，获得预测、对话体验。 * 与 Experience Cloud 或 Lightning Web 组件一起使用，进行混合 UI 开发。 * 通过 MuleSoft 扩展，以实时编排数据丰富或外部系统查找。 ##### 示例 一家跨国保险公司构建了一个客户自助服务入口网站，允许投保人查看他们的统一简档、最近的索赔和个性化优惠。该前端基于 Eact 的应用程序通过 OAuth 2.0 进行身份验证，并使用连接 REST API 和数据图 API 检索数据。所有数据均以实时、同意感知的方式显示，并通过 Data 360 Trust 层进行控制。开发人员直接在 Salesforce 中监控 API 调用和审计跟踪，确保完全合规和可观察。 #### 通过数据图 API 完成客户简档检索 ##### 上下文 企业越来越需要即时访问实时决策系统的完整客户简档，例如服务控制台、推荐引擎或个性化平台。这种模式使应用程序能够使用 Data 360 的数据图 API 近乎实时地检索预先计算的统一客户数据视图，为交互式体验提供亚秒级的响应时间。 典型用例包括： * 在客户服务或 Sales Console 中显示 360 度客户视图。 * 支持基于 AI 的“Next Best Action”或“Next Best Offer”推荐。 * 在页面加载时提供超个性化的 Web 或移动体验。 * 支持客服人员或自助环境中的会话决策。 ##### 问题 应用程序如何即时检索完整的、预先计算的统一客户视图，而不是在运行时执行缓慢的多对象查询？例如，Web 个性化引擎必须在毫秒内加载完整的客户上下文（人口统计、首选项、交易和计算见解），以选择个性化报价。传统关系查询可能需要多次连接，并导致无法接受的延迟。这需要一个 API，它提供非标准化的、现成的简档数据，可以通过单个密钥查找来检索 — 结合了速度、完整性和治理。 ##### 部队 多个运营和性能因素会影响此模式： * **速度：**响应时间必须接近实时。API 必须在毫秒内返回完整的简档，以支持同步交互。 * **完整性：**响应必须包含所有相关属性、关系和计算见解 — 理想情况下在单个负载中。 * **查找效率：**简档应该可以通过标识符（例如 customerId、contactKey 或电子邮件）检索，消除了多步骤查询。 * **数据新鲜度与延迟：**一些用例更喜欢预先计算（缓存）的数据，以提高速度；其他用例需要实时数据，接受更高的延迟。 * **治理和安全：**访问权限必须通过 Salesforce Trust 层策略进行控制，以确保遵守数据可见性和同意规则。 ##### 解决方案 解决方案是使用 Salesforce 数据图 API 检索存储为数据图记录的预先计算的、非标准化的客户视图。数据图是一种具体化的语义视图，它将多个数据模型对象 (DMO)（例如个人、事务和 ProductInterest）合并到一个只读记录中，通常表示为 JSON Blob。 开发人员可以使用 REST 端点，例如： GET /api/v1/dataGraph/{dataGraphEntityName}/{id} 通过唯一标识符检索完整记录。对于动态场景，API 支持 live=true 参数，该参数绕过具体化缓存，跨 Data 360 执行实时查询，用最小的延迟来交换最新鲜的数据。 这允许开发人员根据业务需求在即时（缓存）和即时（实时）简档检索之间进行选择。
解决方案区域 适合 评论/实施详细信息
数据图形定义 必填 架构师定义了一个数据图，它将多个 DMO 组合成一个语义实体（例如，UnifiedCustomerProfile）。
简档查找检索 最佳 应用程序调用 GET /api/v1/dataGraph/{entity}/{id}，以通过唯一 ID 或密钥检索完整的非规范化简档。
实时参数使用情况 可选 附加 ?live=true，以强制新计算，而不是缓存检索；适用于高价值决策。
身份验证 必填 通过连接的应用程序使用 OAuth 2.0，以安全地验证 API 调用。
响应解析 最佳实践 应用程序直接将 JSON 响应解析到其 UI 或决策引擎中；无需进一步连接。
缓存策略 推荐 为重复的简档查找实施短期本地缓存（例如，内存或 CDN）。
监控和可观察性 必填 使用 Trust 层仪表板监控查询性能、响应时间和策略遵守情况。
##### 素描 以下是实施流的摘要： * **定义数据图** — 数据架构师创建的数据图可以跨多个 DMO 对统一客户视图进行建模。 * **注册连接的应用程序** — 开发人员为安全 API 访问配置 OAuth 凭据。 * **调用数据图 API** — 应用程序使用数据图名称和记录 ID 发出 GET 请求。 * **流程响应** — API 返回客户简档的完整 JSON 表示。 * **渲染或行为** — 使用应用程序(UI 或引擎)使用统一数据进行个性化、推荐或服务操作。 * **监测和调整** -- 通过 Trust 层可观察性控制台审查绩效指标和访问日志。 UML 图显示了实施图形 API 的流 ##### 结果 现在，应用程序可以立即检索完整的预连接客户简档，支持实时交互，例如个性化、服务和决策自动化。 此模式可确保： * 即时决策的亚秒响应时间。 * 与 Data 360 语义模型一致的受管数据检索。 * 简化的应用程序逻辑 — 无联接，无模式协调。 * 通过 Trust 层进行可跟踪和合规的访问，以实现审计和可观察性。 ###### 调用机制 调用机制取决于目标云存储平台和激活配置。
机制 何时使用
数据图形 API（首选） 用于通过 ID 或密钥即时检索完整的预具体化简档。
包含 live=true 的数据图 API 用于需要最新数据的高价值用例（例如，欺诈检测、实时优惠），接受稍高的延迟。
连接 API（后备） 用于将数据图检索与其他 Salesforce 数据相结合的复合应用程序场景。
查询 API 在构建临时查询或分析读取而不是即时简档检索时使用。
MuleSoft API 代理 当通过企业网关路由数据图调用时，或当需要额外的编排/策略实施时使用。
###### 错误处理和恢复 * **优雅回退** – 如果实时查询失败或超过超时阈值，自动恢复到缓存的数据图检索。 * **超时管理** – 在高负载下为 API 调用实施重试和断路器逻辑。 * **无效的 ID 处理** – 为不存在的简档密钥返回标准 404 Not Found 响应；在 UI 中正常处理。 * **模式版本验证** – 验证数据图版本元数据，以防止模式演变时出现不匹配。 * 可**观察性整合**----记录信任层仪表板中的所有错误、重试和延迟,以进行SLA监测。 ###### 幂等设计注意事项 * **确定性密钥** – 每个简档检索使用稳定的 ID（例如 IndividualId）来确保可预测的、重放安全的查询。 * **缓存一致性** – 使用 ETag 或上次修改标题进行条件检索和缓存验证。 * **原子检索** \- 每个 API 响应代表具体化数据图记录的一致快照。 * **重放保护** – 确保客户端应用程序通过相关 ID 和时间戳检测重复检索。 ###### 安全注意事项 * **强身份验证** – 通过连接的应用程序的 OAuth 2.0 强制实施安全的、基于令牌的访问。 * **同意感知检索**----仅返回同意的属性;信任层自动应用同意筛选器。 * **字段级治理** – 通过 Data 360 的元数据和策略定义控制对属性的访问。 * **传输中和静态**加密 – 所有响应都使用 TLS 1.2+ 和 AES-256 加密。 * **审计和可跟踪**性 – 每个简档检索事件都记录有标识符、时间戳和策略上下文。 ##### 侧栏 ###### 及时性 * 设计用于即时检索。 * 支持对延迟稍高（亚秒）的最新数据进行实时查询。 * 针对同步决策和交互式应用程序进行了优化。 * 无需进行批量前激活或细分重新计算。 ###### 数据量 * 非常适合每个请求的**单记录查找**或小集合(几十到几百个)。 * 未针对大规模批量检索进行优化；使用批量或查询 API 进行高用量读取。 * 使用水平可扩展的缓存和预具体化来提高速度。 ###### 状态管理 * 保持轻量级、无状态的访问；每个请求都是独立的。 * 支持缓存标题，以便进行重放安全检索。 * 应用程序可以维护本地缓存或短期会话存储，以减少重复查找。 ###### 复杂集成场景 * 与 **Einstein 1**、**Connect API** 和 **MuleSoft** 无缝集成，以获得复合数据体验。 * 可以为需要即时上下文感知的**代理系统**(例如副驾驶或 AI 推理引擎)提供支持。 * 与**数据操作**相结合，以在检索或状态更改时实时触发。 * 在不影响性能或治理的情况下实现**大规模个性化**。 ##### 示例 全球电子商务平台使用 **Data 360 的数据图 API** 实时检索其推荐引擎的统一客户简档。用户登录时，应用程序调用数据图端点获取该客户的 **UnifiedCustomerProfile**，并将人口统计属性、行为信号和计算见解作为单个 JSON 负载返回。个性化引擎在毫秒内消耗此响应，以在活动会话期间确定并显示“Next Best Offer”。所有请求都通过 **Trust 层**进行管理和记录,确保整个互动过程的全面可见性、政策执行和合规。 ### 实时数据操作 实时数据操作支持在 Data 360 中更改时立即激活客户数据。这些操作无需等待计划的批量导出，而是在毫秒内将更新、见解或触发器直接推送到 Salesforce 或外部系统。当客户的状态、同意或参与度量在 Data 360 中更新时，该信号可以立即支持个性化优惠、触发 Service Cloud 自动化或更新忠诚度等级，从而确保每个客户体验反映最新、统一的事实。 此模式非常适合个性化 Web 体验、欺诈检测警报、Next Best-Action 推荐或实时 CRM 更新等**高影响、延迟**敏感的用例。它缩小了数据见解和业务操作之间的差距，将统一数据转化为即时智能。 #### 实时数据操作将客户信号转化为即时操作 ##### 上下文 现代数字体验和运营工作流需要在事件发生时立即采取上下文操作，例如，在 Checkout 期间更新客户记录，在扫描退货时调整库存，或在用户放弃购物车时提供个性化促销。**[实时数据操作](https://help.salesforce.com/s/articleView?id=data.c360_a_data_actions_cdp.htm&type=5)**允许系统调用、丰富统一 Data 360 简档和计算见解并对其采取行动，具有亚秒级到秒级的延迟，从而实现交互式个性化、操作自动化和即时决策。 ##### 问题 应用程序、UI 交互流或中间件如何在运行时调用 Data 360，以读取、计算或更新单个统一简档或触发操作（例如，发送报价、更新 CRM、启动工作流），而无需等待计划的批处理作业或重量级漏斗？ ##### 部队 若干技术、业务和治理力量形成了这一模式: * **低延迟要求：**呼叫必须在亚秒到几秒的范围内完成，以保持良好的 UX 或满足运营 SLA。 * **确定性身份解析：**请求必须可靠快速地解析为正确的统一个人简档（黄金记录）。 * **精细授权：**实时调用必须在请求时强制执行属性级策略和同意检查。 * **有效载荷最小化：**实时负载应小而集中（单个简档或小属性集），以减少延迟和成本。 * **开发人员体验：**API 必须是开发人员友好的 (REST/gRPC/GraphQL)，具有明确的模式和稳定的生产使用合同。 * **可审计性和可追溯性：**每个实时操作都必须记录谱系、用户身份和策略决策，以确保合规性。 ##### 解决方案 推荐的解决方案是在必要时使用 **Data 360 的实时数据操作**界面 (API + SDK) 与边缘缓存和最少的计算转换相结合。集成调用数据操作端点来读取或写入简档属性、计算见解或启动编排。在返回任何负载或执行操作之前，实时策略检查 (CEDAR) 和动态屏蔽会在策略实施点应用。
解决方案区域 适合 评论/实施详细信息
实时数据操作 最佳 显示单记录读/写和操作触发器的端点。通过 OAuth/JWT 进行身份验证。
身份解析 必填 将传入标识符（电子邮件、externalId、cookie）解析为内联统一个人 ID。使用带有缓存的确定性解析器。
政策执行 (CEDAR) 最佳实践 在请求时评估同意、ABAC 和屏蔽策略；根据策略决策拒绝或屏蔽字段。
边缘/缓存层 推荐 对简档片段和计算见解使用短 TTL 缓存，以减少延迟；对变更事件无效。
轻量级转换 推荐 在操作路径中应用简单丰富或计算字段；应预计算繁重转换。
动作编排 最佳 支持复杂流的同步单步操作（例如，返回优惠令牌）和异步编排（队列 \+ Webhook）。
可观察性和跟踪性 必填 将请求/响应、策略决策和谱系记录到 Trust 层/SIEM 进行审计和调试。
流量限制和限制 必填 为高流量时刻强制执行客户端配额和优雅降级策略。
##### 素描 以下是步骤的摘要。 * 客户端（UI/中间件/POS）发送带有标识符和操作类型的经过身份验证的数据操作请求。 * API 网关验证令牌、速率限制，并转发到 Data 360 操作服务。 * 操作服务解析标识符 → 统一个人 ID（快速路径缓存；回退到图表查找）。 * 策略执行 (PDP) 使用来自 PIP 的属性和请求上下文评估 CEDAR 策略。 * 如果允许，操作服务会读取任何所需的简档属性/见解，并执行光线转换。 * 操作服务同步返回响应（例如，要约标记、更新的属性）或队列异步编排并返回确认。 * 所有事件、决策和负载都记录到 Trust 层，并可以选择转发到 SIEM。 UML 图显示了实施数据操作的流 ##### 结果 * 应用程序可以立即获得对统一简档读/写和操作触发器的受策略控制的访问权限，并具有几秒到几秒的延迟。 * 启用实时个性化、决策和操作工作流（例如，优惠、客服人员帮助、库存更新），没有批量延迟。 * 所有操作都是可审计的、同意感知的，并强制实施属性级屏蔽，以保持隐私性和合规性。 ###### 调用机制 调用机制取决于目标平台和激活目标配置。
机制 何时使用
RESTful 数据操作 API 需要同步简档读取或操作响应的 Web/移动应用程序和中间件的首选。
gRPC / Binary RPC 用于具有持久连接的超低延迟企业服务或内部微服务。
GraphQL 单记录查询 当客户需要灵活的字段选择并希望最小化负载时使用。
事件触发的 Webhook 用于操作触发下游流程的异步工作流（例如，开始旅程）。
平台事件/发布订阅 用于多个系统必须对单个操作事件做出反应的扇出场景。
Edge SDK（客户端库） 用于缓存简档片段并仅在需要时调用数据操作 API 的低延迟客户端。
###### 错误处理和恢复 * **同步错误：**使用人类可读的消息和幂等标记返回结构化错误代码。 * **瞬态重试：**客户端应重试 429/5xx 响应指数后退的幂等请求。 * **策略拒绝处理：**拒绝返回明确的原因代码；策略失败时永远不会返回敏感数据。 * **异步编排失败：**编配作业移到 DLQ 并可重放；作业状态 API 允许客户端轮询或接收回调。 * **回退策略：**如果身份解析失败，则返回确定性错误和可选的建议补救措施（例如，需要 externalId）。 ###### 幂等设计注意事项 * **幂等密钥：**客户端提供用于突变操作的幂等密钥（UUID + 客户端命名空间）。 * **确定性密钥：**使用组合密钥 (UnifiedIndividualId + ActionType + TimestampWindow) 检测重复项。 * **安全重试：**将操作设计为副作用耐受或执行更新插入，而不是盲插入。 * **重放保护：**在业务窗口后保留已处理的幂等密钥并 TTL，以避免重放。 * **无国籍:**尽可能保持同步操作的状态；为异步工作流保留最小状态。 ###### 安全注意事项 * **身份验证：**OAuth 2.0（适用于服务客户的 JWT 不记名或 mTLS）；短期令牌和刷新轮换。 * **授权：**策略决策点对每个请求强制执行基于属性的访问控制 (CEDAR) 和同意检查。 * **传输和存储加密：**TLS 1.2+ 正在传输；对于任何缓存的片段或审计日志，AES-256 处于静态。 * **最低权限：**API 客户端的范围是最小权限；角色区分为读取与写入与编排。 * **数据最小化：**仅返回请求和同意的属性；对 PII/PHI 应用动态屏蔽。 * **网络控制：**或者，对于高风险操作，需要来自专用网络（专用连接、IP 允许列表）的调用。 * **审计和监控：**将请求元数据、策略决策、请求者身份和响应散列记录到 Trust 层和 SIEM。 ##### 侧栏 ###### 及时性 * 设计用于同步操作的平均延迟（在亚秒到低-单秒范围内）。 * 边缘缓存（短 TTL）和预先计算的见解减少了往返。 * 异步路径通过后台处理为繁重的任务提供了近乎即时的确认。 ###### 数据量 * 针对单记录或小批量交互（1–100 条记录）进行了优化。 * 不适用于批量导出 — 对大量使用批量激活。 * 高吞吐量使用池/连接重用和并行编排队列。 ###### 状态管理 * 同步调用的无状态请求模型；授予/事务的最低操作状态持续存在。 * 由变更事件驱动的缓存无效 — 确保 TTL 和无效信号保持缓存新鲜。 * 编配作业维护存储在 Trust 层的持久状态（jobId、状态、重试）。 ###### 复杂集成场景 * **客服人员协助：**客服人员的实时简档查找 + 计算倾向会在亚秒内返回到服务控制台。 * **POS/边缘设备：**本地 SDK + 偶尔的数据操作，用于验证促销或忠诚度状态。 * **混合流：**决策 + 异步编排的同步数据操作，以更新下游系统和触发市场活动。 * **第三方中间件：**MuleSoft 或 API 网关可以调解身份验证，丰富上下文，并实施额外的策略检查。 ##### 示例 零售移动应用程序通过调用购物者的电子邮件和购物车上下文中的**优惠资格**数据操作，确定是否在购物者点击 **Checkout** 时显示个性化的即时优惠券。该请求由 API 网关验证并转发到数据操作服务，数据操作服务使用缓存命中将电子邮件解析为统一个人 ID，通过 PDP 验证市场营销同意，并根据客户终身价值和最近购买次数评估资格。如果购物者符合资格，服务会返回签名的优惠券标记，并记录决策。当优惠券发放需要库存预订时，将触发异步编排来保留库存并通知 CRM 系统。该应用程序会立即显示优惠券，而下游更新在后台完成，Trust 层会捕获治理和合规的完整审计跟踪。 ## 引用 * [连接器和集成](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&language=en_US&type=5) * [Web 和移动 SDK](https://help.salesforce.com/s/articleView?id=data.c360_a_web_mobile_app_connector.htm&language=en_US&type=5) * [亚秒级实时摄取](https://help.salesforce.com/s/articleView?id=data.c360_a_real_time_capabilities.htm&type=5) * [自带 Lake（零复制查询）](https://help.salesforce.com/s/articleView?id=data.c360_a_byol_data_federation.htm&language=en_US&type=5) * [自带 Lake (零复制文件)](https://help.salesforce.com/s/articleView?id=data.c360_a_file_federation.htm&type=5) * [数据图形](https://help.salesforce.com/s/articleView?id=data.c360_a_data_graphs.htm&type=5) * [激活：MC 参与](https://help.salesforce.com/s/articleView?id=data.c360_a_create_marketing_cloud_activation.htm&language=en_US&type=5) * [激活：MC Personalization](https://help.salesforce.com/s/articleView?id=data.c360_a_create_mc_personalization_activation_target.htm&language=en_us&type=5) * [激活：B2C Commerce](https://help.salesforce.com/s/articleView?id=data.c360_a_b2c_commerce_activation.htm&language=en_US&type=5) * [数据共享（零复制）](https://help.salesforce.com/s/articleView?id=data.c360_a_data_shares.htm&language=en_US&type=5) * [激活：文件存储](https://help.salesforce.com/s/articleView?id=data.c360_a_add_activation_target.htm&language=en_US&type=5) * [数据操作](https://help.salesforce.com/s/articleView?id=data.c360_a_data_actions_CDP.htm&language=en_US&type=5) * [实时亚秒级数据操作](https://help.salesforce.com/s/articleView?id=data.c360_a_create_a_real_time_data_action.htm&language=en_US&type=5) * [外部激活平台](https://help.salesforce.com/s/articleView?id=data.c360_a_build_external_activation_platforms.htm&language=en_US&type=5)