知识问答效果不好时，团队第一反应通常是换 embedding、调 top-k 或升级模型。我在数据平台场景里遇到的更多情况是：被索引的元数据本身不完整、没有版本，甚至彼此冲突。检索与生成只能重新排列现有信息，不能凭空修复事实链。

RAG 的上限取决于它能拿到什么证据。表名和描述只是最薄的一层；对象身份、来源、有效时间、负责人、血缘、权限和采集状态，决定答案能否从“听起来合理”走到“可以复核”。

数据 Catalog 常见的问题不是没有资产，而是用户不知道该怎么找。平台要求先选实体类型，再填库、表、标签、负责人，只有熟悉元数据模型的人才能用好。自然语言适合作为入口，但它不该绕开 Catalog，直接让模型根据一堆描述猜表。

我的设计是两段式：模型把问题解析成结构化检索意图，Catalog 用确定性查询返回实体；模型再基于实体和关系组织答案。对象身份、权限和血缘事实仍由 Catalog 决定。

开发和生产都存在 sales.orders 时，最危险的不是用户查错表，而是一个带生产凭证的测试任务真的把生产 metadata pointer 提交成功。SQL 语句、表名和 schema 全都合法，事故不会在 parser 或 type checker 阶段被拦住。

多环境 Catalog 隔离不能只靠名称前缀。dev_catalog 和 prod_catalog 如果背后连的是同一个 Metastore、同一个 warehouse，并且作业拿到同一套写凭证，前缀只是提醒，不是安全边界。我要求名称、控制面、存储位置和执行身份四层同时隔离。

数据契约一旦被理解成“上游不许改字段”，很快就会失效。业务一定会增加状态、调整口径、拆分字段，平台不可能靠审批把变化冻结。真正需要禁止的是未经识别、没有迁移窗口、出了问题无法回滚的变化。

我把契约看成生产者与消费者之间的变更协议。Schema 是其中可机器检查的一层，除此之外还要写清字段含义、主键、时间语义、空值、质量阈值、交付时效、owner 和弃用期限。契约的目标不是少改，而是让每次修改都有证据链。

做统一 Catalog 时，团队通常先讨论要接哪些数据源、搜索框怎么做、血缘图画到字段还是表。我更愿意先追问一个看起来很基础的问题：prod 和 test 里都叫 sales.orders 的两张表，到底是不是同一个对象？

这个问题没答清楚，后面所有治理功能都会漂。采集任务重复跑一次可能多出一张表；集群迁移后，原来的标签和负责人找不到了；表重命名既可能把历史血缘切断，也可能错误地把两个对象合并。Catalog 不是把各种名称塞进一个搜索索引，它首先是一套对象身份系统。

数据质量平台发出一条告警：“订单表行数校验失败，实际 980 万，期望大于 1000 万。”收到的人通常还要追问：检查的是哪个分区，数据任务跑完了吗，规则什么时候改过，这次是补数还是正常调度？

如果这些信息不在结果里，一条 FAIL 只是现象。甚至同一条规则重跑后变成 PASS，也无法判断数据被修复了，还是第二次读取了另一批数据。

Great Expectations 0.14.2 把一次验证拆成 Batch、Expectation Suite、RunIdentifier、Validation Result 和后续 Action。这个结构很值得数据平台参考：规则不是悬空执行，结果也不能只保存布尔值。一次质量结论必须能回答“用哪版规则，在什么时候，对哪批数据，算出了什么”。

血缘项目最容易交付的是一张很大的图：点开一张表，左边几十张上游表，右边几十张下游表，连线铺满屏幕。演示时很直观，真正遇到问题却常常答不出来。

“改这个字段会影响谁”需要字段与表达式；“昨晚这批数据为什么错”需要运行实例、代码版本和输入输出水位；“这张表有哪些上游”用表级关系就够。把三种问题都塞进同一张表级拓扑，图再完整也只能回答资产发现。

Apache Atlas 2.1 的模型本身已经给出几种层次：基础 Process 通过 inputs/outputs 连接 DataSet；Hive 还有 hive_column_lineage，保存字段依赖和 expression；模型里也有 ProcessExecution 与 hive_process_execution 表达具体执行。关键不在于有没有这些类型，而是采集和查询时是否保留了问题需要的证据。

数据平台上的 schema 变更，最危险的往往不是 ALTER TABLE 报错，而是 ALTER 成功、任务也能跑，结果却把旧字段读成了另一个含义。

按字段位置读取的系统里，删除第二列后，后面的列全部向前移动；按字段名读取的系统里，先删除 status，过一段时间又新建同名字段，旧文件中的 status 可能被误认为新字段。单看最新 DDL，两次操作都合法，历史数据的语义却已经混在一起。

Apache Iceberg 0.12.0 用永不复用的 Field ID 跟踪列。改名和重排只改变显示信息，字段身份不变；删除后再添加同名列会拿到新 ID，旧数据不会“复活”。这套规则很适合用来理解 schema evolution 的核心：兼容性不是比较两份字段名列表，而是判断字段身份、类型和值域能否连续解释。

做元数据平台时，很容易先把精力花在资产目录、业务术语和页面分类上。界面做得很完整，任务失败时却还是有人在群里问：这张表谁负责，今天是哪段代码写的，改字段会影响哪些任务？

我更愿意从这些运维问题反推元数据模型。它们有明确答案，也能用一次真实故障检验。平台先把表、任务、实例和运行证据串起来，资产目录才不会只剩一棵需要人工维护的树。

下面用 Apache Atlas 2.1.0 的源码模型做参照。对应提交是 da35519，打包时间在 2020 年 7 月。Atlas 已经提供了实体唯一标识、Process 输入输出、实体变更审计和血缘查询；运行实例仍需要平台自己建模。