夜雨聆风先讲个场景。一家大厂的数据团队，数仓里躺着 2000 多张表，ETL 任务跑得稳稳当当，监控大盘绿油油一片。但每周至少三次，业务方跑过来问同一句话——这个字段到底什么意思？
缺的不是表，是元数据。缺的不是平台，是有人在维护的元数据。
这不是个例。我见过太多团队——上了 Atlas，接了血缘，采了元数据，然后觉得「治理完成了」。半年后回头看，业务元数据字段空空如也，owner 已离职，口径早就变成薛定谔的口径。元数据平台成了一个昂贵的墓碑。
今天把元数据拆开来讲清楚：它是什么，分几类，怎么搞，搞完怎么用。顺便把我实际在用的工具清单和模板示例也一并交出来。
本文看点
01
元数据不是数据字典，是数据的说明书
02
业务元数据必须人工校对，自动采集靠不住
03
不做消费的元数据，全是成本
01
UNDERSTAND
元数据是数据的说明书，不是数据字典
DAMA-DMBOK 把元数据管理列为数据管理十一大知识领域之一，定位很明确——元数据是各数据管理职能的粘合剂和通用语言。翻译成大白话，元数据回答五个问题。
有什么数据？数据什么意思？能不能用？从哪来？谁负责？
这五个问题串起来，就是元数据的全部价值。它不是数据字典——数据字典只是元数据的一个子集，而且是其中最静态、最没技术含量的那个子集。
很多人理解的元数据就是「表结构文档」，这是严重低估。一份真正的元数据体系，应该让一个刚入职的数据开发，不用问任何人，就能知道有什么数据、数据什么意思、能不能用、从哪来、谁负责。
02
CLASSIFY
三类元数据：搞法完全不同
元数据分三类，但搞法天差地别。
技术元数据：自动采集，骨架先行
技术元数据是 ETL 工程师最熟悉的那层——表结构、字段类型、分区信息、存储格式、血缘依赖。这层目前自动化程度最高，Hive Metastore 挂一下，Atlas 或 DataHub 的 hook 接一下，血缘图就出来了。
大部分团队做元数据，止步于此。技术元数据能告诉你表长什么样，但告诉不了你数据是什么意思。这是骨架，不是血肉。
业务元数据：必须人工校对，必须来自业务知识输入
这是今天最想讲清楚的观点。
业务元数据包含字段含义、计算口径、业务 owner、数据分级、业务域归属。它的唯一可靠来源，是业务方的知识输入——不是数据开发拍脑袋写注释，不是 DBA 翻旧文档，更不是指望 AI 从字段名自动推断含义。
「业务元数据不是采出来的，是校出来的。它的唯一可靠来源是业务方的知识输入——让实际用这个数据的人来定义：这个字段在我们的业务场景里到底是什么意思。」
为什么自动采集不靠谱？我踩过这个坑。当时团队上了元数据平台，想着从 SQL 注释里自动提取字段含义，结果发现 is_valid 的注释写的是「是否有效」，两年前写的，owner 已经转岗。字段名叫 amt 的，你猜是金额还是数量？自动推断的准确率，说好听叫差强人意，说难听就是看起来很智能，实际没法用。
具体做法：建表审批环节，业务方必须填写字段含义和计算口径，数据开发只做技术审核——类型、分区、存储格式。不填不通过，填了不校对不算完。
操作元数据：自动采集运行信息，人工设定 SLA 阈值
操作元数据管的是任务产出时间、SLA、延迟、依赖链路。运行信息可以自动采集——调度系统的任务日志接入就行。但 SLA 阈值必须人工设定，而且要和业务方共识。
不是你数据开发说「早上 8 点出」就算达标。业务方 9 点开会，8 点出和 10 点出在业务方眼里没区别。SLA 的定义权在消费侧，不在生产侧。
| 业务元数据 | 人工校对为主，自动采集不可靠 | |
03
COLLECT
采集：能自动的自动，该人工的人工
落地第一步是采集。三条线并行。
技术元数据线：Hive Metastore → 元数据平台（Atlas/DataHub）→ 血缘图生成。这条线现在很成熟，唯一需要注意的是 Hive 外部表的元数据是个盲区——表删了 HDFS 数据还在，但元数据已经没了。最好在采集层做个补扫。
业务元数据线：这是整条链路里最需要设计的地方。我的建议是半自动流程：
建表时，系统自动生成元数据模板——表名、字段列表、分区信息已自动填入
业务方在审批环节填写：每个字段的含义、计算口径、业务 owner
数据开发技术审核通过后，表才能建
字段变更时，自动触发业务元数据复审通知
核心逻辑：技术元数据自动填，业务元数据人工填，缺一不可。
▍附：元数据模板示例（可直接抄去用）
上面说的「系统自动生成元数据模板」长什么样？下面两张是我实际在用的表结构，建表审批时强制填写，业务方照着填就行。重点看字段含义 + 计算口径这两列——这正是自动采集永远搞不定的部分。
表一 · 业务元数据登记表（建表 / 变更审批用）
这张表为什么重要？amt 和 qty 的命名混淆是真实高频坑。强制 owner 填「字段含义 + 计算口径」，比任何从字段名自动推断都靠谱。命名烂可以忍，含义和口径不写清，下游一定会踩。
表二 · SLA 登记表（产出时效共识用）
SLA 的定义权在消费侧。这张表是业务方和数据开发「签字画押」用的——不填不排期，填了不达标就升级。它解决的就是「你说 8 点出，业务方 9 点才用」的错位。
操作元数据线：调度系统（Airflow / DolphinScheduler / 自研）任务日志接入，自动采集产出时间、运行时长、依赖关系。SLA 阈值由业务方和数据开发共同设定，写入元数据平台（即上面的表二）。
04
MAINTAIN
管理：不维护就是死数据
元数据平台上线只是开始。不维护的业务元数据，三个月后就是死数据。
我见过一个案例：核心交易表的字段含义，owner 填的是三年前的定义，中间经历了两次口径变更，一次都没更新过元数据。下游业务方早就自己重新定义了，两边口径打架，每次对数据都要来回扯皮。
三个落地策略。
建表审批强制填写。owner + 字段含义是必填项，不填不通过。这个门槛立住了，业务元数据才有存量。
变更自动触发复审。字段类型变更、计算口径变更、owner 变更，自动通知所有下游消费方，要求确认。不是「通知一下就算了」，是「不确认就升级告警」。
元数据健康分。字段注释覆盖率、owner 有效比例（在职且未转岗）、业务元数据完整度、复审及时率。四项指标挂到团队看板，每月 review。没有度量的治理，最后都会变成「感觉做得不错」。
业务元数据必须定期复审。跟业务方确认口径是否仍然有效，至少每季度一次。不是不信任，是业务会变，口径会变，人会走。
05
TOOLING
工具：少造轮子，选对就赢
前面讲采集、管理、消费，真正把这些动作跑起来的杠杆是工具。很多人一上来就自研，我劝你先看看开源——元数据这摊事，已经被前人踩得挺透了。
给一张选型图，后面直接说我的判断。
工具只解决「技术元数据自动采 + 血缘」，业务元数据照样得人填——别指望上了一套平台，治理就自动完成了。
我的选型建议，三条：
中小团队直接起 DataHub 或 OpenMetadata。两者都是现代架构（元数据即图 / 即事件），模型贴合 DAMA，社区活跃。自研一套元数据平台，半年起步，且大概率做不过社区。
看重血缘选 Atlas，看重「找数体验」选 Amundsen。Atlas 和 Hadoop 生态集成最深；Amundsen 的搜索/发现体验最贴近业务方心智。两者不冲突，很多团队 Atlas 采血缘、Amundsen 做发现层。
健康分没有现成，得按团队 KPI 自研几个指标。注释覆盖率、owner 有效比例、业务元数据完整度、复审及时率——这四个前面第四章讲过，工具不替你想，得自己落。
一句话提醒：选型别追新。先把「技术元数据自动采 + 业务元数据强制填」跑通，比换三套平台都管用。工具是放大器，不是补药。
06
CONSUME
消费：不做消费，前面的全是成本
元数据的价值不在「存」，在「用」。三个典型消费场景。
数据发现
业务方自己搜「GMV 相关表」，能搜到、能看懂、能直接判断能不能用。不再需要问数据开发「这个表是干嘛的」。这是元数据最基础的消费场景，省掉的是重复沟通成本，ROI 最直观。
影响分析
上游表改字段，血缘图自动列出所有下游依赖，自动发通知。不再需要「改之前先问一圈」。这个场景在表数量超过 500 张时，价值呈指数级增长。
AI 底座
这是元数据在 AI 时代最重要的消费场景。NL2SQL 智能问数，需要元数据做 context——没有元数据，AI 不知道有哪些表、字段什么意思、口径怎么定义，问数就是瞎猜。RAG 知识库的底座也是元数据。
错误的业务元数据在 AI 场景下是灾难——AI 会信心十足地基于错误口径给出错误答案，而你甚至不知道它错了。这就是为什么业务元数据必须人工校对：不是为了「规范化」，是为了在 AI 消费场景下不出事。
∞
EPILOGUE
总结
元数据治理不是买平台，不是写文档，是建能力——采集、管理、消费的闭环。
技术元数据自动采集，这是骨架。业务元数据人工校对，这是血肉。操作元数据自动采集 + 人工设定 SLA，这是脉搏。三样都做了，元数据才有生命力。
上了元数据平台只是开始，没人维护的业务元数据等于死文档。
你们团队元数据做到哪一层了？技术元数据自动采了？业务元数据有人校对了？还是都还没开始？评论区聊聊。
如果你觉得今天这篇有收获，欢迎 点赞、在看、转发 三连，我们下篇见。