现代 Salesforce 集成必须支持远远超过简单的数据交换。它们有望支持实时客户体验，协调多个系统之间的操作，并在企业级可靠地运行，同时满足严格的安全和合规要求。因此，选择正确的集成方法是一项关键的架构决策，而不是实施细节。 考虑常见的企业场景。客户在移动应用程序中完成购买，触发个性化优惠的实时资格检查。同时，必须在 ERP 系统中记录交易数据，在 Salesforce 中更新客户属性，并将分析流式传输到数据湖，而不会引入延迟、数据重复或合规风险。像这样的场景现在在现代 Salesforce 环境中很常见，Salesforce 很少孤立地运行，必须与更广泛的应用程序和数据平台生态系统无缝集成。 本指南旨在帮助架构师和开发人员清晰自信地设计这些集成。它提供了一组经过验证的集成模式,用于解决重复性的企业场景,例如流程编排、数据同步和实时数据访问,而不是专注于点对点的实施。每个模式都强调架构意图、权衡和执行模型，使团队能够做出明智的设计决策，并不断扩展。 在本文档中，您将找到：

• 代表跨流程、数据和虚拟访问场景的通用企业“文件类型”的集成模式
• 模式选择框架，帮助根据集成意图和执行时间确定正确的方法
• 关于可扩展性、弹性、治理和安全注意事项的实用指导
• 从实际 Salesforce 和 Data 360 实施中提取的最佳实践 本文档的目标是为集成提供共享架构语言，帮助团队设计平衡性能、灵活性和 Trust 的解决方案，同时与企业数据和治理战略保持一致。

本文档适用于需要将企业中其他应用程序的数据与 Salesforce Data 360（以前的 Data Cloud）集成的设计者和架构师。此内容是 Salesforce 架构师和合作伙伴许多成功实施的提炼。 要熟悉大规模采用 Data 360 可用的集成功能和选项，请阅读以下模式汇总和模式选择指南部分。架构师和开发人员应该在 Data 360 的数据交互项目的设计和实施阶段考虑这些模式详细信息和最佳实践。 如果实施正确，这些模式使您能够尽快投入生产，并拥有尽可能稳定、可扩展和免维护的应用程序集。Salesforce 自己的咨询架构师在架构审查期间将这些模式用作参考点，并积极维护和改进它们。 与所有模式一样，本内容涵盖了大多数集成场景，但不是全部。例如，虽然 Salesforce 允许用户界面 (UI) 集成，但此类集成不属于本文档的范围。

每个集成模式遵循一致的结构。这使得每个模式中提供的信息具有一致性，也使得比较模式更加容易。

• 名称:模式标识符，也指示模式中包含的集成类型。
• **上下文：**模式解决的整体集成场景。上下文提供有关用户尝试完成什么以及应用程序如何行为以支持要求的信息。
• **问题：**用问题表示，这是模式设计解决的场景。阅读本节，了解模式是否适合您的集成场景。
• **强制：**使所述场景难以解决的约束和环境。
• **解决方案：**解决集成场景的推荐方式。
• **草图：**UML 序列图，向您展示了解决方案如何解决场景。
• **结果：**解释如何将解决方案应用到集成场景的详细信息，以及它如何解决与该场景相关联的因素。本节还包含应用模式后可能出现的新挑战。
• **侧栏：**与模式相关的其他部分包含关键技术问题、模式的变体、特定于模式的注意事项等。
• **示例：**真实场景，描述了如何在真实 Salesforce 场景中使用设计模式。该示例解释了集成目标以及如何实施模式来实现这些目标。

将此表用作本文档中所含集成模式的目录。

本文档中的集成模式分为三个类别：数据、流程和可视集成。

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），这取决于哪些方面适用于您的集成场景。

此表列出了模式及其关键方面，以帮助您确定在从 Salesforce 集成到另一个系统时哪个模式最适合您的要求

此表列出了模式及其关键方面，以帮助您确定从另一个系统集成到 Salesforce 时最适合需求的模式。

此表列出了一些与中间件相关的关键术语，以及这些模式的定义。

数据接收是 Salesforce Data 360 数据生命周期中的第一步，也是最重要的一步。这是来自多个外部系统（CRM、ERP、Web、移动或第三方 API）的原始信息如何进入平台并成为统一客户视图的一部分。 正确的摄取模式取决于业务需求：

• 数据量 — 一次移动多少数据
• 延迟 — 数据必须有多新
• 源系统功能 — 系统如何连接和传递数据 Data 360 支持多种接收模式来满足这些需求：批量处理高用量负载，流式处理近乎实时的更新，基于事件的事务即时性，以及零复制接收，无需物理移动即可即时访问外部数据。 这些模式共同确保每个客户信号（无论是购买事件、点击流日志还是忠诚度更新）都高效、安全地在正确的时间范围内流入 Data 360，从而推动可信的分析和 AI 驱动的体验。

批处理接收模式是 Data 360 中大规模数据入门的支柱。它们针对批量处理数据（通常是定期或定期处理）而不是连续处理的情况进行了优化。 这些模式最适合：

• 使用现有企业记录初始化平台的历史数据加载
• 与 ERP、数据仓库或专有数据库等记录系统定期同步
• 实时新鲜不是关键，但一致性、完整性和可审计性是关键 批量接收提供了可预测的性能和操作简便性，使其成为管理 TB 结构化或半结构化数据的企业值得信赖的选择。 Data 360 提供一组生产就绪且普遍可用的**连接器**，支持本地批量接收。这些连接器简化了集成设置，减少了自定义 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 地址必须直接添加到源系统的允许列表中。 这些分层控制确保每个文件传输都在零信任、可审计的外围环境中运行，平衡了企业合规性与大规模接收所需的灵活性。

解决方案

此表包含此集成问题的解决方案。

素描

此图说明了将数据从云存储接收到 Data 360 的步骤顺序

在这种情况下：

• 管理员通过 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 中定义的连接器和计划策略。

错误处理和恢复

错误处理和恢复对于确保高用量接收操作的可靠性至关重要。

• **错误检测：**每个数据流运行都会记录 Data 360 Monitoring 中的接收错误（例如，模式不匹配、文件损坏或命名违规）。管理员可以查看和重新处理失败的批次。
• 恢复机制 360 维护检查点，以确保失败的批次不会损坏先前的摄取。在更正源问题（例如，格式错误的 CSV）后，可以配置重试。
• 模式验证.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 级系统，使用数据分区和多流编排。

端点功能和标准支持

端点的功能和标准支持取决于您选择的解决方案。

状态管理

通过数据流及其上次成功运行的时间戳跟踪状态。

• 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 策略一致的强身份验证和加密，并提供了一个可扩展的模块化基础，支持未来的扩展和方案发展。

上下文

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 的步骤顺序

在这种情况下：

• 管理员配置集成用户，并在源组织中分配连接器权限集。
• 管理员配置 Data 360 设置中的连接器（通过 OAuth/连接的应用程序连接到 Salesforce CRM 和 Marketing Cloud）。
• 管理员创建数据流，选择对象和数据扩展，选择完全或增量刷新，并设置计划。
• 在计划运行时，Data 360 会从源请求模式和增量令牌。
• 源系统返回记录（增量或完整负载）。Marketing Cloud 可能会提供提取；CRM 可能会返回 JSON/Query 结果。
• Data 360 将文件暂存到内部安全暂存区域，并根据映射的模式进行验证。
• 如果验证失败，接收日志错误，提醒管理员并停止提交。如果验证成功，Data 360 会将记录原子性地提交到目标 DLO。
• 通过谱系、运行持续时间、行数和凭据使用情况更新监控和审计日志。如果触发阈值或错误，将向管理员发出警报。

结果

核心客户关系和市场营销参与数据作为数据湖对象 (DLO) 引入 Data 360。这会产生：

• 包含简档、个案、业务机会和电子邮件/参与度量的统一数据集。
• 身份解析的基础和统一个人简档的构建。
• 为下游协调、丰富、人工智能建模和激活做好业务准备,同时保持治理和可审计性。

摄取机制

接收机制取决于 Data 360 中定义的连接器和计划策略。

错误处理和恢复

错误处理和恢复对于确保高用量接收操作的可靠性至关重要。

• **每次运行日志：**每次数据流运行都会提供成功/失败详细信息和行级错误。
• **重试和检查点：**修复源或模式问题后，可以重试失败的运行；Data 360 使用暂存和原子提交语义。
• **提醒：**为模式偏差、重复失败或增量序列差距配置警报。

幂等设计注意事项

从设计上来说，摄取是无效的 — 重新处理相同的记录不会导致重复记录。 关键策略包括：

• **变更检测：**增量提取依赖于源系统变更指标 (LastModifiedDate/系统变更数据捕获获)。验证源是否提供可靠的时间戳/标记。
• **重复数据消除：**使用唯一的业务密钥（例如 Contact.ExternalId）对 DLO 进行重复数据消除或更新插入。
• **事务提交：**记录将被暂存，并且仅在批处理成功完成时提交。

安全注意事项

在整个接收漏斗中，从身份验证到加密和访问控制，安全性都是不可或缺的。

• **身份验证和授权：**连接器使用 Salesforce 的安全集成框架，利用命名凭据和外部凭据进行身份验证，而不会暴露秘密。
• **加密：**数据在传输 (TLS 1.2+) 和静态 (AES-256) 中加密。
• **网络控制：**源存储系统（例如 S3 存储桶）必须将 Data 360 IP 列入允许列表。
• **合规性一致性：**在与客户受管密钥 (CMK) 配对时，支持企业数据保护框架，例如 GDPR、HIPAA 和 FFIEC 准则。
• **可审计性：**记录每个接收作业和凭据访问权限，以便进行可追溯性和合规性报告

侧栏

及时性

及时性取决于摄取计划和数据量。

• 理想的节奏取决于业务需求 — 对于近乎实时的市场营销触发器，每小时一次，对于大型对帐，每晚一次。
• 增量模式减少了负载和成本；完全刷新更重，可用于初始负载或主要模式更改。

数据量

• CRM 连接器针对事务和中容量数据集（数百万条记录）进行了优化。
• 对于非常大的历史卷，请考虑分阶段 ETL 进行分区和分阶段加载。

端点功能和标准支持

端点的功能和标准支持取决于您选择的解决方案。

状态管理

• **连接器状态：**数据流维护上次成功的同步时间戳和增量偏移。
• **主键策略：**首选一致的业务标识符（外部 ID），以便下游协调和更新插入具有确定性。

复杂集成场景

在高级企业架构中，此模式可以集成：

• **混合拓扑：**将 CRM 接收与流（平台事件）相结合，实现近乎实时的更新。
• **中间件编排：**当需要复杂的编排、丰富或转换前摄取时，请使用 MuleSoft 或 ETL 工具。
• **激活反馈循环：**协调的 DMO 可以通过数据操作或平台 API 触发源系统的下游更新（小心 SoD 控制）。

示例

跨国零售商将客户、联系人、个案、业务机会和 Marketing Cloud 参与度量整合到 Data 360 中，以创建统一的客户视图。入门数据包初始化核心销售和服务对象，而团队使用自定义字段（例如 Loyalty_Membershipc 和 Customer_Tierc）扩展模型，以获取忠诚度上下文。CRM 数据流在增量模式下每小时运行一次，Marketing Cloud 参与每天使用参与事件的增量提取进行同步。这些数据集通过 DLO 和身份解析进行处理，从而产生统一的客户简档，该简档结合了 CRM 和参与信号，以支持个性化和下游 AI 模型。

这些模式专为毫秒级重要场景构建，即客户交互、交易或信号必须触发即时见解或操作时。它们超越了传统的计划批量接收，实现了事件驱动的数据流，其中的信息在生成时就得到了处理。 在 Salesforce Data 360 生态系统中，“实时”不是单一模式，而是延迟模型的连续体。一端是近乎实时的同步，其中来自记录系统的更新（例如 CRM 或 ERP）在几秒钟或几分钟内反映在 Data 360 中。另一方面是真正的实时事件捕获，客户端的行为信号（例如点击、购买或移动交互）在毫秒内被接收和激活。 对于架构师来说，区别不仅仅是语义。它定义了如何设计漏斗、如何调用 API 以及如何做出下游决策。选择正确的模式（无论是近乎实时的同步还是事件流接收），都可以确保系统满足业务的操作延迟目标，同时保持数据的完整性、可扩展性和治理性。

上下文

这种模式使任何外部系统（例如自定义应用程序、物联网 (IoT) 平台、销售点 (POS) 系统或第三方服务）能够在离散事件发生时以编程方式近乎实时地将事件数据推送到 Data 360 中。

问题

开发人员如何以低延迟可靠地将单个记录或小的异步事件批量从外部应用程序发送到 Data 360，以便数据可以快速用于处理、细分和激活？

部队

这种模式提供了低延迟和更好的开发人员控制，但引入了一些技术约束和操作依赖性：

• **开发人员依赖性：**需要开发人员努力实施经过身份验证的 REST API 客户端和错误/重试逻辑 — 它不是指点单击式连接器。
• **严格的写入模式：**摄取 API 强制实施写时模式。必须定义精确的模式，并将其上传到连接器配置；所有负载必须完全合规，否则将被拒绝。
• **双重交互模式：**相同的连接器支持低延迟、逐记录更新的流 (JSON) 和较大定期同步的批量 (CSV)，架构师必须根据用例进行选择。
• **身份验证和安全：**调用必须通过 Salesforce 连接的应用程序使用 OAuth 2.0 进行身份验证（例如，服务器到服务器的 JWT 不记名流）。令牌管理、轮换和最低权限范围是强制性的。
• **运营可见性：**开发人员和平台团队必须实施响应代码、重试、死信队列和模式偏差警报的监控。
• **实时图形要求：**对于真正的即时激活（即时细分、实时 DMO 映射），目标数据模型对象 (DMO) 必须是实时数据图形的一部分；否则，事件会穿过稍微高的延迟漏斗。

解决方案

此表包含此集成问题的解决方案。

素描

此图表说明了将数据从摄取 API 摄取到 Data 360 的步骤顺序

在这种情况下：

• 外部系统通过 OAuth/JWT 向身份验证服务器请求身份验证。
• 身份验证服务器向外部系统返回访问令牌。
• 外部系统向 Data 360 接收 API 发送带有授权和 JSON 负载的数据接收 POST 请求。
• 摄取 API 通过暂存和验证模块验证请求模式和身份验证。
• 在方案/身份验证失败时：
• 错误返回到外部系统。
• 记录拒绝以进行监控和提醒。
• 成功验证时：
• 暂存并提交到数据湖对象 (DLO) 中的记录。
• 为监控记录的成功。
• 如果启用，数据会传播到实时数据图 (DMO)，触发下游工作流。
• 否则，通过标准批次或高延迟漏斗处理的数据。
• 接收 API 向外部系统确认成功。
• 监控组件会提醒管理员死信队列、拒绝率或延迟问题。

结果

外部事件数据以低延迟被接收到 Data 360 DLO 中。当目标 DMO 是实时图表的一部分时，数据可用于即时细分、客服人员工作流、AI 模型和操作激活。这使得业务能够快速响应来自任何连接的系统的事件。

摄取机制

接收机制取决于 Data 360 中定义的连接器和计划策略。

错误处理和恢复

• **即时(同步)错误：**模式/身份验证错误的 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 工作流，并更新客户细分，以推动实时个性化。

上下文

此模式支持实时从网站和移动应用程序捕获大量精细的用户交互数据，例如页面视图、按钮单击、产品印象和视频播放。它是提供即时个性化的基础，其中每个数字交互都可以动态影响用户体验并推动参与。

问题

企业如何从数字属性捕获和处理连续的行为事件流（每分钟数百万次用户交互），并使该数据在 Data 360 中立即可用，以支持实时细分、个性化和激活？

部队

此用例引入了一些需要专门构建的低延迟接收架构的设计挑战：

• **极端吞吐量 :**高流量网站或移动应用程序每分钟可以发出数百万个事件。接收层必须水平扩展，以处理该容量，而不会造成事件损失或背压，从而确保在峰值负载下一致的延迟。
• **客户侧仪表:**与服务器驱动的集成不同，此模式取决于客户端 SDK。JavaScript 信标 (Salesforce 交互 SDK) 必须嵌入每个页面，或者集成到移动应用程序的本地 SDK。这需要强大的客户端部署、版本控制和事件模式治理。
• **低延迟事件处理：**用户操作（例如“添加到购物车”或“视频播放”）必须在几秒内到达 Data 360，从而启用实时激活和上下文响应（例如，有针对性的优惠、个性化推荐）。
• **数据协调和身份解析:**捕获的事件通常包括匿名标识符（Cookie、设备 ID、会话令牌）。要支持 Customer 360 用例，必须通过 Data 360 的身份解析将这些用例映射到已知简档，并协调到 Customer 360 数据模型。

解决方案

推荐的方法是使用 Salesforce Marketing Cloud Personalization 连接器 — 专为高吞吐量行为接收设计的本机完全受管流漏斗。

素描

此图表说明了将数据从移动和 Web 渠道接收到 Data 360 的步骤顺序

在这种情况下：

• 在 Web 或移动渠道中部署 SDK（用户交互捕获）。
• 使用租户 ID、环境和同意控制配置 SDK。
• 将捕获的 JSON 事件（元数据 + 属性）流式传输到 Marketing Cloud 流式端点。
• 在 Data 360 设置中，创建并配置租户的个性化连接器。
• 将事件引入 DLO，并在 Data 360 中映射 DLO → DMO。
• 在实时图形中启用 DMO，以便立即激活。
• 监控延迟、模式一致性、同意标志、吞吐量、错误率。
• 部署到生产环境，并持续监控。

结果

行为事件的连续低延迟流从数字渠道流向 Data 360。在几秒钟内，每个用户操作都可用于实时细分、预测建模或触发的个性化，从而实现真正的自适应客户体验。

摄取机制

接收机制取决于 Data 360 中定义的连接器和计划策略。

错误处理和恢复

• **分层容错：**实施多层验证和重试机制 - 客户端 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 时，向他们提供个性化的产品推荐和动态内容。使用客户端的 Salesforce 交互 SDK，站点实时捕获页面视图、产品点击、购物车操作和视频交互。这些事件通过 Marketing Cloud Personalization 事件流和 Personalization 连接器流入 Data 360 DLO，在那里它们被建模到 DMO 中并集成到实时图形中。此架构使行为信号立即可用于细分、Einstein 驱动的个性化和 Agentforce 激活，从而实现响应式会话中客户体验

上下文

对于许多业务关键型流程，使 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 之间的持续同步，并最大限度地减少手动干预。

素描

此图表说明了将数据从 CRM 近乎实时地接收到 Data 360 的步骤顺序

在这种情况下：

• 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 之间的可靠、低延迟同步。

错误处理和恢复

• **自动故障恢复：**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 更改后的几秒钟内完成反馈循环。

上下文

现代数字企业依赖于实时事件流平台，例如 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 连接器。

素描

此图表说明了将数据从 Kafka 和 Kinesis 等事件平台近乎实时地接收到 Data 360 的步骤顺序

在这种情况下：

• 应用程序或设备将事件发布到 Kinesis 流或 MSK 主题。
• Data 360 连接器使用 AWS 凭据或 OIDC 令牌进行身份验证。
• Connector 会持续轮询或订阅流。
• 事件被暂存，为模式和策略进行验证，然后提交到数据湖对象 (DLO)。
• 如果映射，数据模型对象 (DMO) 会近乎实时地更新以激活。
• 监控层跟踪度量、模式拒绝和延迟。

结果

将结构化数据直接从 AWS Kinesis 或 MSK 持续、低延迟地引入 Data 360。数据立即可用于：

• 身份解析
• 实时细分
• Einstein AI 激活
• Agentforce 驱动的触发器 消除了对批处理 ETL 的依赖，实现了与企业事件驱动的设计一致的基于流的架构。

摄取机制

错误处理和恢复

• **自动重试：**连接器会使用指数回退重试瞬时网络或平台错误。
• **模式拒绝：**无效负载会路由到模式拒绝队列以供管理员审查。
• **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 在源位置查询和协调存储在 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 连接器。

素描

下图说明了如何在 Data 360 中设置零复制连接并创建外部 DLO。

在这种情况下：

• 管理员在 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 获得对企业级数据的实时读取访问权限，用于身份解析、计算见解和激活。
• 组织在现有治理、加密和合规框架下保持完全控制。
• 这种模式实现了真正的零复制体系结构 — 将本地访问的性能与联合存储的管理结合起来。

调用机制

调用机制取决于为实施此模式选择的解决方案。

错误处理和恢复

• **自动重试和查询后退：**瞬态连接或查询超时使用指数回退自动重试。
• **模式不匹配隔离：**源模式（例如新列）中的更改被记录到模式拒绝队列中；管理员可以重新映射或刷新模式元数据。
• **身份验证故障转移：**如果凭据过期，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 天内花费 > 10000 美元的客户”，Data 360 会将查询推送到 Snowflake，检索聚合结果，并在 Journey Builder 中立即激活这些简档。无需复制或 ETL。此示例使用跨企业数据生态系统统一的实时聚合智能。

出站零复制反向扩展了相同的原则。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 或数据块等数据平台。

素描

下图说明了从 Salesforce Data 360 到外部数据平台的调用。

在这种情况下：

• Data 360 管理员定义的数据共享包括统一客户和计算见解对象。
• 数据共享目标（Snowflake 或数据块帐户）使用安全凭据和治理策略注册。
• Data 360 发布共享；Snowflake/Databricks 管理员接受它。
• 共享数据在仓库中显示为安全的只读表。
• 分析师、BI 工具或 ML 漏斗查询实时统一的客户数据，无需复制或同步。
• 所有访问权限都在 Data 360 Trust 层和仓库治理日志中进行审计。

结果

• 外部仓库可以实时、可查询地访问协调的 Data 360 数据。
• 消除了反向 ETL 漏斗，减少了操作负担和延迟。
• 直接在统一数据上启用 AI/ML 训练、预测建模和高级 BI。
• 保持零重复、强治理和按设计的安全访问控制。
• 完成双向零复制循环，其中入站联合和出站共享在单一治理模式下共存。

调用机制

调用机制取决于为实施此模式选择的解决方案。

错误处理和恢复

• **连接重试：**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 使具有多个 Salesforce 组织的组织（例如，由于业务部门、地区、产品线或收购）能够共享单个中央 Data 360 实例。该组织充当“家庭组织”，而其他组织（称为“伴侣组织”）可以访问该统一数据并对其采取行动，只需最少的工作、没有自定义代码和完整的治理控制。

上下文

企业通常运行多个 Salesforce 组织（例如，一个销售组织、一个服务组织、一个市场营销组织或不同区域）。每个组织可能都有自己的数据、配置和流程。在 Data Cloud One 之前，每个组织都需要自己的 Data 360 设置或复杂的自定义代码来在组织之间共享数据。Data Cloud One 通过允许具有 Data 360 的单个“主页”组织和通过低代码配置和元数据共享连接的多个“伴侣”组织来简化这一点。

问题

企业如何在所有 Salesforce 组织中一致使用统一的 Customer 360 数据(由总部组织的 Data 360 接收、协调和管理)(以便销售、市场营销、服务等都使用相同的基础数据),同时避免重复工作、自定义编码、每个组织单独的 Data 360 实例以及治理差距?

部队

此模式引入了多个架构、安全和性能注意事项：

• 多组织复杂性:每个业务部门的组织可能有不同的数据、自定义对象、安全性和流程 — 保持一致的统一视图很困难。
• 重复和成本:为每个组织运行单独的 Data 360 实例意味着额外的设置、额外的治理、额外的许可以及数据孤岛的风险。
• 治理和数据共享控制:您需要决定每个伴侣组织可以查看和处理哪些数据 — 您不能简单地共享“所有内容”而没有治理风险。
• 设置速度:市场营销、销售或服务团队不能等待几周来等待自定义代码来提供跨组织的数据，他们需要点击配置解决方案。
• 数据驻留、区域注意事项:如果家庭和陪伴组织位于不同区域，则数据存储位置或共享方式可能存在法律或监管约束。

解决方案

下表包含此集成问题的各种解决方案。

素描

下图说明了此模式中的事件顺序，其中 Salesforce 是数据主数据。

在这种情况下：

• 主页管理员：创建数据空间并定义数据共享（选择 DMO/CIO、细分）。
• 主页管理员:为同伴组织创建数据共享目标并配置 Trust(OAuth 客户端,允许的组织 ID)。
• 主页管理员：将数据共享发布到目标；附加 ABAC 策略 (CEDAR) 和加密/密钥控制 (CMK，如果需要)。
• 同伴组织管理员：接收邀请、验证身份映射并接受共享。
• 同伴组织 Cloud One 网桥配置 Data Cloud One 用户，并应用权限集和数据空间可见性。
• 同伴组织应用程序(Flows/Einstein/Apex):查询数据图形或调用 Data Cloud One API，以读取共享 DMO 或细分。
• 激活:同伴组织通过数据操作触发激活或写回（如果允许）。

结果

• 所有连接组织的客户数据(Customer 360)的单一真实来源 -- -- 没有冗余的 Data 360 实例。
• 更快实现价值。 伴随组织可以在几分钟内访问统一数据和 Data 360 支持的功能，而不是几周的自定义编码。
• **受控数据共享。**仅共享授权的数据空间，在保留安全和治理的同时实现业务灵活性。
• 业务功能（销售、服务、市场营销）在相同的统一数据基础上运行，在整个企业中实现一致的度量、激活和见解。

调用机制

调用机制取决于为实施此模式选择的解决方案。

错误处理和恢复

• **跨组织同步弹性：**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 中的批量激活流程遵循指导工作流，最大限度地减少营销人员的技术摩擦，同时保留治理和可扩展性：

素描

以下是步骤的摘要：

• **构建分段：**营销人员或分析师使用可视细分工具创建细分，并组合任何统一数据对象的筛选器。
• **创建激活：**他们选择细分作为来源，并选择预配置的目标（例如 Marketing Cloud 或 Google Ads）。
• **定义有效载荷：**为受众导出和报告选择联系人标识符和其他简档属性。
• **计划交付：**激活计划运行一次或定期运行，使目标中的受众了解最新情况。
• **执行：**在触发时，Data 360 会查询细分，构建负载，应用同意筛选器，并将结果推送到目标系统。

结果

• Data 360 中有针对性的丰富受众细分直接在下游营销和广告平台中可用。
• 受众会自动刷新并与最新统一的客户数据同步，保持实时市场活动的相关性。
• 营销人员可以使用这些激活的受众作为 Marketing Cloud 旅程、电子邮件市场活动或 Google Ads、Meta 或 LinkedIn Ads 等数字广告平台中的自定义受众的入口来源。
• 每次激活运行都会维护端到端的谱系，确保 Data 360 与外部系统之间的合规性、可追溯性和一致性。
• 业务用户可以提供高度个性化的数据驱动体验，这些体验由完整和可信的 Customer 360 视图提供支持。

调用机制

调用机制取决于目标平台和激活目标配置。

错误处理和恢复

• **作业级故障隔离：**每个激活运行在 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）注册为激活目标。然后，用户配置并执行激活工作流，将所需细分导出到指定的文件存储路径中。

素描

以下是步骤的摘要。

• **选择分段：**分析师或数据管理员选择要导出的统一细分。
• **创建激活：**他们创建新的激活作业，并选择注册的云存储目标。
• **定义有效载荷：**指定导出模式、属性列表和文件格式（例如 CSV）。
• **计划导出：**选择一次性或重复性计划。
• **执行作业：**Data 360 生成文件并将其安全地传递到指定的存储桶路径。
• **监控和验证：**结果和日志在 Trust 层中审查，以确保验证和合规。

结果

• Data 360 中有针对性的丰富受众细分直接在下游营销和广告平台中可用。
• 受众会自动刷新并与最新统一的客户数据同步，保持实时市场活动的相关性。
• 营销人员可以使用这些激活的受众作为 Marketing Cloud 旅程、电子邮件市场活动或 Google Ads、Meta 或 LinkedIn Ads 等数字广告平台中的自定义受众的入口来源。
• 每次激活运行都会维护端到端的谱系，确保 Data 360 与外部系统之间的合规性、可追溯性和一致性。
• 业务用户可以提供高度个性化的数据驱动体验，这些体验由完整和可信的 Customer 360 视图提供支持。

调用机制

调用机制取决于目标云存储平台和激活配置。

错误处理和恢复

• **作业级隔离：**每个导出会作为独立作业执行。失败的作业被隔离并独立重试。
• **部分文件重试：**如果某些批次上传失败（例如，由于网络中断），系统会使用指数回退重试这些块。
• **模式不匹配处理：**任何模式偏差或字段不匹配都会将记录路由到模式拒绝队列进行审核。
• **检查点和恢复：**导出作业维护检查点元数据，允许从上次成功写入开始恢复，而不会重复。
• **集成监控：**失败和重试记录在 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 的激活是一种事件驱动的实时方法，可使 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 模型。

上下文

企业通常需要在自定义构建的应用程序（例如内部 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，允许开发人员在一个统一的访问模式下组合多个数据源。

素描

以下是步骤的摘要。

• 注册连接的应用程序 — 定义外部应用程序身份验证的 OAuth 范围和 API 权限。
• 获取访问令牌 — 外部应用程序执行 OAuth 2.0 身份验证，以接收 Data 360 访问的令牌。
• 调用 Connect API — 应用程序进行 REST API 调用，以检索统一简档、细分或见解数据。
• UI 中渲染数据 — 响应被解析并在品牌化入口网站或移动界面中呈现给用户。
• 处理错误和刷新令牌 — 应用程序实施重试逻辑和自动令牌刷新，以实现会话连续性。
• 监测和审计访问 -- -- 所有 API 调用都记录在 Trust 层中，以便可见和合规。

结果

开发人员可以创建与 Data 360 紧密集成的安全自定义品牌应用程序。这些应用程序可以：

• 实时显示统一的客户简档和见解。
• 通过统一 API，在 CRM 或自定义对象旁边显示 Data 360 数据。
• 通过 Trust 层利用一致的身份验证、授权和审计控制。
• 为业务用户或合作伙伴提供跨体验的可信客户智能的无缝、受管访问。

调用机制

调用机制取决于目标云存储平台和激活配置。

错误处理和恢复

• **请求限制：**自动后退，并在速率限制下重试 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 加密处于静态，适用于缓存或存储的响应。
• 同意感知数据访问 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 调用和审计跟踪，确保完全合规和可观察。

上下文

企业越来越需要即时访问实时决策系统的完整客户简档，例如服务控制台、推荐引擎或个性化平台。这种模式使应用程序能够使用 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 对统一客户视图进行建模。
• 注册连接的应用程序 — 开发人员为安全 API 访问配置 OAuth 凭据。
• 调用数据图 API — 应用程序使用数据图名称和记录 ID 发出 GET 请求。
• 流程响应 — API 返回客户简档的完整 JSON 表示。
• 渲染或行为 — 使用应用程序(UI 或引擎)使用统一数据进行个性化、推荐或服务操作。
• 监测和调整 -- 通过 Trust 层可观察性控制台审查绩效指标和访问日志。

结果

现在，应用程序可以立即检索完整的预连接客户简档，支持实时交互，例如个性化、服务和决策自动化。 此模式可确保：

• 即时决策的亚秒响应时间。
• 与 Data 360 语义模型一致的受管数据检索。
• 简化的应用程序逻辑 — 无联接，无模式协调。
• 通过 Trust 层进行可跟踪和合规的访问，以实现审计和可观察性。

调用机制

调用机制取决于目标云存储平台和激活配置。

错误处理和恢复

• 优雅回退 – 如果实时查询失败或超过超时阈值，自动恢复到缓存的数据图检索。
• 超时管理 – 在高负载下为 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 期间更新客户记录，在扫描退货时调整库存，或在用户放弃购物车时提供个性化促销。**实时数据操作**允许系统调用、丰富统一 Data 360 简档和计算见解并对其采取行动，具有亚秒级到秒级的延迟，从而实现交互式个性化、操作自动化和即时决策。

问题

应用程序、UI 交互流或中间件如何在运行时调用 Data 360，以读取、计算或更新单个统一简档或触发操作（例如，发送报价、更新 CRM、启动工作流），而无需等待计划的批处理作业或重量级漏斗？

部队

若干技术、业务和治理力量形成了这一模式:

• **低延迟要求：**呼叫必须在亚秒到几秒的范围内完成，以保持良好的 UX 或满足运营 SLA。
• **确定性身份解析：**请求必须可靠快速地解析为正确的统一个人简档（黄金记录）。
• **精细授权：**实时调用必须在请求时强制执行属性级策略和同意检查。
• **有效载荷最小化：**实时负载应小而集中（单个简档或小属性集），以减少延迟和成本。
• **开发人员体验：**API 必须是开发人员友好的 (REST/gRPC/GraphQL)，具有明确的模式和稳定的生产使用合同。
• **可审计性和可追溯性：**每个实时操作都必须记录谱系、用户身份和策略决策，以确保合规性。

解决方案

推荐的解决方案是在必要时使用 Data 360 的实时数据操作界面 (API + SDK) 与边缘缓存和最少的计算转换相结合。集成调用数据操作端点来读取或写入简档属性、计算见解或启动编排。在返回任何负载或执行操作之前，实时策略检查 (CEDAR) 和动态屏蔽会在策略实施点应用。

素描

以下是步骤的摘要。

• 客户端（UI/中间件/POS）发送带有标识符和操作类型的经过身份验证的数据操作请求。
• API 网关验证令牌、速率限制，并转发到 Data 360 操作服务。
• 操作服务解析标识符 → 统一个人 ID（快速路径缓存；回退到图表查找）。
• 策略执行 (PDP) 使用来自 PIP 的属性和请求上下文评估 CEDAR 策略。
• 如果允许，操作服务会读取任何所需的简档属性/见解，并执行光线转换。
• 操作服务同步返回响应（例如，要约标记、更新的属性）或队列异步编排并返回确认。
• 所有事件、决策和负载都记录到 Trust 层，并可以选择转发到 SIEM。

结果

• 应用程序可以立即获得对统一简档读/写和操作触发器的受策略控制的访问权限，并具有几秒到几秒的延迟。
• 启用实时个性化、决策和操作工作流（例如，优惠、客服人员帮助、库存更新），没有批量延迟。
• 所有操作都是可审计的、同意感知的，并强制实施属性级屏蔽，以保持隐私性和合规性。

调用机制

调用机制取决于目标平台和激活目标配置。

错误处理和恢复

• **同步错误：**使用人类可读的消息和幂等标记返回结构化错误代码。
• **瞬态重试：**客户端应重试 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 层会捕获治理和合规的完整审计跟踪。

• 连接器和集成
• Web 和移动 SDK
• 亚秒级实时摄取
• 自带 Lake（零复制查询）
• 自带 Lake (零复制文件)
• 数据图形
• 激活：MC 参与
• 激活：MC Personalization
• 激活：B2C Commerce
• 数据共享（零复制）
• 激活：文件存储
• 数据操作
• 实时亚秒级数据操作
• 外部激活平台