2、元数据采集概述：采集目标与范围、采集策略（全量/增量）、采集频率与调度

好，咱们正式开始聊元数据采集。说实话，很多团队一开始都低估了这个环节。他们觉得不就是把表结构拉出来嘛，有什么难的？结果一跑起来，问题全来了——采集不全、性能打满、重复数据满天飞。

我个人习惯，在动手写任何采集代码之前，先把三个问题想清楚：采什么、怎么采、多久采一次。这三点定好了，后面基本不会翻车。

2.1 采集目标与范围

先问个问题：你打算采集哪些元数据？

别笑，我见过有人把整个数据库的 binlog 都拉回来，结果 90% 是没用的中间表。也见过有人只采了表名和字段名，连字段类型都没拿，后面做血缘分析时直接傻眼。

一般来说，元数据采集的目标可以分为三层：

层级	采集内容	典型来源	用途
技术元数据	表结构、字段类型、索引、分区、存储大小、行数	Hive Metastore、MySQL information_schema、Kafka Schema Registry	数据地图、影响分析、存储治理
业务元数据	字段中文名、业务定义、枚举值含义、数据域归属	数据字典、业务系统配置表、人工维护的 Excel	数据资产目录、自助分析
操作元数据	ETL 执行记录、调度依赖、数据血缘、访问日志	调度系统 API、审计日志、SQL 解析结果	运维监控、问题排查、合规审计

我在项目中遇到过最典型的坑：只采了技术元数据，业务元数据全靠人工维护。结果业务方问「这个字段到底代表什么」，技术团队翻半天代码也说不清楚。后来我们强制要求：每个新表上线，必须同时提交技术元数据和业务元数据，缺一不可。

2.2 采集策略：全量与增量

范围定好了，接下来就是怎么采。这里有两个基本策略：全量采集和增量采集。

2.2.1 全量采集

说白了，就是把目标数据源的所有元数据一次性拉回来。比如每天凌晨把 Hive 的所有表结构重新扫一遍。

• 优点：实现简单，逻辑清晰，不会漏数据。
• 缺点：数据量大时非常慢，对源系统有压力，而且大部分数据是重复的。

我曾经在一个 5000+ 表的数仓上做全量采集，每次跑 40 分钟，把 Hive Metastore 的 CPU 打到了 90%。运维同事直接来找我喝茶了。

2.2.2 增量采集

只采集自上次采集以来发生变化的部分。比如只拉取新增的表、修改过的字段、删除的分区。

• 优点：速度快，对源系统影响小，适合高频执行。
• 缺点：实现复杂，需要记录「上次采集状态」，还要处理删除和重命名等边界情况。

增量采集的关键在于变更检测机制。我常用的几种方式：

检测方式	原理	适用场景	我的评价
时间戳对比	利用表的 last_modified_time 或 update_time	MySQL、PostgreSQL 等关系型数据库	最简单，但有些系统不维护这个字段
事件监听	监听 DDL 事件（如 Hive Metastore 的 Notification Log）	Hive、Kafka Schema Registry	实时性好，但需要额外配置
版本号对比	维护一个本地版本号，每次采集后更新	自定义元数据存储	可控性强，但需要自己维护状态
快照对比	全量拉取后与本地快照做 diff	数据量小的场景	简单粗暴，但数据量大时性能差

2.3 采集频率与调度

频率怎么定？你想想看，如果你的数据源一天变更 100 次，你却只每天采集一次，那中间 99 次变更都丢了。反过来，如果一个月才变一次，你每小时去扫一遍，纯属浪费资源。

我一般按这个原则来定：

• 技术元数据：每天 1-2 次（凌晨 + 中午）。大部分表结构变更都在发布窗口发生，凌晨采集足够覆盖。
• 业务元数据：每周 1 次。业务定义变化慢，没必要高频采集。
• 操作元数据：实时或每小时。ETL 执行记录、血缘信息需要及时更新，否则排查问题时数据已经过期了。

调度这块，我踩过一个大坑。当时用 Cron 表达式写死了采集时间，结果某个数据源因为网络延迟，采集任务和业务高峰期撞上了，直接把源库拖垮。后来我改成了自适应调度：

# 伪代码示例：自适应调度逻辑
def schedule_collect(source):
    # 获取源系统的历史负载数据
    load_history = get_load_history(source)
    # 找到过去 7 天负载最低的时间窗口
    best_window = find_lowest_load_window(load_history)
    # 在这个窗口内执行采集
    execute_collect(source, best_window)

嗯，这里要注意：自适应调度虽然好，但实现成本高。小团队可以先从固定时间调度开始，等稳定了再优化。

2.4 知识体系总览

说了这么多，咱们用一张图把整个采集体系串起来。这张图我每次做新项目都会先画出来，贴在墙上，团队里每个人都能看懂。

这张图把咱们刚才聊的三个核心维度串在了一起。你仔细看，从左到右其实是一个决策链条：先确定采集目标，再选择采集策略，最后定频率和调度方式。每一步都依赖上一步的决策。

我个人习惯，每次接手一个新数据源，都会拿着这张图过一遍。哪个环节不清楚，就停下来想清楚再动手。磨刀不误砍柴工，采集方案设计好了，后面解析、存储、应用都会顺畅很多。