空间：数据在哪里？

这不仅包括表在哪里，也包括对象、文件、目录、模型产物、非结构化资产在哪里。

数据视图需要将逻辑资产和物理资产连接起来：既能看到被建模的数据产品，也能看到尚未建模但已经存在的数据对象。

时间：数据什么时候变化？

AI 数据湖既需要知道“当前有什么”，也需要知道“刚刚发生了什么”。

表格式（如 Apache Iceberg ）能够提供表级快照、版本历史和 Time Travel 能力，解决的是“某张表在某个版本是什么状态”的问题。

对象和文件层面的变化日志解决的是另一类问题：哪些文件被创建、更新或删除；哪些对象标签、用户元数据信息发生变化。

两者粒度不同，但都属于时间视图的一部分。

语义：数据意味着什么？

语义视图回答的是：这份数据在业务上是什么意思，适合什么任务，不适合什么任务。

其核心不是“给字段写几句说明”，而是把业务口径变成可治理、可复用、可被机器消费的对象。这可以从三个层面来理解：

第一层：自然语言说明

主要帮助人和LLM理解上下文。表、视图、列的业务描述，枚举值和状态码解释，事件时间、处理时间、入湖时间等时间语义，都适合用文档化描述表达。

第二层：结构化约束

主要帮助系统和规则引擎进行过滤、授权和风险判断。敏感等级、数据域、质量等级、使用约束、do_not_use_for 等信息，最好进入 TAG、属性或类似的结构化字段。

第三层：业务语义对象

View、Metric View 这类对象将指标、维度、过滤条件、JOIN 关系和业务口径封装成统一契约，让下游报表、自然语言查询和 Agent 复用同一套定义。

Databricks 的演进路径正是第三层的典型体现。Unity Catalog 本身已提供统一命名空间、权限、表和列注释、标签、信息模式和血缘等治理能力。在此基础上，Databricks 进一步将业务语义推向 Catalog 层，其代表性能力是 Unity Catalog Metric Views。Databricks 官方文档称其为 Unity Catalog Business Semantics 的核心实现。

以收入指标为例，很多企业都有多个收入口径——是否扣除退款、是否含税、是否只看已完成订单、按下单时间还是支付时间统计。如果这些规则散落在不同报表、SQL 和 Notebook 中，同一个问题很容易得出不同答案。

Metric View 将这些规则收回到 Unity Catalog 中进行统一定义。它就像一张带有业务规则的视图：底层仍然读取表、视图或 SQL 查询，但会明确写出收入如何计算、哪些记录需要过滤、可以按哪些维度分析，以及事实表和维表如何关联。

使用时，用户无需重新编写收入公式，只需调用已定义好的指标，再选择按时间、区域、渠道等维度查看。如此一来，BI 报表、自然语言查询和 Agent 面对的就不再是一堆字段名，而是一套可复用的业务口径。

这背后的路径判断是：语义层正在从“下游工具中的约定”回归到“统一治理平面中的一等对象”。

血缘：数据从哪里来，影响哪里？

血缘视图回答的是：这份数据来自哪里，被哪些任务处理过，影响哪些下游表、模型、报表或应用。血缘负责影响分析、审计、回放和质量追踪。