再看召回前置准备。根据业务数据库生成各数据库

这是一篇系列文，请按照顺序阅读。老实说，

终态回顾的观点是，元数据库在整个流程中的位置

dw.sql │ │ 人工分析 ← 这篇文章第一步先
▼conf/meta_config.yaml │ │ 脚本自动 ← 这篇文章接下来
▼MySQL meta 库 │ │ 后续文章
▼Qdrant 向量库 + ES 全文索引

元数据库是“数据的数据”——它不存业务数据。存的是描述业务数据长什么样的说明书。

痛点：如果没有这份说明书。后端程序无法自动生成查询接口，也无法让前端友好地展示指标。

第一步先这方面，从 dw.sql 到 meta_config.yaml

读 dw.sql。提取表结构

打开 /docker/mysql/dw.sql里面定义了若干张表：

表名	角色猜测	说明
dim_region	dim	存地区信息
dim_customer	dim	存客户信息
dim_product	dim	存商品信息
dim_datedim存时间信息

Caution: 记得先检查是否有注释或自定义类型，这些都会影响后续解析。

E.g. 以 fact_order 为例，看它的 DDL：

CREATE TABLE fact_order (
order_id VARCHAR PRIMARY KEY。customer_id VARCHAR,product_id VARCHAR,date_id INT,region_id VARCHAR,order_quantity INT,order_amount FLOAT
);

逐字段分析的观点是，从 DDL 到元数据描述

• Name: 直接从 DDL 抄过来这是代码里调用的名字。怎么说呢，
• DDL 里没有注释。需要人工补充，这是向量检索的关键——使用者说中文，向量靠描述来匹配。比如使用者说“销售额”，向量匹配到 "订单金额".
• ID/Role:
  • Primary key : 唯一标识行。用于关联与主键合并节点补全。不过，
  • Foreign key : 与对应维度表关联；外键会被自动识别为“foreign_key”。如果字段名中含有 "_id" 而且不是主键，就默认是外键。
  • Measure : 数值字段，可聚合。对指标计算尤为关键，
• Aggable: 是否需要支持聚合计算；通常 measure 字段为 true。
• Ablise :  使用者可能用不同说法指代同一个字段；怎么说呢，如 order_amount 的别名可以是。说起来，这些别名也会参与向量化，以扩充匹配面。
•  是否同步到 ES 全文检索； 仅维度字段需要同步，例如省份名称；主键/外键/度量值没有搜索价值，一般设为 false。

User Pain Point： 手动翻译每个字段属性既耗时又易错，特别是在大模型环境下缺少统一标准时更容易出现不一致的问题。

转化成 YAML 配置文件

提示： 以下示例展示了如何把上面的分析写进 /conf/meta_config.yaml.

tables这方面。- name: fact_order
role这方面，fact
description: 订单事实表，记录订单数量和金额等主要指标。columns:
- name: order_id
说到role，primary_key
description: 订单唯一标识。alias这方面，sync: false
- name: customer_id
role这方面。foreign_key
description: 关联客户维度的外键。说到alias，sync: false
- name: product_id
从role来看。foreign_key
description: 关联商品维度的外键。再看alias，sync:false
- name : date_id
role :foreign_key
description :关联时间维度外键
从alias来看，sync :false
- name : region id
role :foreign_key
description :关联地区维度外键
再看alias，sync:false
- name : order quantity
role :measure
description :订单中商品购买数量
alias这方面。sync:false
- name : order amount
role :measure
description :订单金额
至于alias，sync:false
# 指标定义区块，与事实/维度保持同级结构方便统一管理
- name : metric_info
role : metric
description ：指标定义表，存储跨字段计算指标，如 GMV 、AOV 等。怎么说呢，columns :
- name GMV
description ：全称Gross Merchandise Value。表示所有订单成交金额总和。从alias来看，relevant_columns :
- fact_order.order_amount
- name AOV
description ：全称Average Order Value。表示所有订单成交金额平均值。说到alias，relevant_columns :
- fact_order.order_quantity

TIPS： 把指标放在 下面而不是另起一个顶层 key。是为了结构统一——每一项都对应 MySQL meta 库的一张实体，可以 SQL 或映射关系。

& 接下来行动计划

• 完成 DW → Meta Config 的映射后即可跑脚本将 YAML 注入 MySQL meta 数据库；此过程已封装在 repo 中。只需执行 make load_meta_from_yaml .
• 接下来会介绍如何基于已填充好的 Meta Database 自动创建 Qdrant 向量索引与 ElasticSearch 文本索引，为召回提供底层支持。
• 如果你遇到任何映射错误或缺失描述。请先检查 YAML 是否符合规范，再看日志输出中列出的缺失字段列表，以免后期产生无效查询或搜索误差。怎么说呢，

---

这篇文章摘自官方项目仓库。并做了适当排版与补充，如需认真学习，请访问 GitHub 上完整源码及相关 README 文档。

---