词典、血缘与分类
另有 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)
第 3 个模块，共 6 个，属于 Data Architect 课程第 5 章数据质量与治理。每个模块都可以单独阅读。 上一篇：把坏数据挡在门外 · 下一篇：隐私法塑造设计
**本模块回答的问题：**如何记录数据意味着什么、从哪里来、有多敏感？
你接手了一个 org。客户对象有 900 个字段，其中有 Customer_Type__c、Customer_Class__c、Customer_Category__c、Customer_Status__c、ERP_Status__c 和 Account_Status__c。哪一个能告诉你某人是否真的是客户？你打开描述。三个是空的。一个写着“Customer Type”。谢谢。一个说它来自 ERP；另一个是六年前由一个早已离开的人创建的。现在想象你不是架构师，而是一个集成、一个报表团队，或者一个智能体。组织拥有大量数据，但这并不意味着它知道这些数据意味着什么。
这就是元数据变成架构的地方，通过三个相关但不相同的问题：
- **词典：**这份数据意味着什么？
- **血缘：**它从哪里来？
- **分类：**必须如何对待它？
两种元数据
Section titled “两种元数据 ”元数据分两种，两种你都需要。业务元数据是数据对业务意味着什么：定义、所有者、使用规则、敏感程度。技术元数据是数据如何构建、如何流动：对象和字段、类型和长度、API 名称、模式（schema）、从一个系统到另一个系统的映射、从来源到目标的血缘。一个字段的 API 名称和类型告诉开发人员如何使用它；它的定义和所有者告诉其他所有人是否应该使用它。当两者不一致，或者缺了其中一个，集成和报表就会在那里出错。
考点。区分业务元数据（含义、定义、所有者、规则、敏感性：即业务词典和分类）和技术元数据（对象、字段、类型、API 名称、模式、映射和血缘）。
从含义开始
Section titled “从含义开始 ”第 3 章定下了规则：每个字段都要有描述。不是给一个叫 Customer Status 的字段写“Customer Status”，而是写成类似这样：*“合作伙伴与 Steve Trucking 当前的商业关系。激活后由 ERP 设置。不要用于潜在客户的资格认定。”*现在我知道了它的含义、它从哪里来，以及不应该把它用于什么。这就是业务词典的开端：对重要数据的共同定义。什么是客户？什么是活跃客户？已送达是什么意思？什么算准时？这些听起来理所当然，直到你把五个部门放进一个会议室：财务有一个定义，销售有另一个，运营有第三个，数据仓库有第四个，而有人在第五个定义上建了一个仪表板。问题不是没人会说英语，而是企业还没有就含义达成一致。
词典可以放在电子表格或文档工具里，但其中重要的定义需要贴近人们使用数据的地方。在平台上，那就是字段描述、帮助文本和分类元数据。在分析中这一点更为重要：“收入”不能在高管仪表板上是一个意思，在分析师的查询里又是另一个意思。这正是语义层的用途，而 Data 360 的语义模型在物理数据之上保存受治理的定义，比如指标、维度和关系（Create a Semantic Model in Data 360 (opens in a new tab)，英文）。技术会变；需求不变：重要的数据需要一个达成一致的含义。
而且要从含义开始，而不是从技术开始。一份从对象、字段、类型和 API 名称开始的词典，记录的是实现。一份从业务术语开始的词典，记录的是企业：
| 业务术语 | 含义 | 在哪里体现 |
|---|---|---|
| 零售合作伙伴 | Steve Trucking 根据合同为之配送的零售商 | Salesforce 客户；财务 ERP 客户 |
| 配送 | 在某一天、向某一个地址的某一位收货人进行的一次配送 | 目前在 RouteDesk 中；配送迁入 Salesforce 后为工作订单 |
| 收货人 | 接收配送的人 | 配送上的收货人详情 |
| 已送达 | 按照约定的运营定义完成 | 配送状态 |
| 准时配送 | 在约定的配送时间窗口内完成 | 推导出来的指标 |
一个含义，多种技术表示。
然后问它从哪里来
Section titled “然后问它从哪里来 ”一旦知道了一个值的含义，我就想知道**它从哪里来。**这就是血缘。Salesforce 中一个合作伙伴的法定名称：是销售代表输入的，是 ERP 发来的，是某个集成转换过的，是 Data 360 统一过的，是计算出来的，还是 AI 生成的？这些会影响我有多信任它，以及我可以用它做什么。还记得模块 2 的临时记录吗：两个客户可能都叫“Keystone”，一个是销售代表昨天创建的，另一个来自 ERP，带有权威标识符。同样的文本，不同的血缘，不同的对待方式。
血缘不只是数据工程师画的一张上千张表的图。对于重要的数据，我想回答一些实际的问题：它从哪里开始，哪个系统是权威的，什么转换了它，哪些系统拿到了副本，最后是什么修改了它，以及我能否把一个推导出来的值追溯到它的来源？第 4 章的全景图说明系统是相连的。血缘说明数据在途中经历了什么。
有些血缘是免费得来的：客户上的 ERP ID，创建人和上次修改人，集成日志，映射文档。Data 360 会在它的数据对象上加上血缘字段，记录每条记录的数据源和源对象（Data Lineage Fields (opens in a new tab)，英文）。但不要以为系统集成了，血缘就会自动出现。有时最有用的血缘就是一个字段：**来源系统 = Keystone。**而如果来源对治理很重要，就让它在机制上可靠，由集成来设置，而不是由人来输入。
推导出来的数据最需要血缘。假设 Steve Trucking 根据卡车位置、配送时间窗口和路线历史算出一个延误风险，调度用它来排定优先级。“高”是从哪里来的？再加上一个告诉收货人“您的配送将会延误”的智能体，你就需要知道是什么为这句话提供了依据，以及它有多新。你离存储的值越远，越走向计算的、统一的、预测的和生成的值，血缘就越重要。
分类回答的是另一个问题
Section titled “分类回答的是另一个问题 ”现在是：**应该如何对待它？**收货人姓名、配送地址、电话号码、配送备注、配送状态、卡车编号、配送中心、零售合作伙伴、照片：它们的敏感程度并不相同。“配送中”不是一个电话号码，一个配送中心代码也不是一张某人家里的照片。Salesforce 让你在每个字段上记录这些，无论是标准字段还是自定义字段：Data Owner、Field Usage、Data Sensitivity Level 和 Compliance Categorization（Data Classification Metadata Fields (opens in a new tab)，英文）。第 3 章把它们叫作分类字段，也讲了它们为什么重要：把一个字段标记为 PII 或 GDPR，各种流程就能找到它，从掩码工具到 Salesforce 的 AI 信任层（trust layer），后者可以阻止被标记的值到达大语言模型。第 3 章还有一个提醒：Salesforce 现在对智能体禁用了这种 LLM 掩码，因为它可能会去掉智能体需要的上下文（给重要的东西分类：分类字段）。所以分类仍然必须驱动其他控制措施。
我在这里的立场是有意为之的：**给敏感字段分类，而不是每个字段。**我不希望花三个月时间给成千上万个字段分类，只为了让某人报告“100% 已分类”，然后没人用它。收货人的电话号码：是。家庭住址：是。可能包含门禁密码和“院子里有狗”的配送备注：是。可能拍到人或住宅的照片：绝对是。一个内部显示标签？那不是治理精力应该花的地方。这并不意味着没有文档的字段就可以接受。这是两份不同的工作：**文档要广泛；分类要有选择。**正是这一点让分类保持有意义。
一套人们用得起来的分类体系
Section titled “一套人们用得起来的分类体系 ”分类需要一套词汇，即分类体系。Salesforce 的默认值依次是 Public、Internal、Confidential、Restricted 和 MissionCritical；你的组织也许想要自己的标签。我不做规定。只要让它们容易理解：如果有 47 个类别，而隐私团队之外没人能分清第 31 类和第 32 类，它就帮不上忙。一套好的分类体系会把一个标签和行为联系起来。如果一个字段是敏感的个人数据，谁能看到它，它能否进入沙盒，能否离开所在区域，能否出现在分析中，保留多久，智能体能否使用它？这时，分类就在发挥作用了。
没有执行的分类只是装饰
Section titled “没有执行的分类只是装饰 ”把收货人的电话号码标记为敏感，别的什么都不改，你写的就只是文档。有用，但治理要走得更远：分类应该驱动权限、掩码、加密、保留、同意、数据流动、沙盒使用、审计和 AI 访问。其中有些是架构师的设计决定；有些平台现在会直接在策略中应用标签和分类，Data 360 的治理就是这样（Data Governance in Data 360 (opens in a new tab)，英文）。而把一个字段标记为 Restricted，并不会阻止任何人读取它。分类说明一个字段应该如何被对待；安全让它成真。顺序是：识别数据，理解数据，给重要的东西分类，然后施加分类所要求的控制。
关于你的数据的三个问题，而第三个必须驱动点什么。
参考数据也需要元数据
Section titled “参考数据也需要元数据 ”国家代码、配送状态、配送中心代码、合作伙伴标识符、取消原因：它们看起来很简单，直到两个系统意见不一。一个说 CANCELLED，另一个说 CANCELED，第三个说 CNCL，第四个说 9。参考数据需要定义、一个所有者、一个来源、值会变化时的生命周期，以及系统表示方式不同时的映射。小小的值可以驱动非常大的流程。第 6 章会更进一步。
三者合在一起
Section titled “三者合在一起 ”拿收货人电话号码来说。词典：用来联系某次配送的收货人的号码。血缘：来自零售合作伙伴的装货清单。分类：个人数据。现在，架构问题就可以问了：配送小组可以看到它吗，能看多久（简介里说只能在当天、只为自己的停靠点）；它能进入沙盒吗；Snowflake 需要它吗；智能体可以使用它吗；配送完成后会怎样？
再看**配送状态。**词典：配送当前的运营状态。血缘：由 Steve Trucking 的配送流程设置，并通过各自的集成回传给每个合作伙伴。分类：运营数据，不敏感。不同的数据，不同的对待方式。这就是重点。
我不把元数据当作在真正的架构完成之后才产出的文档。如果我说不出一个字段的含义，我就不理解数据模型。如果我不知道一个值从哪里来，我就不理解集成。如果我不知道它是否敏感，我就不理解安全。元数据描述架构，有时还驱动架构。
**考试之外：AI 改变了什么。**分类正在变成决定智能体可以检索或复述什么的开关，而血缘必须一直延伸到智能体的回答或行动。如果一个智能体告诉收货人配送会延误，架构应该能说出是什么为它提供了依据，它从哪里来，以及智能体是否被允许使用它。“Salesforce 里的某个地方”不是血缘，“客户数据”也不是一种分类。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 哪些业务术语需要受治理的定义，这样各个系统和团队就不会给同一个词赋予不同的含义。
- 重要的值如何保留足够的血缘，以显示它们的来源、权威性和转换过程。
- 哪些字段带有敏感性或合规含义，因此需要明确的分类。
- 组织使用哪套分类体系，以及人们能否一致地应用它。
- 分类如何驱动真正的控制措施，而不是被闲置在那里。
在治理数据之前，先知道你拥有什么：它意味着什么，从哪里来，必须如何对待。广泛地写文档，有选择地分类，在重要的地方保留血缘。否则你并没有在治理数据。你只是拥有它。
- Salesforce Help，Data Classification Metadata Fields (opens in a new tab)（英文），查阅日期 2026-10-14。
- Salesforce Help，Data 360：Data Lineage Fields (opens in a new tab)、Data Governance in Data 360 (opens in a new tab) 和 Create a Semantic Model in Data 360 (opens in a new tab)（英文），查阅日期 2026-10-14。