数据治理系列 第11篇 | 图文版
前面十篇一直在用它，这篇讲它本身——数据架构那条线的底座。

小李入职半年，第一次独立接需求。市场部要算客户生命周期价值，指名要"近三年有复购行为的活跃客户"。他先去第 9 篇上过户口的登记系统搜"客户"，出来二十多张表——表名都规规矩矩的，dwd_cust_basic_info、dws_cust_active_analysis，可哪张是"活跃客户"、活跃的口径是九十天还是一年，表上没写。

他挑了张看着像的，去找登记的责任人，人早调岗了。问小王，小王说"口径你得问市场部"。市场部说"你们中台最清楚"。绕了一圈，最后还是老周凭记忆告诉他：活跃客户有两张表，一张九十天口径一张年度口径，别用错了。

小李后来跟老周吐槽：我找数据花了一天半，最后靠的还是您脑子里那点东西。

老周没接话，第二天让助理盘了盘元数据的家底。结果不体面：登记系统里有表名、责任人、状态，是第 9 篇上户口攒下的；字段的业务含义散在数据库 comment 里，建表时写了一半，后来改表没人更新；指标口径在第 5 篇的标准系统里，但标准和表没挂上钩；血缘是第 10 篇上的，只覆盖了跑调度的任务。四个系统各管一块，拼不成一张完整的图。

元数据就是数据的全部背景信息：它叫什么、业务上怎么解释、从哪个系统抽的、下游谁在用、谁负责维护。数据本身是货，元数据是随货单据——单据丢了，货还在仓库里，但没人敢动。

对照前面十篇你会发现问题：华城不是没有元数据，是一直在零打碎敲地建——第 5 篇的数据标准是业务元数据，第 7 到 9 篇的分层、命名、表结构登记是技术元数据，第 9 篇的生命周期状态、第 10 篇的核心表标记是管理元数据。散在四个系统里，各管一段，谁也拼不出全貌。

还有一个认知值得放在前面：元数据不是文档，是设施。

文档是写给人看的，归档之后天然过期；设施是给系统调用的，得持续保鲜、接口可查。第 10 篇的 CI 检查、血缘拉取、评审看板，背后调用的全是元数据——元数据错了，那些机制跟着错。这个认知决定了建元数据的姿势：不是组织一次编纂，而是搭一套水电气。

管理上华城定了三条原则。

采集优先于登记——能自动采的绝不人工填，自动采占七成，人工补占三成，倒过来就干不成。消费驱动建设——先有消费场景，再补对应的元数据，没有消费场景的元数据，登记了也是烂尾。增量优先于存量——新表从建表那天起就被管住，存量老表按消费场景排优先级，慢慢补。

责任分工的要害在"随流程产生"。

技术元数据平台组自动采集；业务元数据数据管家在建表、变更流程中人工确认；管理元数据挂在流程上流转——评审打标、生命周期自动更新，人不额外干活，数据跟着流程自然沉淀。考核盯两个数：完整率说明填了，消费量才说明有用。一个只有完整率没有消费量的元数据系统，本质上是档案馆。

最想让你带走的是老周复盘会战时说的那句话："元数据是流水，不是存款。"靠运动攒下的，会自己漏光。华城两年前搞过百日会战，覆盖率一个月冲到九成，半年跌回三成多。后来靠机制——建表卡 CI、变更带评审、完整率进考核——基础项才稳在九成五。表每天都在新建、变更，元数据必须跟着日常运转走，指望一场运动管三年，不现实。

下篇讲元数据采集与数据血缘分析。这篇只讲了"采结构"，血缘那块只是点了下——表级血缘怎么从 SQL 里解析出来、字段级血缘怎么追、断了怎么排查，是第 12 篇的主角。小李绕的那一天半里，有一段本可以不用绕——他挑的那张表从哪来、谁在用，血缘图上扫一眼的事。

关注我，下篇接着聊。

场景演绎说明：本文中的"华城数据集团"及相关人物、场景均为虚构，旨在通过故事化方式帮助读者理解元数据管理的概念、分类与落地方法。

创作声明：本文核心思想和观点为作者原创，写作过程中借助AI工具进行辅助。