4. 元数据采集：手动采集与自动采集归纳总结
元数据采集这件事，说白了就是两个路子：一个靠人，一个靠机器。我这些年踩过的坑，大多集中在两者边界没划清楚。今天咱们把这两种方式掰开揉碎了讲，最后给出我的混合策略。
4.1 手动采集：原始但可控
手动采集听起来很土，但在某些场景下反而是最优解。我之前在一个数据湖项目里见过，团队上来就搞自动化采集，结果被各种奇葩数据源搞得焦头烂额。最后我建议他们先手工跑几轮，摸清楚数据特征之后，再写自动化脚本。
什么时候该用手动采集？ 我个人习惯：新接入数据源、临时性探查、或者数据源结构极度混乱时，先手动跑，跑通了再考虑自动化。
手动采集的典型操作流程是这样的：
# 1. 手动探查表结构
DESCRIBE my_table;
# 2. 查看分区信息
SHOW PARTITIONS my_table;
# 3. 查看数据样例
SELECT * FROM my_table LIMIT 10;
# 4. 手动记录元数据到Excel或文档
# 或者通过API手动推送到元数据中心
curl -X POST http://metadata-center:8080/api/tables \
-H "Content-Type: application/json" \
-d '{
"table_name": "my_table",
"schema": [
{"name": "id", "type": "int"},
{"name": "name", "type": "string"},
{"name": "created_at", "type": "timestamp"}
],
"partition_key": "created_at"
}'
避坑指南： 我曾经见过一个团队，全靠人工维护1000多张表的元数据文档。结果某次数据源迁移后，文档和实际表结构对不上了，数据质量事故直接坐实。手动采集可以，但必须有个截止点——我建议超过50个表，就得考虑自动化了。
4.2 自动采集：规模化治理的基石
你想想看，几十个数据源、几千张表，靠手搓是肯定不行的。自动采集才是元数据治理能跑起来的真正发动机。
自动采集的核心思想是：通过调度器定期扫描数据源，把元数据拉回来，推送到元数据中心。整个过程无人值守，但可靠性要求极高。
4.2.1 自动采集的几种模式
我通常把它们分成三种：
| 模式 | 原理 | 适用场景 | 我踩过的坑 |
|---|---|---|---|
| 增量扫描 | 基于上次采集的时间戳或偏移量，只拉取新增或变更的元数据 | 每天有大量新表产生的场景 | 时间戳不准会导致数据遗漏 |
| 全量扫描 | 每次遍历整个数据源，全部重拉 | 数据源变更频繁、元数据一致性要求极高 | 数据源数据量大时耗时太长 |
| 事件驱动采集 | 监听数据源的变更事件（如WAL日志），实时推送到采集器 | 要求实时更新元数据的场景 | 事件丢包后状态恢复麻烦 |
4.2.2 自动采集的配置文件示例
拿我之前写的采集器来说，配置是这样的：
version: "2.0"
collector:
name: mysql_collector
type: jdbc
schedule: "0 0 2 * * ?" # 每天凌晨2点执行
source:
url: jdbc:mysql://datawarehouse:3306
user: metadata_user
password: ${METADATA_PASSWORD}
databases:
- "data_warehouse"
- "data_lake"
exclude_tables:
- "tmp_*"
- "backup_*"
sink:
type: http
endpoint: http://metadata-center:8080/api/batch
batch_size: 100
retry_attempts: 3
timeout_seconds: 30
核心要点： 配置文件里一定要有重试和超时机制。我之前一个采集任务因为网络抖动，10分钟的超时时间卡住了整个链路，后面的采集全部堆积。后来我强制加了个超时上限30秒，问题才解决。
4.3 手动 vs 自动：一个完整的对比
直接上表格，大家看得更清楚：
| 维度 | 手动采集 | 自动采集 |
|---|---|---|
| 工具 | curl、SQL客户端、Excel | 采集引擎、调度器、API网关 |
| 频率 | 按需、不定期 | 定期（分钟/小时/天） |
| 精确度 | 取决于个人细心程度 | 机器执行，稳定可靠 |
| 资源消耗 | 人力成本高 | 系统资源消耗可控 |
| 学习成本 | 几乎为零 | 需要掌握调度配置和采集器 |
4.4 混合采集策略：我实际在用的方案
讲完了优缺点，你会发现两者其实是互补的。真正成熟的元数据治理管道，走的是混合采集路线。我目前在公司推的方案是这样的：
- 初期接入：手动跑一轮，摸清楚数据源特征。这步省不了，能避免自动化脚本写反。
- 稳定期：自动采集作为主力，配置调度和告警。出了问题自动重试或告警到人。
- 异常处理：自动采集挂了怎么办？你猜对了，手动介入修正。我见过最惨的情况是自动采集跑了几周，某次数据源升级后采集器彻底不工作，团队没人意识到。从那以后我强制要求每个采集任务保留手动回补入口。
这个混合思路，我画了个流程：
这图想表达什么？ 左边是手动入口，右边是自动入口。数据源第一次进来走手动，稳定之后切自动。自动采集如果失败，告警到人，人工介入修正后走手动二次补录。两个出口都指向元数据中心，最终落盘。
4.5 避坑清单
最后，我把这些年踩过的雷整理成清单，留着给大家当参考：
- 手动采集别裸奔： 我曾经手写了一个表结构文档，结果标点符号写反了，采集器解析失败。后来我规定手动脚本必须做格式校验，哪怕只是跑个正则检查。
- 自动采集的幂等性： 自动采集任务可能被重复调度（比如调度器重启）。你想想看，如果每条元数据都重复插入，元数据中心迟早爆炸。我吃过大亏之后，强制给每个采集任务加上唯一ID和去重逻辑。
- 不要用默认密码： 这个我不多说了，你懂的。配置文件一定要用环境变量或密钥管理工具。
- 手动采集的文档要跟自动采集对账： 我见过最离谱的事：手动文档里写了100张表，自动采集只采到了80张，结果没人发现少了20张。后来我加了每日对账报表，自动采集结果跟手动台账比对，差异告警。