4. 血缘存储与建模：图数据库选型与图谱设计
好，咱们进入第四章节。前面几章我们聊了为什么要做血缘分析，以及怎么采集数据。现在问题来了——采集到的血缘关系，到底存哪儿？怎么存？
我见过不少团队，上来就用 MySQL 硬扛血缘关系。结果呢？三个月后查询一次要几十秒，半年后直接跑崩了。说白了，血缘关系天然就是一张图——表与表之间、字段与字段之间，本质上是多对多的网状结构。用关系型数据库存图，就像用记事本写《红楼梦》，不是不行，但你会疯掉。
4.1 图数据库选型：Neo4j vs JanusGraph
目前主流的图数据库，我重点推荐两个：Neo4j 和 JanusGraph。它们代表了两种不同的设计哲学。
| 对比维度 | Neo4j | JanusGraph |
|---|---|---|
| 存储引擎 | 自研 Native 存储（.db 文件） | 依赖外部后端（HBase / Cassandra / BerkeleyDB） |
| 查询语言 | Cypher（声明式，上手快） | Gremlin（函数式，灵活但陡峭） |
| 事务支持 | ACID，强一致性 | 最终一致性（取决于后端） |
| 水平扩展 | 只支持读扩展，写节点单点 | 原生支持分布式，可横向扩写 |
| 部署复杂度 | 单机部署，5 分钟搞定 | 需要搭 Hadoop / HBase 全家桶 |
| 社区生态 | 成熟，文档丰富 | 相对小众，踩坑得自己填 |
我的选型建议：
- 如果你的血缘数据量在 10 亿条边以内，团队图数据库经验不多——选 Neo4j。我手头三个项目都用它，稳得很。
- 如果数据量超过百亿，或者需要跨机房写入——选 JanusGraph。但要做好运维投入翻倍的准备。
我个人习惯是：先用 Neo4j 快速验证血缘模型，等数据量真的撑不住了，再考虑迁移到 JanusGraph。别一开始就上分布式，你想想看，大部分公司的血缘数据量，Neo4j 单机完全扛得住。
4.2 血缘图谱的节点与边设计
图数据库选好了，接下来就是建模。这是最见功力的地方。我见过最离谱的设计——把所有东西都塞进一个节点类型，然后靠属性区分。结果查询时全表扫描，比 MySQL 还慢。
正确的做法是：节点代表实体，边代表关系。咱们的血缘图谱，核心就两类节点、三类边。
4.2.1 节点设计
| 节点类型 | Label | 核心属性 | 示例 |
|---|---|---|---|
| 数据表 | :Table |
database, schema, tableName, owner, createTime | ods.order_info |
| 数据字段 | :Column |
columnName, dataType, comment, nullable | order_id |
| ETL 任务 | :Task |
taskName, jobType, schedule, owner | dwd_order_daily |
避坑指南：我曾经把 Table 和 Column 合并成一个节点，用属性区分。结果查询「某张表有哪些字段」时，需要先查出表节点，再过滤属性，性能惨不忍睹。后来老老实实拆成两个 Label，查询速度提升了 10 倍。
4.2.2 边设计
边是血缘的灵魂。我设计了三类核心边：
:PRODUCES— 从 Task 指向 Table，表示「这个任务产出了这张表」。:CONSUMES— 从 Table 指向 Task，表示「这个任务读取了这张表」。:LINEAGE— 从 Column 指向 Column，表示「字段 A 来源于字段 B」。这是最细粒度的血缘。
举个例子，一个简单的 ETL 流程：
// 创建节点
CREATE (t1:Table {name: "ods.order_raw", database: "ods"})
CREATE (t2:Table {name: "dwd.order_clean", database: "dwd"})
CREATE (task:Task {name: "clean_order_job", owner: "data_team"})
// 创建边
CREATE (task)-[:PRODUCES {runTime: "2024-01-15 02:00:00"}]->(t2)
CREATE (t1)-[:CONSUMED_BY {runTime: "2024-01-15 02:00:00"}]->(task)
// 字段级血缘
CREATE (c1:Column {name: "order_id", table: "ods.order_raw"})
CREATE (c2:Column {name: "order_id", table: "dwd.order_clean"})
CREATE (c1)-[:LINEAGE {transform: "直接映射"}]->(c2)
注意：边上的属性不要乱加。我见过有人在边上挂了 20 多个属性，查询时每条边都要反序列化，性能直接腰斩。边属性只放查询时一定会过滤的字段，比如时间戳、转换类型。其他信息存到节点上。
4.3 时间戳版本管理
血缘关系是会变的。今天表 A 依赖表 B，明天可能就改成依赖表 C 了。如果不做版本管理，你查到的血缘永远是「当前快照」，回溯历史问题时会一头雾水。
我常用的方案是边时间戳 + 快照表双保险。
4.3.1 边时间戳方案
每条边都带上 validFrom 和 validTo 两个属性：
// 创建带版本的血缘边
CREATE (c1:Column {name: "user_id", table: "ods.user"})
CREATE (c2:Column {name: "user_id", table: "dwd.user_profile"})
CREATE (c1)-[:LINEAGE {
validFrom: "2024-01-01",
validTo: "9999-12-31",
transform: "直接映射"
}]->(c2)
// 查询某个时间点的血缘
MATCH (c1)-[r:LINEAGE]->(c2)
WHERE r.validFrom <= "2024-06-01"
AND r.validTo >= "2024-06-01"
RETURN c1, c2, r
这个方案的好处是查询快，坏处是每次变更都要更新旧边的 validTo，再创建新边。写入逻辑稍微复杂一点。
4.3.2 快照表方案
如果你不想动图数据库的边结构，可以单独建一张快照表：
| 字段 | 类型 | 说明 |
|---|---|---|
| snapshot_id | string | 快照版本号，如 snap_20240115 |
| snapshot_time | timestamp | 快照生成时间 |
| edge_json | text | 该时间点所有血缘边的 JSON 序列化 |
| node_json | text | 该时间点所有节点属性的 JSON |
每天凌晨跑一次全量快照，存到 HDFS 或对象存储里。查询历史血缘时，直接加载对应时间点的快照到内存分析。
我的实践经验：
- 日常查询用边时间戳方案，响应时间控制在 200ms 以内。
- 历史回溯用快照方案，虽然加载慢一点（几秒到几十秒），但能保证数据完整。
- 两个方案并行跑，互不干扰。
4.4 整体架构图
下面这张图，是我在项目中沉淀下来的血缘存储架构。你照着搭，基本不会走弯路。
嗯，这张图基本把咱们这章的核心内容串起来了。从采集层进来，数据落到图数据库做实时查询，同时快照存储做历史回溯。节点和边按标准设计，版本管理双保险。这套架构我在两个日活千万级的平台上验证过，稳得很。
最后说一句：图数据库选型没有银弹。Neo4j 适合快速迭代、团队经验不足的场景；JanusGraph 适合海量数据、有分布式运维能力的团队。别盲目追新，够用就好。