4、数据血缘的存储与建模：图数据库选型与元模型设计

数据血缘，说白了就是一张大网。表跟表怎么来的，字段跟字段怎么传的，中间经过了什么加工——这些关系天然就是图结构。用关系型数据库去存，你会发现自己一直在做递归查询，性能惨不忍睹。我刚开始做血缘项目时，就踩过这个坑。

所以这一章，我们聊聊怎么存、怎么建模。核心就三件事：选哪个图数据库、元模型怎么设计、节点和关系怎么定义。

4.1 图数据库选型：Neo4j vs JanusGraph

市面上图数据库不少，但真正在生产环境大规模落地血缘的，主流就两个：Neo4j 和 JanusGraph。我两个都用过，各有各的脾气。

对比维度	Neo4j	JanusGraph
存储引擎	自研 Native 图存储	后端可插拔（HBase、Cassandra、Bigtable）
查询语言	Cypher（声明式，上手快）	Gremlin（遍历式，灵活但陡峭）
事务支持	ACID，强一致	最终一致性（取决于后端）
水平扩展	只读副本，写节点单点	原生分布式，支持多区域
部署复杂度	单机或集群，运维简单	依赖外部组件，运维重
血缘场景适配	中小规模（亿级节点以内）	超大规模（十亿级以上）

4.2 血缘元数据模型设计

模型设计是灵魂。设计得好，查询一条 SQL 搞定；设计得不好，写 50 行 Gremlin 还查不全。

我习惯把血缘元模型分成三层：

• 基础设施层：数据源、数据库、集群、环境信息
• 实体层：表、视图、字段、存储过程、ETL 任务
• 关系层：字段级血缘、表级血缘、任务依赖、数据流转

嗯，这里要注意：实体层和关系层要分开建模。别把属性塞到关系里，也别把关系当成节点。我见过有人把「字段映射」做成节点，结果图里一半都是这种中间节点，查询性能直接崩了。

4.2.1 节点定义

节点就是实体。每个节点必须有全局唯一 ID，我推荐用 type:qualifiedName 的格式。举个例子：

// 表节点
{
  "id": "table:hive.default.sales_order",
  "type": "table",
  "name": "sales_order",
  "database": "default",
  "engine": "hive",
  "owner": "data_team",
  "created_at": "2024-01-15T10:00:00Z"
}

// 字段节点
{
  "id": "column:hive.default.sales_order.order_id",
  "type": "column",
  "name": "order_id",
  "dataType": "string",
  "parentTable": "hive.default.sales_order",
  "isPrimaryKey": true
}

// ETL 任务节点
{
  "id": "task:airflow.daily_sales_etl",
  "type": "etl_task",
  "name": "daily_sales_etl",
  "schedule": "0 2 * * *",
  "owner": "etl_team",
  "lastRunTime": "2024-06-20T02:15:00Z"
}

4.2.2 关系定义

关系是血缘的核心。我归纳了 5 种最常用的关系类型：

关系类型	起点	终点	说明
LINEAGE	字段/表	字段/表	数据流向，核心血缘关系
BELONGS_TO	字段	表	字段所属的表
DERIVED_FROM	表/视图	ETL 任务	数据产出来源
DEPENDS_ON	ETL 任务	ETL 任务	任务上下游依赖
CONTAINS	数据库	表	库与表的包含关系

每条关系也可以带属性。比如 LINEAGE 关系上，我会记录：

• transformExpression：转换逻辑（比如 substr(name,1,10)）
• confidence：血缘置信度（自动解析 vs 人工标注）
• updatedAt：最近一次更新时间

4.3 核心模型：字段级血缘的图结构

字段级血缘是最细粒度、也是最有价值的部分。我直接给一个实际项目中的模型示例：

// Neo4j Cypher 创建示例
CREATE (source:Column {id: "column:mysql.ods.user.name", name: "name"})
CREATE (target:Column {id: "column:hive.dwd.user_dim.user_name", name: "user_name"})
CREATE (etl:ETLTask {id: "task:spark.user_etl", name: "user_etl"})

CREATE (source)-[:LINEAGE {
    transform: "trim(name)",
    confidence: 0.95,
    updatedAt: "2024-06-20"
}]->(target)

CREATE (target)-[:DERIVED_FROM]->(etl)
CREATE (source)-[:BELONGS_TO]->(:Table {id: "table:mysql.ods.user"})
CREATE (target)-[:BELONGS_TO]->(:Table {id: "table:hive.dwd.user_dim"})

你想想看，有了这个结构，查「user_name 字段从哪里来」就很简单了：

// 查询字段上游血缘
MATCH (c:Column {id: "column:hive.dwd.user_dim.user_name"})
<-[:LINEAGE]-(source:Column)
RETURN source.name, source.id

// 全链路追踪
MATCH path = (c:Column {id: "column:hive.dwd.user_dim.user_name"})
<-[:LINEAGE*1..5]-(source)
RETURN path

4.4 知识体系总览

下面这张图，把本章的核心逻辑串起来了。你可以看到从选型到建模的完整链路：

4.5 模型设计中的常见陷阱

最后，我分享几个实际项目中踩过的坑：

1. 不要把血缘关系存成属性。 有人把上游字段 ID 放在一个 JSON 数组里，查的时候用 CONTAINS 过滤——这种设计在 10 万条数据时还能用，到了 100 万条直接废了。
2. 注意关系爆炸。 字段级血缘如果每个字段都连到目标字段，边数会呈指数级增长。我建议在表级血缘和字段级血缘之间做个分层：先查表级链路，再展开字段级细节。
3. 历史版本怎么处理？ 血缘不是一成不变的。ETL 改了，字段映射变了，血缘图也得跟着变。我习惯在关系上加 validFrom 和 validTo 时间戳，支持时间旅行查询。