3. 数据资产发现与浏览
当你被临时拉进一个陌生的数据域——比如“供应链履约”或“用户增长”——最先遇到的问题往往不是“数据质量好不好”，而是“这里到底有哪些表、哪些字段、谁在用、能不能信”。Unity Catalog（UC）把元数据集中到统一的 Metastore 中，因此资产发现不必再靠口头询问或翻旧文档，而是可以沿着“搜索 → 标签 → 注释 → 血缘”这条路径，从模糊的业务名词逐步收敛到可用的数据对象。本节以一次真实的盘点任务为例，说明如何用 UC 的这几项能力完成陌生数据域的资产摸底。
盘点任务的起点：把业务名词翻译成可检索的元数据
假设任务描述是：“盘点 supply_chain 业务域下的核心数据资产，输出一份可交付的资产清单。”第一步不是打开表，而是确定检索范围。UC 的命名空间是三层结构：catalog.schema.table，因此先确认该域落在哪个 catalog 与 schema 下。例如通过 SQL 查看候选 schema：
SHOW SCHEMAS IN supply_chain_prod;
-- 返回：core, ods, mart, sandbox, tmp 等
SHOW TABLES IN supply_chain_prod.core;
-- 返回：dim_supplier, dim_warehouse, fact_order_fulfillment,
-- fact_inventory_snapshot, dim_carrier, fact_return_request ...这一步的价值在于把“供应链”这个业务词，落到具体的 schema 与表名上。注意 sandbox、tmp 这类 schema 通常不属于正式资产，盘点时应先排除，避免把临时表计入清单。
用搜索与标签快速缩小范围
UC 的搜索支持按对象名、注释内容、标签键值进行匹配。当表数量达到数百张时，逐个 SHOW TABLES 效率很低，更实用的做法是用标签（tag）做第一轮筛选。标签是键值对，例如 domain=supply_chain、layer=gold、sensitivity=internal。可以按标签检索：
SELECT table_catalog, table_schema, table_name, comment
FROM system.information_schema.tables
WHERE table_schema = 'core'
AND table_name LIKE 'fact_%'
ORDER BY table_name;如果该域已经做过治理，标签会直接告诉你哪些是核心事实表、哪些是维度表、哪些含敏感字段。若标签缺失，则说明盘点本身也要顺带补齐标签，这属于盘点任务的附加产出。搜索阶段的目标不是穷举，而是建立一张“候选资产地图”：把表按业务过程分组，例如订单履约、库存快照、承运商、退货，每组挑出 1～2 张主表作为后续深入对象。
注释：判断一张表“能不能用”的第一手线索
表注释和列注释是成本最低、收益最高的元数据。一张有清晰注释的表，通常意味着它被认真维护过。阅读注释时要关注三类信息：业务含义（这张表描述什么过程）、粒度（一行代表什么）、更新频率与数据范围。例如：
COMMENT ON TABLE supply_chain_prod.core.fact_order_fulfillment IS
'订单履约事实表，一行=一个订单行的一次履约事件，T+1 更新，覆盖近 36 个月';
COMMENT ON COLUMN supply_chain_prod.core.fact_order_fulfillment.fulfill_status IS
'履约状态：CREATED/PICKED/SHIPPED/DELIVERED/CANCELLED';如果注释为空，不要立刻放弃这张表，而是把它标记为“待补充注释”，并在盘点结论中说明。对陌生数据域而言，注释缺失本身就是一项需要上报的治理缺口。
血缘：判断资产重要性与影响面的关键依据
血缘回答两个问题：这张表的数据从哪来（上游）、被谁使用（下游）。在盘点场景中，血缘最重要的用途是识别“关键资产”——下游引用越多，说明它越核心，越应该优先纳入清单并优先治理。UC 的血缘可以在 Catalog Explorer 的 Lineage 标签页查看，也可以通过系统表查询：
SELECT source_table_full_name, target_table_full_name
FROM system.access.table_lineage
WHERE source_table_full_name LIKE 'supply_chain_prod.core.%'
OR target_table_full_name LIKE 'supply_chain_prod.core.%';把血缘结果与前面的候选表合并，就能得到一张带方向的资产关系图：上游 ODS 表 → 核心事实/维度表 → 下游报表或特征表。下游节点越多、层级越深的表，优先级越高。
把发现结果落成可交付的资产清单
盘点不能只停留在“看过了”，必须产出一份可复查的清单。建议至少包含以下字段：对象全名、对象类型、业务分组、标签、注释状态、下游引用数、优先级、备注。下面是一份示例（数据为教学假设，非真实环境实测）：
| 对象全名 | 业务分组 | 标签 | 注释状态 | 下游引用数 | 优先级 |
|---|---|---|---|---|---|
| core.fact_order_fulfillment | 订单履约 | domain=supply_chain, layer=gold | 完整 | 5 | P0 |
| core.fact_inventory_snapshot | 库存 | domain=supply_chain, layer=gold | 完整 | 3 | P0 |
| core.dim_supplier | 供应商 | domain=supply_chain | 完整 | 4 | P1 |
| core.dim_carrier | 承运商 | 无 | 缺失 | 2 | P1（待补注释） |
| sandbox.tmp_fulfill_test | — | 无 | 缺失 | 0 | 待确认（疑似废弃） |
system.information_schema 与 system.access.table_lineage 两张系统表，它们能一次性拉取表清单与血缘关系，避免在 Catalog Explorer 中逐表点击。若权限受限看不到系统表，再退回 UI 浏览。盘点收尾：从“看过”到“可交接”
一次合格的资产盘点，最终要能回答四个问题：这个域有哪些核心表、每张表描述什么、数据从哪来到哪去、哪些资产存在治理缺口。搜索解决“有哪些”，标签解决“怎么分类”，注释解决“是什么”，血缘解决“重不重要”。四步走完后，把清单、缺口列表和优先级建议一起交付，陌生数据域就从“黑盒”变成了可被后续质量规则与治理动作接手的对象。需要强调的是，盘点不是一次性动作，标签和注释会随业务演进而过期，建议把这份清单纳入定期复查机制，例如每季度核对一次下游引用数与注释状态。