语义层要把数据目录中的技术元数据加工成可执行的业务契约，给数据表换中文名称远远不够。它要明确“什么对象可以分析、每个字段表示什么、在哪个粒度上计算、表之间怎样连接、谁有权使用、结果如何验证”。对 AI 自动化需求开发而言，这份契约决定了模型能看见哪些候选数据、能生成哪些 SQL，以及哪些答案必须拒绝或转人工审核。

元数据提供证据，语义层提供业务到数据的映射

元数据回答“数据资产是什么、在哪里、由谁负责、怎样流转”。语义层进一步回答“业务问题应该怎样被翻译成数据问题”。两者之间不是复制关系，更像是目录和正文。

例如，元数据可以采集到 dwd_trade_order.pay_amt 是 DECIMAL(18,2)，上游来自支付明细，负责人是交易域数据团队。仅凭这些信息，AI 仍然无法判断它是下单金额、实付金额还是退款后净额，也不知道能否按门店汇总。语义层必须补上业务定义、统计粒度、聚合方式、时间角色、可用维度、过滤规则和权限边界，才能把这个字段变成可查询的“实付金额”。

Mermaid 图 1

图里有一道不能省略的环节：数据目录中的元数据只是候选，不能自动成为已发布语义。这是因为数据库主键不一定等于业务主键，字段注释也可能过期，血缘只证明依赖关系，不证明业务口径。目录侧的自动化负责减少录入成本，语义发布仍要经过业务负责人或数据负责人审核。

元数据到语义属性的转换关系

目录中的已有元数据 可自动生成的语义候选 必须补充或确认的内容
数据源、库、schema、表、字段 物理绑定、数据类型、字段表达式初稿 允许绑定的生产环境、字段是否可对外暴露
主键、唯一键、外键 实体标识、关系候选、基数候选 真实业务粒度、缓慢变化维与历史拉链处理、连接方向
表注释、字段注释、业务术语 展示名、描述、同义词候选 准确定义、反例、歧义词、主题域适用范围
字段值、枚举值、空值率 样例值、枚举标记、质量门槛候选 敏感值脱敏、样例的时效与代表性
SQL解析与字段级血缘 依赖关系、影响范围 跨域依赖是否允许
数据质量规则与运行结果 可用性状态、质量分、阻断条件 哪类失败必须停止 AI 查询，谁有权豁免
负责人、主题域、分级分类 owner、domain、访问策略候选 审批人、行列权限、用途限制
查询日志与报表使用记录 常用维度组合、问句的候选答案 查询是否代表正确实践，是否可升级为标准案例

语义加工要具有可验证性，需要补齐业务判断，并把来源记录清楚。每个语义属性都应保留 source_type、source_ref 和 confidence。这样，自动生成的候选与人工确认的定义不会混在一起，后续变更也能追溯到语义的源头或评审记录。

语义属性清单：从“能展示”到“能执行”

语义属性不要求一次性全部补齐。生产实践可以分为必填、条件选填和增强三档。有一点需要注意，语义层不要做成表面工程，不能只保留字段名称、中文注释和 SQL 表达式这些基本信息，对于AI来说，缺失粒度、关联关系或时间语义、条件限制这些重要信息，输出的结果大概率不可信。下面来看看这些属性，当然这不是规范仅供参考，

1. 模型级属性

属性 必填性 作用与校验要求
name / display_name 必填 模型名称与中文展示名分离；机器名应稳定且无歧义
business_description 必填 说明业务过程、能回答的问题和明确不能回答的问题
domain 必填 所属主题域，如交易域、商品域；用于搜索、权限和责任路由
owner / steward 必填 区分技术负责人和业务口径负责人
version 必填 语义契约版本；发布后变更应可比较、回滚
status 必填 draft、reviewing、published、deprecated 等生命周期状态
effective_from / effective_to 条件必填 业务规则存在生效区间时必须填写，避免 AI 使用过期口径
default_time_dimension 条件必填 支持趋势分析的模型要给出默认时间周期及默认时区
consumer_scope 必填 标明服务于分析师、自动需求开发、BI 或 AI agent 的哪些场景
tags 增强 主题分类、成熟度、敏感等级等可检索标签
entity_type 必填 实体类型：区分事件、主体、快照 等实体，便于判断查询方式
grain 必填 粒度：用自然语言和键同时声明“一行代表什么”，例如“一行一个订单明细”
primary_entity_key 必填 业务主键，可由一个或多个字段组成；必须有唯一性校验
physical_asset 必填 绑定数据库中的表、视图或受控 SQL，而不是自由文本表名
partition_columns 条件必填 大表必须声明可用于裁剪的分区字段及合法过滤范围
update_time_cycle 必填 表更新频率：日、周、月。并标注允许的延迟的时间
update_type 必填 表更新类型：全量、增量
### 2. 维度属性
属性 必填性 作用与校验要求
name、display_name 必填 字段名和展示名
description 必填 描述信息：定义含义、取值边界和典型反例，避免同名字段误用
data_type 必填 数据类型，如 string、number、boolean、date、timestamp
expr 必填 字段表达式，变更时触发血缘与影响分析
synonyms AI 场景必填 业务别名、缩写，如“成交额”、“GMV”等同义词；
sample_values 增强 帮助AI理解枚举值，但必须脱敏、限量并记录采样时间
filter_operators AI 场景必填 字段过滤：限制可用的等于、范围、模糊匹配等操作
null_semantics 条件必填 解释空值代表未知、不适用还是尚未发生
sensitivity / masking_policy 必填 脱敏或拒绝策略
### 3. 事实和度量

事实是业务过程中的一个事件，度量是对事件的量化。企业内部必须固定一套词汇，不能让同一个 度量 在不同团队中分别表示不同的字段。

属性 必填性 作用与校验要求
name、display_name 必填 度量名称：可被指标定义稳定引用的度量名称
description 必填 度量说明：明确金额口径说明、取值范围、是否含税等
expr 必填 字段或受控 SQL 表达式；不得让 AI 临时发明计算公式
additivity 必填 声明可加、半可加或不可加性
unit / currency 条件必填 金额、数量、比例等单位；多币种要声明换算策略引用
metric_ref 增强 指向指标中心的稳定标识与版本，不在此处复制最终指标口径
### 4. 关系与join属性
属性 必填性 作用与校验要求
from_entity / to_entity 必填 连接两端的逻辑实体
join_type 必填 允许的连接类型及其保留哪一侧记录
join_condition 必填 关联条件
cardinality 必填 one-to-one、many-to-one、one-to-many；many-to-many 应通过桥接模型显式处理
join_des 必填 join描述信息

关系必须有方向。以订单和客户为例，从订单连接客户通常保留订单，从客户连接订单则可能要保留从未下单的客户。两条查询的业务含义不同，不能只因为连接条件相同就合并成一条无方向边。

5. 运行属性

属性 必填性 作用与校验要求
update_last_time 必填 表最后更新时间
latest_partition 必填 表最新分区：如果是分区表，记录表的最新分区
quality_latest_exception 必填 当天任务的异常信息
quality_gate 必填 规定哪些失败会阻断查询

属性多并不意味着让维护者填写一张巨表。更可行的做法是让技术属性从元数据同步，让业务属性在web界面补齐，让运行属性由平台回写，再通过统一 schema 做条件校验。

小结

基于元数据建设语义层，需要把“资产事实”转换为“执行契约”。数据目录提供表和字段信息、主题域、粒度、负责人和分区、更新类型等信息；语义建模补充模型的业务信息、维度、度量、关联关系、条件过滤、自然语言别名和验证证据等；发布流水线再把这些定义编译、测试、授权和版本化。

做到这一步，AI拿到的是一组可发现、可解释、可校验、可拒绝的逻辑对象，而非一堆可能相关的表。