4. 血缘元数据模型：存储选型与关系建模
这一章，我们来聊聊血缘分析的「地基」——元数据模型该怎么设计。
说实话，我见过不少团队，一上来就急着写血缘采集代码，结果数据量一上来，查询慢得像蜗牛，想追溯一条字段的来龙去脉要等几十秒。嗯，问题就出在元数据存储和关系建模上。
4.1 元数据存储选型：关系型 vs 图数据库
先问个问题：血缘关系本质上是什么？
说白了，它就是一张巨大的有向图。节点是表、字段、任务，边是数据流向。你想想看，用关系型数据库存这种多对多、多层嵌套的关系，会怎样？
| 对比维度 | 关系型数据库（MySQL/PostgreSQL） | 图数据库（Neo4j / JanusGraph） |
|---|---|---|
| 关系查询深度 | 3层JOIN开始卡顿，5层以上基本不可用 | 毫秒级遍历10层以上 |
| 模型灵活性 | 需要提前设计表结构，加字段要改DDL | 节点和边可以随时加属性 |
| 数据一致性 | 强ACID，适合事务场景 | 最终一致性为主，部分支持事务 |
| 运维复杂度 | 低，DBA普遍熟悉 | 较高，需要专门学习 |
| 典型场景 | 元数据基本信息存储 | 血缘关系查询、影响分析 |
我的建议：不要二选一，而是混合使用。用关系型数据库存元数据的「实体属性」（表名、字段类型、创建时间等），用图数据库存「关系拓扑」（谁依赖谁、数据怎么流转）。
我在项目中遇到过这样的坑：一开始只用MySQL存血缘关系，用递归CTE查上游链路。数据量到10万条边的时候，一次全链路查询要30秒。后来切到图数据库，同样的查询降到50毫秒。差距就是这么大。
4.2 血缘关系建模：节点、边与属性
模型怎么设计？我习惯从三个维度入手：节点、边、属性。
4.2.1 节点类型
- 数据源节点：数据库、表、字段、文件路径
- 计算节点：SQL任务、ETL脚本、数据管道
- 输出节点：报表、API、数据产品
4.2.2 边类型
- PRODUCES：任务产生数据表
- CONSUMES：任务读取数据表
- DERIVES_FROM：字段A由字段B计算而来
- DEPENDS_ON：任务B依赖任务A的输出
4.2.3 属性设计
每个节点和边都要带上足够的上下文，不然查出来也是一堆冷冰冰的ID。
// 节点属性示例
{
"id": "table_12345",
"type": "TABLE",
"name": "order_detail",
"database": "dw",
"schema": "public",
"owner": "data_team",
"created_at": "2024-01-15T10:30:00Z",
"row_count": 5000000,
"description": "订单明细表"
}
// 边属性示例
{
"source": "task_678",
"target": "table_12345",
"type": "PRODUCES",
"execution_time": "2024-01-16T02:00:00Z",
"record_count": 10000,
"status": "SUCCESS"
}
小技巧：属性里加上时间戳和状态，这样你可以回溯「某个时间点的血缘快照」，而不是只能看到最新状态。我曾经靠这个功能定位过一次数据回溯事故——发现某张表在凌晨3点被错误地覆盖了。
4.3 图数据库选型：Neo4j vs JanusGraph
选哪个？这得看你的场景。我两个都用过，说说我的感受。
| 特性 | Neo4j | JanusGraph |
|---|---|---|
| 存储引擎 | 自研Native存储 | 支持HBase、Cassandra、Bigtable |
| 查询语言 | Cypher（声明式，易上手） | Gremlin（函数式，灵活但陡峭） |
| 事务支持 | ACID，强一致性 | 最终一致性为主 |
| 水平扩展 | 企业版支持集群，社区版单机 | 原生支持分布式 |
| 部署复杂度 | 低，单机可跑 | 高，依赖外部存储和索引 |
| 社区生态 | 成熟，文档丰富 | 较窄，中文资料少 |
避坑指南：我曾经在一个项目里选了JanusGraph，因为看中它的分布式能力。结果团队里没人熟悉Gremlin，光是写一个「查询某表所有上游链路」的遍历就折腾了两天。后来换回Neo4j，同样的逻辑用Cypher三行搞定。所以，如果团队图数据库经验不足，别盲目追求分布式。
4.3.1 我的选型建议
- 团队小于10人，数据量在亿级以内：选Neo4j社区版。部署简单，Cypher好上手，出活快。
- 数据量百亿级以上，需要跨机房部署：选JanusGraph。但一定要配一个懂Gremlin的人。
- 如果你们公司已经有HBase或Cassandra集群：JanusGraph可以复用基础设施，省去多维护一套存储的成本。
4.4 核心知识体系
下面这张图，是我自己梳理的血缘元数据模型整体架构。你可以把它当作设计时的参考地图。
4.5 实战：用Cypher构建血缘查询
假设我们选了Neo4j，怎么查血缘？我直接给几个常用的查询模板。
4.5.1 查询某张表的所有上游
MATCH (t:Table {name: 'order_detail'})<-[:PRODUCES]-(task:Task)
OPTIONAL MATCH (task)-[:CONSUMES]->(upstream:Table)
RETURN task.name, upstream.name
4.5.2 查询字段级血缘链路
MATCH path = (f:Field {name: 'order_amount'})<-[:DERIVES_FROM*1..5]-(source:Field)
RETURN path
4.5.3 影响分析：如果下线某张表，会影响哪些下游？
MATCH (t:Table {name: 'raw_log'})-[:PRODUCES]-(task:Task)
MATCH (task)-[:PRODUCES]->(downstream:Table)
RETURN downstream.name, task.name
经验之谈：字段级血缘比表级血缘难维护得多。我建议先做表级，等流程跑通了再逐步下钻到字段级。别一上来就想搞大而全，容易把自己搞崩。
4.6 本章小结
嗯，这一章的内容就这些。核心就三件事：
- 存储选型要混合，别迷信单一方案
- 关系建模要分清楚节点、边、属性
- 图数据库选型看团队能力，别盲目追新