元数据管理怎么做？血缘到底有什么用？

面试进入 45 分钟后，架构深挖的第二道题通常是元数据。面试官想看的是：你有没有用过元数据系统、懂不懂血缘 / 影响分析 / 资产盘点这些场景、有没有自己主导过元数据治理。很多候选人能说出 Atlas / DataHub / Amundsen 这几个工具名，但讲不清楚『这东西解决的是什么问题』——这题的门槛就在这里。

业务场景：我在某元宇宙社交应用从零搭元数据系统

我在某元宇宙社交应用做 Flink + Doris 实时数据平台时，早期完全没有元数据系统——谁建了哪张表只能问人，下线老表不敢动因为不知道谁在用。后来我主导接入了 Apache Atlas + 自定义 Flink Hook，一个季度把 500+ 表和 200+ 任务全部盘进去，真正做到了『改表之前能看到下游』。

Plain

元数据系统的三大能力（我当时的建设路径）：
 
【Phase 1 资产盘点】（第 1 个月）
  - Hive / Doris 表元数据自动采集
  - 任务元数据（DataWorks / Flink Job）采集
  - 建立基础搜索：按表名 / 字段名 / owner 查
 
【Phase 2 血缘追踪】（第 2-3 个月）
  - SQL 解析 → 表级血缘
  - SQL 解析 → 字段级血缘
  - Flink Job → Source/Sink 血缘
 
【Phase 3 业务融入】（持续）
  - 接入 Code Review：改表前自动查下游影响
  - 接入告警：上游异常自动通知下游 owner
  - 接入下线流程：老表下线前强制看血缘

段落一：资产盘点——你到底有多少张表

没有元数据系统的团队通常说不清自己有多少资产。我在某元宇宙社交应用接手时第一次盘点扒出 543 张 Hive 表、189 个 Flink Job、2400 多个调度任务——其中 30% 过去 3 个月没被查询过、15% 的 owner 已经离职。这就是『隐性数据资产』，每一张都在耗存储和算力但没人用。

-- 资产盘点的关键查询（跑在元数据仓库上）
 
-- 查询 1: 无主资产
SELECT table_name, owner, last_modified
FROM meta_table
WHERE owner NOT IN (SELECT email FROM hr_active_employee);
 
-- 查询 2: 僵尸表（90 天没被查过）
SELECT m.table_name, m.owner, m.size_gb
FROM meta_table m
LEFT JOIN (
  SELECT DISTINCT target_table
  FROM query_log
  WHERE query_date >= DATE_SUB(CURRENT_DATE, 90)
) q ON m.table_name = q.target_table
WHERE q.target_table IS NULL
ORDER BY m.size_gb DESC;
 
-- 查询 3: 大表 Top 50（按存储排）
SELECT table_name, size_gb, owner, last_query_date
FROM meta_table
ORDER BY size_gb DESC LIMIT 50;

我的一次真实战果：那次盘点之后我们下线了 120 张僵尸表，省掉 80TB 存储；把 60 张无主表强制转移给现 owner，避免未来事故。这就是资产盘点的直接收益。

段落二：血缘追踪——从 SQL 里抠出血缘关系

血缘采集的核心是 SQL 解析。每当一个 SQL 执行时，解析它的 FROM / JOIN / INSERT INTO 子句，就能得到『输入表 → 输出表』的血缘关系。字段级血缘更进一步，追踪每个输出字段来自哪些输入字段。

Plain

-- 一条 SQL 及其血缘
 
INSERT INTO ads_gmv_daily
SELECT
  u.country,                  -- 血缘：dim_user.country
  o.dt,                       -- 血缘：fact_order.dt
  SUM(o.amount * r.rate)      -- 血缘：fact_order.amount + dim_fx_rate.rate
    AS gmv_usd
FROM fact_order o
JOIN dim_user u USING (uid)
JOIN dim_fx_rate r USING (currency)
GROUP BY u.country, o.dt;
 
表级血缘：
  ads_gmv_daily ← fact_order, dim_user, dim_fx_rate
 
字段级血缘：
  ads_gmv_daily.country ← dim_user.country
  ads_gmv_daily.dt      ← fact_order.dt
  ads_gmv_daily.gmv_usd ← fact_order.amount + dim_fx_rate.rate