为什么需要数据血缘
- 用于数据价值评估，比如评估表的优先级，计算资源的分配时，下游越多也意味着这个数据节点越重要
- 用于数据治理，比如数据冗余是很常见的情况，通过数据血缘查询就可以知道什么表该删，什么表不能删
- ETL任务异常时的归因分析、影响分析、恢复， 如果存在任务异常或者ETL故障，通过血缘关系可以更快定位异常原因，并且进行影响分析，以及下游受影响节点的快速恢复
- 数据权限管理
- 数据调度依赖管理，比如调度系统中无效任务自动下线、任务链路一键快速恢复
- 用于数据安全审计，针对敏感数据，数据安全-数据泄露-数据合规性需要重点关注。通过血缘分析，基于数据全链路来进行安全审计，可以避免出现下游数据安全等级较低，导致上游部分核心数据泄露。
- 数据标准化监控，如果当前公司制定了基于库、表、字段的命名规范，我们可以通过探查血缘中的所有数据节点，并命名规范进行匹配，得到不符合规范的库、表、字段进行整改(其实基于元数据系统就能实现)
基本概念
-
数据节点, 可以理解为数据流转中的一个个实体，用于承载数据功能业务，包括数据表、业务报表，按照血缘关系划分节点：流出节点-> 中间节点 -> 流入节点
- 流出节点： 数据提供方，血缘关系的源端节点
- 中间节点： 血缘关系中类型最多的节点，既承接流入数据，又对外流出数据。
- 流入节点： 血缘关系的终端节点，一般为应用层，例如可视化报表、仪表板或业务系统
-
节点属性，当前节点的属性信息，例如表名、字段名、所属部门/人、注释等
如何构建数据血缘系统
基本思路：
- 需求调研，确定血缘系统的最细节点粒度，确定实体边界范围，例如节点粒度是否需要精确到字段级，或是表级。
- 构建元数据管理系统。元数据作为血缘的基础，一是用于构建节点间的关联关系，二是用于填充节点的属性，三是血缘系统的应用需要基于元数据才能发挥出最大的价值
- 血缘关系的存储方案选型 - 图数据库
- 血缘关系录入 & 更新技术方案制定，包括新增库表如何同步添加血缘关系，上游变更如何通知下游更新
- 开发血缘可视化平台，支持血缘节点间的链路走向与涉及到的节点属性信息展示、属性修改更新，支持血缘统计分析，从不同层面查看数据的分布与使用情况
- 建立完善监控报警机制，能够快速发现问题。
落地实现
- 评估成本与收益后，确定节点粒度为表级已经满足大多数需求, 实体范围分级为数据库系统 - 库名 - 表名。
- 数据节点分为表节点和任务节点，表节点包括接入的 mysql 表、 hive 表、HBase 表、Kafka topic 映射表、elasticsearch 索引映射表, 任务节点即调度系统中对应的任务，包括 ETL 任务、报表任务等，通常调度任务最终会输出写入一张数据表，对应一个表节点
- 基于
Apache Atlas作为元数据管理系统，Apache Ranger作为数据权限管理系统 - 基于图数据库
neo4j作为血缘存储 - 通过 SQL 解析器可自动化获取到当前表的来源表，并进行血缘关系录入
- 血缘关系更新: 变更的消息送出，当任务的生命周期变化的时候，通过 Hook 把状态变更消息通过调用 API 进行登记或者发送到 MQ 进行解耦，血缘服务收到这份通知之后，再主动调用解析服务来更新这个任务血缘
- 自研血缘可视化平台
元数据管理
元数据定义
数据本身的特定属性，为技术元数据:
- 表的 schema 信息以及字段信息等
- 文件存储信息, 比如文件路径、文件数量、文件大小、文件类型，压缩格式等
- 离线与实时任务中的调度信息, 比如任务名称、任务类型、任务调度时间等
- 血缘信息，数据加工、流转过程产生的数据与数据之间的关系，比如任务之间的上下游关系
业务元数据：
- 统一的指标口径、维度信息、指标计算方式等
- 数据质量信息
- 权限信息
元数据的应用场景
- 数据血缘: 构建数据血缘，进行数据关系探查，用于跟踪数据流经路径，追踪溯源
- 分析理解数据: 通过检索、模糊查询等快速定位到所需数据信息，比如数据存在哪，包含哪些
- 联结数据孤岛: 业务部门开发业务报表、调度任务时可以通过元数据系统快速查到是否已经存在可用的数据，避免数据重复建设的情况
- 数据集成，快速开发: 打通各类开发组件，并且通过元数据管理平台，以数据视角触发各种操作，例如表级调度，权限修改，schema信息修改，提交SQL任务等
- 推动数据治理: 通过元数据管理平台，串联数据链路中的开发人员、管理人员和业务人员，打通多部门，全流程。推动开展数据治理、把控过程、结果验证