数据治理：数据血缘关系分析
数据治理：数据血缘关系分析
此文章由百度的多篇文章归纳总结而成，以供本人学习和记录方便，不做任何商务用途，如有侵权，请联系我删除，谢谢！
参考列表：
微信 - 头哥侃码公众号：数据治理的大方向是Database Mesh？先把数据之间的血缘关系搞明白，咱再吹行吗？
搜狐 - 数据大家：数据之间有血缘关系？数据治理不得不懂的血缘关系梳理方法
知乎 - NBI大数据可视化分析平台: 数据治理中的数据血缘关系是什么？用来解决什么问题
相亲相爱的数据：论数据血缘关系
文章目录
- 数据治理：数据血缘关系分析
- 前言
- 血缘关系概念
- 数据血缘关系的应用场景是什么
- 特有特征
- 数据血缘关系的层次
- 数据血缘关系的可视化
- 举例说明
- 我们如何将数据血缘关系进行可视化呢
- 数据血缘关系分析
- 附 一
前言
数据血缘属于数据治理中的一个概念，是在数据溯源的过程中找到相关数据之间的联系，它是一个逻辑概念。
数据治理里经常提到的一个词就是血缘分析，血缘分析是保证数据融合的一个手段，通过血缘分析实现数据融合处理的可追溯。大数据数据血缘是指数据产生的链路，直白点说，就是我们这个数据是怎么来的，经过了哪些过程和阶段。
血缘关系概念
Data Lineage 数据血统，也叫做Data Provenance 数据起源或Data Pedigree 数据谱系。
任何的数据，从产生、ETL处理、加工、融合、流转，到最终消亡，数据之间自然会形成一种关系。好比人类社会中的人际关系，类似的一种关系来表达数据之间的这种关系，称之为数据的血缘关系。
从技术角度来讲，数据a通过ETL处理生成了数据b，那么，我们会说，数据a与数据b具有血缘关系。不过与人类的血缘关系略有不同，数据血缘关系还具有一些个性化的特征。
数据血缘关系的应用场景是什么
在数据的处理过程中，从数据源头到最终的数据生成，每个环节都可能会导致我们出现数据质量的问题。比如我们数据源本身数据质量不高，在后续的处理环节中如果没有进行数据质量的检测和处理，那么这个数据信息最终流转到我们的目标表，它的数据质量也是不高的。也有可能在某个环节的数据处理中，我们对数据进行了一些不恰当的处理，导致后续环节的数据质量变得糟糕。因此，对于数据的血缘关系，我们要确保每个环节都要注意数据质量的检测和处理，那么我们后续数据才会有优良的基因，即有很高的数据质量。
特有特征
-
归属性：特定的数据归属特定的组织（或个人），数据具有归属性。
-
多源性：同一个数据可以有多个来源, 一个数据可以是多个数据经过加工而生成的，而且这种加工过程可以是多个。
-
可追溯性: 数据的血缘关系，体现了数据的生命周期，体现了数据从产生到消亡的整个过程，具备可追溯性。
-
层次性: 数据的血缘关系是有层次的。对数据的分类、归纳、总结等对数据进行的描述信息又形成了新的数据，不同程度的描述信息形成了数据的层次。
数据血缘关系的层次
上图描述的是存储在数据库中的结构化数据血缘关系的层次结构，是最典型的一种血缘关系的层次结构。对于不同类型的数据，血缘关系的层次结构有细微的差别。
一般来说，数据都归属于某个组织或者某个人，数据都有所有者。数据在不同的所有者之间流转、融合，形成所有者之间通过数据联系起来的一种关系，是数据血缘关系的一种，在层次结构中处在最上层。这种关系，清楚地表明了数据的提供者和需求者。
数据库、表和字段，是数据的存储结构。不同类型的数据，有不同的存储结构。存储结构决定了血缘关系的层次结构。所以不同类型的数据的血缘关系层次结构有些差别。相对之下，结构化数据血缘关系的层次结构比较简单，对于非结构化数据，如以文件服务器存储的数据来说，血缘关系的层次结构会略有不同,如下图所示
不同层级数据的血缘关系，体现着不同的含义。所有者层次，体现了数据的提供方和需求方，其他的层次则体现了数据的来龙去脉。通过不同层级的血缘关系，可以很清楚地了解数据的迁徙流转，为数据价值的评估、数据的管理提供依据。
数据血缘关系的可视化
根据数据血缘关系的特点，我们设计了数据的血缘关系可视化图形。
当时的规划，是希望通过可视化，将规则、流向分布显示在图形上的不同位置，从而起到如下几个方面的作用：
- 追踪数据溯源：当数据发生异常，帮助追踪到异常发生的原因，平时也能帮助我们追踪数据的来源，追踪数据处理过程。
- 评估数据价值：要对数据价值进行评估，就需要有依据，数据血缘关系，可以从#数据受众、数据更新量级、数据更新# 频次等方面给数据价值的评估提供依据。
- 数据质量评估：数据的血缘关系图上，可以方便的看到数据清洗的标准清单，这个清单反映了对数据质量的要求。
根据表现含义的不同，血缘关系的可视化图形包括5种可视化元素，分布在图形的不同位置。可视化元素分别是：
1.信息节点
信息节点用来表现数据的所有者和数据层次信息或终端信息。根据血缘关系层次的不同，数据信息有所区别。所有者层次只有所有者的信息，其他的层次则包括所有者信息和数据层次信息或者终端信息，例如关系数据库的字段间的血缘关系，该节点的描述信息就是：所有者.数据库.数据表.数据字段。
信息节点有三种类型：主节点，数据流出节点，数据流入节点。
- 主节点只有一个，位于整个图形的中间，是可视化图形的核心节点。图形展示的血缘关系就是此节点的血缘关系，其他与此节点无关的血缘关系都不在图形上展示，以保证图形的简单、清晰。
- 数据流入节点可以有多个，是主节点的父节点，表示数据来源
- 数据流出节点也可以有多个，是主节点的子节点，表示数据的去向；包括一种特殊的节点，即终端节点，终端节点是一种特殊的数据流出节点，表示数据不再往下进行流转，这种数据一般用来做可视化展示。
2.数据流转线路
数据流转线路表现的是数据的流转路径，从左到右流转。数据流转线路从数据流入节点出来往主节点汇聚，又从主节点流出往数据流出节点扩散。
数据流转线路表现了三个维度的信息，分别是方向、数据更新量级、数据更新频次。
- 方向的表现方式，没有做特别的设计，默认从上到下流转；
- 数据更新的量级通过线条的粗细来表现。线条越粗表示数据量级越大，线条越细则表示数据量级越小。
- 数据更新的频次用线条中线段的长度来表现。线段越短表示更新频次越高，线段越长表示更新频次越底，一根实线则表示只流转一次。
3.清洗规则节点
清洗规则节点用来表现数据流转过程中的筛选标准。大量的数据分布在不同的地方，每个地方对数据质量的要求都有所不同，数据接受方会根据自己对数据的要求来过滤接入的数据，这些要求就形成数据标准，并依据这些标准来做数据清洗。
清洗规则可能会有多种。例如要求不能是空值、要求符合某种格式。在可视化图形上，清洗规则用一个标有大写字母“E”的圆圈表示，把各种规则简略化表达，以保证图形的简洁、清晰。查看规则内容的操作也很简单，鼠标移动到标有大写字母“E”的圆圈上，则会自动展示标准清单列表。
清洗规则的简略图形位于数据流转线路上，表示该线路上流转的数据符合这些标准才能继续流转下去。
4.转换规则节点
转换规则节点在表现形式上类似于清洗规则节点，用一个标有大写字母“T”的圆圈表示。位于数据流转线路上，用来表现数据流转过程中发生的变化、变换。
从数据提供方出来的数据，有时候需要进行特殊处理才能接入到数据需求方，这种处理可能比较简单，例如：只是截取源数据的前四位。也可能非常复杂，需要用到特殊的公式。在可视化方面，为了保证图形的简洁、清晰，做了简略处理。查看数据经过了哪些转换规则，也很简单，鼠标移动到标有大写字母“T”的圆圈上，则会自动展示转换规则清单。
5.数据归档销毁规则节点
我们认为数据是有生命周期的，当数据不再具备使用价值，他的生命就结束了，或者归档或者直接销毁。
判断数据是否还具备使用价值非常困难，需要设计一些条件，当这些条件满足了以后，就认为数据不再具有使用价值，可以归档或者销毁了。
举例说明
现在假设你是一名数据开发工程师，为了满足一次业务需求，然后为了生成这张表，可能是处于程序逻辑清晰或者性能优化的考虑，你会使用很多份数据表，也会通过 MR、Spark 或者 Hive 来生产很多中间表。
如下图，是你将花费时间来实现的整个数据流。
- 其中 Table X 是最终给到业务侧的表。
- 蓝色的 Table A-E，是原始数据。
- 黄色的 Table F-I 是你计算出来的中间表。这些表都是你自己写程序要处理的表。
- 然后你为了懒省事，嗯，应该说本着不重复开发的原则，你还要用到同事小伙伴处理的表，Table J 就是别人处理过的结果表。
过了一段时间后，业务侧的同事感觉你提供的数据中有个字段总是不太对劲，其实就是怀疑你的数据出问题！需要你来追踪一下这个字段的来源。
首先你从 Table X 中找到了异常的字段，然后定位到了它来源于 Table I，再从 Table I 定位到了它来源于 Table G， 再从 Table G 追溯到了 Table D，最终发现是某几天的来源数据有异常。
或者说，你从 Table X 定位到了异常的字段原来来自于其它小伙伴处理的表 Table J，然后继续向前回溯，找到了这张表在处理过程中的某一个步出现了问题。
我们如何将数据血缘关系进行可视化呢
方法一： 桑基图
数据血缘关系分析
考虑到数据血缘的重要性和特性，以一般来讲，我们在血缘分析时，会关注应用（系统）级、程序级、字段级三个层次间数据间的关系。比较常见的是，数据通过系统间的接口进行数据的交换和传输。例如下图，银行业务系统中的数据，由统一数据交换平台进行流转分发给传统关系型数据库和非关系型大数据平台，数据仓库和大数据平台汇总后，交流各个应用集市分析使用。其中涉及大量的数据处理和数据交换工作，我们在分析其中的血缘关系时，主要考虑以下几个方面，
- 全面性，数据处理过程实际上是程序对数据进行传递、运算演绎和归档的过程，即使归档的数据也有可能通过其他方式影响系统的结果或流转到其他系统中。为了确保数据流跟踪的连贯性，必须将整个系统集作为分析的对象。
- 静态分析法，本方法的优势是，避免受人为因素的影响，精度不受文档描述的详细程度、测试案例和抽样数据的影响，本方法基于编译原理，通过对源代码进行扫描和语法分析，以及对程序逻辑涉及的路径进行静态分析和罗列，实现对数据流转的客观反映。
- 接触感染式分析法，通过对数据传输和映射相关的程序命令进行筛选，获取关键信息，进行深度分析。
- 逻辑时序性分析法，为避免冗余信息的干扰，根据程序处理流程，将与数据库、文件、通信接口数据字段没有直接关系的传递和映射的间接过程和程序中间变量，转换为数据库、文件、通信接口数据字段之间的直接传递和映射。
- 及时性，为了确保数据字段关联关系信息的可用和及时，必须确保查询版本更新与数据字段关联信息的同步，在整个系统范围内做到“所见即所得”。
附 一
Data provenance 和 Data lineage 区别：
From our experience, data provenance includes only high level view of the system for business users, so they can roughly navigate where their data come from. It’s provided by variety of modeling tools or just simple custom tables and charts. Data lineage is a more specific term and includes two sides - business (data) lineage and technical (data) lineage. Business lineage pictures data flows on a business-term level and it’s provided by solutions like Collibra, Alation and many others. Technical data lineage is created from actual technical metadata and tracks data flows on the lowest level - actual tables, scripts and statements. Technical data lineage is being provided by solutions such as MANTA or Informatica Metadata Manager.
资料来源： What the difference between data provenance and data lineage?