第2章 元数据混乱：一个互联网公司的真实困境

这一章咱们来聊聊真实发生过的事。我接手这个项目的时候，客户的数据平台已经跑了三年多。业务侧天天催数，数据团队天天加班补坑。表面看是数据质量差，往里一挖——元数据乱得没法看。

你是不是也遇到过这种情况？

• 查一个表名，得问三个人才知道它到底存了什么
• 业务口径对上个月和这个月居然不一样
• 跑了半天的ETL，结果发现源头字段已经改了名字

嗯，这就是元数据失控的信号。这一节我会把当时的场景完整复盘，带你看看混乱到底长什么样。

背景：快速扩张下的数据沼泽

这家公司是做电商+社交裂变的，日活千万级。三年里团队从10个人膨胀到200人。数据仓库从一张宽表变成了3000多张表，数据源从MySQL扩展到了Kafka、Hive、HBase、Elasticsearch，中间还有十几套自研的微服务。

业务迭代快，每周都有新需求。开发为了赶进度，直接往Hive里建表，表名随便起，字段类型凭感觉选。数据字典？没人维护。血缘关系？没人理。

我接手时看到的第一份元数据快照是这样的：

表名：tmp_order_20210803_v2
注释：临时表
字段：id bigint, uid string, amount double
实际情况：uid 存的是订单号，amount 存的是折扣后金额，id 重复且无主键

这样的表，整个平台里有四百多张。光看名字，你根本猜不出它是什么。

元数据混乱的典型表现

我花了两周时间，把线上能收集到的元数据梳理了一遍。问题集中在四个维度：

维度	典型症状	影响范围
表命名	无统一规范，tmp_、test_、bak_ 泛滥	300+ 无效临时表
字段口径	同一字段在不同表里含义不同	80% 的报表对不上
血缘关系	数据从哪来、经过哪些转换完全黑盒	每次排错需要人工追溯
生命周期	无过期策略，僵尸表长年不清理	占用 40% 的存储资源

我曾经遇到过一个案例：业务方要算“当天支付用户数”。数据产品从三个不同入口取数，结果分别是 12.3 万、8.7 万、15.1 万。谁也说不清哪个是对的。最后查了半个月，发现有的统计去了重，有的没去；有的只算了成功支付，有的算了包括退款的。这就是口径混乱的典型结果。

混乱带来的连锁反应

元数据乱，不只是找数据费劲。它会一层层传导到整个数据体系：

你看看，是不是一个螺旋下降的循环？我印象最深的是有一次线上事故：运营临时要一份用户画像数据，数据团队花了三天写了一个临时ETL脚本。结果脚本里引用的一个Hive表已经被删除了——因为那张表没有元数据标记，系统自动清理了“过期”数据。运营没拿到数据，业务决策延误，直接损失了几十万的营销预算。

根源分析：为什么元数据会失控

很多人以为元数据乱是工具不好用，或者开发懒。我个人习惯先找系统性问题，而不是怪个人。复盘下来，三个根因很典型：

• 缺乏入口管控：任何人都能通过Hue或Beeline直接建表，没有审批流程，没有命名规范校验。
• 元数据存储分散：Hive Metastore存了表结构，但业务字典藏在Wiki里，血缘信息埋在代码注释里，数据质量规则散落在各个监控脚本里。
• 认知断层：数据开发只管写SQL，业务方只管提需求，中间没有一个人对元数据治理负责。

你想想看，这三个问题放到一起，是不是很像一个定时炸弹？

我当时在现场给CTO拉了一张图，把混乱的影响范围画了出来——

该怎么破局？——先认清问题全貌

讲到这里，你可能觉得问题很严重。没错，确实很严重。但好消息是，只要把问题拆开、理清，治理路径就出来了。说白了，元数据治理不是技术难，而是管理难、规范难、持续难。

我之前带过的一个组，在“最乱”的平台上先做了三件小事：

• 停掉所有无审批建表权限（先止血）
• 用两天时间把所有临时表打上标签（先看清楚）
• 定义核心表的字段口径文档（先对齐口径）

就这三步，三个月后数据平台的“找表时间”从平均2小时降到了15分钟。你觉得神奇？其实不是工具厉害，而是把元数据这个“隐性资产”显性化了。