理解企业数据
另有 28 种语言版本
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Data Architect 课程第 4 章的学习指南。请先阅读六个模块；这一页帮你检查自己记住了什么。
**关于本学习指南。**它只依据本课程自己的内容，以及 Salesforce 公开发布的考试指南中的目标清单编写。它从不基于真实的考试题目，也不声称知道考试会考什么。如果你参加过考试，请不要把考题发给我：认证协议禁止分享考题，而且死记答案本来就不是成为架构师的正确方式。
考试指南说它不考非 Salesforce 的数据库概念，而本章的大部分内容讲的是 Salesforce 周围的企业。所以和第 1 章一样，这份清单写明每一点支撑的是哪些目标。但不要跳过它：很多考试情景都从一个 ERP、一个数据仓库或第二个 org 开始，而答案取决于谁拥有数据。
边学边打勾。每一条都链接到讲授它的地方。
谁拥有数据（支撑 SDM-2、SDM-3 和主数据一章）
- 我能说出每类数据的记录系统是哪个，并把这句话说完：记录什么的系统？（Salesforce 常常不是记录系统，不要从产品名称开始）
- 我知道常见的模式：客户、产品和价格从 ERP 流入，订单流出，也知道订单箭头依赖其他箭头；然后我会问回程。（我一再看到的那种集成，单向箭头让我不安）
- 我会对主数据问三个问题：它在哪里创建，在哪里编辑，在哪里被引用？（类别背后的四个问题）
- 我知道副本不是权威：ERP 拥有的数据在本地读取、在受控的方式下写入，并把 ERP 的标识符保留为外部 ID。（ERP：后台有引力，全景图会改变数据模型）
数据的类型及其工作负载（支撑 DM-1、LDV-1 和 MDM-4）
- 我能区分主数据、参考数据、交易数据、元数据、分析数据和非结构化数据，也知道每一种对它放在哪里意味着什么。（从类型开始，而不是从对象开始）
- 我知道参考数据虽小，却是集成假设藏身的地方（
Delivered、Complete、D）。（参考数据） - 我能区分运营（OLTP）、分析（OLAP）和流式工作负载：org 经营业务，数据仓库和数据湖分析业务。（类型只是问题的一半）
- 我知道同步（在门口等着）、异步（继续做别的，回来时再处理）和批处理（每小时、每几小时、每天）的区别，知道什么时候批处理就够了，也知道实时是有代价的。（它需要多快地流动？）
- 我会对每个数据集问四个问题：谁拥有它，它变化得多快，它会变得多大，以及它的生命周期。（类别背后的四个问题）
Salesforce 周围的系统（支撑 SDM-3、LDV-3 和集成相关章节）
- 我知道四种系统角色：记录、互动、参考和洞察。（不要从产品名称开始）
- 我知道分析放在哪里，取决于数据放在哪里：全都在 Salesforce 里时用核心报表；涉及其他存储时用分析平台（Tableau，包括 Tableau Next，或者在已经使用它的地方用 CRM Analytics）或数据仓库。（分析放在数据所在的地方）
- 我知道数据仓库、数据湖和湖仓是什么，也知道 MDM、ESB 或 iPaaS 以及事件的角色。（数据仓库、数据湖和湖仓，集成层与事件）
- 我从第一天起就把身份提供商画到全景图上，也知道 SSO 配置可以部署，但密钥和证书不会随之迁移；在全景图上它是一个共享证书（信任），而不是一次调用，因为登录是通过浏览器进行的。（开发人员会忘记的系统：身份）
- 我知道 Data 360 是近核心（在核心之上管理，在核心之外托管），也知道它的零拷贝让数据无需复制就能被查询。（Data 360 放在哪里？，核心、核心之外与 Hyperforce）
org 与托管（支撑 SDM-4）
- 我从一个 org 开始，在添加另一个之前，先寻找一条真实的边界（数据驻留、监管、法律上的隔离、不同的运营模式、一次收购）。（从一个 org 开始，寻找真正的边界）
- 我知道多个 org 的代价：全球报表、主数据、集成、身份和部署，每一项都成倍增加。（再走查一遍箭头）
- 我知道 Hyperforce 让你选择 org 的数据驻留在哪个区域（而不是哪家云提供商），但并不承诺每一项服务都留在那里；也知道 GDPR 本身并不要求单独一个 org：它为离开欧盟的个人数据制定规则，而一家公司可以选择用一个欧洲 org 来满足这些规则。（托管是图的一部分，当欧洲有了自己的 org）
画出和读懂全景图（支撑每一个情景）
- 我能画出一张全景图：人在左边，Salesforce 在中间、它的社区在下方紧贴着它，身份在上方，集成和后台在右边，Data 360 在集成层下方，渠道在下方，数据进出在右下角。（Steve 的全景图布局）
- 在全景图上，箭头从打开连接的那个系统开始，它的标签说明移动的是什么以及朝哪个方向；在数据流图上，箭头跟着数据走。两条数据流就是两个箭头。（现在画出箭头）
- 对于每一个箭头，我都知道客户端处理什么、服务器定义什么：位置、认证、协议和契约、数据载荷、时序、追踪、错误。Salesforce 向外调用时，用命名凭据及其外部凭据；有东西调用 Salesforce 时，用 External Client App（外部客户端应用）和一个仅限 API 的集成用户。（每一个箭头都需要一个机制）
- 我在画箭头之前先数一数：数据量写进清单，并决定机制，甚至可以改变箭头指向的方向。（把零的个数写进清单）
- 只有当一个流程有一两次以上的往返交互时，我才画泳道。（箭头画在全景图上，对话画在泳道里）
考试是底线，不是天花板。下面这些是本章中架构师需要的习惯，不管有没有考题问到它们。
- **在设计 org 之前先画全景图。**从一张空白画布开始。
- **把镜头拉远。**Salesforce 只是众多系统之一。
- **新的一波很少会让旧的一波消失。**为实际存在的企业做架构，而不是为产品手册。
- **把全景图当作职责来读，**而不是标志。
- **单向箭头让我不安。**这条数据流依赖什么，什么会回传？
- 每一个箭头都需要一个机制。“fire and forget”不是答案。
- 箭头画在全景图上，对话画在泳道里。
- **画箭头之前先数一数。**零的个数写进清单，由它们来选择机制。
- **在修复之前先画出现状：**那份电子表格，那个 SFTP 投递，那个“我们正在退役的”系统。
- **如实标出现状：**红色表示糟糕的流程，虚线表示手工完成，红色点线表示缺失的东西。每一条红线都是一条等着被写下来的需求。
- **两条数据流，两个箭头。**双向箭头只用于连接器。
- **不要扮演律师。**问清楚你在满足哪项具体需求，并和拥有这项需求的人一起把它翻译出来。
- 分开不等于简单。
| 术语 | 一句话解释 |
|---|---|
| 系统全景图 | Salesforce 周围的系统、使用它们的人，以及它们之间重要的数据流 |
| 记录系统 | 保存某类数据权威版本的地方 |
| 互动系统 | 人们做事的地方 |
| 参考系统 | 一个系统去查找它需要但并不拥有的信息的地方 |
| 洞察系统 | 数据汇聚起来用于度量、分析和预测的地方 |
| ERP | 负责财务、产品、库存、采购和履约的后台系统 |
| 主数据 | 业务围绕其运转的持久事物：客户、产品、地点 |
| 参考数据 | 给其他数据分类的共享词汇：代码、状态、类别 |
| 交易数据 | 发生了什么的记录：订单、配送、付款、个案 |
| 分析数据 | 从其他数据推导出来、用于度量和比较的数据 |
| 非结构化数据 | 文档、图片、音频、视频、转录文本 |
| 数据仓库 / 数据湖 / 湖仓 | 结构化的分析存储 / 大规模的原始数据存储 / 两者的结合 |
| ESB / iPaaS | 在系统之间充当中介的集成层 |
| OLTP / OLAP | 一次处理少量记录的运营工作 / 跨大量记录的分析 |
| 近核心 | 在核心之上管理，在核心之外托管：Data 360 |
| 命名凭据 / 外部凭据 | Salesforce 保存出站端点的地方 / 保存其认证信息的地方 |
| External Client App（外部客户端应用） | 外部系统如何获得授权来调用 Salesforce |
| 现状 | 设计之前、今天实际存在的全景图；标出了哪里不对 |
| 身份提供商（IdP） | 认证用户并建立 Salesforce 所信任的身份的系统 |
| 同步 / 异步 / 批处理 | 等待答案 / 继续做别的，答案来了再处理 / 按计划成批移动数据 |
| Hyperforce | 运行在公有云基础设施上的 Salesforce，可以选择区域 |
| 零拷贝 | 在数据所在的地方查询数据，而不复制它 |
按课程风格编写的简短情景题。打开答案之前，先想好你的答案。
1. 销售人员在 Salesforce 中跟进客户，但客户一旦购买，ERP 就签发正式的客户编号。Salesforce 把订单发给 ERP。你需要设计什么？
每个阶段谁拥有客户；把 ERP 的编号作为客户上的外部 ID；Salesforce 可以修改哪些字段；ERP 的变更多快到达；以及订单发出后什么会回传（被接受、被拒绝、已发货、已开票）。重读全景图会改变数据模型。
2. 领导层想要按区域统计、并与财务数据关联的五年准时表现。用 Salesforce 报表来做吗？
多半不行。这是跨多个存储的分析工作负载，所以它属于数据汇聚的地方：数据仓库，上面再加 CRM Analytics 或 Tableau。分析放在哪里，取决于数据放在哪里。重读分析放在数据所在的地方。
3. 一家公司在 30 个国家运营，要求每个国家一个 org。你会问什么？
每个国家带来了什么需求：存储、处理、跨境传输、合同、不同的托管方。没有真实的边界，就从一个 org 开始，因为每多一个 org，报表、主数据、集成、身份和部署都会成倍增加。重读地理位置并不自动构成 org 策略。
4. 卡车每天发送 20 万条 GPS 读数。Salesforce 应该把它们全部存下来吗？
多半不应该。这是流式数据：调度员需要的是当前位置，而历史和趋势属于为这种数据量而构建的平台。数一数零（每年超过 7,000 万条），把“它现在在哪里？”和“上个季度发生了什么？”分开。重读类型只是问题的一半。
5. 配送小组在 Salesforce 中处理他们的停靠点，但路线是在一个遗留调度工具里建的，两者之间没有任何连接。你怎么画今天的样子？
照实画，并标明是现状：路线被重新录入 Salesforce，完成的停靠点再被录回去，用虚线是因为这是人在做，用红色是因为这是不对的。不要画你希望存在的集成；每一条红线都会成为设计的一条需求。重读标出哪里不对和RouteDesk 仍然在那里。
6. 有人说欧洲的隐私法要求单独一个 org。你怎么回应？
既不要盲目接受，也不要直接否决。GDPR 本身并不要求单独一个 org；它为个人数据制定规则，包括传输到欧盟以外。问清楚它满足的是哪项具体需求（存储、处理、传输、支持访问、一份合同、政策），然后和隐私、法务及安全团队一起把它转化为架构。重读不要扮演律师和当欧洲有了自己的 org。
7. Salesforce 把订单发送到 ERP 的 API。哪一方处理重试，Salesforce 把密钥存在哪里？
Salesforce 是客户端：它打开连接，看到整个往返过程，是唯一能够重试的一方。命名凭据保存端点，它的外部凭据保存认证信息。ERP 是服务器，定义契约并验证进来的东西。重读每一个箭头都需要一个机制。
8. 一个集成今天每分钟发送几条记录，而业务方预计明年每小时会有几万条。箭头会变吗？
可能它的机制会变，甚至方向也会变。每分钟几条记录可以是从 Salesforce 发出的标注调用（callout）；多得多的记录可能意味着发布事件，由另一个系统订阅，于是箭头从另一端开始；一夜几百万条就是批处理。在做选择之前先知道数量。重读把零的个数写进清单。
- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab)，Salesforce Help（英文，查阅日期 2026-09-25）：官方的考试目标清单及其权重。预约考试前，务必查看最新版本。