第4章 元数据模型设计：实体-关系模型、属性定义与Schema演化策略
元数据模型设计，说白了就是给数据资产画张“基因图谱”。你想想看，要是连自己管理的数据长什么样、跟谁有关系都说不清，后面的工作流编排根本无从谈起。我曾经接手过一个项目，团队直接拿关系数据库的ER图硬套到元数据上，结果跑了半年发现完全不是那么回事——元数据本身是描述数据的数据，它的实体关系比业务数据更抽象、更灵活。
这一章我带你从三个维度把模型立起来：实体怎么划、属性怎么定、Schema怎么优雅地变。嗯，都是我在实际项目中踩过坑之后总结出来的习惯。
4.1 实体-关系模型：核心骨架怎么搭
我个人习惯先画实体，后连关系。元数据领域的实体不会太多，但每个都很关键。拿样本元数据来说，核心实体就那么几个：样本(Sample)、样本集(Dataset)、项目(Project)、实验(Experiment)、流程实例(WorkflowInstance)。
核心原则：实体要有独立生命周期，关系要能表达层次和引用两种语义。
举个例子，样本和样本集之间是“属于”关系，这是层次语义。样本和流程实例之间“由…生成”，这是引用语义。混在一起会出大问题——我之前见过一个模型把样本集当成样本的属性字段，结果样本集重命名时得遍历所有样本去更新，性能直接崩了。
| 实体 | 关键属性（示例） | 主要关系 |
|---|---|---|
| Sample | id, name, type, created_at | belongs_to Dataset, produced_by WorkflowInstance |
| Dataset | id, name, version, description | has_many Sample, belongs_to Project |
| Project | id, name, owner, start_date | has_many Dataset, has_many Experiment |
| Experiment | id, name, config, status | belongs_to Project, triggers WorkflowInstance |
| WorkflowInstance | id, workflow_name, params, run_id | belongs_to Experiment, produces Sample |
避坑提醒：关系不要画太多。我曾经看到一个模型，Sample和Experiment直接关联、Sample和WorkflowInstance也直接关联，结果两边数据不一致。更合理的做法是让WorkflowInstance作为中间实体，它既记录实验触发信息，又关联产出样本。
4.2 属性定义：既要够用，又不能冗余
实体确定下来之后，属性定义就是往里填细节。这里我建议分三类来思考：
- 固有属性：无论什么场景都不会变的，比如ID、创建时间、类型。这类属性直接声明即可，不要去考虑什么动态性。
- 系统属性：由元数据管理平台自动维护的，比如更新时间、版本号、状态、owner。注意，owner不一定是业务负责人，可能是流程实例或用户ID，别搞混。
- 自定义属性：业务方自己扩展用的。这部分最容易被滥用——我见过有人把样本的存储路径、样本的文件格式、样本的预处理参数全塞到自定义属性里，结果查起来头疼得要命。
避坑指南：自定义属性一定要有命名空间隔离。我曾经在一个项目中没做隔离，结果不同的团队往Sample上写了相同的key但语义完全不同的属性值，查询时程序直接崩溃。建议用“namespace:key”的格式，比如“storage:path”、“preprocessing:step”。
属性的数据类型也得想清楚。我个人习惯给每个属性定义明确的类型，而不是统统用字符串：
{
"sample_id": {"type": "string", "required": true, "unique": true},
"sample_name": {"type": "string", "max_length": 200},
"created_at": {"type": "datetime", "auto_generate": true},
"storage_path": {"type": "string", "namespace": "storage"},
"file_size": {"type": "integer", "unit": "bytes"},
"tags": {"type": "array", "item_type": "string"},
"quality_score": {"type": "float", "min": 0, "max": 1}
}小技巧：像tags这样的数组属性，定义好item_type之后，查询时可以直接用数组包含操作，比用逗号拼接字符串高效得多。
4.3 Schema演化策略：变化是常态
元数据模型定下来之后，你很快就会遇到一个现实问题——业务变了，Schema得跟着变。但直接改Schema？那整个数据资产可能会断掉。为什么？因为历史数据已经按照旧结构存进去了。
我建议把Schema演化分为三种场景：
| 演化类型 | 操作示例 | 影响范围 |
|---|---|---|
| 向前兼容（Additive） | 新增可选属性、新增实体、新增关系 | 旧记录无需变动，新记录使用新结构 |
| 向后兼容（Removal） | 废弃不用的属性（标记为deprecated） | 旧记录保留旧属性，新记录不再写入 |
| 非兼容（Breaking） | 修改属性类型、删除必需属性、合并实体 | 必须迁移所有历史数据，发布新Schema版本 |
那具体怎么操作呢？我自己的做法是用版本化+补偿策略：
- 版本化：每个实体或属性都维护一个schema_version字段。新数据写新版本，旧数据保持原样不动。
- 补偿写入：查询时，如果旧数据缺少某个新属性，通过默认值或回填逻辑补齐。这个逻辑我习惯写在元数据服务的读取层，而不是业务代码里。
- 批量迁移：对于非兼容变更，得跑一个离线迁移作业。我记得有一次要把字符串类型的“实验配置”改成结构化的JSON对象，我专门写了个转换脚本，跑完之后再做全量校验。
# 补偿读取示例（伪代码）
def get_sample(sample_id):
raw = storage.read(sample_id)
version = raw.get("schema_version", 1)
if version == 1:
raw["storage_path"] = raw.pop("old_path", "")
raw["quality_score"] = 0.0 # 旧数据默认值
elif version == 2:
# 无需补偿
pass
return raw避坑指南：千万不要在业务高峰期跑Schema迁移脚本。我之前有一次直接在白天迁移Schema，结果锁表导致所有写入操作阻塞了五分钟，那个教训太深刻了。后来我改成凌晨低谷期+灰度放量策略，再没出过问题。
4.4 模型设计的几个实用习惯
最后分享几个我个人觉得特别好用的习惯，算不上什么高深理论，但在实际项目中帮我省了不少事：
- 多用时间戳：每个实体必须保留created_at和updated_at。这在排查问题和做数据血缘时简直救命。
- 区分软删除与硬删除：元数据最好用软删除，加一个status字段标记为deleted。硬删除会破坏数据血缘链条。
- 预留扩展属性字段：哪怕现在没想好，也要给每个实体留一个extras（json格式）字段。实际项目中你永远不知道什么时候会冒出一个新需求。
- 给关系加权重：如果两个实体之间存在多种关系（比如样本被多个流程处理过），那么每条关系记录都最好带上时间戳和relation_type。