4. 元数据管理基础：元数据的分类、采集与工具选型
聊数据湖质量，绕不开元数据。我见过太多团队，一上来就搞规则引擎、搞监控告警，结果连表是谁建的、字段含义是什么都说不清楚。说白了，元数据就是数据的“说明书”。没有它，质量监控就是盲人摸象。
这一章，我们就把元数据这件事掰开揉碎。我会结合自己踩过的坑，聊聊分类、采集、存储，以及两个主流工具——Apache Atlas 和 DataHub。
4.1 元数据的三大分类
元数据不是铁板一块。我个人习惯把它分成三类：技术元数据、业务元数据、管理元数据。你想想看，这三类分别回答了三个问题：数据长什么样？数据什么意思？数据怎么管的？
| 分类 | 核心问题 | 典型内容 | 我见过的坑 |
|---|---|---|---|
| 技术元数据 | 数据长什么样？ | 表结构、字段类型、分区信息、存储路径、ETL 依赖 | 字段类型变更没通知，下游任务全挂 |
| 业务元数据 | 数据什么意思？ | 业务定义、指标口径、数据字典、质量规则 | 口径不一致，两个部门对“活跃用户”定义不同 |
| 管理元数据 | 数据怎么管的？ | 负责人、创建时间、访问权限、数据等级、生命周期 | 离职员工的数据资产没人认领，变成僵尸表 |
关键认知： 三类元数据必须联动。技术元数据告诉你表在哪，业务元数据告诉你表里字段是啥意思，管理元数据告诉你谁能碰。缺一环，质量监控就瘸腿。
4.2 元数据采集与存储
采集元数据，听起来高大上，其实就三步：发现 → 解析 → 注册。
我在项目中遇到过最头疼的事——采集器把 Hive 表结构拉下来了，但字段注释全是空的。为什么？因为建表时就没写 COMMENT。所以，采集之前，先得把规范定好。
4.2.1 采集方式
- Hook 模式：在 Hive/Spark 等引擎上挂载监听器，DDL 操作发生时自动捕获。实时性好，但侵入性强。
- 轮询模式：定时扫描元数据库（如 Hive Metastore、MySQL information_schema）。简单稳定，但有延迟。
- 日志解析：从审计日志或事件流（如 Kafka）中提取元数据变更。适合大规模集群，但解析成本高。
我的建议： 小团队先用轮询模式，成本低、好维护。等数据湖规模上来了，再上 Hook + 日志解析的组合拳。
4.2.2 存储选型
元数据存哪？我见过用 MySQL 的、用 Elasticsearch 的、用图数据库的。各有优劣。
| 存储方案 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| 关系型数据库（MySQL） | 成熟、事务支持好 | 关系查询慢，扩展性差 | 小规模、元数据量 < 10万 |
| 搜索引擎（ES） | 全文检索快 | 关联查询弱，更新成本高 | 搜索型场景，如数据地图 |
| 图数据库（Neo4j） | 血缘关系查询极快 | 运维复杂，学习曲线陡 | 大规模血缘分析 |
| 专用元数据平台（Atlas/DataHub） | 开箱即用，功能完整 | 较重，需要额外部署 | 企业级数据湖治理 |
避坑指南： 我曾经在一个项目里用 MySQL 存了 50 万张表的元数据，结果血缘查询一次要 30 秒。后来切到图数据库，秒级返回。选型时一定要考虑查询模式，别等性能炸了再换。
4.3 Apache Atlas 与 DataHub 简介
这两个是目前最主流的开源元数据平台。我两个都用过，说说我的感受。
4.3.1 Apache Atlas
Atlas 是 Hadoop 生态的老牌选手。它深度集成 Hive、HBase、Kafka 等组件，核心能力是数据分类和血缘追踪。
- 架构：基于 Kafka 做事件通知，用 JanusGraph 做图存储。
- 优势：与 Hadoop 生态无缝对接，权限模型成熟（基于 Apache Ranger）。
- 劣势：UI 比较老旧，二次开发门槛高，社区活跃度不如以前。
我记得有一次帮客户做 POC，Atlas 自动抓取了 Hive 的血缘关系，但 Spark SQL 的血缘死活出不来。后来发现是 Atlas 的 Spark 钩子版本不兼容。嗯，这里要注意，版本匹配很重要。
4.3.2 DataHub
DataHub 是 LinkedIn 开源的新一代元数据平台。它更轻量、更现代化，核心是元数据模型和实时 ingestion。
- 架构：基于 Kafka + MySQL/Elasticsearch，提供 REST API 和 GraphQL 接口。
- 优势：UI 漂亮，文档清晰，支持自定义元数据模型，社区活跃。
- 劣势：对 Hadoop 生态的深度集成不如 Atlas，血缘解析依赖插件。
选型建议： 如果你的数据湖以 Hadoop/Hive 为主，选 Atlas；如果技术栈偏现代（Kafka、Spark、Flink、数据湖格式），选 DataHub。我现在的团队两个都部署了，Atlas 管离线数仓，DataHub 管实时数据湖。
4.4 元数据与质量监控的联动
元数据不是摆设。它直接支撑质量监控的三大能力：
- 自动发现监控对象：从元数据中读取表列表、分区信息，自动生成监控任务。
- 血缘驱动的根因分析：质量告警后，顺着血缘图找到上游问题节点。
- 业务语义增强告警：把技术指标（如空值率）映射到业务指标（如“用户手机号缺失”），告警更可读。
下面这张图，是我在项目中总结的元数据与质量监控的协作流程。
4.5 小结
元数据管理，说白了就是给数据湖建“户口本”。技术元数据管结构，业务元数据管含义，管理元数据管权限。采集方式选轮询还是 Hook，看你的规模和实时性要求。存储选 MySQL、ES 还是图数据库，看你的查询模式。工具选 Atlas 还是 DataHub，看你的技术栈。
我个人觉得，元数据这件事，越早做越好。别等到数据湖里堆了几千张表、几百个任务，再回头补，那成本就高了。嗯，这一章就到这里，内容不少，但都是实战中摸爬滚打出来的经验，希望对你有帮助。