一、设置您的 Data 360 沙盒
创新的架构
在实时环境中测试 Data 360 配置是有风险的，尤其是当您管理着数百万客户数据点时——一个配置错误的身份解析规则或数据流错误就可能扰乱真实客户的体验。
这对定制运动鞋零售商 Cloud Kicks 而言尤为真实。系统架构师 Jamal Cooks 为 Cloud Kicks 设置了 Data 360，营销团队取得了巨大成功。最近，Cloud Kicks 上线了一个超个性化忠诚度计划，把店内购买历史与实时网页浏览行为相融合，以即时推送风格推荐。
为处理这一海量数据集成，Jamal 正与 DevOps 开发者 Vijay Lahiri 一起加班加点。他尤其担心生产数据的完整性——他纠结的是，能否直接在实时环境中测试身份解析规则、计算洞察等大量新配置？是时候提升技能，确保新计划以尽可能安全、高效的方式完成构建与测试。
本徽章将尽我们所能，回答 Jamal 和 Vijay 关于 Data 360 沙盒生命周期的问题。
什么是 Data 360 沙盒？
一个 Data 360 沙盒是您生产 Data 360 元数据的副本。标准 Salesforce 沙盒用于测试核心 Salesforce 平台功能，而 Data 360 沙盒专门用于让您测试数据摄取、建模和身份解析，而不影响实时的客户画像。使用 Data 360 沙盒会消耗您生产 org 的额度（credits）。
如果您不熟悉元数据，可以把它理解为「对数据的描述」。例如，某个计算洞察的配置就是元数据，它会被复制到 Data 360 沙盒；但生产环境中该计算洞察的输出数据不会被复制。Data 360 沙盒会复制数据流、数据模型对象、计算洞察和细分，但不包含任何数据。
Jamal 用 Data 360 沙盒来隔离定制与开发工作、测试数据映射与转换逻辑、提供培训环境，并把零散变更批量合并为一次对生产的部署。
选择 Data 360 沙盒类型
Data 360 支持所有标准 Salesforce 沙盒类型。虽然这些沙盒类型在核心 Salesforce 视角下有所差异（如数据存储上限不同），但一旦供应完成，Data 360 沙盒的行为完全相同，与您选择的核心沙盒无关。
Jamal 根据 Cloud Kicks 的架构需求评估选项：
- Developer 和 Developer Pro：非常适合 Data 360 的初始设置和基础测试，存储有限，适合概念验证；
- Partial Copy（部分副本）：适合用生产数据模型的样本进行测试；
- Full Sandbox（完整沙盒）：生产环境的镜像，对性能测试和全量用户验收测试（UAT）至关重要。
对于新忠诚度计划的初步概念验证，Jamal 决定 Developer 沙盒是最合适的。
设计 Data 360 沙盒策略
在点击 New Sandbox 之前，您需要一份计划。像 Jamal 这样的资深架构师不会随便启动环境，而是设计一套完整的 Data 360 生命周期策略。规划沙盒策略时，考虑以下关键因素：
- 基准生产指标：记录实时环境的当前性能，以便在测试前有清晰的对比点；
- 确定数据量需求：确保所选沙盒层级能承载准确测试所需的数据样本量；
- 评估身份解析测试需求：围绕「统一画像不会复制过来、必须从零构建」这一事实来规划时间表；
- 规划连接器验证：记录需要在隔离环境中安全重新鉴权的外部连接；
- 建立性能基准：在推广到生产前，明确定义新配置「成功测试」的标准。
提前把这些梳理清楚，Jamal 就能保证新的 Developer 沙盒恰到好处地适配忠诚度计划的概念验证。
创建 Data 360 沙盒
策略就绪后，Jamal 在 Cloud Kicks 的生产 org 中开始创建。创建沙盒前，请确保 Data 360 已在生产 org 中供应：
- 在生产 Setup 的 Quick Find 框输入
Sandboxes； - 选择 New Sandbox，输入详情，选择首选层级；
- 点击 Create。
沙盒创建会把元数据从生产复制过来。创建时间随沙盒类型而异：Developer 只需几分钟，Full 沙盒则需要数小时到数天。
在沙盒中启用 Data 360
沙盒创建后，Jamal 必须初始化基础设施并启用 Data 360：
- 登录新沙盒，进入 Setup，选择 Data Cloud Setup；
- 点击 Get Started；
- 配置基本设置，如 Data Cloud 权限集、时区、数据流命名约定和数据保留策略。
此启用过程通常需要 15 到 30 分钟（视沙盒大小而定），之后还要再等 30 到 60 分钟让基本设置从生产 org 流入。Data 360 并非在沙盒中自动启用，请务必在配置任务前验证启用已完成。
保护连接链路
许多企业组织使用 Data Cloud One（DC1） 跨多个核心 org 扩展 Data 360 能力。如果您的公司采用这种架构，就必须在沙盒中保护这些连接链路。
Data 360 沙盒就绪后，Jamal 把 Cloud Kicks 的 DC1 org 连接到沙盒 org。由于沙盒是生产的副本，它通常需要明确指示——是连接真实的生产 org，还是生产的沙盒版本。Jamal 这样保护链路：
- 在 Data Cloud Setup 的 Quick Find 框搜索并选择 Data Cloud One；
- 验证沙盒 org 已作为您的 Companion Org 连接；
- 重新鉴权 CRM 连接器以及任何外部存储连接器（如 Amazon S3 或 Microsoft Azure）；
- 用元数据清理流程移除从生产继承的、沙盒中不需要的孤立数据流或陈旧数据映射。
摄取并测试数据
要测试新的超个性化忠诚度计划，Jamal 现在必须验证沙盒连通性并重建客户画像。他通过摄取一个简单数据源并运行身份解析规则来完成：
- 创建一个本地数据空间；
- 摄取数据流，从一个简单的数据源开始以验证连通性；
- 数据摄取后，进入 Identity Resolution 标签页，为规则集点击 Run——因为统一画像不会从生产复制，必须在 Data 360 沙盒中从零构建。
您的沙盒现在已准备好进行开发和测试。
接下来是什么
您已成功供应 Data 360 沙盒、保护连接链路并验证了数据摄取。本单元要点：
- 选择与生命周期阶段和数据需求匹配的沙盒类型；
- 创建沙盒前先设计策略；
- 在每个沙盒中启用 Data 360（非自动）；
- 用沙盒专属凭据保护连接；
- 摄取有代表性但非敏感的测试数据。
接下来：学习如何刷新沙盒并同步 org 之间的元数据，防止配置漂移。
二、刷新并同步您的 Data 360 沙盒
在 org 之间同步 Data 360 元数据
在上一单元，首席架构师 Jamal Cooks 成功供应了一个 Data 360 Developer 沙盒并摄取数据验证了连通性。现在环境已就绪，他必须让它与生产 org 保持同步。元数据漂移得很快；不同步会导致身份规则错位、孤立数据流和意外行为。
本单元探讨沙盒刷新策略和高级元数据同步，让测试始终反映生产环境的当前现实。
避免元数据漂移
元数据不断变化。如果沙盒落后于生产，任何测试都有失效风险。由于刷新只复制元数据（配置）而不复制实际数据，一个「六个月前的沙盒」只是过去的一个快照——在这种状态下测试会产生在生产中失败的缺陷结果。
考虑 Cloud Kicks 的这个场景：在生产 org 中，Jamal 更新了一个身份解析规则集（Rule Set 2.0），增加了一条更严格的匹配标准以保证高质量的统一画像。
六个月后，DevOps 开发者 Vijay Lahiri 在从未刷新的 Developer 沙盒中工作。他构建了一个针对高价值客户的复杂细分并测试成功（返回 10,000 个统一画像），以为可以部署。但沙盒里是较宽松的 Rule Set 1.0 元数据。当他把细分部署到生产时立即失败——因为生产使用更严格的 Rule Set 2.0，只能找到 8,500 个统一画像，突然少了 1,500 个目标客户，破坏了忠诚度计划的上线。
避免这种生产失败的唯一方法，就是确保构建所基于的沙盒配置是最新生产元数据的镜像——这让及时的沙盒刷新和刷新后清单成为架构师工作流的关键部分。
为 CRM 沙盒刷新做准备
发起刷新前，Vijay 梳理环境依赖。由于 Cloud Kicks 的客户忠诚度数据来自一个 Salesforce CRM 沙盒，他必须在刷新该 CRM 沙盒前采取特定动作。
当 CRM 沙盒被刷新时，它的 OrgId 会改变、鉴权权限集会被删除——这会永久破坏与 Data 360 的连接。如果不做准备，所有以该 CRM 沙盒为源的数据流都会进入错误状态，系统还会阻止您直接断开该 org。
安全准备 CRM 沙盒刷新的步骤：
- 通过创建 DevOps 数据包备份 CRM 数据流配置；
- 删除所有以 CRM 沙盒 org 为源的数据流（可能还需删除下游依赖，如数据映射或细分属性）；
- 进入 Data Cloud Setup，选择 Salesforce CRM Connector，断开 CRM 沙盒 org；
- 刷新 CRM 沙盒 org。
刷新您的沙盒
准备完成后，Vijay 可以刷新 Cloud Kicks 的 Data 360 沙盒了。沙盒刷新会从源 org 更新沙盒的元数据，但不更新数据：
- 元数据同步：复制所有 Data 360 配置，包括数据流、计算洞察和细分；
- 影响：刷新会覆盖沙盒中任何现有工作。
警告：刷新前务必用 DevOps 数据包备份沙盒元数据。
- 进入 Setup，在 Quick Find 框输入
Sandboxes； - 点击沙盒名称旁的 Refresh 链接；
- 查看并编辑名称和描述；
- 选择沙盒许可类型（Developer、Developer Pro、Partial Copy 或 Full）；
- 点击 Create。
完成刷新后检查清单
刷新沙盒只是第一步。Vijay 现在必须重建「管道」，让 Cloud Kicks 的数据重新流动起来：
- 重建 CRM 连接：若刷新了已连接的 CRM 沙盒，必须重建外部 org 用户权限集、把 CRM 沙盒 org 重新连接到 Data 360，并重建对象与字段权限；最后安装数据包以重新部署数据流；
- 重新鉴权连接器：出于安全考虑，与 Marketing Cloud Engagement 等外部系统的连接必须在沙盒中重新授权；
- 初始化身份解析：刷新会复制身份规则，但必须手动触发首次运行以在沙盒中生成统一画像；
- 管理 Data Cloud One（DC1）连接：若企业使用 DC1，刷新充当 DC1 伴生 org 的沙盒会断开与主 Data 360 org 的连接，刷新完成后必须重建 DC1 连接；
- 清理过时元数据：用 Data Cloud Setup 菜单识别并删除同步期间出现的孤立数据流或映射错误。
接下来是什么
您刚刚了解了 Jamal 和 Vijay 如何通过保持沙盒同步、处理刷新后连接来避免元数据漂移。本单元要点：
- 沙盒会随时间漂移 → 定期刷新可预防；
- 刷新前要准备 → 导出数据包、通知团队、备份数据；
- 刷新后至关重要 → 启用 Data 360、重配连接、重新部署数据包。
接下来：学习如何把这些 Data 360 配置打包成 DevOps 数据包，实现安全、可控、可重复的部署。
三、把 Data 360 配置打包成 DevOps 数据包
高效管理部署
本单元学习如何用 DevOps 数据包打包 Data 360 元数据、比较数据包类型，并管理依赖层级以实现顺畅部署。跟随 DevOps 开发者 Vijay Lahiri 和系统架构师 Jamal Cooks，用数据包把 Cloud Kicks 新忠诚度计划的配置从 Developer 沙盒安全地推向生产。
沙盒成功同步后，Vijay 必须找到高效方式把新配置移到生产。与其手动重建 50 个数据映射，他依靠 DevOps 数据包——它能把这些组件打包成一个单元，实现可重复、可审计、安全的跨环境推广。
打包一次、随处部署
数据包是 Data 360 配置的容器。对 Vijay 而言，避免部署期间的依赖错误是首要目标。
对企业团队来说，数据包不仅是传输机制，更是发布工件（release artifacts）：它们捆绑相关配置、确保依赖顺序被遵守、并为部署创建审计追踪。创建数据包时，Vijay 遵循这些最佳实践：
- 纳入发布命名约定（如
v1.2-loyalty-enhancement）； - 审查数据包组件的发布顺序；
- 若在沙盒中新建了数据空间，确保目标 org 中也存在同名数据空间；
- 为发布打上对应生产部署日期的标签。
核心原则：构建一次、部署多次。数据包包含完整配置蓝图，环境相关的设置（凭据、端点）在部署时配置，从而保证在开发环境中测试过的配置就是最终到达生产的那份。
比较标准与 DevOps 数据包
打包忠诚度计划配置前，Vijay 必须为他的架构选择正确的数据包类型：
- 标准数据包（Standard）：面向 AgentExchange 解决方案包，受众是 Salesforce 合作伙伴——专注于把解决方案交付给外部合作伙伴安装；
- DevOps 数据包：面向内部环境迁移，受众是企业架构师和 DevOps——企业级内部元数据管理工具，用于在您自己的组织环境之间（如从 Developer 沙盒到 UAT 沙盒，再到生产）可控、可重复地推广配置变更。
两者的区别至关重要：标准数据包用于外部解决方案交付；而选择 DevOps 数据包则表明，这些捆绑组件属于一条结构化、受审计的部署管线的一部分，而非外部解决方案。
打包您的配置
为安全迁移新忠诚度计划元数据，Vijay 创建一个 DevOps 数据包。在 Data 360 沙盒中，可打包的核心元数据组件包括：
- 数据流：摄取数据的 schema 和源详情；
- 数据模型对象（DMO）：您将数据流映射到的标准与自定义数据模型；
- 计算洞察：用于忠诚度评分等的 SQL 逻辑；
- 身份解析规则：Jamal 统一画像的匹配与调和逻辑；
- 细分：为目标营销定义的受众条件。
Vijay 按以下步骤打包配置：
- 在沙盒 org 进入 Setup，选择 Data Cloud Setup；
- 在 Developer Tools 下选择 Data Kits；
- 点击 New，选择 DevOps Data Kit；
- 选择一个数据空间；
- 输入数据包名称；
- 点击 Save。
管理依赖层级
依赖层级对部署成功至关重要。Vijay 构建数据包时按严格顺序管理依赖：
- 在 Data Kit 页面选择数据包并添加支持的组件（Data 360 会在您添加数据流时自动包含依赖，如数据映射）；
- 用数据流打基础：先添加 Amazon S3 或 CRM 数据流——选择数据流时，Data 360 会智能地拉入关联的数据湖对象（DLO）；
- 用映射连接管道：添加数据模型对象（DMO）时，务必勾选 Include Mappings，确保原始数据一落入目标 org 就知道自己属于统一数据模型的哪一部分；
- 审查发布顺序：在 Data Kit 页面审查发布顺序以防依赖缺失——若某细分依赖某计算洞察，确保该计算洞察先于细分部署；
- 确认组件和依赖后，点击 Save。
提示：为每个数据包使用语义化版本（如 v1.3-loyalty-update），并把导出的清单存入源代码控制。
接下来是什么
您已成功把 Data 360 配置打包进可移植的 DevOps 数据包。本单元要点：
- 构建一次、部署多次 → 数据包保证跨环境一致性；
- 标准 vs DevOps 数据包 → 不同创建方式对应不同工作流；
- 打包逻辑相关的配置（按功能域划分，而非一个大而全的包）；
- 部署时遵守依赖层级。
接下来：用 change sets 和 Salesforce CLI 部署并验证配置，完成部署后的端到端校验。
四、部署并验证您的 Data 360 配置
最后的冲刺
部署只是故事的一半；激活和验证才能确认配置在生产规模下正确运行。元数据就像一件家电——搬过去之后，还得插上电源、打开开关。
在最后一个单元，您将学习如何选择合适的部署工具、把 DevOps 数据包推到生产，并验证端到端数据管道。跟随 DevOps 开发者 Vijay Lahiri 和系统架构师 Jamal Cooks 执行 Cloud Kicks 忠诚度计划的最后冲刺。
检查部署前清单
大规模部署 DevOps 数据包需要企业级治理。Vijay 把任何元数据移到生产前，Jamal 都会执行就绪检查，遵循以下部署前清单：
- 数据空间一致性：确保沙盒与生产 org 以相同方式处理数据空间，避免映射失败——若沙盒中创建了生产不存在的空间，必须在部署前手动在生产创建；
- 功能对等：验证沙盒启用的所有 Data 360 功能在生产也已激活；
- 跨 org 部署策略：如需跨不同生产 org 迁移，严格按路径——从生产 org 一部署到沙盒 org 一，再到关联生产 org 二的沙盒，最后推入生产 org 二；
- 部署发布顺序：在 Data Kit 页面审查发布顺序以防依赖缺失；
- 重新部署规则：若更新已部署的组件想重新部署，务必创建新的数据包；
- Change set 依赖：若用 change sets，上传前先预检是否已手动添加所有必要的组件依赖。
绝不要跳过清单——遗漏一项部署前检查所导致的生产事故，比任何部署工具错误都多。
选择合适的部署工具
大规模部署 DevOps 数据包需要理解多种部署方法并规划企业级治理。迁移并非「一刀切」——取决于复杂度，Vijay 可能用不同工具：
- Change Sets：简单迁移，适合简单管理，但不推荐用于多组件数据包；只在相连 org 之间工作，无版本控制，且无法部署所有元数据类型；
- Salesforce CLI / Metadata API：版本控制的部署——在沙盒创建 DevOps 数据包后，用 CLI 检索元数据清单并提交到版本控制，是可重复元数据部署的黄金标准，但需要 CLI 知识和脚本/管线的手动设置；
- 外部 DevOps 工具（如 Copado、Gearset、GitLab）：企业 CI/CD 管线，在 CLI 之上提供可视化抽象层，管理版本控制集成、自动化测试和顺序推广，但引入许可成本和学习曲线。
典型的 DevOps 部署管线：变更从各个开发者沙盒，经过集成和用户验收测试（UAT），最终到达生产。
用 Change Sets 部署
对于简单迁移，可用标准 Salesforce change sets。Vijay 已在上一单元构建了 DevOps 数据包，可将其打包进 change set 移到生产：
- 授权连接：在生产（目标）org 创建部署连接，允许来自沙盒的入站 change set；
- 创建出站 change set：在沙盒 org 进入 Setup 创建出站 change set；
- 添加数据包：Component Type 选择 Data Package Kit Definition，添加 DevOps 数据包；
- 添加依赖：点击 View/Add Dependent Components 纳入必要的 DMO 关系，滚动所有页面确保无遗漏；
- 上传并部署：上传出站 change set，登录生产 org 进入 Inbound Change Sets 点击 Deploy。
注意：删除任何关键限定符（key qualifier）文件；不要为统一个体等派生对象添加关系（这些会自动处理）。
用 Salesforce CLI 部署
为管理关键任务忠诚度计划及其众多环节，Vijay 选择 Salesforce CLI 与 Cloud Kicks 的版本控制系统集成：
- 在沙盒 org 进入 Data Cloud Setup，点击 Data Kits；
- 选择 DevOps 数据包，点击 Download Manifest——下载的
package.xml包含该数据包的所有元数据实体； - 把数据包元数据检索进沙盒 org：
sf project retrieve start --manifest manifest/package.xml； - 命令完成后会出现新项目文件夹，建议把整个项目上传到 GitHub 等源代码控制系统；
- 重要：不要跳过此步——在部署前删除项目中相关的任何关键限定符（key qualifier）文件；
- 启动对生产 org 的部署：
sf project deploy start --manifest manifest/package.xml。
CLI 部署是拥有成熟 DevOps 实践的组织的推荐方式，可与 Git、CI/CD 管线和自动化测试框架集成。
应对 CLI 和源代码控制的局限
Vijay 扩展 Cloud Kicks 部署时，必须谨慎管理这些已知的 CLI 局限：
- 新文件生成：即使同一底层组件（同一数据流、计算洞察或细分）被加入多个数据包并多次检索，不一致的命名也会每次都生成全新的 XML 文件；
- 无法追踪变更：因为每次都创建新文件，开发者难以追踪单个组件随时间的变化——
git diff、git blame、git merge等标准命令失效； - 合并冲突与冗余：多开发者处理同一组件或创建多个数据包时，命名不一致的文件激增，带来严重合并挑战并污染仓库；
- 模板命名冲突：同一计算洞察加入多个数据包时，生成的模板名可能冲突（出现 CI、CI1、CI2），进一步复杂化识别和管理；
- 合并失败：多开发者在各自沙盒创建同名数据包并合并时，发布顺序不合并，组件因同一组件多个模板的冲突引用而无法成功合并。
在设计部署管线之前先了解这些局限。
排查部署错误
架构师的工作永远做不完。监控和排查是确保顺畅部署的重要技能。以下是 Cloud Kicks 团队可能遇到的一些「静默失败」及修复方式：
- 不兼容映射（Incompatible Mapping）：根因是 org 之间 DMO 字段类型不同 → 在源 org 对齐字段类型并重新打包数据包；
- 缺少数据空间（Missing Data Space）：数据包引用了未创建的数据空间 → 在目标 org 手动创建数据空间并重新部署；
- 空结果（Null Results）：身份解析尚未运行 → 在 Identity Resolution 标签页手动触发运行。
大多数部署错误是依赖或权限问题——先从这里入手，读取完整错误信息，检查部署日志，按依赖顺序解决。
完成部署后清单
元数据已到达生产！但 Vijay 的工作还没结束。他必须遵循严格的部署后工作流，确保数据开始正确流动：
- 查看部署历史：进入 Data Cloud Setup → Data Kits，打开已部署的数据包，检查 Deployment History 标签页确认所有组件按顺序成功发布；
- 管理数据流部署行为：部署的数据流以「草稿（draft）」状态到达，需激活才能处理真实数据。激活步骤因源系统而异：
- CRM 数据流：若连接未立即激活，关联数据流可能安装失败——需先在目标 org 手动激活连接器，再重新部署数据包；
- 非 CRM 数据流（如 Amazon S3）：连接器和数据流都成功部署但处于非激活状态——只需导航到连接器点击激活，无需重新部署。
- 开始摄取：连接器激活后，进入 Data Streams 标签页，选择已部署的数据流，点击 Start Ingestion。
部署完成并不等于部署成功——错误只告诉您部署「结束了」，而非「起作用了」。
执行身份解析审计
部署后，新摄取的数据流流入环境。但系统不会自动对这一新元数据运行身份解析过程。由于统一画像被视为操作数据，必须在新环境中从零构建。
Jamal 的身份解析审计是关键检查点：
- 进入 Data Cloud Setup 的 Identity Resolution 标签页；
- 点击 Run Ruleset 应用新部署的匹配与调和规则；
- 监控 Metrics 部分，确认处理的输入记录数和生成的统一画像在预期容差范围内。
相同的规则集在数据相同时应产生相同结果——若与源 org 结果有显著偏差，需调查数据差异或配置问题。
验证数据管道
最后一步是端到端验证。Jamal 用一组带已知属性的小测试画像作为忠诚度计划的校验：
- 进入 Data Profile 标签页，搜索已知画像（如测试客户「Cody the Bear」）；
- 验证数据映射：检查核心字段（如邮箱地址、忠诚度 ID）是否从源数据流准确填充；
- 验证身份解析：确认「Cody the Bear」被正确统一，所有相关数据记录都归到同一画像下；
- 确认计算洞察：在画像的 Calculated Insights 部分，验证「Cody the Bear」基于测试数据正确显示「Gold Tier」忠诚度等级。
若验证画像通过以上检查，您的部署即成功。先用一个简单、低风险的变更验证管道，再信任它处理复杂部署。
总结
随着新配置的成功部署与验证，Cloud Kicks 现在可以上线其实时风格推荐了。通过采用 DevOps 数据包、沙盒同步和多工具部署，Jamal 和 Vijay 避免了生产停机，并确保每位客户都在正确的时间收到正确的推荐。
您已完成完整的 Data 360 沙盒生命周期：
- 设置：架构、沙盒类型、策略、创建、启用、连接、测试数据；
- 刷新：同步、漂移预防、刷新执行、刷新后恢复；
- DevOps 数据包：标准 vs DevOps、打包配置、依赖层级管理；
- 部署：部署前清单、change sets、CLI、排查、部署后验证、身份审计、管道验证。
有了这些基础，您就能构建稳健、可靠的 Data 360 从开发到生产的管道——Data 360 沙盒也能为您做到同样的事！