3. 元数据采集与集成：自动化采集策略、元数据连接器、实时与批量采集方案
好，咱们进入第三章。元数据管理这件事，说白了，最头疼的不是怎么存、怎么查，而是怎么把散落在各个系统里的元数据给“捞”上来。你想想看，一个典型的数据网格环境里，可能有几十个数据产品、几百张表、上千个指标定义，它们分布在不同的存储引擎、不同的计算平台、甚至不同的云上。如果没有一套靠谱的采集策略，后面所有的治理、血缘分析、数据目录，全都是空中楼阁。
我个人习惯把元数据采集比作“修水管”。你得先把所有源头接上，把水引到同一个池子里，才能谈得上净化、分配和使用。这一章，我们就来聊聊怎么修好这根“水管”。
3.1 自动化采集策略：从“人肉”到“无人驾驶”
很多团队刚开始做元数据管理时，都走过一段弯路——靠人工录入。我在项目中遇到过一家公司，专门雇了两个人，每天手动填写 Excel 表格来维护数据字典。结果呢？表格永远滞后，字段定义经常对不上，最后这两个人自己也放弃了。所以，自动化采集不是可选项，是必选项。
自动化采集策略，核心要解决三个问题：
- 发现：怎么知道系统里新增了哪些数据资产？
- 提取：怎么把元数据从源系统中“拽”出来？
- 同步：怎么把变化及时反映到元数据中心？
针对这三个问题，我建议采用分层采集策略：
| 采集层级 | 目标对象 | 典型技术 | 采集频率 |
|---|---|---|---|
| 基础设施层 | 数据库、数据湖、消息队列 | JDBC/ODBC 连接器、API 轮询 | 低频率（每日/每周） |
| 数据模型层 | 表结构、视图、字段定义、约束 | DDL 解析、Schema Registry | 中频率（每小时/每半小时） |
| 数据血缘层 | ETL 作业、SQL 查询、数据管道 | 日志解析、SQL 解析器、Lineage Hook | 高频率（实时/近实时） |
| 业务语义层 | 指标定义、业务术语、数据标签 | API 回调、事件驱动 | 按需/事件触发 |
为什么要分层？因为不同层级的元数据，其变化频率和重要性完全不同。基础设施层的表结构可能一个月才变一次，你没必要每秒去扫一次；而数据血缘层的查询日志，每秒钟都在产生，必须实时处理。分层采集，本质上是在资源消耗和数据时效性之间找平衡。
3.2 元数据连接器：打通“最后一公里”
自动化采集策略定好了，接下来就是具体干活了。元数据连接器，就是那个负责跟各个数据系统“打交道”的组件。你可以把它理解成一个适配器，每个数据源都需要一个专门的连接器来对接。
市面上常见的元数据连接器，大致可以分为三类：
- 原生连接器：数据系统自带的元数据接口。比如 MySQL 的
information_schema，Snowflake 的INFORMATION_SCHEMA，Kafka 的kafka-magic。优点是稳定、官方维护；缺点是每个系统都不一样，集成工作量大。 - 开源连接器：像 Apache Atlas、DataHub、Amundsen 这些开源元数据平台，都提供了一堆现成的连接器。比如 DataHub 的
datahub-ingestion框架，支持几十种数据源。优点是开箱即用，社区活跃；缺点是定制化能力有限，遇到冷门系统可能没有现成的。 - 自定义连接器：针对内部系统或特殊协议，自己动手写。比如你们公司自研的 OLAP 引擎，或者某个老旧的 FTP 服务器。优点是完全可控；缺点是开发和维护成本高。
我个人建议，优先用开源的，其次用原生的，最后才考虑自研。为什么？因为元数据连接器这东西，看着简单，实则坑很多。比如连接超时、认证失败、数据格式不兼容、版本升级导致接口变更……这些坑，开源社区已经帮你踩过一遍了。
3.3 实时与批量采集方案：两种模式，一个目标
采集策略和连接器都到位了，最后一步是决定怎么采——是批量跑，还是实时流？
这个问题没有标准答案，取决于你的业务场景。我习惯用一张表来对比这两种模式：
| 对比维度 | 批量采集 | 实时采集 |
|---|---|---|
| 触发方式 | 定时调度（Cron、Airflow DAG） | 事件驱动（CDC、Webhook、Kafka 消息） |
| 数据延迟 | 分钟级到小时级 | 秒级到毫秒级 |
| 资源消耗 | 集中式、高负载（跑的时候占资源） | 分散式、低负载（持续小流量） |
| 适用场景 | 表结构变更、数据字典同步、全量快照 | 数据血缘、查询日志、指标更新 |
| 典型技术 | Spark Job、SQL Dump、API 批量拉取 | Debezium、Kafka Connect、Flink CDC |
在实际的数据网格项目中，我通常采用混合模式：
- 批量采集负责“全量快照”。每天凌晨跑一次，把所有的表结构、字段定义、分区信息拉一份全量数据，存入元数据中心的历史表。这样即使实时管道出了问题，我们还有一份“底牌”。
- 实时采集负责“增量变更”。通过监听数据库的 Binlog 或 Kafka 的 Topic，实时捕获元数据的变更事件。比如新增了一个字段、修改了一个表名、运行了一条 SQL 查询，这些事件会立刻被推送到元数据中心，更新血缘关系和活跃元数据。
举个例子，假设我们有一个 MySQL 数据库，里面有一张 orders 表。批量采集每天凌晨会跑一次，把 orders 表的完整 Schema 存下来。而实时采集则通过 Debezium 监听 MySQL 的 Binlog，一旦有人执行了 ALTER TABLE orders ADD COLUMN discount DECIMAL(10,2)，这个变更事件会在几秒内被捕获，并更新到元数据中心。这样，数据消费者在查询 orders 表时，立刻就能看到新字段 discount，而不需要等到第二天。
3.4 知识体系总览：一张图看懂元数据采集
说了这么多，我们来画一张图，把整个元数据采集与集成的知识体系串起来。这张图是我在项目中经常用来跟团队对齐的“作战地图”。
这张图从左到右，从上到下，清晰地展示了元数据采集的完整链路。你可以把它打印出来贴在墙上，或者作为团队技术方案评审的参考。嗯，我个人觉得，这张图的价值在于它把策略、工具、方案、目标四个层面串在了一起，而不是孤立地讲某个技术点。
3.5 小结：采集是基础，但别陷入“采集陷阱”
最后，我想提醒一点：元数据采集不是目的，而是手段。我见过不少团队，花了大半年时间把各种元数据都采上来了，结果发现没人用。为什么？因为采集上来的元数据质量太差，或者跟业务脱节。
所以，在设计和实施采集方案时，一定要时刻问自己三个问题：
- 这些元数据，最终谁会用到？
- 他们需要什么粒度的数据？
- 数据的时效性要求有多高？
想清楚这些问题，再回头去设计你的采集策略、选择连接器、决定实时还是批量。这样，你的元数据采集管道才不会沦为“为了采集而采集”的摆设。