数据治理系列 第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工具进行辅助。