📚 课程目录第4章元数据采集引擎

4、元数据采集引擎：采集适配器模式、增量采集策略、实时采集与批处理采集

元数据采集引擎，说白了就是数据目录的「眼睛」和「耳朵」。它负责把散落在各个数据源里的元数据捞回来，统一喂给目录系统。我见过不少团队，一上来就搞元数据管理，结果卡在采集这一步——要么采不全，要么采不准，要么把源系统压垮了。

这一章，咱们就聊聊采集引擎的三个核心设计：适配器模式怎么搭、增量采集怎么玩、实时和批处理怎么选。

4.1 采集适配器模式：让引擎「认识」所有数据源

企业里的数据源五花八门：MySQL、Oracle、Hive、Kafka、Elasticsearch、S3……每个的元数据接口都不一样。你总不能为每个数据源单独写一套采集逻辑吧？

适配器模式就是来解决这个问题的。它的核心思想很简单：定义一套统一的采集接口，每个数据源实现自己的适配器。

核心接口定义（伪代码）：

interface MetadataCollector {
    // 连接测试
    boolean testConnection(ConnectionConfig config);
    
    // 获取所有数据库/目录
    List<Catalog> listCatalogs();
    
    // 获取所有表/集合
    List<Table> listTables(String catalog);
    
    // 获取表结构（字段、类型、注释）
    List<Column> getColumns(String catalog, String table);
    
    // 获取分区信息（Hive/分区表）
    List<Partition> getPartitions(String catalog, String table);
    
    // 获取行数/大小等统计信息
    TableStats getTableStats(String catalog, String table);
}

每个数据源实现这个接口就行。比如 MySQL 适配器走 JDBC 的 DatabaseMetaData，Hive 适配器走 HMS Thrift API，Kafka 适配器走 AdminClient 的 describeTopics。

我建议在适配器里再加一层「连接池管理」。为什么呢？因为元数据采集往往是批量任务，一个数据源可能要同时采集几百张表。如果每张表都新建连接，连接数会爆炸。我在项目中就踩过这个坑——采集 MySQL 时没复用连接，结果 DBA 找上门说「你们的采集把数据库连接池打满了」。

4.2 增量采集策略：别每次都全量扫

全量采集是最简单粗暴的方式：每次把数据源的所有元数据拉一遍。但问题也很明显——

慢：几千张表，每次全量扫，耗时几十分钟甚至几小时
重：对源系统造成压力，尤其是 JDBC 的 SELECT * FROM information_schema
浪费：大部分元数据其实没变化

所以，增量采集才是生产环境的标配。常见的增量策略有这几种：

策略	原理	适用场景	我踩过的坑
时间戳对比	记录每张表的 `last_modified_time`，只采集有变化的表	MySQL、PostgreSQL 等关系型数据库	有些表的时间戳不准确，比如只记录数据变更，不记录结构变更
事件监听	监听数据源的 DDL 事件（如 MySQL binlog、Hive Metastore 事件）	需要实时感知元数据变化的场景	binlog 解析复杂，且会占用源系统资源
版本号/哈希对比	对表结构计算哈希值，哈希变了才重新采集	不支持时间戳的数据源（如某些 NoSQL）	哈希计算本身也有开销，适合表结构变化不频繁的场景
日志对比	记录上次采集的元数据快照，与当前快照做 diff	全量采集后的增量更新	快照存储成本高，适合表数量不多的场景

我个人习惯用「时间戳 + 事件监听」的组合策略。时间戳兜底，保证每天至少全量同步一次；事件监听做实时增量，保证元数据变更能在分钟级内感知到。

避坑指南：我曾经遇到过一个场景——某张表的结构一天变了十几次，每次都是加字段。如果只用时间戳增量采集，每次都要重新拉整张表的元数据。后来我加了个「变更频率检测」：如果某张表在短时间内频繁变更，就把它加入「热表队列」，单独用事件监听处理，避免反复全量采集。

4.3 实时采集与批处理采集：两种模式怎么选

实时采集和批处理采集，不是二选一的关系，而是互补的。我见过很多团队非要二选一，结果要么实时扛不住，要么批处理延迟太大。

4.3.1 批处理采集：稳定、可控、适合大规模

批处理采集是最成熟的方式。它的核心流程是：

调度触发：通过 Quartz、Airflow 等调度器，按固定周期（如每小时、每天）触发采集任务
任务分发：把采集任务按数据源分组，分发给不同的采集 Worker
并行采集：每个 Worker 按适配器接口采集元数据，写入消息队列或直接入库
数据清洗：对采集到的元数据做去重、格式统一、关联关系补全
写入目录：把清洗后的元数据写入数据目录的存储层

批处理的优势很明显：可控。你可以控制采集频率、并发数、对源系统的压力。我建议批处理采集的周期不要短于 15 分钟，否则对源系统的压力会线性增长。

4.3.2 实时采集：低延迟、高敏感、适合关键链路

实时采集不是真的「毫秒级」，而是指元数据变更后，能在秒级或分钟级内感知到。它通常依赖事件驱动：

MySQL binlog：监听 DDL 事件（CREATE、ALTER、DROP）
Hive Metastore 事件：监听表/分区变更
Kafka Schema Registry：监听 Schema 版本变化
自定义 Webhook：数据源主动推送变更事件

实时采集适合哪些场景？我总结了三类：

数据血缘追踪：表结构变了，下游的 ETL 任务可能立刻报错，需要实时感知
数据安全审计：敏感字段被修改了，需要第一时间告警
数据目录的「新鲜度」保障：用户查目录时，看到的元数据必须是当前最新的

注意：实时采集不是万能的。它依赖数据源的事件能力，而且事件处理本身也有延迟。比如 MySQL binlog 的解析和投递，从事件产生到元数据入库，通常有 1-5 秒的延迟。如果你的业务要求「零延迟」，那实时采集也做不到。

4.4 架构设计：批处理 + 实时采集的混合模式

在实际项目中，我推荐用混合模式：批处理兜底，实时采集做增量。

下面这张图展示了混合模式的整体架构：

这个架构的核心思路是：

批处理负责「全量同步」和「定期刷新」，保证数据目录的元数据不会遗漏
实时采集负责「增量感知」，保证元数据变更能快速反映到目录中
消息队列做缓冲和解耦，批处理和实时采集的数据都写入同一个 Topic，下游的清洗和入库逻辑统一处理

我的经验：在消息队列里，我建议用「元数据变更事件」作为消息体，而不是直接传元数据全量。比如：

{
  "event_type": "TABLE_ALTER",
  "source": "mysql://prod-db:3306/orders",
  "table": "order_detail",
  "changed_fields": ["new_column:amount:decimal(18,2)"],
  "timestamp": 1712345678000
}

这样下游的清洗逻辑可以按事件类型做差异化处理，而不是每次都全量解析。

4.5 采集引擎的「避坑清单」

最后，我把自己在项目中踩过的坑整理成一份清单，希望能帮你少走弯路：

坑	表现	解决方案
连接泄漏	采集几次后，数据源连接数飙升，最终拒绝连接	适配器内用连接池，采集完成后显式关闭连接
大表采集超时	几百万分区的 Hive 表，采集分区信息时超时	分页采集，每次只拉 1000 个分区，配合限流
元数据不一致	同一张表，不同时间采集到的字段顺序不同	采集时按字段名排序，入库时做字段顺序归一化
事件丢失	实时采集时，某些 DDL 事件没被监听到	批处理兜底，每天全量同步一次，保证最终一致性
采集任务堆积	数据源太多，采集任务排队，延迟越来越高	按数据源优先级排队，核心数据源优先采集

嗯，采集引擎这部分内容就这些。记住一个原则：不要追求「完美」的采集，要追求「可用」的采集。先跑起来，再优化，这是我在多个项目中验证过的经验。