元数据分类与采集：技术元数据、业务元数据、管理元数据、元数据采集方法与工具

聊元数据治理，第一个绕不开的问题就是：元数据到底分几类？

我刚开始做数据治理项目时，也以为元数据就是“数据的数据”这么简单。结果一上手就懵了——业务部门问“这个字段啥意思”，技术部门问“这个表从哪里来的”，运维问“谁改过这个配置”。同一个“元数据”，不同人问的完全不是一回事。

所以，咱们得先把元数据分清楚。我个人习惯把它分成三大类：技术元数据、业务元数据、管理元数据。这三类各有各的用途，采集方式也不一样。

1. 技术元数据：数据工程师的“地图”

技术元数据，说白了就是描述数据怎么存、怎么算、怎么流转的那些信息。它是数据工程师最常打交道的部分。

我记得有一次排查一个报表数据不准的问题。业务说“昨天数据还是对的，今天就不对了”。我第一反应是查技术元数据——一看血缘图，发现上游有个 ETL 作业昨天被改过调度时间，导致数据没跑完就触发了下游任务。这就是技术元数据的价值：帮你快速定位问题根因。

2. 业务元数据：业务人员的“字典”

业务元数据解决的是“这个数据是什么意思”的问题。技术元数据告诉你字段名叫 cust_id，业务元数据告诉你这是“客户唯一标识，来自 CRM 系统”。

你想想看，如果没有业务元数据，业务人员看数据仓库里的表，就像看天书一样。字段名全是 col_001、f_amt 这种缩写，谁能看懂？

我曾经在一个金融客户那里遇到一个经典案例。他们有个“逾期天数”字段，技术元数据里写的是 overdue_days INT。但业务部门说这个字段不准。一查才发现，业务元数据里根本没定义“逾期”的起点——是从应还日开始算？还是从宽限期结束后开始算？不同业务线口径不一样，数据自然对不上。

所以，业务元数据不是可有可无的装饰品，它是数据能真正被业务用起来的基石。

3. 管理元数据：运维和治理的“日志”

管理元数据关注的是数据谁在用、谁在管、什么时候改过。它更像是数据治理的“审计日志”。

4. 元数据采集方法：从“手工”到“自动化”

元数据分类清楚了，下一步就是怎么把它采回来。采集方法我总结为三种模式：手工录入、接口采集、日志解析。

4.1 手工录入

最原始的方法，但某些场景下必不可少。比如业务术语的定义、数据质量规则的描述，这些“人肉知识”很难从系统里自动抽出来。

我建议：手工录入只用于业务元数据和管理元数据中的非结构化部分。技术元数据千万别靠手工，累死人还容易出错。

4.2 接口采集

这是最主流的方式。通过数据库的 JDBC/ODBC 接口、ETL 工具的 API、数据湖的 Catalog API 来拉取元数据。

-- 示例：通过 JDBC 采集 MySQL 表结构元数据
SELECT 
    TABLE_NAME,
    COLUMN_NAME,
    DATA_TYPE,
    CHARACTER_MAXIMUM_LENGTH,
    IS_NULLABLE,
    COLUMN_DEFAULT
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'your_database'
ORDER BY TABLE_NAME, ORDINAL_POSITION;

这段 SQL 我几乎每个项目都会用到。它从数据库的系统表里把表结构信息一次性拉出来，是技术元数据采集的“基本功”。

4.3 日志解析

有些元数据没法直接通过接口拿到，比如数据血缘中的字段级依赖关系。这时候就得靠解析 SQL 日志、ETL 作业日志来反向推导。

INSERT OVERWRITE TABLE dws.sales_summary
SELECT 
    product_id,
    SUM(amount) AS total_amount
FROM dwd.sales_detail
WHERE dt = '2024-01-01'
GROUP BY product_id;

5. 元数据采集工具选型

工具选型这块，我踩过不少坑。简单说说主流工具的特点：

我个人建议：中小团队优先用 DataHub 或 Atlas，别一上来就自研。我见过太多团队花半年自研采集器，结果功能还没开源工具完善。除非你的数据源非常特殊（比如自研的存储引擎），否则没必要重复造轮子。

6. 一张图看懂元数据分类与采集

下面这张图是我自己总结的，把三类元数据、采集方法和工具串在了一起。你可以把它当作本章的知识框架图。

7. 避坑指南：我踩过的三个坑

最后分享几个实战中容易踩的坑，希望能帮你少走弯路。