本文整理了两个部分：

  1. 数据中台当前的元数据架构与只读检索链路。
  2. 在隔离实验副本中进行的标准字典迁移实验与评测结果。

原始项目保持不动，所有实验都在复制出来的新目录里完成。

一、数据中台架构

1.1 总体链路

这套架构的核心不是“直接写 SQL”，而是把问题拆成可解释的元数据检索步骤：

  • 先把用户的自然语言问题转成业务概念。
  • 再从业务目录、Hive Metastore 和 DataRiver 图谱里找证据。
  • 最后输出候选表、字段语义、别名、血缘和解释。

1.2 关键组件

组件 作用
mcp/ 元数据检索服务与实验代码
catalog.json 本地业务资源目录，来源于资源清单
Hive Metastore 真实表、字段、存储位置、表参数
DataRiver Metadata 逻辑表、字段节点、process 节点、血缘关系
doops / 运维链路 只读连通性检查与环境接入
Skill 把问题拆解成可操作的元数据检索任务

1.3 只读边界

这套系统只做元数据分析，不做业务写入：

  • 允许：SELECT、SHOW、DESCRIBE、EXPLAIN
  • 不允许：INSERT、UPDATE、DELETE、DROP、ALTER、CREATE
  • 不允许直接改表、改结构或执行危险运维操作

也就是说，它更像一个“数据资产解析器”，而不是通用 SQL 执行器。

1.4 主要能力

能力 说明
search_business_catalog 按业务语言检索本地目录
business_search 在表名、字段名、注释、别名里做业务检索
describe_table_detail 返回表、字段、存储位置、结构语义
resolve_data_resource 判断资源是实体表、别名、逻辑过程还是字段级资源
search_datariver_vertices 搜索 DataRiver 节点
get_lineage 解释表之间的血缘和上下游关系

1.5 架构要点

  • 数据入口是业务目录，不是直接从自然语言猜表名。
  • Hive Metastore 负责物理表事实，DataRiver 负责逻辑关系和 process 血缘。
  • 归一化、别名映射、资源解释是检索效果的关键。
  • 结果必须可解释，最好能给出“为什么命中”。

二、标准字典实验

2.1 实验目标

这次实验想回答三个问题：

  1. 标准字典能不能把自然语言问题对齐到统一概念。
  2. 有了标准字典后，检索和数据处理会不会更稳。
  3. 关系扩展后的结果，能不能方便人工复核。

2.2 实验方法

在隔离实验副本中，按照 SCHEMA-MINERpro 的思路做了四步：

2.3 字典长什么样

标准字典不是单个词表，而是“概念 + 别名 + 表 + 字段 + 关系”的组合。

结构大致如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
  "id": "业务.概念",
  "label": "中文标准名",
  "domain": "业务域",
  "aliases": ["别名1", "别名2"],
  "preferredTables": ["主表1", "主表2"],
  "fieldKeywords": ["字段词1", "字段词2"],
  "relations": [
    {
      "type": "related_to",
      "target": "另一个概念"
    }
  ]
}

2.4 全量字典覆盖规模

指标 数值
目录资源数 595
概念数 488
生成概念数 475
预置人工概念数 13
别名引用数 4583
唯一别名数 2692
优先表引用数 624
唯一优先表数 577
字段关键词数 4550
唯一字段关键词数 1661

这说明全量字典已经不是“几个关键词”的小词表，而是一套可用于业务检索和关系扩展的候选标准体系。

2.5 评测指标是什么意思

指标 含义 怎么看
Precision@K 前 K 条里有多少是对的 越高越准
Recall@K 应该命中的结果，有多少被找出来 越高越全
MRR 第一个正确结果出现得早不早 越高越好
conceptRecall 直接概念有没有对齐到字典里 看字典识别能力
relationAccuracy 相关概念是否被关系扩展带出 更像关系覆盖率，不等于人工语义真值

2.6 100 条评测结果

模式 P@1 P@3 P@5 P@10 R@1 R@3 R@5 R@10 MRR 额外指标
无字典 0.800 0.397 0.264 0.143 0.652 0.804 0.849 0.878 0.848 -
标准字典 0.790 0.333 0.210 0.127 0.652 0.733 0.746 0.789 0.822 conceptRecall 0.880 / relationAccuracy 0.120
关系增强字典 0.790 0.333 0.210 0.127 0.652 0.733 0.746 0.789 0.822 conceptRecall 0.880 / relationAccuracy 0.860

2.7 结果怎么理解

这组结果说明了三件事：

  1. 标准字典的主要价值不是立刻把检索排序做高，而是把问题先对齐到统一概念上。
  2. 关系增强后，相关概念更容易被带出来，relationAccuracy 明显更高。
  3. 但自动指标不能直接代表“语义正确”，尤其是关系扩展部分，仍然需要人工抽查。

换句话说，标准字典更像“统一语言”，关系增强更像“补上下文”，两者都需要人来验。

三、人工抽样复核

为了避免只看自动指标，这次还做了抽样复核页：

打开摘要实验报告 打开抽样复核页 下载抽样样本 JSON

抽样规则是分层抽样，一共 25 条，按 5 类任务各抽 5 条：

  • business
  • table
  • relation
  • field
  • alias

复核时建议重点看三件事：

  1. 候选表是不是对的。
  2. 标准概念有没有对齐。
  3. 关系扩展有没有拉偏。

复核页里已经提供了“通过 / 部分通过 / 不通过”和问题标签，最后还能导出复核 JSON。

四、复现方式

1
2
3
4
5
cd <实验副本>/mcp
npm run build:full-standard-dictionary
npm run generate:full-dictionary-tasks
npm run eval:full-dictionary
npm run review:full-dictionary

五、结论

  • 数据中台架构这边，关键是“业务目录 + Hive + DataRiver + 只读解释链路”。
  • 标准字典实验这边，关键是把业务概念、别名、表、字段和关系连起来。
  • 在这组实验里，标准字典提升了概念对齐，关系增强提升了关系覆盖，但最终仍应结合人工复核判断。

六、相关输出文件