JRY's digital garden

数据血缘与元数据管理

10 min read

数据血缘与元数据管理

数据血缘与元数据管理是工业数据治理框架的”神经系统”——它记录了数据从哪里来、经过了什么处理、到哪里去，以及每个数据资产的含义是什么。当报表上的OEE-设备综合效率数字异常时，数据血缘能帮你追溯到是哪台PLC的传感器出了问题；当工厂数据仓库建模中的模型需要调整时，元数据能告诉你影响范围有多大。

数据血缘的定义与价值

什么是数据血缘

数据血缘（Data Lineage）描述的是数据从源头到终点的完整流转路径。在工厂场景中，一条典型的数据血缘链路是：

PLC传感器信号 
  → OPC UA/MQTT采集 
    → Kafka原始Topic 
      → Flink清洗转换 
        → Kafka清洗后Topic 
          → Doris DWD表 
            → ETL聚合 
              → Doris DWS表 
                → 指标API 
                  → 看板展示

数据血缘的价值

  1. 影响分析：当数据源发生变化时，评估影响范围。例如某PLC地址变更，影响哪些报表和看板
  2. 根因定位：当报表数据异常时，沿血缘链路反向追踪，定位问题环节
  3. 合规审计：证明数据来源可信，处理过程可追溯，满足工业数据安全审计要求
  4. 变更管理：支撑工厂主数据管理中的变更影响评估
  5. 数据资产盘点：全面了解工厂数据资产的全貌

工厂数据血缘的层级

字段级血缘（Column-level Lineage）

最精细的血缘粒度，追踪单个字段的来源和转换：

  • 报表中的oee_value字段来自DWS表的oee字段
  • DWS表的oee字段由DWD表的availability、performance、quality三个字段计算得到
  • DWD表的availability来自Flink作业，从Kafka的device_status Topic消费
  • Kafka的device_status来自数据采集层架构中的OPC UA采集

字段级血缘是最有价值的，但也是最难自动获取的——需要解析SQL、解析代码逻辑。

表级血缘（Table-level Lineage）

追踪表与表之间的依赖关系：

  • DWS层dws_oee_daily依赖DWD层dwd_device_status和dwd_production_report
  • ADS层ads_dashboard_summary依赖多个DWS层表

表级血缘相对容易自动获取——通过解析SQL的FROM和JOIN子句。

应用级血缘（Application-level Lineage）

追踪数据在应用系统之间的流转：

应用级血缘帮助理解系统间的数据依赖关系。

元数据管理

元数据是”描述数据的数据”，分为三大类：

技术元数据

描述数据的技术特征：

  • 表结构：表名、字段名、字段类型、分区策略
  • 存储信息：存储格式、压缩方式、数据量、分区数
  • 调度信息：ETL作业的调度周期、依赖关系、执行时间
  • 数据特征：字段的取值范围、空值率、唯一值数量

业务元数据

描述数据的业务含义：

  • 业务名称和描述：oee_value → “设备综合效率（OEE），等于可用率×性能率×质量率”
  • 业务口径：OEE-设备综合效率的计算公式和参数说明
  • 指标定义：良率-Yield是否包含返工品的明确定义
  • 业务分类：属于哪个主题域（设备/生产/质量/物料/能耗）
  • 数据所有者：业务负责人和数据管家
  • 关联主数据：关联工厂主数据管理中的哪个实体

操作元数据

描述数据的使用和运维信息：

  • 执行记录：ETL作业的每次执行时间、耗时、状态
  • 数据产出时间：每个表最近一次数据更新的时间
  • 质量检测记录：每次质量检测的结果和问题
  • 访问日志：谁在什么时间查询了什么数据
  • 变更历史：表结构、计算逻辑的变更记录

工具选型

Apache Atlas

Apache基金会开源的元数据管理和数据治理平台：

优势：

  • 与Hadoop生态深度集成（Hive、HBase、Kafka、Spark等）
  • 支持自动血缘采集（通过Hook机制）
  • 内置分类、标签、搜索功能
  • REST API完善

劣势：

  • UI较为粗糙
  • 对非Hadoop生态的数据源支持有限
  • 部署和维护复杂度较高
  • 对Flink、Doris等工厂常用组件需要自研集成

DataHub

LinkedIn开源的现代元数据平台：

优势：

  • 现代化的架构和UI
  • 支持丰富的数据源集成
  • 良好的扩展性，支持插件式集成
  • 活跃的社区

劣势：

  • 部署依赖较多（Kafka、Elasticsearch等）
  • 字段级血缘需要额外配置
  • 对于工业场景的特定需求需要定制

自研方案

对于有技术能力的团队，可以考虑基于开源组件自研：

核心功能模块：

  • 元数据采集服务：对接各种数据源，自动采集表结构和字段信息
  • SQL解析引擎：解析ETL SQL，自动构建字段级血缘
  • 血缘图谱存储：使用Neo4j等图数据库存储血缘关系
  • 元数据门户：提供搜索、浏览、可视化的Web界面
  • API服务：提供元数据和血缘查询的API

工厂场景的定制需求：

  • 支持OPC UA地址、MQTT Topic等工业数据源的元数据采集
  • 支持Flink作业的血缘解析（解析Flink SQL或DataStream API）
  • 支持设备-采集点-字段的层级血缘（设备 → PLC地址 → Topic → 表 → 字段）
  • 与工业数据质量系统的联动（质量问题在血缘图上标注）

血缘自动采集的实现

SQL血缘解析

通过解析SQL语句自动构建血缘：

  • SELECT 子句的列 → 目标字段
  • FROM 和 JOIN 子句的表 → 源表
  • WHERE 和 GROUP BY 提供过滤和聚合信息
  • 可使用Apache Calcite或自研SQL Parser

Flink作业血缘

Flink SQL的血缘解析方式：

  • 解析Flink SQL的DML语句
  • 通过Flink的Catalog API获取表结构信息
  • 对于DataStream API，需要在代码中添加血缘注解

端到端血缘

将不同组件的血缘片段拼接成端到端链路：

  • Kafka Topic作为连接点：Flink作业的输出Topic = 下游作业的输入Topic
  • 统一使用规范化命名：Topic名、表名中包含数据域和层级信息
  • 在元数据平台中维护组件间的连接关系

实施建议

  1. 从表级血缘开始：先实现表级血缘，覆盖核心数据链路，再逐步细化到字段级
  2. 覆盖关键路径：优先覆盖”采集→数仓→报表”和”采集→实时→看板”两条核心路径
  3. 结合数据质量：在血缘链路上标注工业数据质量评分，实现质量问题的影响分析
  4. 自动化优先：尽量自动采集血缘信息，减少人工维护
  5. 定期验证：定期验证血缘信息的准确性，及时发现和修正错误

数据血缘与元数据管理是数据治理的基础设施。有了完整的血缘链路和丰富的元数据，工厂的数据才能真正成为”可信赖、可追溯、可管理”的数据资产，为智能制造概述与工业4.0的深入推进提供坚实的数据底座。

Graph View

Backlinks