4、血缘关系建模：节点与边的设计、属性定义、图数据库选型
好，咱们进入第四章节。前面聊了血缘的采集和解析，数据是捞上来了，但怎么存？怎么让这些关系能被高效查询？这就涉及到建模了。
说白了，血缘关系建模就是决定「用什么形状的网，来兜住这些数据流动的轨迹」。我个人的习惯是，先想清楚节点和边分别代表什么，再考虑往上面挂哪些属性，最后才是选数据库。顺序别搞反了，否则容易返工。
4.1 节点设计：谁是图中的「实体」？
在图里，节点就是实体。在血缘场景里，实体无非这么几类：
- 数据对象：表、字段、文件、Kafka Topic、API 接口。
- 处理过程：ETL 任务、SQL 脚本、存储过程、数据模型转换。
- 组织/系统：数据源系统、应用系统、数据域、责任人。
我建议把节点类型设计成一个枚举标签（Label），而不是用不同的节点标签去硬分。比如在 Neo4j 里，我会给一个节点同时打上 :Table 和 :Field 两个标签，这样既能按类型过滤，又能保留灵活性。
核心原则：每个节点必须有一个全局唯一的业务标识（Business Key），比如 schema.table.column 或者 project.dataset.table。别只用内部 ID，否则审计溯源时你根本对不上业务系统的表。
4.2 边设计：关系的「语义」比方向更重要
边就是关系。血缘里最常见的关系就三种：
- 数据流向：从源表到目标表，从输入字段到输出字段。
- 依赖关系：下游任务依赖上游任务的产出。
- 派生关系：字段 A 经过某种计算变成了字段 B。
嗯，这里要注意。边的方向必须和数据流动方向一致。我曾经在一个项目里看到有人把边方向画反了，结果合规审计时查数据来源，一路追到了反方向，差点把责任认定搞错。
边的类型我一般用枚举值，比如 DERIVED_FROM、DEPENDS_ON、PRODUCES。别用太模糊的词，比如 RELATED_TO，审计人员看了会懵。
4.3 属性定义：时间戳、操作类型、数据质量标签
光有节点和边还不够，你得往上面挂属性，才能回答「谁、什么时候、做了什么、质量怎么样」这些问题。
4.3.1 时间戳
每个节点和边都应该带两个时间戳：
created_at：这条血缘记录首次被采集的时间。last_seen_at：最近一次被观测到的时间。
为什么需要 last_seen_at？因为血缘关系会变。如果某个字段三个月没被任何任务引用，它可能已经废弃了。审计时，我们只关心「在审计时间窗口内活跃的血缘」。
4.3.2 操作类型
操作类型描述的是数据是怎么被处理的。我常用的枚举值：
| 操作类型 | 含义 | 典型场景 |
|---|---|---|
SELECT |
读取 | 查询源表 |
INSERT |
写入 | 加载数据到目标表 |
UPDATE |
更新 | 变更已有记录 |
DELETE |
删除 | 清理数据 |
TRANSFORM |
转换 | 字段映射、聚合计算 |
MERGE |
合并 | 拉链表、SCD 处理 |
操作类型要记录在边上，而不是节点上。因为同一个字段可能被多次读取和写入，操作类型是「这一次关系」的属性。
4.3.3 数据质量标签
这是合规审计里非常关键的一环。我习惯在边上挂一个 quality_tag 字段，取值可以是：
TRUSTED：数据来源可靠，经过校验。UNCERTAIN：数据来源不明，或校验未通过。REJECTED：数据质量不合格，被下游拒绝使用。
一个小技巧：在审计追溯时，如果发现某条路径上的边带有 REJECTED 标签，可以直接判定该路径上的数据不可用于合规报告。这能帮你快速剪枝，不用每条路径都查到底。
4.4 图数据库选型：Neo4j vs JanusGraph
选型这件事，没有银弹。我两个都用过，说说我的感受。
4.4.1 Neo4j：开箱即用，适合中小规模
Neo4j 是我个人用得最多的。它的优势很明显：
- 上手快：Cypher 查询语言非常直观，团队里随便一个会 SQL 的人，半天就能写复杂查询。
- 事务支持好：ACID 特性，适合需要强一致性的合规场景。
- 可视化工具：Neo4j Browser 直接能看到图，审计人员很喜欢。
但它的短板也很突出：水平扩展能力有限。我遇到过单机 Neo4j 存了 5 亿条边之后，写入性能明显下降。如果你公司的血缘数据量在 10 亿条边以内，Neo4j 完全够用。
4.4.2 JanusGraph：分布式，适合超大规模
JanusGraph 是 Apache 基金会下的项目，底层依赖 HBase/Cassandra 做存储，用 Elasticsearch 做索引。它的优势：
- 线性扩展：加机器就能扛更多数据。
- 支持多模型：可以同时存图数据和原始日志。
- 开源免费：没有许可证费用。
但代价是运维复杂度高。我记得第一次搭 JanusGraph 集群，光调优 HBase 的 Region Split 策略就花了一周。而且它的查询语言 Gremlin，学习曲线比 Cypher 陡不少。
4.4.3 选型对比表
| 维度 | Neo4j | JanusGraph |
|---|---|---|
| 部署难度 | 低，单机或集群 | 高，依赖外部存储 |
| 查询语言 | Cypher（类 SQL） | Gremlin（函数式） |
| 事务支持 | 强 ACID | 最终一致性 |
| 水平扩展 | 有限（企业版支持集群） | 原生支持 |
| 适合场景 | 中小规模、快速原型 | 超大规模、高吞吐 |
| 许可证 | 社区版免费，企业版收费 | 完全开源 |
避坑指南：我曾经在一个项目里，因为迷信「分布式一定更好」，选了 JanusGraph 来存只有几千万条边的血缘数据。结果运维成本远超预期，查询延迟也没比 Neo4j 快。后来我学乖了——先评估数据量，再选技术栈。数据量在 10 亿条边以下，优先考虑 Neo4j。
4.5 知识体系总览
下面这张图，把本章的核心逻辑串起来了。你可以把它当作建模时的检查清单。
你看，整个建模过程其实就三步：先定节点类型，再定边的语义，最后往上面挂属性。选型是最后一步，而且一定要基于你的数据量级来决策。
我个人建议，刚开始做血缘项目时，先用 Neo4j 快速跑通原型。等数据量真的上来了，再考虑迁移到 JanusGraph 或者用 Neo4j 企业版做集群。别一开始就上分布式，否则你很可能在调优上花掉比建模多十倍的时间。