3. 元数据采集技术：JDBC/ODBC采集、日志解析采集、API采集、事件监听采集

元数据采集，说白了就是怎么把数据从各个源头“捞”出来。我做了这么多年数据治理，见过太多团队在采集这一步就栽了跟头——要么漏采了关键信息，要么把源库压垮了。今天咱们就把四种主流采集方式掰开揉碎讲清楚。

3.1 JDBC/ODBC采集：最传统，也最稳

JDBC和ODBC是数据库连接的标准接口。这种方式适合采集结构化元数据，比如表结构、字段信息、主键、索引这些。

工作原理：通过数据库驱动直连，执行系统表或信息视图的查询。比如MySQL的information_schema，Oracle的ALL_TAB_COLUMNS。

但我得提醒你，这种方式有个大坑。我在项目中遇到过，直接用JDBC去扫几百张表的元数据，结果把生产库的IO打满了。为什么？因为information_schema的查询会锁表啊！

代码示例（Java JDBC采集MySQL元数据）：

// 获取指定库的所有表
DatabaseMetaData metaData = connection.getMetaData();
ResultSet tables = metaData.getTables(
    catalog, schemaPattern, tableNamePattern, types
);

while (tables.next()) {
    String tableName = tables.getString("TABLE_NAME");
    String tableType = tables.getString("TABLE_TYPE");
    String remarks = tables.getString("REMARKS");
    
    // 获取每张表的字段信息
    ResultSet columns = metaData.getColumns(
        catalog, schema, tableName, "%"
    );
    while (columns.next()) {
        String colName = columns.getString("COLUMN_NAME");
        int dataType = columns.getInt("DATA_TYPE");
        String typeName = columns.getString("TYPE_NAME");
        int colSize = columns.getInt("COLUMN_SIZE");
    }
}

3.2 日志解析采集：不侵入，但费脑子

有些场景下你不能直连数据库，比如安全限制严格的金融系统。这时候日志解析就派上用场了。

我习惯把日志采集分成两类：

• 数据库日志：比如MySQL的binlog、Oracle的redo log
• 应用日志：比如数据平台的ETL日志、调度日志

binlog解析示例（基于Canal）：

// 监听MySQL binlog事件
CanalConnector connector = CanalConnectors.newSingleConnector(
    "127.0.0.1", 11111, "example", "", ""
);

connector.connect();
connector.subscribe(".*\\..*");

while (true) {
    Message message = connector.getWithoutAck(100);
    long batchId = message.getId();
    
    for (CanalEntry.Entry entry : message.getEntries()) {
        if (entry.getEntryType() == CanalEntry.EntryType.ROWDATA) {
            CanalEntry.RowChange rowChange = CanalEntry.RowChange.parseFrom(
                entry.getStoreValue()
            );
            // 解析出表名、操作类型、变更前后的数据
            String tableName = entry.getHeader().getTableName();
            CanalEntry.EventType eventType = rowChange.getEventType();
        }
    }
    connector.ack(batchId);
}

3.3 API采集：标准化，但依赖接口

现在很多数据平台都提供了元数据API，比如Atlas的REST API、DataHub的GraphQL接口。这种方式适合采集平台自身的元数据。

常见API类型：

平台	接口类型	采集内容
Apache Atlas	RESTful	实体类型、分类、血缘关系
DataHub	GraphQL	数据集、数据流、Schema
Kafka Schema Registry	RESTful	Avro/Protobuf Schema
Hive Metastore	Thrift	表、分区、存储格式

调用Atlas API获取实体类型的示例：

GET /api/atlas/v2/types/typedefs

Response:
{
  "classificationDefs": [...],
  "entityDefs": [
    {
      "name": "hive_table",
      "superTypes": ["DataSet"],
      "attributeDefs": [
        {"name": "name", "typeName": "string"},
        {"name": "owner", "typeName": "string"},
        {"name": "createTime", "typeName": "date"}
      ]
    }
  ]
}

3.4 事件监听采集：实时，但复杂

如果你需要秒级感知元数据变化，事件监听是唯一选择。这种方式通过订阅消息队列或事件总线，实时捕获变更事件。

典型架构：

• 源系统产生事件 → 发送到Kafka/RabbitMQ → 消费者解析 → 写入元数据存储
• 支持的事件类型：建表、删表、修改字段、变更分区、更新权限

Kafka事件消费示例：

// 消费元数据变更事件
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("group.id", "metadata-collector");
props.put("key.deserializer", 
    "org.apache.kafka.common.serialization.StringDeserializer");
props.put("value.deserializer", 
    "org.apache.kafka.common.serialization.StringDeserializer");

KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
consumer.subscribe(Arrays.asList("metadata-events"));

while (true) {
    ConsumerRecords<String, String> records = consumer.poll(100);
    for (ConsumerRecord<String, String> record : records) {
        String eventJson = record.value();
        // 解析事件，提取表名、操作类型、时间戳
        MetadataEvent event = parseEvent(eventJson);
        updateMetadataStore(event);
    }
}

3.5 四种方式怎么选？

我整理了一张对比表，你根据实际情况对号入座：

维度	JDBC/ODBC	日志解析	API采集	事件监听
实时性	低（定时轮询）	中（近实时）	中（取决于接口）	高（秒级）
侵入性	高（直连数据库）	低（读日志）	中（调用接口）	低（订阅消息）
实现难度	低	高	中	高
适用场景	关系型数据库	安全限制严格的系统	数据平台/工具	实时血缘/变更捕获
维护成本	低	高（日志格式变化）	中（接口版本管理）	高（消息队列运维）

说白了，没有银弹。我一般建议：

• 核心关系库用JDBC做全量采集，配合binlog做增量
• 数据平台用API采集，省心
• 实时场景上事件监听，但要做好兜底