数据越多越乱？真正让大数据平台失控的，可能不是数据，而是“没人知道数据是什么”

作者：Echo_Wish

很多公司做数据平台，都经历过一个非常相似的阶段：

刚开始，数据不多。

一个 MySQL、几个业务库，外加几个 Excel 文件，大家还能勉强记得：

“订单表在这里，用户表在那里，销售额去这个库查。”

后来业务起来了。

Kafka、Flink、Spark、Hive、ClickHouse、Doris、Elasticsearch、对象存储……一个个都接进来了。

数据湖建了，数据仓库建了，数据中台也建了。

最后出现一个非常尴尬的场景：

数据越来越多，但真正敢用数据的人反而越来越少。

为什么？

因为大家开始不知道：

这个字段是什么意思？

这个表是谁维护的？

这个数据到底准不准？

“订单金额”到底是含税金额还是未税金额？

“用户数”到底是注册用户、活跃用户，还是去重后的付费用户？

这个 status=1 到底代表正常、完成，还是有效？

这时候你会发现，大规模数据平台真正缺的，往往不是存储能力。

而是两个看起来特别不起眼的东西：

元数据（Metadata）和数据目录（Data Catalog）。

---

一、先说一个最扎心的问题：为什么“有数据”不等于“能用数据”？

我们假设公司现在有一张订单表：

CREATE TABLE orders (
    id BIGINT,
    user_id BIGINT,
    amount DECIMAL(18,2),
    status INT,
    create_time DATETIME
);

从开发人员角度看，非常简单。

但如果把这个表交给一个刚入职的数据分析师，他可能马上开始问：

• amount 是订单原价还是实付金额？
• 包含优惠券吗？
• 包含运费吗？
• 是人民币吗？
• status=1 是支付成功还是订单完成？
• create_time 是下单时间还是入库时间？
• user_id 是会员 ID 还是平台统一用户 ID？

你看。

数据库告诉你“这里有一个字段”，却没有告诉你“这个字段到底意味着什么”。

这就是元数据存在的价值。

简单理解：

数据是“东西”，元数据是“东西的说明书”。

比如：

数据：
orders.amount = 199.00

元数据：
字段名称：amount
中文名称：实付金额
数据类型：DECIMAL(18,2)
单位：元
是否含税：否
是否包含运费：是
业务定义：用户实际支付金额
数据负责人：订单中心
更新时间：实时

真正的大数据平台，不能只保存数据。

还必须保存“关于数据的数据”。

---

二、元数据到底是什么？别把它想得太复杂

很多人一听“元数据”，第一反应就是：

“这是不是又要搞一个特别复杂的平台？”

其实没那么玄乎。

我们每天都在接触元数据。

比如 Linux：

ls -lh orders.csv

你看到的：

-rw-r--r-- 1 root root 128M Sep 7 08:10 orders.csv

文件大小、权限、创建时间、修改时间，本质上都是元数据。

数据库里面也是一样：

SELECT
    table_name,
    column_name,
    data_type
FROM information_schema.columns
WHERE table_name = 'orders';

得到的：

orders | id          | bigint
orders | user_id     | bigint
orders | amount      | decimal
orders | status      | int
orders | create_time | datetime

这些就是典型的技术元数据。

但真正的大数据平台，需要的元数据远远不止这些。

通常可以分成几类。

1. 技术元数据

回答：

“数据长什么样？”

例如：

表名
字段名
字段类型
分区字段
索引
数据量
存储位置
更新时间

---

2. 业务元数据

回答：

“这些数据到底是什么意思？”

例如：

订单金额 = 用户实际支付金额
有效订单 = 支付成功且未取消的订单
活跃用户 = 过去30天至少登录一次的用户

这部分其实特别重要。

因为很多数据事故，并不是程序报错。

而是：

程序运行完全正常，但业务人员理解错了。

---

3. 管理元数据

回答：

“谁负责？”

比如：

数据Owner：订单中心
技术负责人：张三
业务负责人：李四
所属部门：供应链事业部
数据等级：重要

出现问题以后，至少知道找谁。

---

4. 运行元数据

回答：

“这份数据是怎么来的？”

例如：

MySQL
   ↓
Kafka
   ↓
Flink
   ↓
ODS
   ↓
DWD
   ↓
DWS
   ↓
BI Dashboard

这其实就是数据血缘。

---

三、没有数据目录的大数据平台，最后一定会变成“数据垃圾场”

我一直觉得，很多公司数据平台建设有一个非常明显的误区：

特别喜欢建表，却不喜欢管表。

今天业务部门说：

“我要一个订单宽表。”

建。

明天说：

“我要一个用户画像表。”

建。

后天：

“我要一个销售分析表。”

继续建。

一年下来：

dw_order
dw_order_new
dw_order_v2
dw_order_final
dw_order_final2
dw_order_final_new
dw_order_realtime
dw_order_realtime_v2
dw_order_analysis
dw_order_analysis_new

看到这里，是不是已经有点熟悉了？

更可怕的是，没人知道哪个是真的。

于是数据平台开始出现一种很奇怪的现象：

数据越多，沟通成本越高。

一个分析师想查“销售额”。

第一件事不是写 SQL。

而是去群里问：

“谁知道销售额应该查哪张表？”

然后可能得到三个答案：

A：查 dws_sales
B：我们现在都用 dws_sales_v2
C：别用这两个，昨天刚上线 sales_detail_new

这就是没有数据目录的后果。

---

四、数据目录解决的其实不是“查表”，而是“找答案”

一个真正的数据目录，不应该只是：

数据库
 └── 表
      └── 字段

如果只是这样，那充其量就是一个“高级版数据库客户端”。

真正的数据目录应该能够回答：

“我想找某个业务数据，应该去哪里找？”

比如搜索：

关键词：订单金额

系统返回：

数据资产：订单主题域

1. dws_order
   - 订单金额
   - 日更新
   - 数据Owner：订单中心

2. ads_sales_report
   - 销售金额
   - 实时
   - 数据Owner：数据中心

3. ods_order
   - 原始订单金额
   - T+1
   - 数据Owner：数据平台

甚至可以继续告诉你：

订单金额
   ↓
dwd_order_detail
   ↓
dws_order
   ↓
ads_sales_report
   ↓
销售大屏

这时候，数据平台才真正开始具备“知识”。

---

五、数据血缘为什么越来越重要？

假设老板发现：

“昨天销售大屏的金额怎么少了500万？”

传统运维可能这样排查：

数据库？
Kafka？
Flink？
Hive？
ClickHouse？
ETL？
BI？

一层一层查。

运维人员可能花几个小时。

但如果有完整的数据血缘，可以直接看到：

MySQL.orders
      ↓
Kafka.order_topic
      ↓
Flink.order_clean
      ↓
DWD_ORDER
      ↓
DWS_SALES
      ↓
ADS_SALES_REPORT
      ↓
BI Dashboard

然后发现：

Flink.order_clean
        ↓
status = 1

这个条件昨天被改成了：

status = 2

问题立刻定位。

这就是数据血缘最大的价值：

它让数据问题从“猜”变成“追”。

---

六、甚至代码本身，也应该成为元数据的一部分

比如我们有一段 ETL：

df = spark.sql("""
    SELECT
        user_id,
        SUM(amount) AS total_amount
    FROM dwd_order
    WHERE status = 1
    GROUP BY user_id
""")

df.write.mode("overwrite").saveAsTable("dws_user_amount")

表面上只是一个 Spark SQL。

但如果平台能够自动解析这段代码，就可以得到：

dwd_order.user_id
        ↓
dws_user_amount.user_id

dwd_order.amount
        ↓
SUM(amount)
        ↓
dws_user_amount.total_amount

dwd_order.status
        ↓
过滤条件

于是系统就知道：

dws_user_amount.total_amount
        来源：
dwd_order.amount

这就是所谓的字段级血缘。

相比“表级血缘”，它更细。

当然，字段级血缘实现起来也更麻烦，因为你需要解析 SQL、Spark SQL、Flink SQL，甚至 Python、Java 代码。

但从长期来看，非常值得。

---

七、元数据平台最重要的一个能力：影响分析

这是我认为元数据真正开始“值钱”的地方。

假设开发人员准备修改：

ALTER TABLE dwd_order
DROP COLUMN amount;

如果没有元数据平台：

执行。

然后某一天：

BI挂了
报表挂了
数据接口挂了
推荐系统挂了
财务对账也挂了

大家开始开会。

如果有数据血缘：

amount
 ↓
dws_order
 ↓
ads_sales
 ↓
销售日报
 ↓
BI

系统直接告诉你：

删除 amount 将影响 3 张表、2 个任务、4 个报表。

这时候开发人员就不会那么头铁了。

---

八、这也是为什么“大数据治理”最后一定会走向元数据治理

很多人理解的数据治理是：

数据质量
数据标准
数据安全
数据权限

其实这些事情背后，都离不开元数据。

例如数据质量：

def check_data(df):
    assert df["user_id"].notnull().all()
    assert (df["amount"] >= 0).all()

问题来了：

为什么 user_id 不能为空？

为什么 amount 不能小于0？

因为元数据里面定义了：

user_id:
  nullable: false

amount:
  nullable: false
  min: 0

于是数据质量规则可以自动生成。

再比如数据安全：

phone:
  security_level: sensitive

id_card:
  security_level: highly_sensitive

平台就可以自动识别：

phone
 ↓
敏感字段
 ↓
限制访问
 ↓
脱敏
 ↓
审计

你会发现：

元数据并不是数据治理中的一个边角料。

它更像是整个数据治理体系的“地基”。

---

九、从运维角度看，元数据甚至可以帮助做智能化运维

这一点特别有意思。

传统监控关注的是：

CPU
内存
磁盘
网络
JVM
Kafka Lag
数据库连接数

这些当然重要。

但是现代数据平台还应该关注：

数据有没有来？
数据有没有变？
数据是不是延迟了？
数据质量有没有下降？
这个数据异常会影响哪些业务？

例如：

if actual_count < expected_count * 0.8:
    alert(
        "订单数据量异常",
        level="P1"
    )

进一步：

if data_quality_score < 0.95:
    alert(
        "数据质量下降",
        affected_assets=get_downstream_assets()
    )

再往前走一步：

数据异常
   ↓
元数据
   ↓
血缘关系
   ↓
影响业务
   ↓
自动生成告警等级

于是告警不再只是：

“DWS任务失败。”

而可以变成：

“订单数据延迟32分钟，预计影响销售日报、库存分析和经营驾驶舱，共17个下游数据资产。”

这才是真正对业务有意义的告警。

---

十、那么一个真正靠谱的数据目录，应该长什么样？

我个人比较推荐把它设计成下面这个结构：

                    数据目录
                       │
        ┌──────────────┼──────────────┐
        ↓              ↓              ↓
     数据资产        元数据          数据血缘
        │              │              │
        ↓              ↓              ↓
     数据库/表       技术元数据       上游
     API/文件        业务元数据       下游
     Kafka Topic     管理元数据       字段级
        │              │
        └──────────────┼──────────────┘
                       ↓
                    数据治理
                       │
          ┌────────────┼────────────┐
          ↓            ↓            ↓
       数据质量      数据安全      数据运维

最核心的其实就一句话：

让每一份数据都有身份、有说明、有主人、有来源、有去向。

---

十一、但这里还有一个坑：元数据平台千万别做成“手工登记平台”

这是很多公司踩过的坑。

刚开始：

“大家把表信息登记一下。”

于是创建一个 Excel：

表名 | 字段 | 描述 | Owner | 更新时间

第一周：

100%

一个月后：

70%

三个月后：

30%

半年后：

没人维护。

最后元数据平台自己都变成了“脏数据”。

所以我的观点非常明确：

元数据一定要自动采集为主，人工补充为辅。

例如：

MySQL
   ↓
Schema Collector
   ↓
Metadata

Kafka
   ↓
Topic Collector
   ↓
Metadata

Hive / Spark
   ↓
SQL Parser
   ↓
Lineage

Flink
   ↓
Job Parser
   ↓
Lineage

然后再让业务人员补充：

业务定义
Owner
数据等级
使用场景
备注

这样才比较现实。

---

十二、我一直觉得：数据平台的终点，不是“存更多数据”

做数据平台几年以后，你会慢慢发现一个特别有意思的变化。

最开始大家比：

谁的集群大？

后来比：

谁的数据多？

再后来比：

谁的数据实时？

但真正到了大型企业，你会发现：

数据多并不代表数据资产多。

100TB 的垃圾数据，不如 1TB 的高质量数据。

10000 张没人知道用途的表，不如 1000 张定义清晰、有Owner、有血缘、有质量保障的表。

所以我越来越认同一个观点：

数据平台真正的核心竞争力，不是“存了多少数据”，而是“有多少数据能够被可信地找到、理解和使用”。

而元数据和数据目录，恰恰就是连接这一切的那根线。

---

最后：别等数据平台“乱成一锅粥”了，才想起来治理

如果你的公司现在只有几十张表，可能觉得：

“搞什么数据目录，太重了。”

确实。

但如果已经发展到：

1000+ 张表
100+ 个数据任务
几十个业务系统
Kafka + Flink + Spark + Hive + ClickHouse

还没有统一的元数据体系，那我建议尽早开始。

不需要一上来就搞一个“宇宙级数据治理平台”。

可以先做三个东西：

第一，统一数据资产登记。

表 → 字段 → Owner → 业务定义

第二，自动采集元数据。

数据库
Kafka
Hive
Flink
Spark
API

第三，建立数据血缘。

Source
  ↓
ODS
  ↓
DWD
  ↓
DWS
  ↓
ADS
  ↓
BI

然后逐步把：

数据质量
数据安全
数据权限
影响分析
智能告警

全部建立在元数据之上。

因为到了大规模数据平台阶段，真正可怕的已经不是：

“我没有数据。”

而是：

“我有一大堆数据，但我不知道哪个是真的、谁负责、从哪来的、改了会影响什么，更不知道能不能放心用。”

这时候，数据就不再是资产了。

它只是堆在数据湖里的数字。

而元数据和数据目录真正要解决的，就是把这些“数字”，重新变成企业真正可以理解、管理和使用的数据资产。

—— Echo_Wish