📚 课程目录第3章血缘元数据模型

3、血缘元数据模型：元数据采集范围、元数据存储结构（图数据库 vs 关系型数据库）

血缘元数据模型是工程分析平台中数据血缘构建的核心骨架。它定义了“采集什么”、“存在哪里”以及“如何查询”三个关键问题。本章从元数据采集范围出发，对比图数据库与关系型数据库在血缘存储上的优劣，并给出选型建议。

3.1 元数据采集范围

血缘分析依赖的元数据并非单一类型，而是覆盖从数据源到消费端的全链路信息。根据采集对象，可分为以下四大类：

类别	采集对象	典型内容	采集方式
技术元数据	数据源、表、字段、分区	库名、表名、字段类型、主键、外键、分区键、存储路径	JDBC/ODBC 扫描、Hive Metastore API、文件系统遍历
作业元数据	ETL 任务、调度任务、SQL 脚本	任务 ID、调度时间、输入/输出表、SQL 文本、执行计划	日志解析、调度系统 API、SQL 解析器
数据血缘元数据	字段级依赖、表级依赖、转换逻辑	源字段→目标字段映射、函数调用、过滤条件、聚合逻辑	SQL 解析（AST 分析）、运行时拦截、手动标注
业务元数据	数据字典、业务术语、数据质量规则	字段业务含义、枚举值说明、数据质量约束、数据分类分级	人工录入、数据治理平台导入

实践建议： 初期优先采集技术元数据和作业元数据，血缘元数据通过 SQL 解析自动生成；业务元数据可在平台上线后逐步补充，避免因采集范围过大导致项目延期。

3.2 元数据存储结构：图数据库 vs 关系型数据库

血缘数据本质上是“节点-边”结构（节点为表/字段，边为依赖关系），传统关系型数据库（RDBMS）与图数据库（Graph DB）在存储和查询上存在显著差异。下表从多个维度进行对比：

对比维度	关系型数据库（如 MySQL、PostgreSQL）	图数据库（如 Neo4j、JanusGraph）
数据模型	表 + 外键关联，血缘关系需通过 JOIN 表实现	节点 + 边，血缘关系天然为图结构
多跳查询性能	深度超过 3 层时 JOIN 性能急剧下降，需递归 CTE 或多次查询	原生支持深度遍历，n 跳查询性能与跳数近似线性
字段级血缘	需额外设计字段映射表，查询复杂	字段作为节点，字段间边直接表达映射关系
变更管理	表结构变更需 DDL 操作，历史版本维护成本高	节点/边可带时间戳属性，支持多版本快照
查询语言	SQL（标准，生态成熟）	Cypher / Gremlin / SPARQL（需学习成本）
事务与一致性	强 ACID，适合精确计费、元数据管理	多数为最终一致性，部分支持 ACID（如 Neo4j）
运维复杂度	低，DBA 技能普遍	较高，需掌握图数据库集群、索引调优
适用场景	元数据管理、数据字典、批量血缘统计	交互式血缘溯源、影响分析、全链路可视化

3.3 混合存储架构

在实际工程中，单一存储往往无法满足所有需求。推荐采用“关系型数据库 + 图数据库”混合架构，各取所长：

关系型数据库：存储元数据基础信息（表结构、字段定义、作业配置、数据质量规则），利用 ACID 特性保证数据一致性，支持复杂统计查询。
图数据库：存储血缘关系（表级依赖、字段级映射），提供毫秒级的多跳查询，支撑前端血缘图谱的交互式探索。

数据同步策略：通过 CDC（变更数据捕获）或定时任务，将关系型数据库中的元数据变更同步至图数据库，保持血缘关系的时效性。

  架构要点： 关系型数据库作为“元数据事实库”，图数据库作为“血缘关系查询引擎”。两者通过统一的元数据 ID 关联，避免数据冗余。

3.4 血缘元数据模型结构图

下图展示了混合存储架构下的核心数据模型，包含节点类型、边类型以及存储分配：

3.5 字段级血缘存储示例

字段级血缘是血缘分析中最精细、也最有价值的粒度。以下分别展示关系型数据库和图数据库的存储方式：

3.5.1 关系型数据库存储（字段映射表）

-- 字段映射表结构
CREATE TABLE field_lineage (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    source_table_id BIGINT NOT NULL,
    source_field_id BIGINT NOT NULL,
    target_table_id BIGINT NOT NULL,
    target_field_id BIGINT NOT NULL,
    transform_expression TEXT COMMENT '转换逻辑，如：CONCAT(a, b)',
    job_id BIGINT COMMENT '产生该血缘的作业ID',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_target (target_table_id, target_field_id),
    INDEX idx_source (source_table_id, source_field_id)
);

-- 查询某个字段的上游血缘（3层）
WITH RECURSIVE upstream AS (
    SELECT source_table_id, source_field_id, 1 AS depth
    FROM field_lineage
    WHERE target_table_id = 101 AND target_field_id = 5
    UNION ALL
    SELECT fl.source_table_id, fl.source_field_id, u.depth + 1
    FROM field_lineage fl
    INNER JOIN upstream u ON fl.target_table_id = u.source_table_id
        AND fl.target_field_id = u.source_field_id
    WHERE u.depth < 10
)
SELECT * FROM upstream;

3.5.2 图数据库存储（Cypher 查询）

// 创建字段节点和血缘边
CREATE (f1:Field {id: 101, name: 'user_id', table: 'ods_user'})
CREATE (f2:Field {id: 102, name: 'user_id', table: 'dwd_order'})
CREATE (f1)-[:MAPS_TO {transform: 'CAST', job: 'etl_job_01'}]->(f2)

// 查询字段 'dwd_order.user_id' 的完整上游血缘
MATCH (target:Field {name: 'user_id', table: 'dwd_order'})
CALL apoc.path.expand(target, 'MAPS_TO>', '+Field', 1, 10)
YIELD path
RETURN path

注意： 关系型数据库的递归 CTE 在深度超过 5 层时性能明显下降，且 SQL 写法复杂；图数据库的 Cypher 查询更直观，且深度遍历性能稳定。如果项目对交互式血缘溯源有强需求，建议优先采用图数据库。

3.6 选型决策矩阵

根据项目阶段和团队能力，可参考以下矩阵进行存储选型：

项目特征	推荐存储	理由
团队无图数据库运维经验，项目周期短	关系型数据库	SQL 生态成熟，DBA 技能普遍，快速上线
需要交互式血缘图谱，深度溯源频繁	图数据库	多跳查询性能优异，可视化集成方便
既有元数据管理需求，又有血缘查询需求	混合架构	各取所长，关系型管事实，图数据库管关系
数据量极大（百亿级节点/边）	分布式图数据库（JanusGraph）	支持水平扩展，可承载超大规模血缘

总结：血缘元数据模型的设计应遵循“采集全面、存储分层、查询高效”的原则。采集范围覆盖技术、作业、血缘、业务四类元数据；存储结构推荐混合架构，以关系型数据库为事实库，图数据库为查询引擎，兼顾数据一致性与查询性能。