📚 课程目录第3章元数据采集技术

3、元数据采集技术：从源头把数据「抓」回来

元数据采集，说白了就是解决一个问题——数据到底长什么样，它从哪来，又去了哪。我做了这么多年数据治理，见过太多团队在建模阶段拍脑袋定标准，结果一落地发现连最基本的表结构都采不回来。嗯，这一步要是没走稳，后面全是坑。

这一章咱们就聊聊元数据采集的几种常见方法，以及市面上主流的采集框架怎么选。我会结合自己踩过的坑，给你一些实在的建议。

3.1 元数据采集的四种主流方法

先看一张总览图，把四种方法的核心逻辑理清楚：

3.1.1 JDBC/ODBC：最传统，也最可靠

JDBC 和 ODBC 是数据库连接的标准接口。你写个连接串，跑几条 information_schema 的查询，表结构、字段、主键、索引就全出来了。我最早做元数据采集时，就是靠 JDBC 把 Oracle、MySQL、PostgreSQL 的表结构一把拉回来。

举个例子，MySQL 采集表结构的核心 SQL 长这样：

SELECT 
    TABLE_NAME,
    COLUMN_NAME,
    DATA_TYPE,
    CHARACTER_MAXIMUM_LENGTH,
    IS_NULLABLE,
    COLUMN_DEFAULT,
    COLUMN_COMMENT
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'your_database'
ORDER BY TABLE_NAME, ORDINAL_POSITION;

优点：稳定、标准、几乎零依赖。只要数据库支持 JDBC/ODBC，就能采。

缺点：只能采结构化元数据。血缘关系、ETL 逻辑、数据质量这些，它管不了。

我的经验：JDBC 采集时一定要注意连接池和超时设置。我曾经在生产环境一次性采集 2000+ 张表，结果连接没释放，直接把源库连接池打满了。后来我习惯用 setFetchSize 控制每次拉取的行数，避免 OOM。

3.1.2 API 采集：云原生时代的标配

现在很多 SaaS 工具和云数据平台都提供了元数据 API。比如 Snowflake 的 INFORMATION_SCHEMA 视图、Tableau 的 Metadata API、Salesforce 的 Tooling API。你只需要拿到 API ，按文档调接口就行。

我去年帮一家客户做数据中台，他们的核心报表在 Tableau Server 上。用 Tableau Metadata API 直接拉取数据源、工作表、字段的血缘关系，比手动翻 UI 快一百倍。

# 伪代码示例：调用 Tableau Metadata API 获取数据源
import requests

url = "https://your-tableau-server/api/3.12/metadata/graphql"
headers = {"X-Tableau-Auth": "your_"}
query = """
{
  publishedDatasources {
    name
    upstreamTables {
      name
      database {
        name
      }
    }
    downstreamWorkbooks {
      name
    }
  }
}
"""
response = requests.post(url, json={"query": query}, headers=headers)
print(response.json())

优点：能采到血缘、使用频率、权限等丰富信息。

缺点：每个平台的 API 都不一样，适配成本高。而且 API 通常有频率限制，大规模采集要小心。

避坑指南：我曾经对接一个云数据平台的 API，文档说每分钟 1000 次请求，结果实际只有 200 次。后来我加了重试和退避策略，才稳定下来。记住：永远不要相信 API 文档的限流数字，先压测再上线。

3.1.3 日志解析：血缘追踪的利器

如果你想知道一条数据从 Hive 表经过 Spark 计算，最后落到报表里的完整链路，日志解析是最直接的方法。Kafka 的 Connect 日志、Airflow 的 DAG 运行日志、Spark 的 SQL 执行计划，里面都藏着血缘信息。

我做过一个项目，用 Flume 实时采集 Hive 的审计日志，解析出每条 SQL 的输入表和输出表，然后构建血缘图。虽然解析逻辑复杂，但效果非常好。

# 示例：从 Hive 审计日志中提取血缘
日志原文：
2024-01-15 10:23:45 INFO  - USER=hadoop, QUERY=INSERT OVERWRITE TABLE dws.sales_summary 
SELECT product_id, SUM(amount) FROM ods.sales_detail GROUP BY product_id

解析结果：
{
  "user": "hadoop",
  "timestamp": "2024-01-15 10:23:45",
  "input_tables": ["ods.sales_detail"],
  "output_tables": ["dws.sales_summary"],
  "operation": "INSERT_OVERWRITE"
}

优点：能捕获实时血缘，粒度细到字段级别。

缺点：日志格式不统一，解析规则需要持续维护。而且日志量巨大，存储和计算成本不低。

3.1.4 爬虫：最后的补充手段

有些元数据藏在 Confluence 页面、GitLab Wiki、甚至 Excel 文档里。这时候就得用爬虫了。我见过一个团队，把内部 200 多个 Confluence 页面里的数据字典全部爬下来，解析成结构化元数据。

不过说实话，爬虫是「不得已的选择」。它的维护成本很高，页面结构一变，爬虫就挂了。我建议只用来采集那些实在没有接口的非结构化来源。

3.2 采集框架选型：Atlas、DataHub、OpenMetadata

方法讲完了，接下来是框架选型。目前市面上最主流的三个开源元数据平台是 Apache Atlas、DataHub 和 OpenMetadata。我三个都用过，下面说说我的真实感受。

对比维度	Apache Atlas	DataHub	OpenMetadata
出身	Apache 基金会，Hadoop 生态	LinkedIn 开源，现在由 Acryl Data 维护	社区驱动，2022 年从 Uber 内部工具演化而来
采集方式	Hook + Bridge，依赖 Kafka	Ingestion Framework，Python 为主	Ingestion Pipeline，Python + Airflow
血缘能力	强，支持字段级血缘	强，支持列级血缘和 SQL 解析	中等，正在快速迭代
部署复杂度	高，依赖 HBase、Solr、Kafka	中等，Docker Compose 可快速启动	低，单机 Docker 即可运行
社区活跃度	低，更新缓慢	高，月活贡献者多	高，增长最快
适合场景	已有 Hadoop 生态的大企业	互联网公司、数据中台	中小团队、快速落地

3.2.1 Apache Atlas：老牌选手，但有点重

Atlas 是 Hadoop 生态的元数据管理方案。它通过 Hook 机制监听 Hive、HBase、Sqoop 等组件的操作，自动采集元数据。如果你公司已经上了 CDH/HDP，用 Atlas 是顺理成章的事。

但说实话，Atlas 的部署太重了。HBase + Solr + Kafka 三件套，光搭环境就得一两天。而且它的 UI 比较老旧，查询响应也慢。我建议：除非你已经在 Hadoop 生态里，否则别碰 Atlas。

3.2.2 DataHub：现代、灵活、社区活跃

DataHub 是我目前最常用的框架。它的 Ingestion Framework 用 Python 写，支持 100+ 数据源。你写个 YAML 配置文件，跑一条命令就能把元数据采进来。

# DataHub 采集 MySQL 元数据的配置文件示例
source:
  type: mysql
  config:
    host_port: localhost:3306
    database: my_database
    username: datahub
    password: secret

sink:
  type: datahub-rest
  config:
    server: http://localhost:8080

然后执行：

datahub ingest -c mysql_recipe.yml

就这么简单。DataHub 的血缘解析也很强，能自动从 SQL 里提取输入输出表。我有个客户，用 DataHub 一周内就完成了 500+ 张表的元数据采集和血缘构建。

我的建议：如果你团队有 Python 基础，选 DataHub 准没错。它的文档清晰，社区响应快。我遇到过一次采集 Kafka Schema Registry 的问题，在 Slack 里提问，2 小时就有人回复了。

3.2.3 OpenMetadata：后起之秀，上手最快

OpenMetadata 是 2022 年才火起来的。它的最大优势是开箱即用。一条 Docker Compose 命令就能启动全套服务，包括 UI、API、Elasticsearch 和 MySQL。

# 启动 OpenMetadata
docker compose -f docker-compose.yml up -d

它的 UI 做得很好，非技术人员也能轻松浏览数据目录。而且 OpenMetadata 内置了数据质量模块，可以配置规则自动跑数据校验。这一点是 DataHub 和 Atlas 都没有的。

不过 OpenMetadata 的血缘能力还在追赶中。字段级血缘的准确率不如 DataHub。如果你对血缘要求极高，建议再等等。

3.3 选型决策建议

说了这么多，到底怎么选？我总结了一个简单的决策树：

已有 Hadoop 生态 → Apache Atlas（但要做好运维准备）
互联网公司，数据源多，要求血缘精准 → DataHub
中小团队，想快速落地，还要数据质量 → OpenMetadata
预算充足，不想自己运维 → 三个都有商业版，DataHub 的 Acryl 和 OpenMetadata 的 Collate

最后提醒一句：框架只是工具，元数据治理的核心是「用起来」。我见过太多团队花三个月搭好 Atlas，结果没人用，最后成了摆设。选一个能让你最快跑通端到端流程的框架，比选一个「功能最全」的框架重要得多。

嗯，这一章的内容就到这。元数据采集是数据治理的「地基」，地基不稳，上面盖什么都白搭。希望这些实战经验能帮你少走弯路。