4、数据资产目录建设：目录结构设计、元数据采集与注册、目录维护与更新机制
数据资产目录，说白了就是你家数据资产的「户口本」。没有它，你连自己手里有多少数据、数据在哪、谁在用都不知道。我见过太多企业，数据资产散落在各个系统里，像一盘散沙。Owner 想找点东西，得挨个问人，效率极低。
这一章，我们就来聊聊怎么把这个「户口本」建好、管好。
4.1 目录结构设计：先搭好骨架
目录结构是数据资产目录的骨架。骨架歪了，后面再怎么填肉都别扭。我个人习惯，设计目录结构时，先想清楚两个问题：谁来用？和怎么找？
业务用户和技术用户的视角完全不同。业务用户关心「这是哪个部门的报表？」，技术用户关心「这个表在哪个数据库？」。所以，目录结构必须能同时满足这两种视角。
我建议采用分层 + 标签的组合模式。分层保证结构清晰，标签提供灵活检索。
4.1.1 分层设计：三层结构最实用
我在项目中遇到过，有的团队把目录分了七八层，结果用户点进去就迷路了。层数太多，反而增加认知负担。我个人推荐三层结构：
| 层级 | 名称 | 说明 | 示例 |
|---|---|---|---|
| L1 | 主题域 | 按业务领域划分，最高层级 | 客户、产品、交易、风控 |
| L2 | 业务对象 | 主题域下的核心业务实体 | 客户信息、客户画像、客户标签 |
| L3 | 数据资产 | 具体的数据表、文件、API等 | dwd_customer_info_di |
你看，三层结构，一目了然。业务用户从 L1 往下钻，技术用户可以直接搜 L3 的表名。各取所需。
4.1.2 标签体系：给资产打上「记号」
分层结构是「硬分类」，标签是「软分类」。硬分类解决归属问题，软分类解决检索问题。
举个例子，一张「客户交易明细表」，它属于「交易」主题域下的「交易流水」业务对象。但它同时可能涉及「风控」和「营销」两个场景。这时候，给它打上「风控场景」和「营销场景」的标签，就能被两个团队同时找到。
我建议的标签类型包括：
- 技术标签：数据源类型（MySQL、Hive）、存储格式（Parquet、ORC）、更新频率（T+1、实时）
- 业务标签：所属部门、应用场景、数据敏感等级
- 管理标签：Owner、Steward、数据质量等级
4.2 元数据采集与注册：把「户口」上上去
骨架搭好了，接下来就是把数据资产的「户口信息」填进去。这个过程，就是元数据采集与注册。
元数据，就是「关于数据的数据」。它包括技术元数据（表结构、字段类型）、业务元数据（字段含义、业务规则）、管理元数据（Owner、创建时间）。
4.2.1 采集方式：自动为主，手动为辅
全手动采集？别开玩笑了。几百张表，手动录入得累死。我建议采用自动化采集 + 人工补录的方式。
自动化采集工具（如 Apache Atlas、DataHub、开源的 Amundsen）可以：
- 自动扫描数据库、数据湖、数据仓库
- 抓取表结构、字段、分区信息
- 解析血缘关系（ETL 脚本、SQL 语句）
但自动化工具也有盲区。比如字段的业务含义，工具是猜不出来的。这时候就需要人工补录。
核心原则：机器能干的，绝不让手工干。机器干不了的，才让人工补。
4.2.2 注册流程：标准化是关键
采集到的元数据，需要经过标准化处理后，才能注册到目录中。我建议的注册流程如下：
- 元数据采集：自动化工具扫描数据源，生成原始元数据
- 元数据清洗：去重、格式统一、字段名标准化（如将 "cust_id" 统一为 "customer_id"）
- 元数据丰富：人工补录业务描述、标签、Owner 信息
- 元数据校验：Owner 审核，确认信息准确
- 注册发布：将元数据写入目录，对用户可见
嗯，这里要注意，注册不是一次性工作。新表上线、旧表下线、字段变更，都需要重新触发注册流程。
4.3 目录维护与更新机制：别让目录变成「死目录」
很多企业的数据资产目录，建完就没人管了。半年后，目录里的信息跟实际数据对不上，用户就不再信任它了。这就是典型的「死目录」。
我曾经接手过一个项目，目录里 30% 的表已经下线了，但目录里还挂着。用户查到了，去跑任务，跑不出来，回头就骂目录是垃圾。你说冤不冤？
所以，目录维护与更新机制，必须从一开始就设计好。
4.3.1 更新频率：按数据变化节奏来
不同数据资产的变化频率不同，更新机制也要区别对待。
| 数据资产类型 | 变化频率 | 推荐更新策略 |
|---|---|---|
| 核心业务表（如订单表） | 频繁（每天新增分区） | 每日自动扫描，增量更新 |
| 维度表（如地区字典） | 低频（每月或每季度变更） | 每周全量扫描，覆盖更新 |
| 报表/指标 | 按需（业务调整时变更） | 人工触发更新，Owner 审核 |
| 已下线/废弃资产 | 极少 | 定期（每月）清理，标记为「已废弃」 |
4.3.2 变更通知：让相关人知道
数据资产变了，谁该知道？Owner 肯定要知道，数据消费者也要知道。我建议建立变更通知机制：
- 元数据变更时，自动通知该资产的 Owner 和订阅用户
- 变更内容包括：字段新增、字段类型修改、表下线、Owner 变更
- 通知渠道：邮件、企业、钉钉，或者集成到数据平台上
4.3.3 定期审计：给目录做「体检」
目录维护不能只靠被动触发，还要主动审计。我建议每季度做一次目录健康度检查：
- 覆盖率检查：实际数据资产数量 vs 目录中注册的数量，差距不能超过 5%
- 准确性检查：随机抽取 10% 的资产，核对元数据与实际是否一致
- 活跃度检查：统计近 30 天被搜索、被访问的资产比例，低于 20% 的资产要标记为「低活跃」
审计结果要形成报告，发给所有 Owner 和数据治理委员会。做得好的表扬，做得差的督促整改。
4.4 核心逻辑：一张图看懂目录建设
说了这么多，我画了一张图，把目录建设的核心逻辑串起来。你一看就明白了。
你看，整个流程是闭环的。从数据源出发，经过采集注册，形成目录结构，再通过维护机制持续更新，最终输出一个可信、可用、可查的目录。任何一个环节断了，目录都会出问题。
4.5 总结：Owner 该做什么？
作为数据资产 Owner，你在目录建设中的职责很明确：
- 设计阶段：参与目录结构设计，确保你的资产能被正确归类
- 注册阶段：提供业务元数据，打上准确的标签，审核注册信息
- 维护阶段：关注变更通知，定期检查你的资产信息是否准确
说白了，目录不是 IT 部门的事，也不是数据治理团队的事。它是每个 Owner 的事。你不管，你的资产就会变成「黑户」，没人找得到，也没人敢用。
嗯，这一章就到这里。记住，目录建设是「三分建、七分管」。建好骨架只是开始，持续维护才是关键。