企业数据的类型
另有 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)
第 2 个模块，共 6 个，属于 Data Architect 课程第 4 章理解企业数据。每个模块都可以单独阅读。 上一篇：Salesforce 只是众多系统之一 · 下一篇：Salesforce 周围的系统
**本模块回答的问题：**一个企业拥有哪些类型的数据，为什么它们属于不同的地方？
一条客户记录。一份国家列表。一个订单。一个字段定义。五年的销售总额。四百万张配送照片。它们都是数据，但在架构上它们不是同一样东西。它们的变化方式不同，增长方式不同，使用方式不同，所有者也不同，所以它们不应该自动放在同一个地方。所以当有人说“我们需要把这些数据放进 Salesforce”时，我接下来的问题是：**它是哪类数据？**答案会开始告诉我该怎么处理它。
从类型开始，而不是从对象开始
Section titled “从类型开始，而不是从对象开始 ”作为 Salesforce 从业者，我们几乎会立刻把需求翻译成结构：客户，客户对象；照片，文件；状态，选项列表。这最终是有用的。但在企业层面，我首先想知道自己面对的是哪类信息。分类的方式有很多（DAMA 知识体系是标准参考），我觉得有六种类型很有用：**主数据、参考数据、交易数据、元数据、分析数据和非结构化数据。**这些类别本身不是架构，而是一种提出更好问题的方式。
主数据：业务所知道的事物
Section titled “主数据：业务所知道的事物 ”主数据描述业务围绕其运转的那些持久的事物：客户、产品、定价、员工、供应商、地点、资产。在一个 Salesforce 销售 org 里，就是你的客户和联系人、你的产品和价格手册。在 Steve Trucking，零售合作伙伴是主数据。Keystone 不是一个事件，而是一个与 Steve Trucking 有持续关系的组织。九个配送中心也是主数据。
主数据比使用它的交易存在得更久：一个零售合作伙伴可以有几百万次配送。所以关于它的第一个问题总是**谁拥有它？**可能不是 Salesforce。ERP 可能拥有产品。Salesforce 可能拥有潜在客户，而一旦他们成为客户，ERP 就成为权威。一个 MDM 平台可能拥有由多个系统拼合而成的企业级客户身份。第 6 章“主数据与身份”会深入讨论。现在，先认出它的形状。
参考数据：业务共享的词汇
Section titled “参考数据：业务共享的词汇 ”参考数据是用来给其他数据分类的受控词汇：国家代码、货币、产品类别、原因代码、状态。Steve Trucking 的配送状态（已排期、已装车、配送中、即将到达、已送达、已安装、异常、已退回）就是参考数据。它们不是配送，而是用来描述配送的词。
它看起来小而无害，常常只是一个有八个值的选项列表。不要把小和不重要混为一谈。如果 Salesforce 说 Delivered，ERP 说 Complete，某个零售合作伙伴发来 D，就得有人定义每个值是什么意思、它们如何映射。参考数据是集成假设藏身的地方。
交易数据：发生了什么
Section titled “交易数据：发生了什么 ”交易数据记录活动：下了一个订单，付了一笔款，完成了一次配送，开了一个个案。在同一个销售 org 里，就是报价和报价行、订单和订单项、付款：每一条都指回一个客户和一个产品。Steve Trucking 每年一百万次配送是交易数据，它们的状态更新也是：每次配送大约八次，所以每年八百万次状态变更，而业务每年增长 30%。
这和主数据的增长曲线完全不同。顶上是三个零售合作伙伴；底下是几百万行。这就是 Steve 的“零的个数” 发挥作用的地方：你不能看着零售合作伙伴 → 配送 → 状态，就给每个方框同样的分量。面对交易数据，我会立刻想到数据量、速度、保留、历史、归档、集成，以及人们实际需要如何找到它。第 2 部分会在那里花很多时间。
元数据：关于数据的数据
Section titled “元数据：关于数据的数据 ”整门课你都在和元数据打交道：一个对象的定义，一个字段的类型、它的描述、它的关系。整个企业都有元数据：数据仓库的结构、集成映射、数据目录、API 契约，以及每个字段的所有者、敏感级别、定义、血缘和保留规则。值是数据；对它们含义的描述是元数据。正如第 3 章所说，Flag2__c 什么也没告诉任何人，而现在 AI 会读取元数据来弄清数据的含义，这一点就更重要了。
分析数据：我们从其他数据中制造出来的数据
Section titled “分析数据：我们从其他数据中制造出来的数据 ”“过去五年我们按零售合作伙伴统计的准时率是多少？”不是一笔交易。它是一个分析问题，要通过从几百万次配送中推导出新数据来回答：准时百分比、货损率、每个合作伙伴的收入、安装质量、配送小组的趋势。而且这是另一份工作。调度员问“217 号卡车的下一站是哪里？”时，不需要扫描五年的历史。领导层按区域比较五年的准时表现时，就需要。这就是为什么分析数据通常放在为这种工作而构建的数据仓库、湖仓或分析平台里。Salesforce 能够存储某样东西，并不意味着运营平台就是对它运行每一项分析的地方。
非结构化数据：装不进行里的东西
Section titled “非结构化数据：装不进行里的东西 ”文档、PDF、图片、音频、视频、电子邮件、转录文本、知识文章。在 Steve Trucking，就是配送照片：每次配送大约四张，有安装的更多，每年四五百万张。一张照片不只是又一个字段。它很大，它可能拍到某人家里的样子，它有自己的保留规则，而且它的搜索方式不同，如果能搜索的话。
这类数据一年比一年重要，因为 AI 现在能对过去处于结构化模型之外的信息做有用的事。一份转录文本是数据。一本 PDF 手册是数据。一张安装照片是数据。这并不意味着它属于 Salesforce 的核心平台。它意味着它属于全景图。
六种数据，每种四个问题。答案随种类而变，这正是关键所在。
类型只是问题的一半：工作负载
Section titled “类型只是问题的一半：工作负载 ”知道我们有哪类数据还不够。我还想知道**我们要用它做什么。**这里有三种工作负载很重要，把它们混淆就会产生糟糕的架构。
**运营：经营业务。**调度员更新一次配送，配送小组完成一个停靠点，服务人员开一个个案。大量的小规模读写：找到这个，更新那个，给我看今天的停靠点。这就是 OLTP，联机事务处理，而 Salesforce 非常擅长这个；这是管理员和开发人员的主场。
**分析：理解业务。**五年里的每一次配送，按合作伙伴和配送中心分组，逐年比较，再和财务数据关联。现在我们是在扫描和聚合。这就是 OLAP，联机分析处理，数据仓库、湖仓和分析平台正是为此而建的。简单地说：**org 经营业务；数据仓库和数据湖分析业务。**一个经典的错误，是把这种工作负载放到运营平台上，然后在零越来越多时感到意外。如果有人想反复扫描海量的历史，不要把它当作“又一份报表”。要问一问这是不是合适的平台。第 2 部分会在为规模而设计 *(coming soon)*中回到这一点（不要把核心当成你的数据仓库），第 3 部分会在超越关系型 *(coming soon)*中展示分析结构是如何构建的。
**流式：流动中的数据。**事件、遥测、状态变更、传感器读数。Steve Trucking 的卡车每天发送大约 **20 万条 GPS 读数。**调度员关心的是 217 号卡车现在在哪里。Salesforce 需要保留每辆卡车每分钟的每一条读数吗？也许不需要。“它现在在哪里？”和“上个季度的路线效率趋势如何？”来自同一个来源，却导向完全不同的存储决定。
它需要多快地流动？
Section titled “它需要多快地流动？ ”然后是延迟。我在课上是这么说的：实时就是站在门口等某人回来。你派他们出去，然后站在那里，因为在他们回来之前你没法继续。这就是同步。近实时就是看着他们离开，然后去做别的事；他们不久后回来时，你再处理。这就是异步。然后还有批处理：没有人一个一个地出门。数据先等着，再按计划成批移动：每小时、每几小时或每天。很多情况下批处理就足够了，也有些情况不够。分清哪是哪，正是你的工作。这三个不只是集成术语，而是架构上的选择。
拿常见的 ERP 集成来说。上午 11 点，ERP 里创建了一个新产品。销售真的需要在中午之前就能卖它吗？两种答案我都见过。有些客户希望越快越好；另一些客户说，如果我们还没把那个 SKU 发给你们，就不能指望你们现在去卖它。所以产品通常每天同步一次，有时更快。客户，至少每天一次；我见过每小时的，极端情况下是近实时的。订单就不同了：履约必须开始，所以要近实时。销售人员成交后就去做别的事了，订单在几秒到一两分钟内到达 ERP。“企业数据”没有唯一正确的延迟。问一问业务实际需要什么，不要因为听起来厉害就把一切都做成实时的。实时是有代价的。
类别背后的四个问题
Section titled “类别背后的四个问题 ”你不需要到处宣布“这是交易数据！”分类的意义，在于对每一个重要的数据集引出四个问题：
- 谁拥有它？哪个系统是权威的？我把它拆成三个问题：它在哪里创建，在哪里编辑，在哪里被引用？第 6 章会深入讨论这些（在哪里创建、编辑、引用，变化多快？）。
- **它变化得多快？**一年一次、每天、每秒几十到几百次？
- **它会变得多大？**十条记录、一万条、一千万条、一百亿条？
- **它的生命周期是什么？**它会永远存在、被归档、必须被删除，还是会随时间失去价值？
这四个问题告诉我的，远比“Salesforce 能存这个吗？”要多得多。它们也把我们已经学过的东西串了起来：所有权、生命周期、零的个数、数据放在哪里。
一个业务会产生每一种数据
Section titled “一个业务会产生每一种数据 ”在 Steve Trucking，零售合作伙伴是主数据；状态词汇是参考数据；每次配送是交易数据；它的字段定义是元数据；五年准时率记分卡是分析数据；安装照片是非结构化数据；GPS 数据流是流式数据。它们都是“Steve Trucking 的数据”。但这并不意味着它们属于同一个数据库。这就是那个转变。
**考试之外：AI 改变了什么。**为了回答一个问题，智能体可能需要一条结构化的客户记录、一笔最近的交易、一本 PDF 手册、一份服务转录文本和实时遥测数据。非结构化数据和流式数据成为架构中的一等成员，即使它们不属于 CRM 数据库，而架构师仍然必须知道每个来源归谁所有、它有多新，以及智能体是否应该信任它。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 每一个重要的数据集是哪类数据，以及谁拥有它。
- 它的工作负载是运营、分析、流式，还是混合。
- 它变化得多快，以及其他系统真正需要多快看到这个变化。
- 数据量和生命周期如何决定它放在哪里、放多久。
- Salesforce 应该拥有它、保留一份副本、引用它，还是把它留在更适合这种工作负载的地方。
当有人交给你一项需求时，不要直接跳到哪个对象、哪个字段、哪个 API。先问它是哪类数据，谁拥有它，它变化得多快，它会变得多大，它存在多久，以及我们想用它做什么。一个客户、一个配送事件、一个五年汇总和一张照片，可能对同一个业务都很重要，却不是同一个架构问题。
- DAMA International，DAMA-DMBOK: Data Management Body of Knowledge，第 2 版（2017，英文）：关于数据类别和数据管理的标准参考。
- Steve Trucking 的简介，第 4 节（数据量）。