Salesforce 数据云的基础

正如我们在第1章中看到的，Salesforce数据云可以解决许多问题。虽然它需要一些初始设置，但在日常操作中，数据云将由管理员进行管理。除了管理员之外，可能还有许多不同的最终用户需要访问数据云中的统一数据。

其中许多Salesforce最终用户可能每天都在Sales Cloud或Service Cloud应用程序中工作，而这些用户可能不需要直接访问数据云应用程序。相反，数据云中的数据可能会作为数据增强（例如相关列表）显示在他们的Sales Cloud或Service Cloud应用程序中。

除了在Sales和Service云应用程序中显示数据之外，Salesforce数据云还常用于营销目的。在这些场景中，可能会有更多的最终用户在数据云应用程序中工作。可以预见的是，数据分析专家、营销专家和营销经理将直接或间接负责在数据云中创建和激活细分市场。

在最终用户能够访问数据云应用程序和数据之前，数据云平台需要进行配置并为最终用户准备好。数据云的设置和首次实施可能由于多种原因而具有挑战性。一方面，将来自许多不同内部和外部来源的大量异构数据整合在一起通常需要大量的努力、多种技能组合以及各部门和数据所有者之间的协调。

数据云实施团队的角色可能包括项目经理、业务分析师、质量保证（QA）专家、Salesforce管理员和Salesforce开发人员，以及一个或多个架构师。数据云实施需要一些明确定义的专业角色，但团队中的个人承担多个角色并不罕见。了解团队成员的各种角色很重要，因为这些构建者将需要访问数据云应用程序，以便为最终用户设置平台。

我们将在后续章节中更多地了解Salesforce数据云的实施，但需要认识到的是，由于数据云平台相对较新，具备丰富Salesforce数据云经验的专家并不多。如果您是希望增强当前技能或寻找新职业角色的个人，这是个好消息。

有许多与Salesforce相关的角色可以通过学习Salesforce数据云受益（见图2-1）。应用程序开发人员也有机会创建新应用程序来支持这些Salesforce特定的最终用户，并在Salesforce AppExchange上提供这些数据云应用程序。

拥有Salesforce核心或Salesforce营销云背景对于许多数据云角色来说当然有帮助，但对于具有公共云技术和平台经验的数据架构师和数据工程师来说，也有很好的机会，这些技术合作伙伴包括Amazon、Databricks、Google、Microsoft和Snowflake。云数据架构师通常更了解如何为基于使用量计费的平台设计解决方案，这对Salesforce数据云非常重要，因为这是Salesforce首次推出的按使用量计费的产品。

从成本和架构的角度来看，转向像Salesforce数据云这样的基于使用量的平台对一个组织来说是合理的。让我们分别考虑这两方面。

从成本角度来看，有些持有许可证的用户可能经常使用传统的基于许可证的平台，而其他用户可能很少登录。但无论他们的使用频率如何，您为拥有相同许可证的每个人支付的费用是一样的。然而，使用基于使用量的平台，您是根据资源的实际使用情况收费的，例如存储和计算资源。我们刚刚也讨论了，可能有许多Salesforce用户在从未登录数据云平台的情况下，仍然从数据云中获得下游价值。

从架构的角度来看，转向基于使用量的平台也有好处。在基于使用量的平台上，您越优化架构并以可扩展的方式构建它，您就能节省越多的资金。实际上，您通过构建更高效和有效的架构获得了成本节约的奖励。

架构师在数据云实施项目中扮演着关键角色，本章对于那些有志成为数据云架构师的人来说将特别有吸引力。整本书都围绕您可以用来了解Salesforce数据云平台的概念和细节展开，但如果您希望成为Salesforce数据云架构师，您需要确保自己对Salesforce架构的限制有一个很好的理解。您可以在Paul McCollum的《Practical Salesforce Architecture》（O'Reilly, 2023）中找到对一般Salesforce数据和架构限制的良好解释。

在本章中，我们将重点讨论一些数据云的基础概念。我们将从一些针对架构师的特别考虑开始，然后介绍Salesforce数据云的功能方面和技术细节。最后，我们将看看数据云的一些独特数据存储功能。

架构师的特别考虑事项

在2012年至2016年之间，我们进入了一个数字数据增长的时代，称为Zettabyte时代，这一时期在人类和计算机科学史上以全球IP流量的巨大增长为标志。这些形式的数字数据来自许多来源，包括安全摄像头存储的数据、手机通话中的语音数据、公共互联网数据以及在线流媒体服务的数据。

如今，创建、捕获、复制、存储和消费的数据量每周超过两泽字节。一泽字节相当于一万亿千兆字节，因此公司难以为终端用户提供访问所有这些数据的能力也就不足为奇了，这些数据需要被精炼、分析，并以可操作的方式提供。因此，许多组织已经开始了一个转型过程，旨在实施新的数据战略，以更好地从数据中获得洞察，并学习如何在大规模上构建数据驱动的产品。

2020年，Salesforce 开始从头构建其数据云平台，为组织提供一个平台，将大量客户数据收集到单一事实来源 (SSOT) 中，用于协调、统一和培育信息。Salesforce 在 Amazon Web Services (AWS) 上构建了其数据云数据湖存储。此外，Salesforce 开始了一项新的努力，以现代化其 Salesforce 核心平台的数据基础设施，该平台现在正在从 Oracle 数据库迁移到托管在 AWS 上的 Salesforce Hyperforce。

对于在 Salesforce 生态系统中工作的架构师来说，这是一个激动人心的时刻，因为 Salesforce 正在继续创新并为现代时代重新架构其平台。一旦完全实施，Salesforce 的单一平台方法将简化 Salesforce 的功能，并更好地支持新的人工智能（AI）可能性，包括新的 Einstein 功能。对于架构师来说，了解这些变化背后的驱动因素以及构建数据驱动平台的挑战非常重要。

数据驱动模式的用例

构建现代数据系统的复杂性在于，许多新的架构数据模式正在出现，以应对各种现代数据驱动的用例。例如，事件处理需要支持流数据摄取和转换的存储模式（我们简称为摄取和转换）。分析需要批量摄取和批量转换以及列存储的支持。Salesforce 已经确定了六个由数据云支持的主要数据驱动模式用例（见图2-2）。

这些数据范式如何由 Salesforce 数据云存储层支持的底层技术细节在“存储分层”中有所描述。现在，让我们来看一下 Salesforce 在构建数据驱动平台时需要解决的主要架构考虑因素。

构建数据驱动平台的考虑事项

Salesforce 确定了一些用于构建数据云的基础概念数据原则：

• 为数据访问设置冷、温、热数据存储层
• 可互换的事件和表
• 多模式访问
• 支持机器学习 (ML) 和分析
• 用于分析的高性能查询层
• 所有数据都带有 Salesforce 元数据类型

存储大量以 PB（拍字节）为单位的数据非常昂贵，因此 Salesforce 面临的挑战是构建一个能够利用冷存储节省成本的平台，同时仍然能够快速为用户提供最相关的数据。最重要的是，不同层级的冷、温、热存储之间的转换对最终用户来说必须是无缝的。

创建可互换的事件和表是 Salesforce 实施的第二个原则，这是一个革命性的概念。事务数据和分析数据通常是分开存储的，但要获得有意义的客户 360 度视图，就需要一种查看所有数据的方式。为了实现这一目标，Salesforce 为每个事件生成表中的一行，包括数据云操作，如洞察和细分。

数据云是一个开放且可扩展的平台——一个基于开源技术的系统，这意味着数据不是被锁定的。数据存储格式不是专有的；您可以通过不同的模式访问数据，如结构化查询语言 (SQL)、Salesforce 对象查询语言 (SOQL)、Salesforce REST API、Webhooks、平台事件、旅程事件、Lightning 组件等。

确保数据云能够支持机器学习和高性能查询以进行分析是 Salesforce 在构建新平台时的首要考虑之一。作为设计的一部分，快照和分区被构建以提供时间旅行等功能，使您可以回到之前的数据版本，而无需做任何特别的操作。

Salesforce 数据云特有的最重要的数据原则之一是平台上的所有内容都需要支持 Salesforce 商业用户体验。所有数据云数据都带有 Salesforce 元数据类型，因此 Salesforce 系统的用户体验是一致的。在数据云中设计这种一致的用户体验，作为整体 Salesforce 系统设计的一部分，是数据云架构师的责任，Salesforce 提供了许多资源来协助架构师履行这一角色。Salesforce Well-Architected 系列于 2023 年初启动，已经发布了大量的知识内容。

Salesforce Well-Architected 资源

Well-Architected 框架的概念由 AWS 于 2015 年确立，其他云服务提供商随后也推出了类似的框架。这些 Well-Architected 框架提供了有关如何在其相应平台上设计和部署工作负载的最佳实践和指导。

类似于其他 Well-Architected 框架，Salesforce Well-Architected 通过白皮书形式提供指导。然而，Salesforce 与其他平台有些不同，因此其 Well-Architected 框架版本也有所不同。例如，在每篇 Salesforce Well-Architected 白皮书的结尾，您会发现一个相关工具部分和一个相关资源部分。

Salesforce Well-Architected 是 Salesforce 内部产品专家、工程团队成员以及 Salesforce 生态系统中的思想领袖之间合作的结果。该框架围绕“值得信赖、易用和适应性强”这三个主要概念构建。

如果您的目标是成为 Salesforce 数据云架构师，那么您需要熟悉 Salesforce Well-Architected 资源。相关工具部分将为您提供有关可以在 Salesforce 中利用的实际功能的详细信息，以帮助改进您的解决方案，并且该部分中的所有内容都与关键主题相对应。在相关资源部分，您将找到可以用来更好地理解核心概念并实施所学内容的文档列表。Salesforce 创建了这些 Well-Architected 白皮书和资源，旨在确保所有使用 Salesforce 产品构建架构的人都知道健康的解决方案应该是什么样子的。

数据云技术能力图

Salesforce 架构师还可以访问 Salesforce 模板库，其中包括 Salesforce 数据模型和预构建的工件。其中一个工件是 Salesforce 数据云技术能力图一级文档和实施图。它展示了平台的技术能力以及支持这些技术能力的产品组合。根据 Salesforce 能力图，Salesforce 数据云有五个主要的技术能力。其中两个由 Salesforce 管理，另外三个可供最终用户访问（见图 2-3）。

数据湖仓和大数据处理在“引擎盖下：数据云技术细节”中有所描述。其他三个技术能力中的许多功能是数据云最终用户可以直接访问的，这将是本书中我们主要关注的内容。

数据云的关键功能方面

Salesforce 数据云使您能够连接并协调大量数据，从而创造价值。那么，最终用户如何利用数据云的关键功能方面来实现这一目标呢？数据云提供的功能包括构建连接器和数据摄取、数据转换和建模，以及创建实时单一事实来源（SSOT）（见图 2-3）。这个实时的 SSOT 可以个性化体验，例如实时推荐、实时服务机器人和实时销售互动。

为了更好地理解 Salesforce 数据云的运作原理，让我们首先回顾一些通用的关键数据概念，然后将其与数据云生命周期的五个主要步骤关联起来。我们将简要讨论这五项活动，这些活动是数据云平台中创造价值的基石。我们还将涉及一些关于连接多个 Salesforce 云的重要要点，最后简要概述 Salesforce AppExchange 在数据云中的作用。

总体而言，本节是对数据云关键功能方面的简要介绍。正如我们将在后续章节中发现的那样，数据云用户可以使用多种数据连接器来设置数据流。这些连接器从 Salesforce 内部摄取数据，也将外部来源的数据摄取到数据云中。数据摄取和存储是第 6 章的主题。

第 7、8 和 9 章分别详细介绍了数据建模、数据转换和数据映射。此外，CDP 处理支持的实时 SSOT 功能是第 10 章的主题。

第 11、12 和 13 章详细描述了如何从数据云中提取价值。这些章节介绍了数据云增强、数据操作、细分和激活，以及利用数据云数据的 Einstein 功能等功能。

通用关键数据概念

目前每周生成和存储的超过两泽字节的数据包括非结构化、半结构化和结构化数据类型的组合。结构化数据通常是可以量化的数据，可以捕获在行列关系数据库中。例如包括地址详情和其他人口统计信息等第一方数据。

半结构化数据比结构化数据更灵活，但它确实具有一些属性，如标签或元数据，使其更易于组织，而非结构化数据没有关联的数据结构或模型。逗号分隔值（CSV）、可扩展标记语言（XML）和 JavaScript 对象表示法（JSON）是常见的半结构化格式。非结构化数据的示例包括 PDF、文本文件、社交媒体内容、传感器数据、照片和音频文件。按数量计算，大多数数据都是非结构化数据。

由于数据量巨大、数据生成和摄取的速度以及数据格式的多样性，寻找利用这些大量数据的方法需要不同的架构模式。

之前，我们探讨了 Salesforce 数据云支持的六个数据模式用例以及 Salesforce 团队在构建数据云时所考虑的因素。现在，让我们从描述将被摄取、处理并提供给数据云最终用户以提取价值的数据的角度来审视数据云。理解数据如何创造价值非常重要，因为创造是数据云发挥其作用的核心（见图 2-4）。

所有数据通常由六个维度因素描述，这六个因素被统称为数据的六个V。以下是对它们的详细解释：

可变性（Variability）
这是数据的一致性；包括数据的质量、格式和含义。换句话说，可变性是指数据点之间以及与分布中心的距离。某些数据，如温度计读数，可能每小时记录一次，间隔非常规律。而其他数据可能只在触发事件（如运动探测器激活）发生时记录。你不太可能在源头上影响可变性，但了解数据的预期可变性往往是影响其他特征的一个因素。一个例子是，根据已知的数据源可变性，决定要设置的摄取速度（例如批量或流式处理）。

速度（Velocity）
这是数据生成、摄取和处理的速度。在光谱的一端，是低速率的数据，使用批量处理来定期摄取和处理数据。而在另一端，是用于高速度数据（如物联网（IoT）设备和移动应用程序数据）的实时或近实时处理。高速度数据不一定比低速度数据有更多的价值，特别是因为以更高速度摄取数据会增加成本。考虑你的用例是否需要更高的速度，或较低速度的批量摄取是否足以满足你的需求。

体量（Volume）
这是生成、摄取和存储的数据量。不同的数据源可能具有不同的体量。例如，IoT 设备可能每分钟流式传输数百万个事件，而电子商务平台可能每分钟处理数百或数千个订单。我们知道，数据量越大，洞察力越有可能受益，但并非所有的数据点都适用于你的特定用例。考虑哪些数据源是你的用例所必需的。例如，没有必要摄取所有数据源文件或对象中的所有字段。

多样性（Variety）
这是数据源和格式的多样性，包括结构化数据（如关系数据库）、半结构化数据（如 CSV、JSON 和 XML）、非结构化数据（如 PDF 和电子邮件）以及二进制数据（如图像、音频和视频）。在数据云中，你不仅限于访问结构化数据。Salesforce 数据云中的新向量数据库将为你提供一种方法，将非结构化数据作为流程的一部分，来为大型语言模型（LLM）提供支持。

真实性（Veracity）
这是数据的准确性和可靠性。不完整的源数据和来自不可靠来源的数据会影响数据的质量。你不太可能完全控制摄取到数据云中的所有数据的真实性，这也是为什么你需要考虑是否需要在摄取数据之前或之后进行转换。

价值（Value）
这是数据的相关性和实用性。其他五个因素都会影响从数据中衍生出的价值。大多数寻求为自身创造更多价值的组织都会包含一些数据和 AI 民主化的元素，这为团队成员访问和理解他们需要的数据以做出明智决策奠定了基础，无论他们的技术知识如何。

架构师明白，构建一个坚实的基础和可扩展的解决方案需要评估将被摄取到数据云中、处理并提供给最终用户的数据的这六个特性。当处理后的数据可以用于分析和预测，或者当用户可以设置自动化操作或激活个性化细分时，就实现了业务价值。

对于许多组织来说，Salesforce CRM 通常是第一方数据存在的平台，但这些组织也经常有存在于 Salesforce CRM 平台之外的外部事件或参与相关数据。将所有这些不同的数据源拼接在一起以创建统一的档案，释放了提取价值和实现数据及 AI 民主化的可能性。这就是真正的魔力所在。

数据云的魔力如何发挥作用

数据云可以通过多种不同方式提供业务价值。我们从用例的角度来定义业务价值。用例通过定义实现目标所需的要求，将组织目标与结果联系起来。在数据云中，这些目标通过利用数据和 AI 民主化实现的关键业务价值活动来完成（见图2-5）。第3章将专门解释数据云的价值活动，并详细描述数据云如何发挥其魔力。

你会注意到，达到价值活动层级需要一些基础步骤和组成组件。将许多不同的数据源拼接在一起并创建统一的个人档案或统一的账户档案是必要的基础步骤。

构建组成组件也是从数据云投资中获得价值的重要前提（见图2-5）。构建这些组成组件包括创建洞察力和构建细分市场。我们将在第3章及后续章节中进一步讨论这些步骤和组件。理解这些步骤和组件将帮助你制定一个有效的解决方案蓝图和一个可行的数据云实施策略。

在设计你的数据云用例实施路线图时，一个重要的考虑因素是确定在哪里为你的新数据云组织（org）进行配置。你可以在现有的组织中配置数据云，或者为你的数据云实例新建一个 Salesforce 组织。可以将多个 Salesforce 云连接到数据云平台，但需要注意一些注意事项。

多云连接

可以将多个外部来源和多个商务云连接到数据云，但每个数据云只能连接一个 Salesforce 营销云和一个营销云个性化数据集（见图2-6）。

对于一个组织来说，拥有多个 Salesforce CRM 实例并不罕见，特别是对于那些进行了大量公司收购的企业，每个被收购的公司可能都有自己的 Salesforce 实例。同样，您也可以将一个或多个 Salesforce CRM 组织连接到 Salesforce 数据云。

为数据云远程组织建立远程组织连接

本节及整本书将描述的是数据云当前如何支持多个 Salesforce CRM 组织之间的连接。与 Salesforce 数据源组织的连接允许从这些连接的组织中将数据摄取到主组织，然后允许为连接的组织设置数据操作目标。在不久的将来，将提供远程组织连接，这将允许 Salesforce 源组织与数据云主组织之间建立双向连接，使源组织成为数据云远程组织。将 Salesforce CRM 组织建立为数据云远程组织后，数据云远程组织将能够访问与当前数据云主组织中相同的平台功能。例如，在远程组织中可以使用 Flow、SOQL、数据增强、Lightning Web Components (LWC)、报告等功能。

您的数据云实例所在的 Salesforce CRM 组织被视为您的主组织或主要组织。如果您使用主组织进行销售云、服务云、行业云（如健康云或金融服务云）或忠诚度管理云的操作，您可以使用 Salesforce CRM 连接器将主组织内的 CRM 数据摄取到数据云中。

如果您计划从 Salesforce 忠诚度管理云摄取数据，则该云必须位于主 Salesforce 组织中（见图2-7）。此外，您计划用于数据云的任何 Salesforce AppExchange 应用程序也应安装在您的主 Salesforce 组织中。

有时，可能需要在独立的组织中设置 Salesforce 数据云（见图 2-8）。这种情况通常发生在现有组织受到严格监管或数据云管理员用户与 Salesforce CRM 管理员用户不同的情况下。

多个 CRM 外部组织可以是生产组织或沙箱组织。Salesforce CRM 组织与数据云组织之间的关系可以是一对一、一对多或多对一（见图 2-9）。

商务云的拓扑结构可以是一对一、一对多或多对多（见图 2-10）。单个商务云可以连接到多个数据云组织，而一个数据云组织也可以连接到多个商务云。

Salesforce 营销云账户与数据云组织之间存在一对一和一对多的关系，这由营销云企业 ID (EID) 表示，EID 也等同于父业务单元成员 ID (MID)。一个营销云账户可以连接到一个或多个数据云组织，但单个数据云组织只能连接到一个营销云账户（见图 2-11）。数据云在账户级别连接到营销云，但在从数据云激活细分时，可以选择账户内的特定业务单元。

Salesforce 营销云个性化账户与数据云组织的拓扑结构可能与其他拓扑结构有所不同。这种拓扑结构侧重于营销云个性化账户中的数据集。任何特定的数据集只能连接到一个数据云组织，但一个数据云组织可以连接到一个或多个数据集，即使这些数据集位于不同的营销云个性化账户中（见图 2-12）。

在做出这些架构决策时，如果您不确定哪种数据云架构最能支持您的用例，请记住，您的 Salesforce 客户经理和实施合作伙伴可以帮助您进行指导。拓扑选项应根据您的具体用例进行评估，并且决定是将数据云配置在现有 CRM 组织中还是作为独立组织是一个重要的决策。此类决策可能会受到工作流程、数据治理、安全模型、现有集成等因素的影响。此外，与这些主要架构考虑因素密切相关的是数据空间的概念，我们将在接下来讨论这个主题。

数据空间

数据空间是用于组织数据云数据的逻辑分区，旨在实现档案统一、洞察分析和营销。数据空间可以用于在单个数据云实例内对数据进行隔离，从而避免大多数组织需要多个数据云实例的需求。

数据空间使得可以将数据、元数据和流程分隔到不同的类别中。常见的数据空间类别包括品牌、地区和部门。最终用户只能在其特定类别的上下文中查看和处理数据。

并非数据驻留解决方案

数据空间并不用于支持数据驻留解决方案。数据驻留解决方案旨在解决有关数据和元数据的物理地理位置和移动的问题。相比之下，数据空间是数据的逻辑分区。

数据流和数据湖对象（DLOs）可以跨数据空间访问。可以将 DLO 与数据空间关联，无论是否使用过滤器，并且您可以将 DLO 添加到多个数据空间（见图 2-13）。

数据模型对象（DMOs）和其他平台功能，如身份解析、洞察与操作以及细分，都是特定于特定数据空间的用户（见图 2-13）。该数据空间内的安全访问仍然通过权限集进行控制。并非所有数据空间功能都具备数据空间感知能力，但以下功能具备数据空间感知能力：

• 自带湖泊 (BYOL) 的数据共享
• 数据图表
• 身份解析
• 计算洞察 (CIs)
• 数据操作
• 细分
• 激活

每个数据云组织都创建了一个默认数据空间，所有数据云对象都映射到默认数据空间，除非您创建了其他数据空间。在本书中的所有示例中，我们将仅使用默认数据空间。

带有沙箱的应用生命周期管理

数据云在沙箱环境中的功能于 2024 年 6 月推出，而通过 Salesforce DevOps Center 将更改从沙箱部署到生产环境的功能于 2024 年 7 月推出。随着在沙箱环境中引入数据云功能，现在可以在安全、可信的环境中构建、测试和部署数据云。

沙箱使解决关键开发用例和快速、安全地应对常见的变更管理需求变得更容易。它们允许您使用生产环境的副本进行开发、培训和测试，以降低干扰实时生产数据和工作流的风险。

数据云的元数据和配置在沙箱配置中会自动复制。这是在现有的同一沙箱中完成的，而不是在单独的沙箱中，因为数据云是 Salesforce 平台的一部分。为数据云配置沙箱环境的前两个步骤与为其他目的配置 Salesforce 沙箱的步骤相同（见图 2-14）。

最后一步是设置沙箱中的连接，这样数据就可以出现在您的沙箱环境中以用于数据云的目的。您可以建立与合成数据源的连接，这样您可以使用测试数据而非生产数据。这对于在高度监管行业中运营的组织尤其重要。连接到合成数据源也很有用，因为您可以限制摄取的数据量。这是一个重要的考虑因素，因为数据云的使用费用适用于沙箱内的使用以及生产环境内的使用。

Salesforce AppExchange 和数据套件

Salesforce AppExchange 是 Salesforce 于 2005 年推出的企业云计算市场。AppExchange 已有超过 1100 万次安装，并包括许多免费和付费解决方案。Salesforce AppExchange 数据云产品集合包括数据激活应用程序、数据丰富应用程序以及数据战略专家部分。

Salesforce 独立软件供应商（ISV）的数据云打包策略是独特的。ISV 合作伙伴创建数据套件，通过托管包安装来简化客户组织中数据云数据流的部署。数据套件是一种可移植且可定制的模板化独立可打包元数据捆绑包。由于数据套件存储的是模板而非实际元数据，因此可以多次实现和部署。例如，数据套件可以多次部署到订阅者的 数据云 组织中，用于不同的空白区域。

数据套件可以通过用户界面轻松创建，无需编写任何代码。在开发者组织中，ISV 合作伙伴通过以下步骤创建托管包：

1. 在具名空间的 Salesforce Developer Edition 组织中配置数据云元数据，包括数据流、DLO 和转换、DMO 和映射以及计算洞察（CIs）。您可以访问数据云扩展准备矩阵以获取有关可打包内容的最新信息。
2. 创建一个新的数据套件，并将新创建的 CRM 数据流和数据模型添加到新的数据套件中。数据套件会建议相关的功能元数据。
3. 将数据套件添加到托管包中，并在 Salesforce AppExchange 上提供托管包。

数据套件始终从默认数据空间创建，但可以部署到任何数据空间。最佳实践是使用数据套件而非 Salesforce Metadata API 进行元数据迁移。

数据云应用程序仅包含数据云元数据，这些元数据被添加到数据套件中，然后添加到包中。托管包中包含的元数据组件必须遵循某些规则，这些规则决定了其在订阅者组织中的行为。这些规则定义了在安装托管包后，您和/或订阅者是否可以更改或删除组件。关于第二代托管包（Managed 2GPs）的更多信息，可以在 Salesforce 开发者文档中在线查看。

截至 2024 年 4 月，托管 2GPs 已提供给 Salesforce 合作伙伴用于构建数据云应用程序。使用托管 2GPs 有显著优势（表 2-1）。

	托管 2GP	托管 1GP
协作级别	简单	在大规模时变得具有挑战性
开发环境	合作伙伴业务组织 (PBO) 和具名空间组织	合作伙伴业务组织 (PBO)、多个打包组织、多个补丁组织
每个具名空间的包	多个	一个
事实来源	版本控制系统	打包组织中的元数据
用户专业水平	需要更多经验	需要较少经验
版本控制	灵活	线性且更容易出错

第二代打包是通过开发者体验命令行界面开发的，使其成为源驱动型。这允许 ISV 合作伙伴使用自己选择的工具管理其版本控制，而不需要将开发元数据保存在组织中。

引擎盖下：数据云技术细节

Salesforce 数据云是 Salesforce 现代数据技术栈的核心。Salesforce Einstein AI 和 Flow 自动化服务利用了数据云的超大规模近实时数据的强大功能。

您会注意到，您可以仅使用 Salesforce CRM 事务数据库来支持部分 Einstein AI 策略。然而，利用 Salesforce 数据云的近实时超大规模能力，能够获得一个完整的 360 度视图，从而更好地构建您的 AI 和数据策略，这将为您带来巨大的收益（见图 2-15）。

数据云 是基于 Hyperforce 构建的，这是 Salesforce 的下一代基础设施架构。Salesforce 选择 AWS 作为构建 Hyperforce 的云提供商，每个 Hyperforce 区域在至少三个独立位置（称为可用区，AZs）配置和部署。Salesforce 维护了一个包含有关 Hyperforce 的最新信息的常见问题页面。

Salesforce 数据云从头开始被构建为一个开放且可扩展的数据平台，使组织能够以可信的方式无缝集成其 Salesforce 数据云组织与其他平台。然而，数据云仍然使用 Salesforce 组织的核心功能来处理报告和仪表板、Flow 和身份验证等事项。

共享规则和数据访问

数据云中的共享规则和数据访问限制与 Salesforce CRM 中的工作方式有所不同。有关共享规则和数据访问的更多信息，请参见第4章。

数据云数据可以使用来自 Salesforce AppExchange 的应用程序以及第一方广告平台（如 Meta、Google 和 Amazon Ads）进行丰富。数据云还可以通过自带湖泊（BYOL）功能进行扩展。使用 BYOL，可以与 Snowflake、Google BigQuery 和 Amazon Redshift 双向扩展数据访问。

使用自带模型（BYOM）功能，可以在外部创建的预测模型（如 Amazon SageMaker、Databricks 和 Google Vertex AI）中使用数据云数据。通过 Azure OpenAI 和 IBM watsonx 的自带 LLM（BYOLLM）技术，可以扩展 Salesforce 平台内的 LLM 功能。有关 BYOL 和 BYOLLM 的更多信息，请参见第13章。

数据云在 Amazon Web Services 上的架构

Salesforce 数据云的构建始于 2020 年的数据湖仓项目。一个新成立的数据云大数据处理计算层团队在印度承担了将数据从营销云智能（MCI）迁移到新的数据湖仓的复杂任务。

该团队负责在 Apache Iceberg 上构建 Salesforce 数据湖仓，并将现有的 MCI 客户数据迁移到数据湖仓。该团队使用 Airflow（一种开源工具）来创建、调度和跟踪迁移数据所需的工作流。这为大量数据直接摄取到数据湖仓中奠定了基础，在那里可以由 Spark 和 Presto 处理。在摄取的数据被处理和统一后，可以使用 Trino 进行细分，Trino 是一种将查询分成多个部分并在几秒钟内汇总数据的工具。这些技术与 Amazon Athena 和 Amazon EMR 等超高性能查询服务相结合，支持 Salesforce 数据云湖仓中的记录级更新和 SQL 查询管理。

这些顶级技术的结合，使数据云能够轻松处理 PB 级数据，因为 Salesforce 将所有数据云数据存储在数据湖仓中，而不是关系数据库中。在数据湖仓中，数据以 Apache Parquet 文件格式存储在 Amazon Simple Storage Service（Amazon S3）桶中。Parquet 是一种开源格式，利用列式文件格式，而不是行导向的 CSV 数据格式。Salesforce 档案数据存储在 Amazon DynamoDB 中，这是一个热存储。这些都是 Salesforce 独特存储分层系统的一部分。

存储分层

支持元数据存储层级的存储分层是一个新概念。Salesforce 数据云数据以 Parquet 文件格式存储，提供列式仓库文件存储访问。Parquet 是一个行业标准的列式格式，有助于大规模查询，但用户通常理解的是表格，因此依赖 Iceberg 作为表格格式。覆盖在 Parquet 数据之上的元数据是 Apache Iceberg，这也是一种开源解决方案。

在 Iceberg 之上是 Salesforce 核心元数据和由 Salesforce 专家精心设计的所有强大的数据模型关系。这个层级被称为云表（cloud table），这是 Salesforce 独有的概念。在这一层，Salesforce 可以与 Snowflake 等第三方平台共享数据。Salesforce 与这些第三方平台之间的集成是在文件级别进行的。

在此之上是湖库层（lake library），这是云表层的抽象（见图 2-16）。湖库层支持 Spark 数据框架和元组（tuples），这些通常用于处理大规模数据流，以应对数据密集型应用如数据科学和机器学习。当 Salesforce 向开发者开放这一层时（如 Spark 开发者），湖库层将非常重要，他们可以访问数据云数据并使用该库。在存储层之上是 Spark 和 Trino 等大数据服务。

存储分层在存储层级支持元数据，并使 BYOL 等功能成为可能。Salesforce 在 AWS 上构建数据云的方式，包括存储分层，是 Salesforce 支持前面描述的六个数据驱动模式用例的方式：大数据湖、事件处理、分析、实时决策、ML 处理和应用程序。

正如预期的那样，只有在信息能够以近实时方式获取的情况下，才能实现实时决策能力。为了使信息能够以近实时方式获取，架构必须支持近实时的数据摄取和近实时的数据处理。

近实时摄取和数据处理

从数据流架构的角度来看，数据摄取到数据云是通过实时、流式或批量摄取方法实现的（见图 2-17）。摄取的数据存储在 Salesforce 数据湖仓中，在那里可以进行近实时处理。数据云的价值活动利用湖仓数据进行洞察和探索，为决策和行动提供基础。

我在图 2-17 中列出了 10 个数据云的价值活动，用编号的水滴标记表示。此外，还展示了第 11 个用例，即提供与外部平台双向数据共享功能的零复制模式。除了这 11 个用例之外，还将在第 3 章进一步讨论另一个数据云的价值活动。

实时决策和操作需要实时摄取

是否能够真正对特定的数据输出价值活动进行近实时操作，部分取决于用于该价值类别的源数据是通过流式还是批量方式摄取的。

从实施的角度来看，您需要仔细考虑数据的输入速度和所需输出数据的速度。它是全程流式的吗？是批量的，还是两者的结合？

从最佳实践的角度来看，了解端到端路径的敏感性非常重要，因为它伴随着相关的成本。数据云采用基于使用量的定价模式，这意味着您为使用的内容付费，而近实时活动的费用比批量处理要高。

例如，Salesforce 客户数据云的费率表目前显示，流式数据管道的使用费率是批量数据管道处理一百万行的两倍半。您还会注意到，数据共享行的共享费率倍数是数据联邦或访问共享行倍数的十倍以上。因此，在为数据云实施创建架构蓝图之前，了解这些使用倍数和数据云的计费使用类型非常重要。这样，您可以仔细权衡选项的成本与收益，目标是创建一个可扩展的解决方案。

到目前为止，我们已经看了一些构建在超大规模平台上的 Salesforce 数据云的技术细节。这些概念对架构师来说很重要，但典型的 Salesforce 数据云最终用户可能永远不需要了解幕后发生的事情。不过，数据云中有一些独特的数据存储功能，最终用户需要熟悉这些功能。

独特的数据存储功能

许多 Salesforce 应用程序构建在一个通用的核心平台上，因此共享相同的数据存储。示例包括 Salesforce Sales Cloud、Service Cloud、Health Cloud、Education Cloud，以及几个行业云，如 Loyalty Management Cloud 和 Net Zero Cloud。目前有一些例外情况，但 Salesforce 计划最终将几乎所有应用程序都整合到通用核心平台中。Salesforce 的路线图还包括继续从传统的 Oracle 关系数据库存储向 Hyperforce 过渡，后者是 Salesforce 的下一代基础设施架构。

在 Salesforce 将其核心平台过渡到 Hyperforce 的同时，它还忙于从头构建数据云平台。在本章前面，我们深入了解了 Salesforce 数据云的技术细节，以更好地理解数据云是如何构建以处理各种数据驱动的架构模式的。幸运的是，Salesforce 为最终用户抽象了管理数据云存储和处理所依赖的数据湖仓的复杂性。

Salesforce 设计了新的数据存储功能，使最终用户能够利用数据云的强大新功能，而无需理解或管理底层架构。现在，让我们对数据云中特有的新数据实体、自带湖泊 (BYOL) 功能和数据空间进行初步介绍。

数据云数据实体

数据实体是数据库表的物理实现的抽象。在 Salesforce 数据云中，存在数据流实体和数据模型实体（见图 2-18）。

数据流实体的目的是便于连接到源对象并摄取数据，并进行计划刷新。数据流实体包括数据源对象（DSO）和数据湖对象（DLO）。DSO 可以包含来自 Sales Cloud、Service Cloud、Loyalty Management Cloud、Marketing Cloud 或其他任何 Salesforce 云的内部 Salesforce 系统数据。DSO 还可以包括来自外部源（如 Amazon S3）的数据。DLO 是从 DSO 自动创建的。

数据模型实体通过将来自一个或多个数据流的数据映射构建而成。数据模型实体包括 DLO 和数据模型对象（DMO）。DMO 是用于以一致的语义描述 DLO 数据的实体及其关系集合。标准数据云 DMO 遵循 Salesforce 客户 360 数据模型，并且与 360 模型一样，可以通过添加自定义字段来扩展标准数据云 DMO。

除了标准和自定义 DMO 类型之外，数据云中还引入了从流程中自动创建的 DMO 新对象类型。一些示例包括 ADG（用于数据图表）、Bridge（用于链接对象）、Derived（用于统一对象）、Insights、Semantic、Segment Membership 和 Activation Audience。每个数据云 DMO 还具有一个关联的类别，例如 Profile、Engagement、Other、Segment Membership、Activation Membership、Chunk 和 Index。我们将在后续章节中了解更多关于 DMO 类型和类别的内容。目前，需要知道的是 DMO 既有描述 DMO 结构的类型，也有描述 DMO 中存储数据的类别。

对于那些曾使用过 Salesforce MCI 平台（以前称为 Datorama）的人来说，数据流是一个熟悉的概念。数据云数据流的构建具有支持更细粒度数据摄取所需的灵活性。

DSO、DLO 和 DMO 是 Salesforce 数据云平台所独有的。这些是 Salesforce 数据云用户界面中可访问的六个主要对象，用户可以使用它们来摄取、存储、转换、统一和处理客户数据。以下是这些对象及其特征的简要总结：

• DSO 是暂时性云存储对象，用于临时保存原始源数据，保持原始文件格式。
• DLO 是持久性云存储对象，其中转换后的数据永久存储在数据湖中的 Parquet 格式中。
• DMO 是通过数据映射过程创建的与 Salesforce 元数据结构（由客户 360 数据模型表示）相对应的和谐数据的逻辑视图。
• 非结构化 DLO（UDLO）是用于存储非结构化数据详细信息的云存储容器。
• 非结构化 DMO（UDMO）是非结构化数据详细信息的逻辑分组。
• 外部 DLO 是包含从外部数据源联合的数据元数据的云存储对象，作为指向外部数据源中持久存储数据的参考。

数据被摄取到用于暂存的 DSO 中，并且转换后的 DSO 数据存储在持久的 DLO 存储中。正如“存储分层”中所描述的那样，数据云数据湖中数据的存储方式与其他 Salesforce 对象作为事务数据库中的结构化对象存储的方式不同。

DLO 数据被统一并作为逻辑或实体化视图呈现给用户，称为 DMO（见图 2-19）。DMO 还包括经过身份解析过程后的统一数据。因此，DMO 包括像统一个人（Unified Individual）这样的实体化视图，以及客户 360 DMO，它们是映射后的 DLO 数据的逻辑视图。

DMO 被组织为不同的主要主题领域，包括**“Party”（当事人）、“Engagement”（参与）、“Privacy”（隐私）、“Loyalty”（忠诚）和“Case”（案例）**。这些主题领域将 Salesforce 标准数据模型分为相关的分组。它们还帮助数据云架构师和数据模型师更轻松地利用为 Salesforce 核心平台开发的现有元数据。

存储在 Salesforce DMO 中的数据还可以与外部数据进行连接。数据还可以与 Salesforce 之外创建的预测和 AI 模型结合使用。这是通过与其他合作伙伴的协作，通过“零复制合作伙伴网络”实现的。关于合作伙伴网络的更多信息可以在第 13 章中找到，利用该网络是加快从数据云实施中实现价值的一种方式。前面章节中我们讨论了如何使用数据包简化数据云数据流的部署，使用入门数据包是另一种帮助您更快实现数据云价值的方法。

入门数据包

入门数据包将各种 Salesforce 云中的预定义 Salesforce 对象导入数据云。入门数据包可用于 Salesforce 原生连接器，其中一些 Salesforce 连接器提供多种数据包选项。入门数据包减少了实施时间，因为这些包包括将 Salesforce 数据源映射到数据云 DMO 结构的数据流定义。

例如，营销云入门数据包包括电子邮件、MobileConnect 和 MobilePush 数据集的包选项。电子邮件数据集包括电子邮件参与事件，例如发送、打开、点击、退回、投诉、取消订阅和 Einstein 参与评分。

以下是一些可以使用入门数据包的 Salesforce 数据对象和数据集：

• Salesforce Sales Cloud
• Salesforce Service Cloud
• Salesforce Loyalty Management Cloud
• Salesforce Unified Health Scoring
• Salesforce B2C Commerce
• Salesforce Omnichannel Inventory
• Salesforce Marketing Cloud
• Salesforce Marketing Cloud Account Engagement
• Salesforce Marketing Cloud Personalization

一些数据包数据集在多个入门数据包中都可以使用。例如，Salesforce CRM 联系人映射数据集在 Sales 和 Service Cloud 入门数据包中都可用。预计未来将会增加更多的入门数据包。Salesforce 开发者的数据云参考指南中包含所有入门数据包和数据包数据集的最新列表。如果您点击参考指南中的任何入门数据包名称，您将获得该数据包的特定 DLO 到 DMO 映射。

总结

本章一开始，我们讨论了架构师在使用数据云时需要考虑的一些特别事项，随后我们探讨了数据云的关键功能方面，包括连接多云的各种拓扑结构。接着，我们深入分析了数据云的技术细节，涵盖了数据云如何利用存储分层以及如何实现近实时数据摄取和处理。

我们在本章结束时讨论了数据云独特的数据存储功能，包括数据云数据实体、数据云的双向数据共享能力以及入门数据包。在下一章中，我们将关注通过 Salesforce 数据云实现的业务价值，并探讨该平台如何用于实现数据和 AI 的民主化。