第3章 元数据模型与Schema
第3章 · 元数据模型与Schema
章节摘要：元数据模型是 DataHub 的坐标系系统——没有它，接入的每一条元数据都是无家可归的碎片。本章从实体与关系两个基本概念讲起，深入 Aspect 这一 DataHub 特有的建模单元，最后落到实操：用 PDL 语言定义自己的实体类型、注册到平台并安全地演进 Schema。读完本章，你应当能读懂平台内置模型的设计逻辑，并为一类业务自定义资产（比如指标、特征、数据产品）建立合规的模型。这是全册技术含量最高的一章，也是连接架构与接入实战的桥梁。
学习目标
读完本章，你应当能够：
- 用实体、Aspect、关系三要素描述任意一种元数据资产，并判断它该建模为实体还是 Aspect；
- 解释 URN 的构造规则与命名空间设计，为自定义实体起一个不会返工的标识；
- 阅读平台内置的表实体模型，指出它的 Aspect 划分逻辑与各 Aspect 的职责；
- 编写一个 PDL 文件定义新的实体类型与自定义 Aspect，并通过校验注册到平台；
- 为自定义 Aspect 设计键结构与局部更新语义，避免整块覆盖导致的数据丢失；
- 制定团队自己的模型演进规范：什么改动向后兼容、什么改动需要迁移、迁移怎么做。
核心概念速览
DataHub 的模型世界由三层构成：实体是被管理的"名词"（表、任务、仪表盘），Aspect 是挂在实体上的"属性包"（结构、所有权、血缘），关系是实体间通过特殊 Aspect 表达的"动词"（上下游、包含、归属于）。平台的一切能力——搜索、血缘、治理——都建立在这三层之上。
一句金句概括本章：建模是把"大家都在说但谁也没定义"的东西，变成"机器能存、人能查、系统能用"的契约。 带着这句话读三节会有一个统一的视角：判定三问是在筛选值得立契约的对象，Aspect 设计是在决定契约的粒度与修订方式，PDL 与演进规则是把契约落成受版本管理的正式文件。
子章节导航
- 3.1 建模基础：实体与关系——从"什么值得成为实体"讲起，给出实体与属性的判定方法，附 URN 命名规范。
- 3.2 Aspect 模型设计——DataHub 最有特色的建模单元：为什么要按 Aspect 拆分、键怎么设计、更新语义怎么选。
- 3.3 用 PDL 自定义模型与 Schema 演进——从写第一个 PDL 文件到注册生效的完整流程，以及模型变更的兼容性规则。
子章节之间的逻辑关系
三节是"概念、机制、实操"的递进：3.1 建立世界观（什么是什么），3.2 深入核心机制（DataHub 与其他平台模型差异最大的地方），3.3 动手落地（写模型、注册、演进）。跳过 3.1 直接读 3.3 会知其然不知其所以然；跳过 3.2 则在自定义建模时必然踩覆盖语义的坑：
[3.1 实体与关系] ──> [3.2 Aspect机制] ──> [3.3 PDL实操与演进] 世界观 核心机制 动手落地
前置知识与后续延伸
本章假设你已读完第 2 章，知道 Aspect 存放在主库、被索引进搜索视图——建模决策直接决定这些存储里的数据形状。不需要编程经验，PDL 的语法接近 JSON 加类型定义，会读配置文件就能上手。
一个降低畏惧心的提示：本章的三节都不要求你一次学会。3.1 的判定三问与 URN 规范是纯概念，十分钟就能建立判断框架；3.2 的更新语义在遇到"谁覆盖了谁"的问题时回头精读即可；3.3 的 PDL 实操等到真的要接入新资产类型时再动手不迟。建模知识是典型的"用时方知贵重"，先留下印象，需要时本章就在这里。
学完本章，第 4 章的接入工作就有了模型依据：连接器采集的每条元数据都要装进本章定义的模型容器里。如果你所在团队计划把特征平台、指标平台接入元数据体系，3.3 节的自定义建模就是为此准备的武器。
反之，若团队暂时没有自定义资产的需求，3.1 与 3.2 的概念仍然必修——它们是读懂平台里一切元数据行为的语法书。
回到金句再补一句：好的建模不是一次性设计出来的，是按本章的演进规则一版一版养出来的。