4. 元数据采集与自动发现

在数据平台里，元数据治理的第一步不是“治理”，而是“看见”。如果连有哪些表、字段、视图、函数、卷和外部位置都不清楚，后续的血缘、权限、质量规则和生命周期管理都无从谈起。Unity Catalog 的价值在于，它把元数据采集从“人工登记”变成了“平台自动发现 + 可查询 + 可同步”的闭环。本节围绕三个核心问题展开：Unity Catalog 如何自动发现数据资产、如何通过 Information Schema 查询元数据、以及元数据在对象变更后如何同步。

一、自动发现：从存储到目录的三层映射

Unity Catalog 的元数据模型是三层命名空间：catalog.schema.object。自动发现的关键在于，它并不要求用户先手工创建每一张表的元数据，而是通过“存储位置 + 外部位置 + 目录托管”三种方式，把物理数据映射为可治理的资产。

第一种是托管表（Managed Table）。当用户执行 CREATE TABLE 或写入 DataFrame 时，Unity Catalog 会在指定 schema 下自动登记表名、字段、类型、分区、存储路径和创建者。元数据由平台维护，删除表时数据与元数据一并清理。第二种是外部表（External Table），通过 CREATE EXTERNAL TABLE ... LOCATION 指向云存储路径，Unity Catalog 只登记元数据，不接管数据生命周期。第三种是外部位置（External Location）与存储凭证（Storage Credential），它们让平台能够安全地“看到”云存储上的文件，再通过 CREATE TABLE 或自动加载器把文件注册为表。

自动发现还体现在对已有数据的“扫描式登记”。例如，使用 CREATE TABLE ... AS SELECT 从 Parquet 目录读取时，Unity Catalog 会解析文件 schema，推断字段类型并写入元数据。对于 Delta 表，它还会读取事务日志中的 schema、分区和表属性。这个过程不需要用户逐字段声明，但推断结果需要人工确认，尤其是当源文件存在类型歧义（如 int 与 bigint、时间戳时区）时。

二、Information Schema：用 SQL 查询元数据

自动发现之后，元数据必须可查询。Unity Catalog 在每个 catalog 下提供 information_schema，它是一组只读系统视图，把元数据以标准 SQL 表的形式暴露出来。常用的视图包括：

• information_schema.tables：表、视图、物化视图的名称、类型、创建时间、所有者。
• information_schema.columns：字段名、数据类型、是否可空、默认值、注释。
• information_schema.views：视图定义、依赖关系。
• information_schema.volumes：卷的路径、类型、所有者。
• information_schema.table_privileges：表级授权记录。

下面是一段可直接在 Databricks SQL 中执行的查询，用于列出某个 schema 下所有表的字段清单：

SELECT
  t.table_catalog,
  t.table_schema,
  t.table_name,
  t.table_type,
  c.column_name,
  c.data_type,
  c.is_nullable,
  c.comment
FROM information_schema.tables AS t
JOIN information_schema.columns AS c
  ON t.table_catalog = c.table_catalog
 AND t.table_schema  = c.table_schema
 AND t.table_name    = c.table_name
WHERE t.table_schema = 'sales_gold'
ORDER BY t.table_name, c.ordinal_position;

这条查询的价值在于，它把“有哪些表、每张表有哪些字段、字段是否可空、有没有注释”一次性拉平。对于数据质量治理，注释字段尤其重要：如果 comment 为空，说明该字段缺少业务含义说明，应列入待补充清单。类似地，可以用 information_schema.tables 中 table_type 区分 MANAGED、EXTERNAL、VIEW，从而判断哪些资产需要重点做生命周期管理。

三、元数据同步机制：变更如何被感知

元数据不是一次性快照，而是随对象变更持续演进的。Unity Catalog 的同步机制可以理解为三条路径并行：

第一条是 DDL 触发同步。当用户执行 CREATE、ALTER、DROP、RENAME 等语句时，Unity Catalog 在事务提交阶段同步更新 Metastore 中的元数据记录。这意味着，只要 DDL 成功，元数据立即可见，不需要额外刷新。例如执行 ALTER TABLE sales_gold.orders ADD COLUMN channel STRING 后，information_schema.columns 中会立即出现 channel 字段。

第二条是日志读取同步。对于 Delta 表，Unity Catalog 会读取 _delta_log 中的事务日志，获取 schema 演进、分区变更、表属性变化。当外部写入工具（如 Spark 作业、Flink 任务）直接向 Delta 路径写入并触发 schema 变更时，Unity Catalog 通过日志感知这些变化，并在下一次元数据刷新时更新记录。这条路径的延迟取决于刷新策略，通常不是毫秒级，而是秒级到分钟级。

第三条是定时刷新与手动同步。对于外部表或通过自动加载器注册的资产，平台会按配置的周期扫描存储位置，发现新增文件、分区或 schema 变化。用户也可以执行 REFRESH TABLE 或 MSCK REPAIR TABLE 手动触发分区元数据同步。在排查“表里明明有新分区但查询不到”这类问题时，通常先检查是否缺少手动刷新。

四、一个可复用的元数据盘点示例

假设我们需要对 sales_gold schema 做一次元数据健康度盘点，可以组合以下查询，输出“表名、字段数、无注释字段数、表类型、最后变更时间”：

SELECT
  t.table_name,
  t.table_type,
  t.last_altered,
  COUNT(c.column_name) AS column_count,
  SUM(CASE WHEN c.comment IS NULL THEN 1 ELSE 0 END) AS missing_comment_count
FROM information_schema.tables AS t
LEFT JOIN information_schema.columns AS c
  ON t.table_catalog = c.table_catalog
 AND t.table_schema  = c.table_schema
 AND t.table_name    = c.table_name
WHERE t.table_schema = 'sales_gold'
GROUP BY t.table_name, t.table_type, t.last_altered
ORDER BY missing_comment_count DESC;

结果中 missing_comment_count 越高，说明该表的字段说明越不完整，应优先补充。若某张表 last_altered 很近但 column_count 突然增加，说明发生了 schema 演进，需要确认新增字段是否符合预期、是否影响下游质量规则。若 table_type 为 EXTERNAL，则要额外确认外部位置权限和存储凭证是否仍然有效。

需要强调的是，以上查询和参数均为教学示例，实际执行时应替换为真实 catalog、schema 和表名。元数据采集与自动发现不是一次性的“建目录”动作，而是持续运行的治理基础设施：自动发现解决“看得见”，Information Schema 解决“查得到”，同步机制解决“跟得上”。三者配合，才能让后续的数据质量规则、血缘分析和权限审计建立在可信的元数据之上。