日期：2026-08-28 业务场景：梳理各业务系统原始表 DDL 与表关系 → 基于指标口径分析出支撑指标查询的宽表 → 用 AI 帮助需求方查询指标、分析业务问题
核心链路（三个动作）：
① 元数据梳理：采集各业务系统原始表的 DDL 定义 + 表之间的关系
↓
② 宽表建模：基于指标口径 + 看数分析逻辑，分析出支持指标查询的数据宽表
↓
③ AI 语义查询：基于宽表 + 原始数据，用 AI 帮需求方查指标、分析业务问题
本质：把「写 SQL 查指标」变成「用自然语言查指标」。让业务人员不用懂表结构、不用写 SQL，直接问「上个月华东区 GMV 环比下降多少？为什么？」，系统给出指标数据 + 分析。
这与「本体驱动 AI」一脉相承：指标、维度、口径、宽表就是这套系统的「业务本体」——它们是需求方和 AI 之间的语义层，用来消除「模型看不懂表字段」的语义鸿沟。
| 挑战 | 说明 |
|---|---|
| 元数据缺失/不准 | 原始表没有注释、字段名无意义、表关系靠人肉记 |
| 口径不统一 | 同一个「GMV」不同部门算法不同（含不含退款、含不含税） |
| 宽表怎么建 | 哪张表做事实表、哪些是维度表、指标怎么落到宽表 |
| AI 幻觉/乱查 | LLM 直接生成 SQL 会错用字段、乱 join、误解口径 |
| 口径溯源 | 查出来的数，要能说清楚「这个数从哪来、怎么算的」 |
结论：AI 查询指标不能靠「裸 Text-to-SQL」，必须建立在元数据 + 指标口径 + 宽表三层治理之上，用指标语义约束 AI。
┌────────────────────────────────────────────────────────┐
│ 应用层：AI 语义查询 │
│ 需求方自然语言 → 指标识别 → 维度解析 → SQL 生成 → 查询 → │
│ 结果 + 业务分析 │
├────────────────────────────────────────────────────────┤
│ 指标语义层（核心，相当于「业务本体」） │
│ · 指标库：指标名、口径、计算逻辑、维度、度量、时间粒度 │
│ · 宽表模型：事实表 + 维度表（星型模型） │
│ · 血缘：指标 ← 宽表 ← 原始表 │
├────────────────────────────────────────────────────────┤
│ 元数据层：DDL + 表关系 │
│ · 表/字段/类型/注释/主键 │
│ · 表关系（关联字段、数据血缘） │
├────────────────────────────────────────────────────────┤
│ 数据层：MaxCompute 分层数仓 │
│ ODS（原始）→ DWD（明细）→ DWS（宽表汇总）→ ADS（指标结果） │
└────────────────────────────────────────────────────────┘
关键设计：AI 不直接面对 ODS 原始表和 SQL，而是面对「指标语义层」——它只允许查已定义的指标（受口径约束），维度、时间、筛选都有明确语义。这就像 Palantir Ontology 里 ActionType 的约束：只允许执行受控的「指标查询」动作。
采集内容： - 表：表名、中文名、所属业务系统、分层（ODS/DWD/DWS/ADS） - 字段：字段名、类型、中文注释、是否主键、是否分区字段 - 关系：外键/关联字段、join 关系、数据血缘（上游表 → 下游表）
采集方式：
- MaxCompute 通过 information_schema / SHOW TABLES / DESC <table> 拉 DDL
- 血缘用 DataWorks 数据地图（阿里云已有能力）或自建解析
存储：元数据中心（元数据表：meta_table、meta_column、meta_relation）
指标三要素：
| 指标类型 | 说明 | 示例 |
|---|---|---|
| 原子指标 | 不可再拆的度量 | 订单金额、订单数 |
| 派生指标 | 原子指标 + 维度/时间/修饰 | 近7天华东区订单金额 |
| 复合指标 | 多个指标的运算 | 客单价 = 订单金额 / 订单数 |
指标定义（每个指标一条记录）：
指标名：GMV（成交总额）
口径：支付成功且未退款的订单金额之和（明确含不含退款/税/运费）
度量：SUM(order_amount)
维度：时间、地区、渠道、品类
时间粒度：日/周/月
数据来源：dws_trade_order_wide（宽表）
计算逻辑：WHERE status='paid' AND refunded=0
宽表建模（关键产出）： - 基于指标口径，反推需要哪些字段 → 设计宽表 - 星型模型：事实表（度量字段 + 维度外键）+ 维度表（维度属性） - 一个宽表尽量支撑一批相关指标，减少跨表 join - 分层：ODS 原始 → DWD 明细清洗 → DWS 汇总宽表 → ADS 指标结果
流程：
需求方问：「上个月华东区 GMV 环比下降多少？为什么？」
↓
① 指标识别：LLM + 指标库 → 匹配到「GMV」（口径、计算逻辑、宽表）
↓
② 维度解析：时间(上个月)、地区(华东)、对比(环比)
↓
③ SQL 生成：基于指标定义 + 宽表字段 → 生成 SQL（受约束，不自由发挥）
↓
④ 查询执行：MaxCompute 执行 SQL
↓
⑤ 结果 + 分析：返回指标值 + 让 LLM 基于结果做业务分析（下钻、归因）
核心：把「指标语义」喂给 LLM - 不是让 LLM 裸写 SQL，而是让它从已定义的指标/维度/宽表里选 - LLM 的职责是「意图理解 + 参数填充」，SQL 生成走受约束的模板/规则 - 这样从根上避免「错用字段、乱 join、误解口径」
| 层 | 技术 | 说明 |
|---|---|---|
| 数据 | MaxCompute | 已有，分层数仓 |
| 元数据/血缘 | DataWorks 数据地图 + 自建元数据表 | 阿里云原生，血缘现成 |
| 指标库 | 自建（元数据表）+ 可选 DataWorks 指标 | 指标口径需要自己定义 |
| 宽表 | MaxCompute 分层表（DWS） | 数仓建模 |
| AI 语义查询 | LLM（DeepSeek/百炼）+ 受约束 SQL 生成 | 指标语义注入 + 模板化 SQL |
| 后端 | Java 11 + Spring Boot | 已有能力 |
| 查询执行 | MaxCompute SDK（你已有封装 MaxComputeQueryService） |
复用 |
端到端演示：一个业务指标的自然语言查询
需求方问：「上个月华东区的 GMV 是多少？环比涨了还是跌了？」
系统：
1. 元数据：找到 dws_trade_order_wide 宽表（已建好）
2. 指标：匹配「GMV」→ 口径 SUM(支付成功且未退款金额)
3. SQL：SELECT region, SUM(amount) ... WHERE dt BETWEEN ... GROUP BY region
4. 查询：MaxCompute 返回结果
5. 分析：LLM 基于结果回答「华东区 GMV = XX，环比 -12.3%，主因是...」
MVP 边界： - 只做 3-5 个核心指标、1-2 个维度（时间 + 地区）、1 张核心宽表 - 只支持「查询 + 简单对比（同比/环比）」，不做复杂下钻 - 先人工定义指标和宽表，元数据采集可半自动
| 维度 | 传统 | 本方案 |
|---|---|---|
| 查指标 | 提需求给数仓 → 等排期 → 写 SQL | 自然语言即时查 |
| 口径一致性 | 各部门口径打架 | 指标库统一口径 |
| 数据可信 | 不知道数从哪来 | 血缘可溯源 |
| AI 幻觉 | 裸 Text-to-SQL 乱查 | 指标语义约束 + 模板化 SQL |
这个场景是本体驱动思想在指标领域的自然落地：
| 本体概念 | 本场景对应 |
|---|---|
| ObjectType（对象类型） | 业务实体（订单/用户/商品）+ 指标（GMV/活跃用户） |
| LinkType（链接类型） | 表关系、指标血缘（指标←宽表←原始表） |
| ActionType（动作，受约束） | 「指标查询」这个受口径约束的操作 |
| 语义层 | 指标口径 + 宽表映射 = 需求方与 AI 之间的共同语言 |
一句话总结：不靠 LLM「裸查数据库」，而是先建好「指标语义层」（元数据 + 口径 + 宽表），让 AI 在这个语义层上受约束地查询和分析——这样才既准、又可解释、可溯源。