3. 元数据采集与接入：元数据分类、采集方式与常见工具

各位同学，咱们今天聊点实在的。元数据采集，说白了就是给数据资产做「人口普查」。你连自己家里有多少数据、长什么样、从哪来的都不知道，后面的治理、分析、应用全是空中楼阁。我刚开始做数据治理那会儿，就吃过这个亏——项目启动三个月，才发现核心业务系统的字段含义没人说得清。嗯，从那以后，我养成了一个习惯：先搞元数据，再谈其他。

3.1 元数据的三大分类

元数据不是铁板一块。我个人习惯把它分成三类：技术元数据、业务元数据、管理元数据。你想想看，这三类分别回答了三个问题：数据「是什么结构」、「有什么含义」、「该怎么管」。

分类	核心关注点	典型内容	我踩过的坑
技术元数据	数据的技术属性	表结构、字段类型、主外键、分区信息、ETL 脚本、数据血缘	曾经有个项目，技术元数据采集了 2000 张表，但字段注释全是空的——等于白采
业务元数据	数据的业务含义	业务术语、指标定义、数据标准、数据质量规则、数据分类分级	业务元数据最难搞，因为业务方自己都说不清楚「客户活跃度」到底怎么算
管理元数据	数据的管理属性	数据所有者、数据管理员、创建时间、访问权限、数据生命周期	管理元数据容易被忽略，但审计的时候它就是救命稻草

3.2 元数据采集的三种主流方式

采集方式怎么选？说白了就三种：JDBC、API、日志解析。每种都有它的适用场景，也有它的坑。我一个个说。

3.2.1 JDBC 采集

JDBC 是最传统的方式，直接连数据库的元数据表。比如 MySQL 的 information_schema，Oracle 的 ALL_TAB_COLUMNS。这种方式简单粗暴，适合批量采集表结构、字段信息。

-- 一个典型的 JDBC 元数据查询示例
SELECT 
    t.TABLE_NAME,
    c.COLUMN_NAME,
    c.DATA_TYPE,
    c.IS_NULLABLE,
    c.COLUMN_COMMENT
FROM 
    information_schema.TABLES t
    JOIN information_schema.COLUMNS c 
        ON t.TABLE_NAME = c.TABLE_NAME
WHERE 
    t.TABLE_SCHEMA = 'your_database'
    AND t.TABLE_TYPE = 'BASE TABLE';

3.2.2 API 采集

API 采集适合云原生环境。像 Snowflake、AWS Glue、阿里云 DataWorks 这些平台，都提供了元数据查询的 REST API。这种方式比 JDBC 更安全，不会直接操作数据库，但需要处理认证、限流、分页等问题。

// 伪代码：调用元数据 API 采集表信息
function fetchTableMetadata(apiEndpoint, , database) {
    const response = await fetch(`${apiEndpoint}/tables?database=${database}`, {
        headers: {
            'Authorization': `Bearer ${}`,
            'Content-Type': 'application/json'
        }
    });
    
    if (!response.ok) {
        // 我曾经遇到过 API 返回 429（限流），后来加了指数退避重试
        throw new Error(`API 调用失败: ${response.status}`);
    }
    
    return response.json();
}

3.2.3 日志解析采集

日志解析是采集数据血缘的利器。通过解析 SQL 执行日志、ETL 脚本日志，可以还原数据从哪里来、经过什么转换、最终流向哪里。这种方式对业务无侵入，但解析难度大。

# 一个简化的 SQL 日志解析逻辑
import re

def parse_lineage_from_sql(sql_text):
    # 提取 INSERT ... SELECT 中的血缘关系
    pattern = r'INSERT\s+INTO\s+(\w+)\s+.*?SELECT\s+.*?\s+FROM\s+(\w+)'
    match = re.search(pattern, sql_text, re.IGNORECASE)
    
    if match:
        target_table = match.group(1)
        source_table = match.group(2)
        return f"{source_table} -> {target_table}"
    return None

# 我曾经用这个逻辑解析了 10 万条 SQL 日志，准确率大概 85%
# 剩下的 15% 是因为子查询、CTE、动态 SQL 等复杂场景

3.3 常见元数据管理工具

工具选型是个大话题。我重点说两个：Apache Atlas 和 DataHub。这两个我都用过，各有千秋。

3.3.1 Apache Atlas

Atlas 是 Hadoop 生态的老牌元数据工具。它支持通过 Hook 自动采集 Hive、HBase、Kafka 等组件的元数据，也支持通过 Bridge 对接其他系统。它的血缘展示能力很强，但 UI 嘛……嗯，只能说「能用」。

特性	Atlas	我的评价
安装复杂度	高（依赖 Solr、Kafka、HBase）	我曾经花了两周才搭好一个生产环境
血缘采集	强（支持 Hook 自动采集）	Hive 血缘基本零配置，但 Spark 需要额外配置
搜索性能	中等（基于 Solr）	数据量超过 100 万实体后，搜索明显变慢
API 丰富度	高（REST API + Java SDK）	二次开发友好，但文档有点乱

3.3.2 DataHub

DataHub 是 LinkedIn 开源的新一代元数据平台。它的架构更现代，基于 Kafka + Elasticsearch，支持实时元数据变更。UI 比 Atlas 好看太多，而且支持数据资产「发现」——说白了就是搜索体验好。

# DataHub 的元数据 ingestion 配置示例
source:
  type: "mysql"
  config:
    host_port: "localhost:3306"
    database: "your_database"
    username: "metadata_user"
    password: "******"
    # 我曾经忘记加这个配置，结果把所有系统表都采进来了
    database_pattern:
      deny:
        - "information_schema"
        - "performance_schema"
        - "sys"

sink:
  type: "datahub-rest"
  config:
    server: "http://localhost:8080"

3.4 本章知识体系总览

下面这张图是我自己画的，把本章的核心知识点串起来了。你可以把它当作一个「元数据采集全景图」来用。