3、元数据采集技术：JDBC/ODBC采集、日志采集、API采集、事件驱动采集

元数据采集，说白了就是给数据湖仓装上一双「眼睛」。没有这双眼睛，你根本不知道湖里存了什么、从哪里来、质量如何。我见过太多团队，湖仓建得漂漂亮亮，结果元数据一塌糊涂，最后数据变成了一滩死水。

今天咱们聊聊四种主流的采集方式。每种都有它的脾气，选对了事半功倍，选错了……嗯，我踩过的坑可以写本书。

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

JDBC/ODBC 采集，是元数据采集的「老黄牛」。它通过数据库的标准接口，把表结构、字段、索引、分区这些信息一把抓过来。我最早做数据治理时，用的就是这招。

它的原理其实很简单：通过 JDBC 驱动连接数据库，执行 information_schema 或 SHOW CREATE TABLE 之类的元数据查询，然后把结果结构化存储起来。

// 伪代码示例：JDBC 采集 MySQL 元数据
Connection conn = DriverManager.getConnection(url, user, password);
DatabaseMetaData meta = conn.getMetaData();

// 获取所有表
ResultSet tables = meta.getTables(null, null, "%", new String[]{"TABLE"});
while (tables.next()) {
    String tableName = tables.getString("TABLE_NAME");
    String tableType = tables.getString("TABLE_TYPE");
    String remarks = tables.getString("REMARKS");
    
    // 获取字段信息
    ResultSet columns = meta.getColumns(null, null, tableName, "%");
    while (columns.next()) {
        String colName = columns.getString("COLUMN_NAME");
        String colType = columns.getString("TYPE_NAME");
        int colSize = columns.getInt("COLUMN_SIZE");
        // 存储到元数据中心
    }
}

JDBC/ODBC 适合的场景：

• 批量采集：每天凌晨跑一次，把全量元数据拉回来
• 历史数据：对实时性要求不高的存量系统
• 结构稳定：表结构变化不频繁的场景

但它有个硬伤——实时性差。你想想看，如果业务表每秒钟都在变更，靠 JDBC 每分钟轮询一次，不仅延迟高，还会给数据库带来额外压力。我曾经有个客户，因为 JDBC 轮询太频繁，直接把生产库的 CPU 打满了……

3.2 日志采集：流式处理的利器

日志采集，是应对「数据洪流」的好手。Flume 和 Filebeat 是这领域的两个代表。

Flume 是 Apache 家的老牌日志采集工具。它的架构是 Agent-Collector-Storage 三层。我习惯把它用在 Hadoop 生态里，尤其是跟 Kafka、HDFS 配合时特别顺手。

Filebeat 则是 Elastic 家的轻量级选手。它更轻、更简单，适合跟 Elasticsearch 搭档。我最近的项目里，Filebeat 用得更多——部署方便，资源占用小。

# Filebeat 配置示例：采集应用日志中的元数据变更
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/app/metadata-change.log
  fields:
    log_type: metadata_change
  multiline:
    pattern: '^\d{4}-\d{2}-\d{2}'
    negate: true
    match: after

output.kafka:
  hosts: ["kafka1:9092", "kafka2:9092"]
  topic: "metadata-events"
  partition.round_robin:
    reachable_only: true

日志采集的核心优势：

• 实时性高：日志产生即采集，延迟秒级
• 对源系统无侵入：只读日志文件，不碰数据库
• 可追溯：日志本身就是审计证据

3.3 API 采集：对接外部系统的桥梁

API 采集，说白了就是「你提供接口，我来拉数据」。现在的主流数据平台，像 Snowflake、Databricks、阿里云 DataWorks，都提供了丰富的元数据 API。

我常用的 API 采集方式有两种：

• RESTful API：通过 HTTP 请求获取 JSON/XML 格式的元数据
• GraphQL：可以精确指定要查询的字段，避免数据冗余

# 调用 Snowflake 元数据 API 示例
curl -X GET "https://account.snowflakecomputing.com/api/v2/databases/MY_DB/schemas/PUBLIC/tables" \
  -H "Authorization: Bearer ${}" \
  -H "Content-Type: application/json"

API 采集适合的场景：

• SaaS 平台：像 Salesforce、Shopify 这类外部系统
• 云原生数据仓库：Snowflake、Redshift、BigQuery
• 按需拉取：不需要实时，但需要灵活查询

3.4 事件驱动采集：实时元数据的终极方案

事件驱动采集，是元数据采集的「法拉利」。它通过监听数据源的变更事件，一旦有变化就立刻推送过来。最典型的实现就是 CDC（Change Data Capture）。

CDC 的原理：数据库的 binlog、redo log 或者 WAL 日志里，记录了每一次数据变更。CDC 工具（如 Debezium、Canal、Maxwell）解析这些日志，把变更事件发到消息队列，然后元数据系统消费这些事件，实时更新。

// Debezium 配置示例：监听 MySQL binlog
{
  "name": "mysql-connector",
  "config": {
    "connector.class": "io.debezium.connector.mysql.MySqlConnector",
    "database.hostname": "192.168.1.100",
    "database.port": "3306",
    "database.user": "debezium",
    "database.password": "dbz_pass",
    "database.server.id": "184054",
    "database.server.name": "myapp",
    "database.include.list": "myapp_db",
    "table.include.list": "myapp_db.orders,myapp_db.users",
    "database.history.kafka.bootstrap.servers": "kafka:9092",
    "database.history.kafka.topic": "schema-changes.myapp"
  }
}

事件驱动采集的优缺点：

优势	劣势
实时性极强，毫秒级响应	对源系统有侵入（需要开启 binlog）
数据一致性高，不会漏掉变更	运维复杂度高，需要管理 CDC 组件
天然支持审计和回放	事件顺序和幂等性需要额外处理
对源库压力小（只读日志）	初始全量同步需要配合其他方式

3.5 四种方式怎么选？

说实话，没有银弹。我参与过的项目里，基本都是组合拳：

• 存量数据：用 JDBC/ODBC 做一次全量拉取
• 实时变更：用 CDC 事件驱动持续监听
• 日志类元数据：用 Flume/Filebeat 流式采集
• 外部系统：用 API 按需拉取